From nobody Mon Jan 15 06:21:57 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 2DDF812D7F1; Mon, 15 Jan 2018 06:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 4wLAz464Kw4N; Mon, 15 Jan 2018 06:21:47 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 DD40012D7E2; Mon, 15 Jan 2018 06:21:46 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id a24so10752601otd.4; Mon, 15 Jan 2018 06:21:46 -0800 (PST) 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=8pBrW+GU7fPQRCe7I2i+YMl599G8HEUTUF3rhxyoMv8=; b=jPdtr0AkkEMZnGpfLerOY95psENoL2yK7MatBKFcC21A2/5GJb650a6BQRoxdjf/Ri GsxCEHk5YYWVey5Bm4HxPia52ZscTI8agVzui3h/MpuuipGL7vmvVXaZRzVkKIP7gcZH 7KjSFFSFuc3fGVDWauRWN35F2YBE6wKDXnaxhKe6qhgybzcMvfWJ2weCHiki1gbhbGNL whCSPbDbEujHBNzldvyRr4MjiS6UwpRHligqfXyffO+2w10sTxg2rbQswrvG9QAzLK6y XmSu+qI2INJ/TY8oA80UHs9Xk+TzYoA5LHOUI6Qt+KUMX7FCaYNKyLwqA0KqwrAtcktm vI4g== 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=8pBrW+GU7fPQRCe7I2i+YMl599G8HEUTUF3rhxyoMv8=; b=rEO++phVC5iVYo4vMI4s9tYKcUgbaWriigbok0Jl1mMb3etESSfHJs3mKAUsRBdWDY VytKfdbZcCQ0VLL25VgKgfAQTuEKY9daTcEnchAL5z/jsP3tUgEyRmtA9sIp9QwkKQyA PfeZMq81CpRgJmR4KPmmHiPQx91MXGbdRIoPz0QijlAVDYnEJm9iN2EtVaHHm7KYLjGF xbh6B9LTEx34zc/JKhCVrThS1Sg4H1RztD72dAb8Urng7qfCijQBeBtqJRdcT//KvufM jMuCUjZgXvrUkhq3AI03h0wKgqauRFlQUzJsnAEsM7xJxz0/PqGEQ8GxY0Vmp1EC5kaJ zWZg== X-Gm-Message-State: AKwxytd05mgp+VPDuyXZeNzuzOf2ivtr4wklGYKxSdFmYxM3+VKsYuEi lsOje1uk/v/ruzBBB8Am5dWuBzbDkfZ+4m2Uz/c= X-Google-Smtp-Source: ACJfBouufQZ+C9F7OPe71X2p4pL9LhWxw4s9v4wtxpMBuxLMSGLPCeqDP47/SwcsWuoZ9vGhjlH92Q3sIr2AzHGivLo= X-Received: by 10.157.86.193 with SMTP id b1mr16107001otj.187.1516026105884; Mon, 15 Jan 2018 06:21:45 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Jan 2018 09:21:45 -0500 From: Alvaro Retana In-Reply-To: <45838C7F-F97B-4737-AC1F-CC6BB55BFC8A@ripe.net> References: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> <45838C7F-F97B-4737-AC1F-CC6BB55BFC8A@ripe.net> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Mon, 15 Jan 2018 09:21:45 -0500 Message-ID: To: Terry Manderson , Tim Bruijnzeels Cc: sidr-chairs@ietf.org, Chris Morrow , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, The IESG , sidr@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19d12082f6520562d15552" Archived-At: Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and 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: Mon, 15 Jan 2018 14:21:49 -0000 --94eb2c19d12082f6520562d15552 Content-Type: text/plain; charset="UTF-8" Terry: Hi! Any thoughts on this document? Thanks! Alvaro. On December 22, 2017 at 9:52:21 AM, Tim Bruijnzeels (tim@ripe.net) wrote: Dear Terry, We just uploaded version -10 that we hope addresses your points. This version adds: - explicit text in the abstract stating that this document considers validation under a Trust Anchor only, and that overlaps between multiple TAs are out of scope - three examples using the validation algorithm in this document: 1- Old OID only 2- New OID only 3- A mix of old and new OIDs in a single RPKI tree - the deployment considerations section clearly says discussion still needs to be had, but points at example 3 as a possible deployment scenario Kind regards, Tim Bruijnzeels, and co-authors > On 31 Aug 2017, at 05:29, Terry Manderson wrote: > > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss > > 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-rpki-validation-reconsidered/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for considering the stability of the internet's routing system during > administrative changes to resources. > > One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the > plan that a small amount discussion will resolve it. > > With the definition of the new validation OID (a idea that I like BTW), at any > stage of the certificate issuance can the validation OID be switched? That is a > TA has a particular OID and down the tree an issued certificate has a different > OID? If that can't happen (and please make that clear in the document) is there > plan to migrate the set of all issued certificates to the new OID? and > deprecate the old OID? > > Logically speaking a trust anchor cannot be thought of as over-claiming. (eg > you trust where the self signed cert came from, and its contents) However the > new validation constructs suggest that a TA can over-claim, but it seems like > there won't be any warning (as the example in S4.3) to highlight this possible > eventuality when (in the model where all RIRs issue a TA) a resource is > transferred from one RIR to another for the clients use. Is that interpretation > correct? OR does this new model espouse the belief that all RIRs each issue a > TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean > that RFC6491 should be updated or made historic? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I get the sense that many of the ramifications for this validation change are > yet to be discovered. It worries me that from the shepherd writeup "The > existing CA/RP code implementations will support this once published." What > experiments have been done to identify any gaps and assumptions? > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --94eb2c19d12082f6520562d15552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Terry:

Hi!=C2=A0 Any thoughts on this document?

Thanks!

Alvaro.

On December 22= , 2017 at 9:52:21 AM, Tim Bruijnzeels (tim@= ripe.net) wrote:

Dear Terry,

We just uploaded version -10 that we hope addresses your points.

This version adds:
- explicit text in the abstract stating that this document considers va= lidation under a Trust Anchor only, and that overlaps between multiple TAs = are out of scope
- three examples using the validation algorithm in this document:
1- Old OID only
2- New OID only
3- A mix of old and new OIDs in a single RPKI tree
- the deployment considerations section clearly says discussion still n= eeds to be had, but points at example 3 as a possible deployment scenario

Kind regards,

Tim Bruijnzeels, and co-authors



