From nobody Thu Mar 22 10:02:36 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9712E03B for ; Thu, 22 Mar 2018 10:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igGP-F3R0481 for ; Thu, 22 Mar 2018 10:02:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1081127419 for ; Thu, 22 Mar 2018 10:02:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8C45A300A19 for ; Thu, 22 Mar 2018 13:02:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tjf2iy9O0yps for ; Thu, 22 Mar 2018 13:02:20 -0400 (EDT) Received: from dhcp-8e33.meeting.ietf.org (dhcp-8e33.meeting.ietf.org [31.133.142.51]) by mail.smeinc.net (Postfix) with ESMTPSA id 8CB8D3005DF for ; Thu, 22 Mar 2018 13:02:20 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 22 Mar 2018 13:02:21 -0400 To: IETF SIDR X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sidr] draft-ietf-sidrops-signed-tal-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 17:02:28 -0000 Is the intent to use CMS to sign the trust anchor list? Since ROAs are = signed with CMS, I was expecting these signatures to follow the same = convention. However, there is no reference to CMS in the draft. Russ From nobody Thu Mar 22 10:07:21 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A2912704A for ; Thu, 22 Mar 2018 10:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NzJfhxoWyqT for ; Thu, 22 Mar 2018 10:07:12 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D7E126CF6 for ; Thu, 22 Mar 2018 10:07:12 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ez3gE-0002Fu-8S; Thu, 22 Mar 2018 18:07:11 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-203.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ez3gE-0006Fh-2R; Thu, 22 Mar 2018 18:07:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 22 Mar 2018 17:07:07 +0000 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: <5A5E79B7-4E84-4803-A9EC-4EC2D5719C77@ripe.net> References: To: Russ Housley X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b04c294aa7d41d88954ae004801c0171 Archived-At: Subject: Re: [sidr] draft-ietf-sidrops-signed-tal-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 17:07:14 -0000 Hi Russ, Yes, this is a CMS object. Section 3 describes this. It=E2=80=99s an = extension of RPKI Signed Object - which is CMS.- and specifies the = relevant content type (3.1) and eContent (3.2). Tim > On 22 Mar 2018, at 17:02, Russ Housley wrote: >=20 > Is the intent to use CMS to sign the trust anchor list? Since ROAs = are signed with CMS, I was expecting these signatures to follow the same = convention. However, there is no reference to CMS in the draft. >=20 > Russ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Thu Mar 22 10:45:00 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63E126579 for ; Thu, 22 Mar 2018 10:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpdqbRRQCi1R for ; Thu, 22 Mar 2018 10:44:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41921200A0 for ; Thu, 22 Mar 2018 10:44:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A20C2300A1E for ; Thu, 22 Mar 2018 13:44:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qJETGOhxWUiJ for ; Thu, 22 Mar 2018 13:44:54 -0400 (EDT) Received: from dhcp-9a0d.meeting.ietf.org (dhcp-9a0d.meeting.ietf.org [31.133.154.13]) by mail.smeinc.net (Postfix) with ESMTPSA id 5678E3005DF; Thu, 22 Mar 2018 13:44:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <5A5E79B7-4E84-4803-A9EC-4EC2D5719C77@ripe.net> Date: Thu, 22 Mar 2018 13:44:56 -0400 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A5E79B7-4E84-4803-A9EC-4EC2D5719C77@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] draft-ietf-sidrops-signed-tal-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 17:44:59 -0000 Tim: I think that a statement in Section 3 that it uses CMS SignedData = [RFC5652] would make this very clear. Russ > On Mar 22, 2018, at 1:07 PM, Tim Bruijnzeels wrote: >=20 > Hi Russ, >=20 > Yes, this is a CMS object. Section 3 describes this. It=E2=80=99s an = extension of RPKI Signed Object - which is CMS.- and specifies the = relevant content type (3.1) and eContent (3.2). >=20 > Tim >=20 >> On 22 Mar 2018, at 17:02, Russ Housley wrote: >>=20 >> Is the intent to use CMS to sign the trust anchor list? Since ROAs = are signed with CMS, I was expecting these signatures to follow the same = convention. However, there is no reference to CMS in the draft. >>=20 >> Russ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 From nobody Fri Mar 23 00:08:34 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A45C7124239; Fri, 23 Mar 2018 00:08:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152178890862.17651.1945481394806204107@ietfa.amsl.com> Date: Fri, 23 Mar 2018 00:08:28 -0700 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 07:08:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing WG of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI Authors : Di Ma David Mandelberg Tim Bruijnzeels Filename : draft-ietf-sidr-slurm-07.txt Pages : 17 Date : 2018-03-23 Abstract: The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. ISPs can also be able to use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of the RPKI to control its own network while making use of RPKI data. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-07 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-slurm-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 27 02:38:33 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51FB1241FC for ; Tue, 27 Mar 2018 02:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-VPXlDeeNFr for ; Tue, 27 Mar 2018 02:38:29 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7D61200C5 for ; Tue, 27 Mar 2018 02:38:29 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f0l3i-0005dI-6l; Tue, 27 Mar 2018 11:38:27 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-150.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f0l3i-0001kD-2r; Tue, 27 Mar 2018 11:38:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 27 Mar 2018 11:38:15 +0200 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A5E79B7-4E84-4803-A9EC-4EC2D5719C77@ripe.net> To: Russ Housley X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071947dc7c19b3e2858a7847328f6c44d3b2 Archived-At: Subject: Re: [sidr] draft-ietf-sidrops-signed-tal-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 09:38:31 -0000 Hi Russ, all, How about: OLD: A signed TAL is an RPKI signed object, as specified in [RFC6488]. NEW: The signed TAL object uses the standard template for specifying signed objects that can be validated using the RPKI [RFC6488], which is based on Cryptographic Message Syntax (CMS) [RFC5652] as a standard encapsulation format. (Relevant text included and paraphrased from 6488) Tim > On 22 Mar 2018, at 18:44, Russ Housley wrote: >=20 > Tim: >=20 > I think that a statement in Section 3 that it uses CMS SignedData = [RFC5652] would make this very clear. >=20 > Russ >=20 >=20 >> On Mar 22, 2018, at 1:07 PM, Tim Bruijnzeels wrote: >>=20 >> Hi Russ, >>=20 >> Yes, this is a CMS object. Section 3 describes this. It=E2=80=99s an = extension of RPKI Signed Object - which is CMS.- and specifies the = relevant content type (3.1) and eContent (3.2). >>=20 >> Tim >>=20 >>> On 22 Mar 2018, at 17:02, Russ Housley wrote: >>>=20 >>> Is the intent to use CMS to sign the trust anchor list? Since ROAs = are signed with CMS, I was expecting these signatures to follow the same = convention. However, there is no reference to CMS in the draft. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>=20 >=20 >=20 From nobody Tue Mar 27 07:48:15 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726AD12DA27 for ; Tue, 27 Mar 2018 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE9IcEWtQSjM for ; Tue, 27 Mar 2018 07:48:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3421127522 for ; Tue, 27 Mar 2018 07:48:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C6B0B300A12 for ; Tue, 27 Mar 2018 10:48:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LvZAZkvTelXT for ; Tue, 27 Mar 2018 10:48:09 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9CFBA300494; Tue, 27 Mar 2018 10:48:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 27 Mar 2018 10:48:14 -0400 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: <7213DABC-FD92-4FB2-A1BB-7D778A0C7BEE@vigilsec.com> References: <5A5E79B7-4E84-4803-A9EC-4EC2D5719C77@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] draft-ietf-sidrops-signed-tal-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 14:48:14 -0000 Tim: Works for me. Thanks for considering my suggestion. Russ > On Mar 27, 2018, at 5:38 AM, Tim Bruijnzeels wrote: >=20 > Hi Russ, all, >=20 > How about: >=20 > OLD: > A signed TAL is an RPKI signed object, as specified in [RFC6488]. >=20 > NEW: > The signed TAL object uses the standard template for > specifying signed objects that can be validated using the > RPKI [RFC6488], which is based on Cryptographic > Message Syntax (CMS) [RFC5652] as a standard > encapsulation format. >=20 > (Relevant text included and paraphrased from 6488) >=20 > Tim >=20 >=20 >> On 22 Mar 2018, at 18:44, Russ Housley wrote: >>=20 >> Tim: >>=20 >> I think that a statement in Section 3 that it uses CMS SignedData = [RFC5652] would make this very clear. >>=20 >> Russ >>=20 >>=20 >>> On Mar 22, 2018, at 1:07 PM, Tim Bruijnzeels wrote: >>>=20 >>> Hi Russ, >>>=20 >>> Yes, this is a CMS object. Section 3 describes this. It=E2=80=99s an = extension of RPKI Signed Object - which is CMS.- and specifies the = relevant content type (3.1) and eContent (3.2). >>>=20 >>> Tim >>>=20 >>>> On 22 Mar 2018, at 17:02, Russ Housley = wrote: >>>>=20 >>>> Is the intent to use CMS to sign the trust anchor list? Since ROAs = are signed with CMS, I was expecting these signatures to follow the same = convention. However, there is no reference to CMS in the draft. >>>>=20 >>>> Russ >>>>=20 >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Tue Mar 27 20:49:43 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B617120724; Tue, 27 Mar 2018 20:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152220897556.29881.11439165736430017715.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2018 20:49:35 -0700 Archived-At: Subject: [sidr] Ignas Bagdonas' No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 03:49:36 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-sidr-slurm-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few comments: 1. Document uses all capital form of AND for filters containing both prefixes and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 language. 2. s/Route Origination Authorization/Route Origin Authorization 3. If a local assertion is added without a matching filter, does it take priority over existing assertion? 4. The term 'putative TA' has been flagged a couple of times in various reviews as being not known. It does not appear to be formally defined, RFC7730 seems to be the closest source - while it is not formally defined there either. From nobody Wed Mar 28 01:57:28 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E75124C27; Wed, 28 Mar 2018 01:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHcEF4XtvDvy; Wed, 28 Mar 2018 01:57:26 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7ED1200C1; Wed, 28 Mar 2018 01:57:26 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f16tW-0003F2-Ld; Wed, 28 Mar 2018 10:57:23 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-185.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f16tW-0001hF-Ho; Wed, 28 Mar 2018 10:57:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <152220897556.29881.11439165736430017715.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2018 10:57:08 +0200 Cc: The IESG , draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152220897556.29881.11439165736430017715.idtracker@ietfa.amsl.com> To: Ignas Bagdonas X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198f161b6459a3fc2182e779616e55ac4d Archived-At: Subject: Re: [sidr] Ignas Bagdonas' No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 08:57:27 -0000 > On 28 Mar 2018, at 05:49, Ignas Bagdonas wrote: >=20 > Ignas Bagdonas has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few comments: >=20 > 1. Document uses all capital form of AND for filters containing both = prefixes > and ASNs, and filters containing ASNs and SKIs. That is not part of = RFC2119 > language. Emphasis was intended, but lower case =E2=80=98and=E2=80=99 is fine. > 2. s/Route Origination Authorization/Route Origin Authorization ack >=20 > 3. If a local assertion is added without a matching filter, does it = take > priority over existing assertion? No, local assertions are similar to ROA VRPs or Router Certificates = found through validation. They are complementary. > 4. The term 'putative TA' has been flagged a couple of times in = various reviews > as being not known. It does not appear to be formally defined, RFC7730 = seems to > be the closest source - while it is not formally defined there either. I believe the word =E2=80=98putative=E2=80=99 can be dropped. It=E2=80=99s= not like this is special kind of Trust Anchor. Regards Tim >=20 >=20 >=20 From nobody Thu Mar 29 06:45:51 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEC112DA15; Thu, 29 Mar 2018 06:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152233113911.9148.16721220683934829919.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2018 06:45:39 -0700 Archived-At: Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-slurm-07=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 13:45:40 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-slurm-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd write-up says "Internet Standard" but I assume "Proposed Standard" as indicated in the datatracker is correct...? From nobody Fri Mar 30 10:54:27 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 815F812420B; Fri, 30 Mar 2018 10:54:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> Date: Fri, 30 Mar 2018 10:54:24 -0700 Archived-At: Subject: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 17:54:24 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidr-slurm-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The directorate reviews have some good comments, especially about expanding acronyms/defining terms. I think Section 3.3 would benefit from greater clarity about individual components of the JSON array that is the value of the "slurmTarget" element, versus that element itself. (Also, slurmTarget appears to be mandatory, so talking about cases where it is present seems strange, and presumably a nonempty value being present is the desired criterion.) I'm also not entirely sure I understand the intended semantics -- when first introduced in Section 3.2, we say that "all targets MUST be acceptable to the RP". (Presumably that includes both ASN and FQDN entries.) Does this mean that if the same SLURM file is provided to multiple RPs, those RPs both need to be "responsible for" all the ASNs and FQDNS contained therein? Would this present a limit on the ability to reuse SLURM files for multiple recipients within a single administrative domain (that may span multiple ASNs and FQDNs)? Some editorial suggestions follow. Abstract: OLD: [...] ISPs can also be able to use the RPKI to validate the path of a BGP route. NEW: [...] ISPs can also use the RPKI to validate the path of a BGP route. Section 3.2 OLD: o A SLURM Version indication that MUST be 1 NEW: o A SLURM Version indication. This document specifies version 1. Also, in * Zero or more target elements. In this version of SLURM, there are two types of values for the target: ASN or Fully Qualified Domain Name(FQDN). If more than one target line is present, all targets MUST be acceptable to the RP. What's the difference between a target element and a target line? Section 3.5 (both subsections): "is locally configured with" does not mention SLURM at all as being involved in that configuration; perhaps it should. Section 4.2 [...] To do so, the RP MUST check the entries of SLURM file with regard to overlaps of the INR assertions and report errors to the sources that created these SLURM files in question. The "report errors to the sources" part seems ineligible for MUST-level requirement. Also, in case of conflict, does the "MUST NOT use them" apply to all SLURM files, only the ones with directly conflicting inputs, or only enough files to remove the conflict? Section 6 I'm always a little sad to see security-relevant functionality (such as the transport with authenticity and integrity protection of SLRUM files over the network) left as out of scope with no examples of reasonable usage given. I also wonder if we would benefit from a little discussion of the potential routing issues that could arise from using a "broken" (or deliberately adversarial) SLURM file, though I expect that the target audience is probably pretty familiar with these already. From nobody Fri Mar 30 11:49:51 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF581243F6; Fri, 30 Mar 2018 11:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBj06QpdbCRk; Fri, 30 Mar 2018 11:49:42 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9661241F3; Fri, 30 Mar 2018 11:49:42 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id p33-v6so4033983otp.11; Fri, 30 Mar 2018 11:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=inbfv7kElDz00+UkSOvLxs04Y+VIug200S2qhABs6fs=; b=ePQeLNCbJjIbCM6nFWT423olvunudAETPTw0fLXJQdOJAOo67NZiMtLbaXGwJxv1DY YpYF0P0FeT2d4LzI68zd3wsS0blHqoUd8Ugg5Gt/llfPYxyYhnckX1RxyUanC1CFucoz 6/46kYazLZOOHUTzcACHwjcZViYDIJme10KkL9dEu/e/pXI0sCS0UezLcKfXWZ/rprPG UjYZt675t3znD/hKPzUIgO/HDw4jsdlTgZiAdLMogqm93rQGuYDTCK1midYd3zI6c46/ pS4irj5lTbJeziAsxavveuRu5qRmwVRBUL9x3esGLtt6rz92loQjMeAGhMd+NqaFDXMz 39FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=inbfv7kElDz00+UkSOvLxs04Y+VIug200S2qhABs6fs=; b=tkESNyqPemOkni+dSc02x8weStpCnyhLLSe6vFYSYQugxPkji8I3PyV4J/rSQfmD2J /LZ+YRN+3pExEW3T78Rx47u21VkC+GLyVtSAdV4jbDLv+UoLgsO1ablLf1+MBq//Ho55 2sMnUj9i6Tj7/ym9h564T8iG4WWQcFtijqA/zPcH5sxqKD/2EGU+Mfv54+gWuWcNtTFn KBRgsgcmnbzbtMBDSz12piYXwQaOCK0MuV2WSliLqWBUUZcNdSsIuzmJI792BGlH7qLS hQAvDuYTbByxqo9KbsVqakcx4cr+3w6/acdeYYTEWZllQZgnVWAEdJHPPChv38oq19fY JjRg== X-Gm-Message-State: ALQs6tDe33QvZutETsKYQD/Nfoh+GV5PTiY7/Vh7P8DTPq31iZTCK2lH fCVfdU43N+Xn9qcU5m3kwMhdSAQQkmZP0jjBjZQ= X-Google-Smtp-Source: AIpwx4/VIgPkV+k0tEzeZQsYsXvDn8BD8DLJp20kEobhQWDFgb/rpyRVi8tTmaMgCIsV+QXMWLmOnGZQew9ruGCHVek= X-Received: by 2002:a9d:16f3:: with SMTP id s48-v6mr97621ots.304.1522435781890; Fri, 30 Mar 2018 11:49:41 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 30 Mar 2018 14:49:41 -0400 From: Alvaro Retana In-Reply-To: <152233113911.9148.16721220683934829919.idtracker@ietfa.amsl.com> References: <152233113911.9148.16721220683934829919.idtracker@ietfa.amsl.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Fri, 30 Mar 2018 14:49:41 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG Cc: sidr-chairs@ietf.org, Chris Morrow , sidr@ietf.org, draft-ietf-sidr-slurm@ietf.org Content-Type: multipart/alternative; boundary="000000000000f915af0568a5b3c5" Archived-At: Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-sidr-slurm-07=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 18:49:45 -0000 --000000000000f915af0568a5b3c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On March 29, 2018 at 3:45:39 PM, Mirja K=C3=BChlewind (ietf@kuehlewind.net) wrote: The shepherd write-up says "Internet Standard" but I assume "Proposed Standard" as indicated in the datatracker is correct...? Yes, it is a PS. Alvaro. --000000000000f915af0568a5b3c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 29, 2018 at 3:45:39 PM, Mirja K=C3=BChle= wind (ietf@kuehlewind.net) wrote= :