> On 31 Aug 2017, at 05:29, Terry Manderson <terry.manderson@icann.org> wrote:
> =20
> Terry Manderson has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
> =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.ht= ml
> 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-r= pki-validation-reconsidered/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> DISCUSS:
> ------------------------------------------------------------------= ----
> =20
> Thank you for considering the stability of the internet's rout= ing system during
> administrative changes to resources.
> =20
> One thing isn't quite clear to me, so I'm balloting this a= s a DISCUSS with the
> plan that a small amount discussion will resolve it.
> =20
> With the definition of the new validation OID (a idea that I like = BTW), at any
> stage of the certificate issuance can the validation OID be switch= ed? That is a
> TA has a particular OID and down the tree an issued certificate ha= s a different
> OID? If that can't happen (and please make that clear in the d= ocument) is there
> plan to migrate the set of all issued certificates to the new OID?= and
> deprecate the old OID?
> =20
> Logically speaking a trust anchor cannot be thought of as over-cla= iming. (eg
> you trust where the self signed cert came from, and its contents) = However the
> new validation constructs suggest that a TA can over-claim, but i= t seems like
> there won't be any warning (as the example in S4.3) to highli= ght this possible
> eventuality when (in the model where all RIRs issue a TA) a resour= ce is
> transferred from one RIR to another for the clients use. Is that i= nterpretation
> correct? OR does this new model espouse the belief that all RIRs e= ach issue a
> TA that covers 0/0 and ::/0 in perpetuity? In that construct does = this mean
> that RFC6491 should be updated or made historic?
> =20
> =20
> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
> =20
> I get the sense that many of the ramifications for this validation= change are
> yet to be discovered. It worries me that from the shepherd writeup= "The
> existing CA/RP code implementations will support this once publish= ed." What
> experiments have been done to identify any gaps and assumptions?
> =20
> =20
> =20

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf= .org/mailman/listinfo/sidr
--94eb2c19d12082f6520562d15552-- From nobody Sun Jan 21 17:27:29 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 7D1FC126C19; Sun, 21 Jan 2018 17:27:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151658444250.8179.6286711798902606717.idtracker@ietfa.amsl.com> Date: Sun, 21 Jan 2018 17:27:22 -0800 Archived-At: Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-10: (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: Mon, 22 Jan 2018 01:27:22 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-10: 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-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for adding text into the document that placates my DISCUSS concerns until others look to implement (and use in anger) this in the wild. I'm going to leave a part of my original thoughts on this document here for future reflection: "I get the sense that many of the ramifications for this validation change are yet to be discovered. It worries me that from the shepherd writeup "The existing CA/RP code implementations will support this once published." What experiments have been done to identify any gaps and assumptions?" And further add that the RPKI is starting to appear, in my eyes, exceptionally fragile when faced with operational realities and also quasi-political issues surrounding trust anchors. Without doubt the underpinnings of routing security and integrity is hard, no surprise that this effort (as one of many that has preceded it) also struggles. From nobody Mon Jan 22 01:36:38 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 993A2124B17; Mon, 22 Jan 2018 01:36:36 -0800 (PST) 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 Cu0HaD_cvpXa; Mon, 22 Jan 2018 01:36:34 -0800 (PST) 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 725211243F6; Mon, 22 Jan 2018 01:36:34 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edYWi-0003wb-A8; Mon, 22 Jan 2018 10:36:29 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-180.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edYWh-0000Yl-3P; Mon, 22 Jan 2018 10:36:27 +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: <151658444250.8179.6286711798902606717.idtracker@ietfa.amsl.com> Date: Mon, 22 Jan 2018 10:36:26 +0100 Cc: The IESG , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B10581B-4F2F-45D7-964C-8385EF0B29EA@ripe.net> References: <151658444250.8179.6286711798902606717.idtracker@ietfa.amsl.com> To: Terry Manderson 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 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071984d38c1e99ecd88560ad62c961cf1d7c Archived-At: Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-10: (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: Mon, 22 Jan 2018 09:36:37 -0000 Dear Terry, all, Terry thank you for very much for reviewing. I have two comments to your remaining concerns: > On 22 Jan 2018, at 02:27, Terry Manderson = wrote: >=20 > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-10: 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-rpki-validation-reconside= red/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for adding text into the document that placates my DISCUSS = concerns > until others look to implement (and use in anger) this in the wild. >=20 > I'm going to leave a part of my original thoughts on this document = here for > future reflection: "I get the sense that many of the ramifications for = this > validation change are yet to be discovered. It worries me that from = the > shepherd writeup "The existing CA/RP code implementations will support = this > once published." What experiments have been done to identify any gaps = and > assumptions?=E2=80=9D As I mentioned in this message: https://www.ietf.org/mail-archive/web/sidr/current/msg08596.html The RIPE NCC RPKI Validator has been using the new algorithm since = version 2.17, released 3 July 2014. With one difference: in the RIPE NCC validator the decision to accept = the intersection of validated resources, rather than reject, is a global = configuration setting, rather than a per CA certificate decision. = Changing this code is trivial though once we know which OID to use to = drive the if statement. In terms of analysis: we have done interop testing between our validator = (with the setting turned on) and the other validators and we find no = differences that can be traced back to this. First of all because we = have not yet caught any persistent overclaims in the wild, and secondly = the algorithm we use where we track =E2=80=9CValidated Resource Sets=E2=80= =9D is not semantically different in cases where no actual overclaims = are found. The experiment we have NOT done is to create an actual in-the-wild = over-claiming parent certificate and compare validation notes. This is = not trivial for us because our CA implementation has built-in checks to = prevent this kind of thing. Thanks to your insisting, the document now = describes better what will happen in this case. But in a nutshell: I am = happy to invest time in doing this experiment when we get to the point = of discussing the deployment of validation-reconsidered. > And further add that the RPKI is starting to appear, in my eyes, = exceptionally > fragile when faced with operational realities and also quasi-political = issues > surrounding trust anchors. Without doubt the underpinnings of routing = security > and integrity is hard, no surprise that this effort (as one of many = that has > preceded it) also struggles. This document addresses potential operational issues, that we haven=E2=80=99= t actually seen in the wild. Similarly we invested time and effort to = develop the delta protocol (RRDP) to prevent big issues with rsync = scaling (before they actually become problematic). And recently I have = been asking for the adoption of a working group item (Signed TALs) to = address the issue of TA key rolls - before they become problematic. So, in my opinion, the RPKI standards did not get everything right from = the start, but we can (and do) fix things. In that regard I am also very = happy to see that the SIDROPS WG has an explicit mandate to look at the = operational side of the RPKI and apply lessons learned. Kind regards, Tim From nobody Mon Jan 22 06:31:21 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 5BF39124207; Mon, 22 Jan 2018 06:31:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana.ietf@gmail.com, morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151663147136.8024.15861188767285115207.idtracker@ietfa.amsl.com> Date: Mon, 22 Jan 2018 06:31:11 -0800 Archived-At: Subject: [sidr] Protocol Action: 'RPKI Validation Reconsidered' to Proposed Standard (draft-ietf-sidr-rpki-validation-reconsidered-10.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: Mon, 22 Jan 2018 14:31:11 -0000 The IESG has approved the following document: - 'RPKI Validation Reconsidered' (draft-ietf-sidr-rpki-validation-reconsidered-10.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ Technical Summary This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. The use of this updated procedure is signalled by form of a set of alternative Object Identifiers (OIDs) indicating that the alternative version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484) defined in this document should be used. Furthermore this document provides an alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication requested) validation. Working Group Summary The discussion of this document in the WG was contentious at the start, but it eventually settled and consensus was reached. Document Quality This is not a protocol change, but a mechanics change. The existing CA/RP code implementations will support this once published. Personnel Shepherd: Chris Morrow (morrowc@ops-netman.net) Reponsible AD: Alvaro Retana (aretana@cisco.com) From nobody Mon Jan 29 10:21:26 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 3571712D7F1; Mon, 29 Jan 2018 10:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 WkaKb1Aktt2C; Mon, 29 Jan 2018 10:21:22 -0800 (PST) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 5D44912D7EC; Mon, 29 Jan 2018 10:21:14 -0800 (PST) Received: by mail-ot0-x243.google.com with SMTP id p36so7420854otd.10; Mon, 29 Jan 2018 10:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=4Q3DyewObuN/Uz4IeJtZGJzJLlbpwPbDsaPgMq8k2g4=; b=o3BgMm1Nj43lx8f0ZUmfKvc4PvWhYFVoiWhbYlEzp29Lj4RC2AQ1F83GZnSYnacHFC yv/bjJD42Pm93GBddezQdCvnf6Ug8lHL0cv6/tCUifA5FyEn/4SEv4/FQozs0BmASgKm LTNviFv8n6I8yQv0CDTz9QOOLmt3/GYRy3NRloZyw3jghheBATgEWvHC+J7u/cBfRfPS MF05+bblyr0svHTXywl4tICEGd9yzzxG+xChpANNkH2pJ2wmru4Di3iRGAuclnzS3gpW miRzRZixJt2cOb5eTHpH3FZ8TGTZ+Yme0XKpGd1O9Qsp7AbTIr1jvMniAjO3mXTNH8us pKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=4Q3DyewObuN/Uz4IeJtZGJzJLlbpwPbDsaPgMq8k2g4=; b=ar/Y3sbk++YI5HQ7+iJWwvnW7Wsch3Oi9vmzLCgE00BbjgT6oTLomxmAU24o2Mwemt rIayc45zZpOHEXipIaiabY1OqocJKZliVk2fa6TL1U1u60JO5fUb8HN5FFs9BDBRsZ/w r8TmIBfbAnYKDzZzgEFjJp+RBsHH2jV0OWKiPMgex904bp9q+Kdr3E/ZOh3zqkJJNWi1 CdaKRmCGeflJ1oPkYSlY0F7SPPa9ECJ/SqkcxmUkcToZR5E452VBrxEawzxqYDnrRSv7 g4s+/dYHu3MT+DSV+BE59Ha54Yml3H+MO8bSj22wjuFSYBHi2QQEFyJdE8uNBL9Em5Gx TgOA== X-Gm-Message-State: AKwxytcwTWrhhPtje3vQsJj8JTAlVcACUqB6S9G19FBb1xcfJFJN3dnx +g7FlL+zJvrF7y1TE9LQe5HJVEPkacnoTLcL8eE= X-Google-Smtp-Source: AH8x227IaAqNKCx/+e5e3DYA8pjujOuMijVtjAsQjHcQJwjbRlgW/HB7A2uhTZixywktVMKwYIPPvBrY+/h0HFlLXRA= X-Received: by 10.157.22.220 with SMTP id s28mr19018464ots.317.1517250073509; Mon, 29 Jan 2018 10:21:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Jan 2018 10:21:13 -0800 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Mon, 29 Jan 2018 10:21:13 -0800 Message-ID: To: draft-ietf-sidr-slurm@ietf.org Cc: sidr@ietf.org, sidr-chairs@ietf.org, Chris Morrow Content-Type: multipart/alternative; boundary="001a113e4d2aaac6740563ee4f2a" Archived-At: Subject: [sidr] AD Review of draft-ietf-sidr-slurm-04 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: Mon, 29 Jan 2018 18:21:25 -0000 --001a113e4d2aaac6740563ee4f2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reading this document. I have some comments (below) that should be easy to address =E2=80=94 pleas= e take a look. I need you to address the References before I start the IETF Last Call because of the DownRef to rfc6483. Thanks! Alvaro. Major: M1. Section 3.1: I'm not sure what the Normative result is form this piece of text: "JSON members that are not defined here MUST not be used in SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error." (s/MUST not/MUST NOT) If the not defined members MUST NOT be used, when would the RPs not ignore (or even better, treat as errors) them? IOW, why use SHOULD instead of MUST? M2. Section 4.2: "Before an RP configures SLURM files from different source it MUST make sure there is no internal conflict among the INR assertions in these SLURM files. To do so, the RP SHOULD check the entries of SLURM file..." I think there's a Normative mismatch: "MUST make sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the door open to not always checking -- are there cases when the entries wouldn't be checked *and* the MUST can still be guaranteed? It seems to me like both keywords should be MUST. M3. Section 6: "...but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file." Please indicate that the mechanism to update files, and the authentication/integrity verification are outside the scope of this document. M4. References: M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be Normative. M4.2. I believe the following references should also be Normative: ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7159. M4.3. [minor] Please update the references according to the Nits [1]. [1] https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-si= dr-slurm-04.txt Minor: P1. "Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document." If it's out of scope, then there shouldn't be any Normative language. s/MAY/may P2. "Locally Added Assertions" are sometimes called "Locally Adding Assertions". Nits: N1. s/control make use of RPKI data/control use of RPKI data --001a113e4d2aaac6740563ee4f2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

I just finished reading this document.

I have some comments (below) that shou= ld be easy to address =E2=80=94 please take a look.=C2=A0 I need you to add= ress the References before I start the IETF Last Call because of the DownRe= f to rfc6483.

Thanks!=

Alvaro.



Major:=

M1. Section 3.1: =C2=A0I'm n= ot sure what the Normative result is form this piece of text: "JSON me= mbers that are not defined here MUST not be used in SLURM Files, however Re= lying Parties SHOULD ignore such unrecognized JSON members at the top level= , while any deviations from the specification at lower levels MUST be consi= dered an error." =C2=A0(s/MUST not/MUST NOT) =C2=A0If the not defined = members MUST NOT be used, when would the RPs not ignore (or even better, tr= eat as errors) them?=C2=A0 IOW, why use SHOULD instead of MUST?


M2. Section 4.2: "Before an RP configures SLURM files = from different source it MUST make sure there is no internal conflict among= the INR assertions in these SLURM files.=C2=A0 To do so, the RP SHOULD che= ck the entries of SLURM file..." =C2=A0I think there's a Normative= mismatch: "MUST make sure...no...conflict" vs "SHOULD check= the entries"; the SHOULD leaves the door open to not always checking = -- are there cases when the entries wouldn't be checked *and* the MUST = can still be guaranteed?=C2=A0 It seems to me like both keywords should be = MUST.


M3. Section 6: "...but if the RP update= s its SLURM file over the network, it MUST verify the authenticity and inte= grity of the updated SLURM file." =C2=A0Please indicate that the mecha= nism to update files, and the authentication/integrity verification are out= side the scope of this document.

M4. References:

M4.1. s/I-D.ietf-sidr-bgpsec-overvie= w/rfc8205 =C2=A0...and should be Normative.

M4.2. I believe the following references should also be Normative:= ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7= 159.

M4.3. [minor] Please update th= e references according to the Nits [1].





Minor:
=

P1. "Relying party software MAY mod= ify other forms of output in comparable ways, but that is outside the scope= of this document." =C2=A0If it's out of scope, then there shouldn= 't be any Normative language. s/MAY/may

P2. "Locally Added Assertions" are sometimes called &quo= t;Locally Adding Assertions".


Nits:

N1. s/control make use of RPKI data/control= use of RPKI data
--001a113e4d2aaac6740563ee4f2a-- From nobody Mon Jan 29 12:36:59 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 7EBD8126CF9; Mon, 29 Jan 2018 12:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 EqRDDqxpX2Is; Mon, 29 Jan 2018 12:36:55 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0134.outbound.protection.outlook.com [23.103.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FB412FB27; Mon, 29 Jan 2018 12:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MeyuWJlJzUwQ7h7vpmbn7ZOIDWCBTZ/RN4aQSlrwYNQ=; b=mYT5RctQOGOQhXeOp2UmLgJPeaFXE0mmBvTgeHbkLTY1M/GjqTB3FtqazSfbH/3mP4RbhHtIpm0cFsoT0Z/cbhNVWL9P5eE3KBAGKK6TYspFcRVENXaGtZPUTyPoTixDquKGcXJJ82ZoUenG6JQxyPIHraecFQPiR5tptn6FmCg= Received: from DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) by DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Mon, 29 Jan 2018 20:36:52 +0000 Received: from DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::4017:83d3:c343:fdb6]) by DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::4017:83d3:c343:fdb6%18]) with mapi id 15.20.0444.016; Mon, 29 Jan 2018 20:36:52 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alvaro Retana , "draft-ietf-sidr-slurm@ietf.org" CC: Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Thread-Topic: [sidr] AD Review of draft-ietf-sidr-slurm-04 Thread-Index: AQHTmS4Ff7xRcKiiDUW92yPkN3RlL6OLR8ew Date: Mon, 29 Jan 2018 20:36:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0559; 7:F4aChWy+2CkSRuRvxU82y3a1/cWW69xKj9uRWJX6RfeLadHgP06J6KAlaMZm8NFxDt5IHKoYIyYZkOEKcpYCAcSR+Yk1KP/taUo05uZqfvK+H+5zqRmtVA3BieB+P1MkYFw/agokwBFgrAC2wxtxOP3BXc37NeHx5j+qMdKHpLU4tmMC0DeW7EZnzqvAQIDagnsn7KvXaZ/7Bflhhm7ye00mExLG0hf3M/aCDhGj/YE6xP6MgUqr9drtlZPFwAmW x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(366004)(396003)(39860400002)(199004)(189003)(2906002)(6116002)(86362001)(3846002)(66066001)(186003)(68736007)(3660700001)(3280700002)(14454004)(790700001)(7696005)(2501003)(5250100002)(76176011)(110136005)(54906003)(55016002)(2950100002)(9686003)(106356001)(6306002)(54896002)(26005)(316002)(966005)(5660300001)(236005)(53936002)(59450400001)(2900100001)(105586002)(6246003)(33656002)(81156014)(19609705001)(478600001)(606006)(8936002)(7736002)(6506007)(74316002)(102836004)(229853002)(39060400002)(6436002)(99286004)(81166006)(25786009)(8676002)(4326008)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0559; H:DM2PR09MB0559.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 02af9677-8d14-4d48-6b0f-08d567580759 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM2PR09MB0559; x-ms-traffictypediagnostic: DM2PR09MB0559: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM2PR09MB0559; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0559; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: Cj6AlLw6EzCg61UBsLHe1yPMvuEk5OnGXC/xD7BHdB46Dnu2aAyH9/uxAxCpCBqToAyddFG9w6GJtgSmGbzWSg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB055943E50F1E08DC82BED08484E50DM2PR09MB0559namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 02af9677-8d14-4d48-6b0f-08d567580759 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2018 20:36:51.9626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0559 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 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: Mon, 29 Jan 2018 20:36:57 -0000 --_000_DM2PR09MB055943E50F1E08DC82BED08484E50DM2PR09MB0559namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQsIERpLCBUaW06DQoNClRoZXNlIGFyZSBtaW5vciBjb21tZW50cyBpbiBhbGlnbm1lbnQg d2l0aCBBbHZhcm/igJlzLg0KDQpBbHZhcm8gd3JvdGU6DQoNCj5NNC4gUmVmZXJlbmNlczoNCg0K Pk00LjEuIHMvSS1ELmlldGYtc2lkci1iZ3BzZWMtb3ZlcnZpZXcvcmZjODIwNSAgLi4uYW5kIHNo b3VsZCBiZSBOb3JtYXRpdmUuDQoNCj5NNC4zLiBbbWlub3JdIFBsZWFzZSB1cGRhdGUgdGhlIHJl ZmVyZW5jZXMgYWNjb3JkaW5nIHRvIHRoZSBOaXRzIFsxXS4NCg0KPlsxXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2lkbml0cz91cmw9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXNpZHItc2x1cm0tMDQudHh0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZpZG5pdHMlM0Z1cmwl M0RodHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaWQlMkZkcmFmdC1pZXRmLXNpZHItc2x1 cm0tMDQudHh0JmRhdGE9MDIlN0MwMSU3Q2tvdGlrYWxhcHVkaS5zcmlyYW0lNDBuaXN0LmdvdiU3 Q2M1OTQzMmQxYjIwYjRjZWI0NmE1MDhkNTY3NDUxZThlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2Uw NTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjUyODQ2ODkzMzk1NzE0MSZzZGF0YT01UWJqWmREdVN5 OUNnREhONGdLQVBzSjVFcFJ3SmJGSVZwbjZMaDdkN0QwJTNEJnJlc2VydmVkPTA+DQoNCldpdGgg cmVnYXJkIHRvIHVwZGF0aW5nIHRoZSByZWZlcmVuY2VzLCBJIG5vdGljZWQgdGhhdCB0aGUgZHJh ZnQgcmVmZXJlbmNlcw0KW0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3XSBpbiB0d28gcGxh Y2VzIHdoZXJlIGl0IHNob3VsZCByZWZlcmVuY2UNCkJHUHNlYyBQcm90b2NvbCBTcGVjaWZpY2F0 aW9uIFtSRkMgODIwNV0uICBGb3IgZXhhbXBsZSwgb24gcGFnZSAzOg0KDQooVmFsaWRhdGlvbiBv ZiB0aGUgb3JpZ2luIG9mIGEgcm91dGUgaXMNCiAgIGRlc2NyaWJlZCBpbiBbUkZDNjQ4M10sIGFu ZCB2YWxpZGF0aW9uIG9mIHRoZSBwYXRoIG9mIGEgcm91dGUgaXMNCiAgIGRlc2NyaWJlZCBpbiBb SS1ELmlldGYtc2lkci1iZ3BzZWMtb3ZlcnZpZXddLikNCg0KRm9yIOKAnHZhbGlkYXRpb24gb2Yg dGhlIHBhdGggb2YgYSByb3V0ZeKAnSB0aGUgcG9pbnRlciBzaG91bGQgYmUgU2VjdGlvbiA1IG9m IFJGQyA4MjA1Lg0KDQpBRkFJSywgW0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3XSBpcyBl eHBpcmVkIGFuZCB0aGVyZSBhcmUgbm8gcGxhbnMgdG8gcHVibGlzaCBpdC4NCg0KSSB3b3VsZCBh bHNvIHN1Z2dlc3QgdGhhdCBib3RoIFJGQ3MgNjQ4MyBhbmQgNjgxMSBjYW4gYmUgcmVmZXJlbmNl ZCB3aGVuDQp0YWxraW5nIGFib3V0IOKAnFZhbGlkYXRpb24gb2YgdGhlIG9yaWdpbiBvZiBhIHJv dXRlLuKAnSAgUkZDIDY4MTEgaXMgU3RhbmRhcmRzIFRyYWNrDQp3aGlsZSA2NDgzIGlzIEluZm9y bWF0aW9uYWwuDQoNClRoYW5rcy4NCg0KU3JpcmFtDQo= --_000_DM2PR09MB055943E50F1E08DC82BED08484E50DM2PR09MB0559namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRh dmlkLCBEaSwgVGltOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBhcmUgbWlub3IgY29t bWVudHMgaW4gYWxpZ25tZW50IHdpdGggQWx2YXJv4oCZcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWx2YXJvIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0O000LiBSZWZlcmVuY2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O000LjEuIHMvSS1E LmlldGYtc2lkci1iZ3BzZWMtb3ZlcnZpZXcvcmZjODIwNSAmbmJzcDsuLi5hbmQgc2hvdWxkIGJl IE5vcm1hdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7TTQuMy4gW21pbm9yXSBQbGVhc2UgdXBkYXRlIHRoZSByZWZlcmVuY2VzIGFjY29y ZGluZyB0byB0aGUgTml0cyBbMV0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7WzFdJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmlkbml0cyUzRnVybCUzRGh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZpZCUyRmRyYWZ0LWlldGYtc2lkci1zbHVybS0wNC50eHQmYW1w O2RhdGE9MDIlN0MwMSU3Q2tvdGlrYWxhcHVkaS5zcmlyYW0lNDBuaXN0LmdvdiU3Q2M1OTQzMmQx YjIwYjRjZWI0NmE1MDhkNTY3NDUxZThlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFk ZWMlN0MxJTdDMCU3QzYzNjUyODQ2ODkzMzk1NzE0MSZhbXA7c2RhdGE9NVFialpkRHVTeTlDZ0RI TjRnS0FQc0o1RXBSd0piRklWcG42TGg3ZDdEMCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt aWV0Zi1zaWRyLXNsdXJtLTA0LnR4dDwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldpdGggcmVnYXJkIHRvIHVwZGF0aW5nIHRoZSByZWZlcmVuY2VzLCBJIG5vdGljZWQg dGhhdCB0aGUgZHJhZnQgcmVmZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3XSBpbiB0d28gcGxhY2VzIHdoZXJl IGl0IHNob3VsZCByZWZlcmVuY2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QkdQc2VjIFByb3RvY29sIFNwZWNpZmljYXRpb24gW1JGQyA4MjA1XS4gJm5ic3A7Rm9yIGV4 YW1wbGUsIG9uIHBhZ2UgMzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFZhbGlkYXRpb24gb2Yg dGhlIG9yaWdpbiBvZiBhIHJvdXRlIGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgZGVzY3JpYmVkIGluIFtSRkM2NDgzXSwgYW5kIHZhbGlkYXRpb24g b2YgdGhlIHBhdGggb2YgYSByb3V0ZSBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtc2lkci1iZ3BzZWMtb3Zl cnZpZXddLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIOKAnHZhbGlkYXRpb24gb2YgdGhl IHBhdGggb2YgYSByb3V0ZeKAnSB0aGUgcG9pbnRlciBzaG91bGQgYmUgU2VjdGlvbiA1IG9mIFJG QyA4MjA1LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BRkFJSywgW0ktRC5pZXRmLXNpZHItYmdw c2VjLW92ZXJ2aWV3XSBpcyBleHBpcmVkIGFuZCB0aGVyZSBhcmUgbm8gcGxhbnMgdG8gcHVibGlz aCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBhbHNvIHN1Z2dlc3QgdGhhdCBi b3RoIFJGQ3MgNjQ4MyBhbmQgNjgxMSBjYW4gYmUgcmVmZXJlbmNlZCB3aGVuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50YWxraW5nIGFib3V0IOKAnFZhbGlkYXRpb24gb2Yg dGhlIG9yaWdpbiBvZiBhIHJvdXRlLuKAnSZuYnNwOyBSRkMgNjgxMSBpcyBTdGFuZGFyZHMgVHJh Y2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoaWxlIDY0ODMgaXMgSW5m b3JtYXRpb25hbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TcmlyYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_DM2PR09MB055943E50F1E08DC82BED08484E50DM2PR09MB0559namp_-- From nobody Wed Jan 31 00:39:49 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 7E64813169D; Wed, 31 Jan 2018 00:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 akMAwZ5iMtx0; Wed, 31 Jan 2018 00:39:42 -0800 (PST) Received: from smtpbg132.qq.com (SMTPBG132.QQ.COM [113.108.23.42]) (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 3361D1316A0; Wed, 31 Jan 2018 00:39:38 -0800 (PST) X-QQ-mid: bizesmtp5t1517387951tl3iam7be Received: from [192.168.216.94] (unknown [202.173.9.211]) by esmtp4.qq.com (ESMTP) with id ; Wed, 31 Jan 2018 16:39:10 +0800 (CST) X-QQ-SSF: 00400000004000F0FF30000B0000000 X-QQ-FEAT: pQslgWCixdZFaCkWDG7aZvCm+bE9j7NTpEHG1F/YtT24BdFiYOZ7+pNMRd74P 9PCPzLoRVP61+8lDVm30aC/5dTP6ioubhFk5Ne7S7kZgx6+GokJdfHg1wTeyqfubwqP2M9V fHw8UzbXH+0IhjuWLZzs+CveKFEz02H0U3HVudTR3crkuW1sokmVs+6HFejxm1x0k4KNCA+ zHrvSUUF5YxTI/X6LHbOAm0cnB+Mhk/5sxLOYnuNiCAK5DYCtgHMy0UDjaJVlcHFZAM4yuM UEbhLOzAtwJiOIQBoZxWUkQJcgyYTtZ7blMgLVEucl6xuH X-QQ-GoodBg: 2 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: Date: Wed, 31 Jan 2018 16:39:09 +0800 Cc: Alvaro Retana , "draft-ietf-sidr-slurm@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <15A3BEEB-4A6A-49FB-AF29-3CD53D4EF484@zdns.cn> References: To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb17 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 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, 31 Jan 2018 08:39:48 -0000 Sriram, Thanks for your comments. We authors will update the draft, in response to your suggestions and = comments from the AD. Di > =D4=DA 2018=C4=EA1=D4=C230=C8=D5=A3=AC04:36=A3=ACSriram, Kotikalapudi = (Fed) =D0=B4=B5=C0=A3=BA >=20 > David, Di, Tim: > =20 > These are minor comments in alignment with Alvaro=A1=AFs. > =20 > Alvaro wrote: > =20 > >M4. References: > =20 > >M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be = Normative. > =20 > >M4.3. [minor] Please update the references according to the Nits [1]. > =20 > >[1] = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-s= idr-slurm-04.txt=20 > =20 > With regard to updating the references, I noticed that the draft = references > [I-D.ietf-sidr-bgpsec-overview] in two places where it should = reference > BGPsec Protocol Specification [RFC 8205]. For example, on page 3: > =20 > (Validation of the origin of a route is > described in [RFC6483], and validation of the path of a route is > described in [I-D.ietf-sidr-bgpsec-overview].) > =20 > For =A1=B0validation of the path of a route=A1=B1 the pointer should = be Section 5 of RFC 8205. > =20 > AFAIK, [I-D.ietf-sidr-bgpsec-overview] is expired and there are no = plans to publish it. > =20 > I would also suggest that both RFCs 6483 and 6811 can be referenced = when > talking about =A1=B0Validation of the origin of a route.=A1=B1 RFC = 6811 is Standards Track > while 6483 is Informational. > =20 > Thanks. > =20 > Sriram > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 31 07:20:40 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 43E32131A72; Wed, 31 Jan 2018 07:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 Cq0CaSc77RzL; Wed, 31 Jan 2018 07:20:29 -0800 (PST) Received: from smtpbg328.qq.com (smtpbg328.qq.com [14.17.43.160]) (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 3B9FF12EB3F; Wed, 31 Jan 2018 07:19:02 -0800 (PST) X-QQ-mid: bizesmtp3t1517411933tmy608orw Received: from [192.168.3.3] (unknown [118.247.18.232]) by esmtp4.qq.com (ESMTP) with id ; Wed, 31 Jan 2018 23:18:52 +0800 (CST) X-QQ-SSF: 00400000004000F0FF30000B0000000 X-QQ-FEAT: 41DRBDnXI11/MA2S/plGql3C/O7a0q0wXuN/fi7qkMjMSxodcOSFNNUUT7Moz GbSAmLiZOFUZZFZs8uyVvlgsQrjxGHFeXEC2VwowGWRIzFfAcRXg/EIjueQo0VqTF472ABv a8GopGxpk6MSF8AATwu0BUopKiAOO5z+0N/EpRTYVM6ieDSP48sVaK3KFgQc+Gg3UDH/Tsg ZrlzgKNIvYIk839FwJ2xzawJNtjFZsLzqWgohMnSL53+eRtyRyzOxAEtCBVkPpVG6OmMyQb BnwNXliVvbeJNlSho5Fs/9nJjuetJIVsI393v+nOPnuBCU X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: Date: Wed, 31 Jan 2018 23:18:52 +0800 Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> References: To: Alvaro Retana X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb19 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 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, 31 Jan 2018 15:20:35 -0000 Hi, Alvaro, Thanks for your comments. Please see my responses in lines. > =E5=9C=A8 2018=E5=B9=B41=E6=9C=8830=E6=97=A5=EF=BC=8C02:21=EF=BC=8CAlvar= o Retana =E5=86=99=E9=81=93=EF=BC=9A >=20 > Dear authors: >=20 > I just finished reading this document. >=20 > I have some comments (below) that should be easy to address =E2=80=94 = please take a look. I need you to address the References before I start = the IETF Last Call because of the DownRef to rfc6483. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 > Major: >=20 > M1. Section 3.1: I'm not sure what the Normative result is form this = piece of text: "JSON members that are not defined here MUST not be used = in SLURM Files, however Relying Parties SHOULD ignore such unrecognized = JSON members at the top level, while any deviations from the = specification at lower levels MUST be considered an error." (s/MUST = not/MUST NOT) If the not defined members MUST NOT be used, when would = the RPs not ignore (or even better, treat as errors) them? IOW, why use = SHOULD instead of MUST? >=20 We authors think MUST is better than SHOULD. And we would like to update section 3.1 saying: "This document describes responses in the JSON [RFC7159] format. JSON = members that are not defined here MUST not be used in SLURM Files and = additional top-level members MUST be defined in RFCs that update this = document. Relying parties MUST ignore unrecognized JSON members at the = top level, while any deviations from the specification at lower levels = MUST be considered an error.=E2=80=9D Here is the consideration:=20 The current document describes local exceptions with regards to ROAs and = Router Certificates, which are significant to local control of routing. = The thought here was that we would leave an option for future other = =E2=80=99top-level=E2=80=99 elements to describe local exceptions with = regards to other (future) RPKI objects as long as they have fundamental = effect in routing control , while maintaining backward compatibility. = But this is not explicit in the document as written. The risk here, as = written, is that implementations can just add stuff at will for their = own purpose and we can end up with the same member name being re-used. >=20 >=20 > M2. Section 4.2: "Before an RP configures SLURM files from different = source it MUST make sure there is no internal conflict among the INR = assertions in these SLURM files. To do so, the RP SHOULD check the = entries of SLURM file..." I think there's a Normative mismatch: "MUST = make sure...no...conflict" vs "SHOULD check the entries"; the SHOULD = leaves the door open to not always checking -- are there cases when the = entries wouldn't be checked *and* the MUST can still be guaranteed? It = seems to me like both keywords should be MUST. Yes.=20 You are making sense here.=20 >=20 >=20 > M3. Section 6: "...but if the RP updates its SLURM file over the = network, it MUST verify the authenticity and integrity of the updated = SLURM file." Please indicate that the mechanism to update files, and = the authentication/integrity verification are outside the scope of this = document. Agreed.=20 We are going to add: "Yet the mechanism to update SLURM file to guarantee authentication and = integrity is out of the scope of this document. " Besides, we need to change =E2=80=98source=E2=80=99 to =E2=80=98sources=E2= =80=99 :-) >=20 >=20 > M4. References: >=20 > M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be = Normative. >=20 > M4.2. I believe the following references should also be Normative: = ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and = rfc7159. >=20 > M4.3. [minor] Please update the references according to the Nits [1]. >=20 > [1] = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-s= idr-slurm-04.txt=20 >=20 >=20 Agreed.=20 >=20 > Minor: >=20 > P1. "Relying party software MAY modify other forms of output in = comparable ways, but that is outside the scope of this document." If = it=E2=80=99s out of scope, then there shouldn't be any Normative = language. s/MAY/may Agreed. >=20 > P2. =E2=80=9CLocally Added Assertions" are sometimes called "Locally = Adding Assertions". We authors are going to change 4.1 and 4.2 to say =E2=80=9CLocally Added = Assertions=E2=80=9D because we refer to the elements. The lower case =E2=80=9Clocally adding assertions=E2=80=9D in 3.2 is = fine, because it describes an action. >=20 > Nits: >=20 > N1. s/control make use of RPKI data/control use of RPKI data Agreed. Di= From nobody Wed Jan 31 07:29:22 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 33E5913181E; Wed, 31 Jan 2018 07:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 WkITx1uL-2qJ; Wed, 31 Jan 2018 07:29:10 -0800 (PST) Received: from smtpbg339.qq.com (smtpbg339.qq.com [14.17.44.34]) (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 2EB6F12EB73; Wed, 31 Jan 2018 07:26:21 -0800 (PST) X-QQ-mid: bizesmtp14t1517412374tpelieeq Received: from [192.168.3.3] (unknown [118.247.18.232]) by esmtp4.qq.com (ESMTP) with id ; Wed, 31 Jan 2018 23:26:13 +0800 (CST) X-QQ-SSF: 00400000004000F0FG30000B0000000 X-QQ-FEAT: 5gms5Di3ODjQt/A+ZLWtNltG6OiEjZkezD2IncgPRkVF5pnNXKzYWOK3mJGUo 4PXcSQWG30Gd7H7WzY8Lz+zAyyP6B/dcrms++yQaCca+ZmAcC4OpkmPaTi0oZmY1J3RlPrc b281OnMMge6P+hdftiW1TwMpC8xrsIjpQYB0907HWXWUWDcPitvqs3HcjbgWGqCBZ03QDGc 10Hyu0/thO9fnr0mw6jfsN+pEADblOWxZMms2HEb4KmotqlFUhtc5MGCltdjYD+Otd2V3vQ Ro076B3kg5vzeHy20Ni+fihtrDMakztE8K3GMnxV0B+CXb X-QQ-GoodBg: 2 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: Date: Wed, 31 Jan 2018 23:26:12 +0800 Cc: Alvaro Retana , "draft-ietf-sidr-slurm@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <441F300D-4D67-4EA4-A5F6-1305ABFB872A@zdns.cn> References: To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb3 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 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, 31 Jan 2018 15:29:20 -0000 Sriram, Thanks again for your comments. > =D4=DA 2018=C4=EA1=D4=C230=C8=D5=A3=AC04:36=A3=ACSriram, Kotikalapudi = (Fed) =D0=B4=B5=C0=A3=BA >=20 > David, Di, Tim: >=20 > These are minor comments in alignment with Alvaro=A1=AFs. >=20 > Alvaro wrote: >=20 >> M4. References: >=20 >> M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be = Normative. >=20 >> M4.3. [minor] Please update the references according to the Nits [1]. >=20 >> [1] = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-s= idr-slurm-04.txt=20 >=20 > With regard to updating the references, I noticed that the draft = references > [I-D.ietf-sidr-bgpsec-overview] in two places where it should = reference > BGPsec Protocol Specification [RFC 8205]. For example, on page 3: >=20 > (Validation of the origin of a route is > described in [RFC6483], and validation of the path of a route is > described in [I-D.ietf-sidr-bgpsec-overview].) >=20 > For =A1=B0validation of the path of a route=A1=B1 the pointer should = be Section 5 of RFC 8205. Yes. We should make the change. >=20 > AFAIK, [I-D.ietf-sidr-bgpsec-overview] is expired and there are no = plans to publish it. >=20 > I would also suggest that both RFCs 6483 and 6811 can be referenced = when > talking about =A1=B0Validation of the origin of a route.=A1=B1 RFC = 6811 is Standards Track > while 6483 is Informational. Agreed. RFC 6811 is more competent to talk about Validation of the origin of a = route.=20 Di >=20 > Thanks. >=20 > Sriram > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 31 07:40:07 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 A24F512EC01; Wed, 31 Jan 2018 07:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 iu0NKvc5IJp9; Wed, 31 Jan 2018 07:40:03 -0800 (PST) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 5CC5B12EB34; Wed, 31 Jan 2018 07:39:36 -0800 (PST) Received: by mail-ot0-x243.google.com with SMTP id l5so7650714otj.11; Wed, 31 Jan 2018 07:39:36 -0800 (PST) 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=kv8u9GojQ6CyzRX3TlqefM6LoPY1opt64IVF4s2mNks=; b=IEZ+9GnozbEBiMHqJj8YPvgyfV2mKUyegM9DRZDP9mo3hQ58BpAX5aJp8LIXsR6Rxs /7IDiLIzFkqenEWyDwDXnqnIlRIon9jVtovdM5GC1IDHj6tYDSmksBI/pF+vpBaJGkO7 zeDhEuz+p3HG0Mp6s9NRuBXB8b51BTl17IxnVBD7Hb5NpIWz61boRNm+vfnvj29ux5f/ ef5otOPEQRPdaFFoeXlo4uzG1VMprUW3qX71LjHD3AwKhkNDYN+U06t1uL3u/2sSyxAF hbk/JRLHFlbB5OC5XViGsM7P39fM9cLNYesKtwve59kThqmQblCq27L1iL0yQah6BdtK GJjw== 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=kv8u9GojQ6CyzRX3TlqefM6LoPY1opt64IVF4s2mNks=; b=k3A9Mwtly4zHqMG8ShNU+cJbyNS4+BEz63WAOmK3MBK5H6qU9KzTxWBbO9vAfrAIHj ZvmpkMeTVljkpjj0LBaGnvassfSDMw1+ApTumlUVRx8LjdctYzIxsw2l2E4jj0mnl4UF jc+Dsa2y2BX6lk80uBWZmjd8D9B4qxDderHATikmVX8rCv9A5TZd78x68CVKLXO5pB4P wEXOOY7qjDB2PWO9V/wB3zpcyCYAmwO1+4C9ahgBa4ZqjXqx8sLcYNb3djHSpP7T+Qty rHR558y7/bxECN/uL1ipFwR+Q2iFWszuqtvqX5Rh6sH4LGLzz+m/a4TZC1HgknGNNiPW V/sg== X-Gm-Message-State: AKwxytcFQbGmplA0BALNHZHER45iLwBU4kfVWTbJDez9Wm+cD44H5oBh wBr+NfonBwzEz8JD2ztyRTwYAj61whiQFUtoCN0= X-Google-Smtp-Source: AH8x224vRoozP3zOayfnwqJDApR6s6++Ehb+O+qA5li/IGxvkQ+LYbdJwS6KUdk1VVNYcwz1u7wxT0cOgkRZXMVMoIA= X-Received: by 10.157.34.196 with SMTP id y62mr26001915ota.307.1517413175786; Wed, 31 Jan 2018 07:39:35 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jan 2018 07:39:35 -0800 From: Alvaro Retana In-Reply-To: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> References: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 31 Jan 2018 07:39:35 -0800 Message-ID: To: Di Ma Cc: sidr-chairs@ietf.org, Chris Morrow , sidr@ietf.org, draft-ietf-sidr-slurm@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04f8d65202d7056414499f" Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 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, 31 Jan 2018 15:40:06 -0000 --94eb2c04f8d65202d7056414499f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Di: Hi! Thanks for your prompt reply. I look forward to an updated draft. Alvaro. On January 31, 2018 at 10:18:57 AM, Di Ma (madi@zdns.cn) wrote: Hi, Alvaro, Thanks for your comments. Please see my responses in lines. > =E5=9C=A8 2018=E5=B9=B41=E6=9C=8830=E6=97=A5=EF=BC=8C02:21=EF=BC=8CAlvaro= Retana =E5=86=99=E9=81=93=EF=BC=9A > > Dear authors: > > I just finished reading this document. > > I have some comments (below) that should be easy to address =E2=80=94 ple= ase take a look. I need you to address the References before I start the IETF Last Call because of the DownRef to rfc6483. > > Thanks! > > Alvaro. > > > > Major: > > M1. Section 3.1: I'm not sure what the Normative result is form this piece of text: "JSON members that are not defined here MUST not be used in SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error." (s/MUST not/MUST NOT) If the not defined members MUST NOT be used, when would the RPs not ignore (or even better, treat as errors) them? IOW, why use SHOULD instead of MUST? > We authors think MUST is better than SHOULD. And we would like to update section 3.1 saying: "This document describes responses in the JSON [RFC7159] format. JSON members that are not defined here MUST not be used in SLURM Files and additional top-level members MUST be defined in RFCs that update this document. Relying parties MUST ignore unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error.=E2=80=9D Here is the consideration: The current document describes local exceptions with regards to ROAs and Router Certificates, which are significant to local control of routing. The thought here was that we would leave an option for future other =E2=80=99to= p-level=E2=80=99 elements to describe local exceptions with regards to other (future) RPKI objects as long as they have fundamental effect in routing control , while maintaining backward compatibility. But this is not explicit in the document as written. The risk here, as written, is that implementations can just add stuff at will for their own purpose and we can end up with the same member name being re-used. > > > M2. Section 4.2: "Before an RP configures SLURM files from different source it MUST make sure there is no internal conflict among the INR assertions in these SLURM files. To do so, the RP SHOULD check the entries of SLURM file..." I think there's a Normative mismatch: "MUST make sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the door open to not always checking -- are there cases when the entries wouldn't be checked *and* the MUST can still be guaranteed? It seems to me like both keywords should be MUST. Yes. You are making sense here. > > > M3. Section 6: "...but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file." Please indicate that the mechanism to update files, and the authentication/integrity verification are outside the scope of this document. Agreed. We are going to add: "Yet the mechanism to update SLURM file to guarantee authentication and integrity is out of the scope of this document. " Besides, we need to change =E2=80=98source=E2=80=99 to =E2=80=98sources=E2= =80=99 :-) > > > M4. References: > > M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be Normative. > > M4.2. I believe the following references should also be Normative: ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7159. > > M4.3. [minor] Please update the references according to the Nits [1]. > > [1] https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-si= dr-slurm-04.txt > > Agreed. > > Minor: > > P1. "Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document." If it=E2= =80=99s out of scope, then there shouldn't be any Normative language. s/MAY/may Agreed. > > P2. =E2=80=9CLocally Added Assertions" are sometimes called "Locally Addi= ng Assertions". We authors are going to change 4.1 and 4.2 to say =E2=80=9CLocally Added Assertions=E2=80=9D because we refer to the elements. The lower case =E2=80=9Clocally adding assertions=E2=80=9D in 3.2 is fine, = because it describes an action. > > Nits: > > N1. s/control make use of RPKI data/control use of RPKI data Agreed. Di --94eb2c04f8d65202d7056414499f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Di:

Hi!
=
Thanks f= or your prompt reply.=C2=A0 I look forward to an updated draft.

Alvaro.

On January 31, 2018 at 10:18:57 AM, Di Ma (madi@zdns.cn) wrote:

Hi, Alvaro,

Thanks for your comments.

Please see my responses in lines.

> =E5=9C=A8 2018=E5=B9=B41=E6=9C=8830=E6=97=A5=EF=BC=8C02:21=EF=BC= =8CAlvaro Retana <aretana.ietf= @gmail.com> =E5=86=99=E9=81=93=EF=BC=9A
> =20
> Dear authors:
> =20
> I just finished reading this document.
> =20
> I have some comments (below) that should be easy to address =E2=80= =94 please take a look. I need you to address the References before I star= t the IETF Last Call because of the DownRef to rfc6483.
> =20
> Thanks!
> =20
> Alvaro.
> =20
> =20
> =20
> Major:
> =20
> M1. Section 3.1: I'm not sure what the Normative result is fo= rm this piece of text: "JSON members that are not defined here MUST no= t be used in SLURM Files, however Relying Parties SHOULD ignore such unreco= gnized JSON members at the top level, while any deviations from the specifi= cation at lower levels MUST be considered an error." (s/MUST not/MUST= NOT) If the not defined members MUST NOT be used, when would the RPs not = ignore (or even better, treat as errors) them? IOW, why use SHOULD instead= of MUST?
> =20

We authors think MUST is better than SHOULD.

And we would like to update section 3.1 saying:

"This document describes responses in the JSON [RFC7159] format. = JSON members that are not defined here MUST not be used in SLURM Files and = additional top-level members MUST be defined in RFCs that update this docum= ent. Relying parties MUST ignore unrecognized JSON members at the top level= , while any deviations from the specification at lower levels MUST be consi= dered an error.=E2=80=9D

Here is the consideration: =20
The current document describes local exceptions with regards to ROAs an= d Router Certificates, which are significant to local control of routing. = The thought here was that we would leave an option for future other =E2=80= =99top-level=E2=80=99 elements to describe local exceptions with regards to= other (future) RPKI objects as long as they have fundamental effect in rou= ting control , while maintaining backward compatibility. But this is not ex= plicit in the document as written. The risk here, as written, is that imple= mentations can just add stuff at will for their own purpose and we can end = up with the same member name being re-used.


> =20
> =20
> M2. Section 4.2: "Before an RP configures SLURM files from di= fferent source it MUST make sure there is no internal conflict among the IN= R assertions in these SLURM files. To do so, the RP SHOULD check the entri= es of SLURM file..." I think there's a Normative mismatch: "= MUST make sure...no...conflict" vs "SHOULD check the entries"= ;; the SHOULD leaves the door open to not always checking -- are there case= s when the entries wouldn't be checked *and* the MUST can still be guar= anteed? It seems to me like both keywords should be MUST.

Yes. =20

You are making sense here. =20

> =20
> =20
> M3. Section 6: "...but if the RP updates its SLURM file over = the network, it MUST verify the authenticity and integrity of the updated S= LURM file." Please indicate that the mechanism to update files, and t= he authentication/integrity verification are outside the scope of this docu= ment.

Agreed. =20

We are going to add:

"Yet the mechanism to update SLURM file to guarantee authenticatio= n and integrity is out of the scope of this document. "

Besides, we need to change =E2=80=98source=E2=80=99 to =E2=80=98sources= =E2=80=99 :-)

> =20
> =20
> M4. References:
> =20
> M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be No= rmative.
> =20
> M4.2. I believe the following references should also be Normative:= ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7= 159.
> =20
> M4.3. [minor] Please update the references according to the Nits [= 1].
> =20
> [1] https://tools.ietf.org/idnits?url= =3Dhttps://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt =20
> =20
> =20

Agreed. =20

> =20
> Minor:
> =20
> P1. "Relying party software MAY modify other forms of output = in comparable ways, but that is outside the scope of this document." = If it=E2=80=99s out of scope, then there shouldn't be any Normative lan= guage. s/MAY/may

Agreed.

> =20
> P2. =E2=80=9CLocally Added Assertions" are sometimes called &= quot;Locally Adding Assertions".

We authors are going to change 4.1 and 4.2 to say =E2=80=9CLocally Adde= d Assertions=E2=80=9D because we refer to the elements.

The lower case =E2=80=9Clocally adding assertions=E2=80=9D in 3.2 is fi= ne, because it describes an action.

> =20
> Nits:
> =20
> N1. s/control make use of RPKI data/control use of RPKI data

Agreed.

Di
--94eb2c04f8d65202d7056414499f--