=
The shepherd write-up says "Internet Standard"= but I assume "Proposed Standard"=C2=A0
as indicated in the datatracker is correct...= ?=C2=A0
=

<= /div>
Yes, i= t is a PS.

Alvaro.
--000000000000f915af0568a5b3c5-- From nobody Fri Mar 30 12:50:05 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07B2126CD8; Fri, 30 Mar 2018 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyiY_BWrUxIA; Fri, 30 Mar 2018 12:49:50 -0700 (PDT) Received: from out20-3.mail.aliyun.com (out20-3.mail.aliyun.com [115.124.20.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8D6124E15; Fri, 30 Mar 2018 12:49:47 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.07866272|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03302; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.BVd.fjI_1522439379; Received: from 192.168.3.3(mailfrom:madi@rpstir.net fp:117.100.109.111) by smtp.aliyun-inc.com(10.147.41.120); Sat, 31 Mar 2018 03:49:41 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> Date: Sat, 31 Mar 2018 03:49:39 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D527078-A80E-4B45-AD81-CA4F840686E9@rpstir.net> References: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 19:49:54 -0000 Benjamin, Thanks very much for your comments. I will exchange notes with co-authors on your editorial suggestions. Yet as for your question about slurmTarget, here is the explanation. First of all, the FQDN is used by the SLURM file distributor to = determine which RP will use this slurm file, noting that RP is = identified by FQDN.=20 People might think this design is sort of redundancy, arguing that if = the SLURM file distributor does not want a specific RP to effect SLURM, = just not do that, why bother to throw this file to that RP, indicating = =A1=AFthis file is not for you=A1=AF. The reason why we do this is to provide the scalability for SLURM in = operations. Given a SLURM file distributor service several RPs and SLURM file need = to change at times to reflect local policy.=20 An easy to do so is that all the registered RPs simply synchronize with = SLURM file distributor, telling from the slurmTarget to decide whether = to effect =A1=AEa specific version=A1=AF of slurm file 'this time'.=20 All in all, to answer your question, if the same SLURM file is provided = to multiple RPs, those RPs identified by FQDN, will first to see whether = =A1=AEthis version=A1=AF of slurm file is for itself 'this time'.=20 And then an RP uses this slurm file to form different views for = different BGP speakers as specified by slrumtarget ASN. BTW, as stated in the document, if the operator does not want to use = slrumtarget =A1=AEhostname=A1=AF to gain management granularity, just = not put it into a slrumtarget element. I hope my clarification is making sense here. Di > Does this mean that if the same SLURM file is > provided to multiple RPs, those RPs both need to be "responsible > for" all the ASNs and FQDNS contained therein? Would this present a > limit on the ability to reuse SLURM files for multiple recipients > within a single administrative domain (that may span multiple ASNs > and FQDNs)? Di Ma RPSTIR https://bgpsecurity.net > =D4=DA 2018=C4=EA3=D4=C231=C8=D5=A3=AC01:54=A3=ACBenjamin Kaduk = =D0=B4=B5=C0=A3=BA >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The directorate reviews have some good comments, especially about = expanding > acronyms/defining terms. >=20 > I think Section 3.3 would benefit from greater clarity about = individual > components of the JSON array that is the value of the "slurmTarget" = element, > versus that element itself. (Also, slurmTarget appears to be = mandatory, so > talking about cases where it is present seems strange, and presumably = a > nonempty value being present is the desired criterion.) >=20 > I'm also not entirely sure I understand the intended semantics -- > when first introduced in Section 3.2, we say that "all targets MUST > be acceptable to the RP". (Presumably that includes both ASN and > FQDN entries.) Does this mean that if the same SLURM file is > provided to multiple RPs, those RPs both need to be "responsible > for" all the ASNs and FQDNS contained therein? Would this present a > limit on the ability to reuse SLURM files for multiple recipients > within a single administrative domain (that may span multiple ASNs > and FQDNs)? >=20 > Some editorial suggestions follow. >=20 > Abstract: >=20 > OLD: >=20 > [...] ISPs can also be able to use the RPKI to validate the > path of a BGP route. >=20 > NEW: >=20 > [...] ISPs can also use the RPKI to validate the > path of a BGP route. >=20 > Section 3.2 >=20 > OLD: > o A SLURM Version indication that MUST be 1 >=20 > NEW: > o A SLURM Version indication. This document specifies version 1. >=20 > Also, in >=20 > * Zero or more target elements. In this version of SLURM, there > are two types of values for the target: ASN or Fully Qualified > Domain Name(FQDN). If more than one target line is present, > all targets MUST be acceptable to the RP. >=20 > What's the difference between a target element and a target line? >=20 > Section 3.5 (both subsections): >=20 > "is locally configured with" does not mention SLURM at all as being > involved in that configuration; perhaps it should. >=20 > Section 4.2 >=20 > [...] To do so, the RP MUST > check the entries of SLURM file with regard to overlaps of the INR > assertions and report errors to the sources that created these SLURM > files in question. >=20 > The "report errors to the sources" part seems ineligible for > MUST-level requirement. >=20 > Also, in case of conflict, does the "MUST NOT use them" apply to all > SLURM files, only the ones with directly conflicting inputs, or only > enough files to remove the conflict? >=20 > Section 6 >=20 > I'm always a little sad to see security-relevant functionality (such > as the transport with authenticity and integrity protection of SLRUM > files over the network) left as out of scope with no examples of > reasonable usage given. >=20 > I also wonder if we would benefit from a little discussion of the > potential routing issues that could arise from using a "broken" (or > deliberately adversarial) SLURM file, though I expect that the > target audience is probably pretty familiar with these already. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr