From nobody Thu Feb 1 03:53:12 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 A46B512EC9E; Thu, 1 Feb 2018 03:53:10 -0800 (PST) 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 zSLJShbCRNHA; Thu, 1 Feb 2018 03:53:08 -0800 (PST) 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 7A58E12DA06; Thu, 1 Feb 2018 03:53:08 -0800 (PST) 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.89) (envelope-from ) id 1ehDQM-0008Ed-TJ; Thu, 01 Feb 2018 12:53:04 +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 1ehDQM-0007sx-OL; Thu, 01 Feb 2018 12:53:02 +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, 1 Feb 2018 12:52:48 +0100 Cc: Di Ma , Chris Morrow , draft-ietf-sidr-slurm@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0866B2B2-2758-4BDA-9D28-29D7D041B713@ripe.net> References: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> To: Alvaro Retana 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: 784d7acfe6559f2a0b602ec6519a0719d07a2c841a9967eefb91a0b567bb425c 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: Thu, 01 Feb 2018 11:53:11 -0000 Dear Alvaro, all, I have an addition to Di=E2=80=99s reply to the comments on section 3.1 = (The use of JSON). Sorry for the confusion on this. I was the author insisting on this, but = I have come to realise that there is no good cause for treating = top-level JSON members different from lower level members. The initial = idea was that we could have backwards compatible future additions to = this spec. But as it is, such updates would most likely require changes = deep in the structure as well. Therefore I now propose that the JSON = structure is locked down: This document describes responses in the JSON [RFC7159] format. JSON members that are not defined here MUST NOT be used in SLURM Files. = Relying Parties MUST consider any deviations from the specification an error. = Future additions to the specifications in this document MUST use an = incremented value for the =E2=80=9CslurmVersion=E2=80=9D member. We will post an updated draft shortly. Tim > On 31 Jan 2018, at 16:39, Alvaro Retana = wrote: >=20 > Di: >=20 > Hi! >=20 > Thanks for your prompt reply. I look forward to an updated draft. >=20 > Alvaro. >=20 > On January 31, 2018 at 10:18:57 AM, Di Ma (madi@zdns.cn) wrote: >=20 >> Hi, Alvaro,=20 >>=20 >> Thanks for your comments.=20 >>=20 >> Please see my responses in lines.=20 >>=20 >> > =E5=9C=A8 2018=E5=B9=B41=E6=9C=8830=E6=97=A5=EF=BC=8C02:21=EF=BC=8CAl= varo Retana =E5=86=99=E9=81=93=EF=BC=9A=20 >> > =20 >> > Dear authors:=20 >> > =20 >> > I just finished reading this document.=20 >> > =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 >> > =20 >> > Thanks!=20 >> > =20 >> > Alvaro.=20 >> > =20 >> > =20 >> > =20 >> > Major:=20 >> > =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 >> > =20 >>=20 >> We authors think MUST is better than SHOULD.=20 >>=20 >> And we would like to update section 3.1 saying:=20 >>=20 >> "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=20 >>=20 >> 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 >>=20 >> > =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.=20 >>=20 >> Yes. =20 >>=20 >> You are making sense here. =20 >>=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.=20 >>=20 >> Agreed. =20 >>=20 >> We are going to add:=20 >>=20 >> "Yet the mechanism to update SLURM file to guarantee authentication = and integrity is out of the scope of this document. "=20 >>=20 >> Besides, we need to change =E2=80=98source=E2=80=99 to =E2=80=98sources= =E2=80=99 :-)=20 >>=20 >> > =20 >> > =20 >> > M4. References:=20 >> > =20 >> > M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be = Normative.=20 >> > =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 >> > =20 >> > M4.3. [minor] Please update the references according to the Nits = [1].=20 >> > =20 >> > [1] = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-s= idr-slurm-04.txt =20 >> > =20 >> > =20 >>=20 >> Agreed. =20 >>=20 >> > =20 >> > Minor:=20 >> > =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=20 >>=20 >> Agreed.=20 >>=20 >> > =20 >> > P2. =E2=80=9CLocally Added Assertions" are sometimes called = "Locally Adding Assertions".=20 >>=20 >> 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.=20 >>=20 >> The lower case =E2=80=9Clocally adding assertions=E2=80=9D in 3.2 is = fine, because it describes an action.=20 >>=20 >> > =20 >> > Nits:=20 >> > =20 >> > N1. s/control make use of RPKI data/control use of RPKI data=20 >>=20 >> Agreed.=20 >>=20 >> Di > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Feb 5 19:00:03 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 C113E124217; Mon, 5 Feb 2018 18:59:56 -0800 (PST) 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.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151788599674.25004.4293551795496190312@ietfa.amsl.com> Date: Mon, 05 Feb 2018 18:59:56 -0800 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-05.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: Tue, 06 Feb 2018 02:59:57 -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-05.txt Pages : 17 Date : 2018-02-05 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. In the future, ISPs also will 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-slurm-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-05 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 Mon Feb 5 19:09:56 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 26DD612DA49; Mon, 5 Feb 2018 19:09:31 -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 OmnOhWjiDp5G; Mon, 5 Feb 2018 19:09:26 -0800 (PST) Received: from smtpbg327.qq.com (smtpbg327.qq.com [14.17.43.158]) (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 C2EFA12DA46; Mon, 5 Feb 2018 19:09:24 -0800 (PST) X-QQ-mid: bizesmtp8t1517886536tuh8c6bq7 Received: from [192.168.216.94] (unknown [202.173.9.211]) by esmtp4.qq.com (ESMTP) with id ; Tue, 06 Feb 2018 11:08:55 +0800 (CST) X-QQ-SSF: 00400000004000F0FG30B00A0000000 X-QQ-FEAT: lRUSrEWtKQDZhYAXFGWC1TMlJKQxkHiHXmaYuUgTOBKat4O/6g4atfNyDT1OU tqB/2kpl/NsBhOOKF2Vy9ChpJbCfyNSS7F8ALmZKHAeyyzTv9K3DlwiKqa56cop7mMG8Wkx ZfPjPg8Oulj6jUQfU34n3AIPXyd8vOtrFwCNofuB++wOIUPcWB1Pq6tmcWBs5CyHJXQLDXj KjU11vix1tDjm2aKsrxnxVjWLO4TxBc8Ms9wSVOJIAlIYn+mQ01ZFo9BhLvYE90Xl8kY8H5 dy5nBJ6HFNI/175+5SXaCps+9uv4QyU4DDOWbZwdUIsOow 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: Tue, 6 Feb 2018 11:08:55 +0800 Cc: Chris Morrow , draft-ietf-sidr-slurm@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E39EC57-A0C2-4CB7-8563-F5D9F9C64291@zdns.cn> References: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb18 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: Tue, 06 Feb 2018 03:09:31 -0000 Hi, Alvaro, A new version (-05) has been submitted for you to review. The draft is updated based on the comments from you and Sriram. And it places a more strict limit on the slurmVersion JOSN member = compared to the previous version by saying: =20 =E2=80=9CFuture additions to the specifications in this document = MUST use an incremented value for the =E2=80=9CslurmVersion=E2=80=9D = member." Di > =E5=9C=A8 2018=E5=B9=B41=E6=9C=8831=E6=97=A5=EF=BC=8C23:39=EF=BC=8CAlvar= o Retana =E5=86=99=E9=81=93=EF=BC=9A >=20 > Di: >=20 > Hi! >=20 > Thanks for your prompt reply. I look forward to an updated draft. >=20 > Alvaro. >=20 > On January 31, 2018 at 10:18:57 AM, Di Ma (madi@zdns.cn) wrote: >=20 >> Hi, Alvaro,=20 >>=20 >> Thanks for your comments.=20 >>=20 >> Please see my responses in lines.=20 >>=20 >> > =E5=9C=A8 2018=E5=B9=B41=E6=9C=8830=E6=97=A5=EF=BC=8C02:21=EF=BC=8CAl= varo Retana =E5=86=99=E9=81=93=EF=BC=9A=20 >> > =20 >> > Dear authors:=20 >> > =20 >> > I just finished reading this document.=20 >> > =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 >> > =20 >> > Thanks!=20 >> > =20 >> > Alvaro.=20 >> > =20 >> > =20 >> > =20 >> > Major:=20 >> > =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 >> > =20 >>=20 >> We authors think MUST is better than SHOULD.=20 >>=20 >> And we would like to update section 3.1 saying:=20 >>=20 >> "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=20 >>=20 >> 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 >>=20 >> > =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.=20 >>=20 >> Yes. =20 >>=20 >> You are making sense here. =20 >>=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.=20 >>=20 >> Agreed. =20 >>=20 >> We are going to add:=20 >>=20 >> "Yet the mechanism to update SLURM file to guarantee authentication = and integrity is out of the scope of this document. "=20 >>=20 >> Besides, we need to change =E2=80=98source=E2=80=99 to =E2=80=98sources= =E2=80=99 :-)=20 >>=20 >> > =20 >> > =20 >> > M4. References:=20 >> > =20 >> > M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be = Normative.=20 >> > =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 >> > =20 >> > M4.3. [minor] Please update the references according to the Nits = [1].=20 >> > =20 >> > [1] = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-s= idr-slurm-04.txt =20 >> > =20 >> > =20 >>=20 >> Agreed. =20 >>=20 >> > =20 >> > Minor:=20 >> > =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=20 >>=20 >> Agreed.=20 >>=20 >> > =20 >> > P2. =E2=80=9CLocally Added Assertions" are sometimes called = "Locally Adding Assertions".=20 >>=20 >> 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.=20 >>=20 >> The lower case =E2=80=9Clocally adding assertions=E2=80=9D in 3.2 is = fine, because it describes an action.=20 >>=20 >> > =20 >> > Nits:=20 >> > =20 >> > N1. s/control make use of RPKI data/control use of RPKI data=20 >>=20 >> Agreed.=20 >>=20 >> Di > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Feb 6 09:48:23 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 EE39A1276AF; Tue, 6 Feb 2018 09:48:21 -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 7VKuLf3ppB4D; Tue, 6 Feb 2018 09:48:18 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 83A6E12D856; Tue, 6 Feb 2018 09:48:17 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id a7so2518403otk.9; Tue, 06 Feb 2018 09:48:17 -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=ftzAbvAelmjfGxGSfBvqDizrF8aQcsjmMjOoRD693tE=; b=TdwIByngbAYoeV05z5pe6eSp8L03hTI4rWlYHoO9fVQcs/+JZ2eUQU2yp7LLR3jgUG cYVe78t2YXiPO/zJ6Wmf08y4vN3LsXQ7SwjM9aKoYiM453YkK58rCUQkRwLXJN9yzeo3 vzeSu6quc26rOqKlp3xx/tXfcOfvgzV8baKNAdP1DX5ZBBPMfmbJu4aaUC4cu3mvq9P8 WS+YYBTD0DJisUUiXT/mZ/qaW8qSEuQ4bxii9WcwmaclG+ZJFtRmAeSHAHo4NyXMq0of SsKZRNtTPm/HVoP4+B/M/2AEGObl+oHj2OX21boYHW94rAZaFuksw122Q0vGilunuOaf +85g== 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=ftzAbvAelmjfGxGSfBvqDizrF8aQcsjmMjOoRD693tE=; b=JnRsVtIlWOzsyEtgLvsop1N2FMNyVo3ZWN3gw7gv3d1egpFikPpvv3vN12l9RBjcpa q/qXeO1DbheHjgNd/CTczyU+TFpJbf8rE90i0YuKDfzvztQhjuDD8CSPQ6NSDTaXm4+3 R4AD0bfYoCYcYSvEyebMDwjbuh8rFRZ7H3cx5RvPsH7RKwgKLF68vLd5n3ogOKop8l5f RfIiB27YZF8G1fzxn+9dYNWR0jeoVTlJlvB9R9nA4+u2Sp51iAdTOvFaUhpNN/64EE4b WVwKIHsLrGmdz9EV0IYhPJg5kAIRFZLi6Z4Xz+nu1I0ix8XxhiVUDgniDKAnr4WgFX+6 YEiw== X-Gm-Message-State: APf1xPDcLw2b238kjUWoEoCC7ean9nEjmvNcuSrYrF2824fG2u/8CP+M Pc/P/6tm9PveAKIj/3anbq9/mJonP3/kLdeFchw= X-Google-Smtp-Source: AH8x224CBVDLB0fW/yX9QlZ3Zz0JKW1FIV00GNYCOeWvnNpY/GulaXiPpkA4a0kRuLvCF3aR/uNFjjYJG17Ut4EvTGw= X-Received: by 10.157.22.242 with SMTP id s47mr2161577ots.317.1517939296976; Tue, 06 Feb 2018 09:48:16 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 09:48:16 -0800 From: Alvaro Retana In-Reply-To: <3E39EC57-A0C2-4CB7-8563-F5D9F9C64291@zdns.cn> References: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> <3E39EC57-A0C2-4CB7-8563-F5D9F9C64291@zdns.cn> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 09:48:16 -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="001a114148c896424a05648ec80b" 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: Tue, 06 Feb 2018 17:48:22 -0000 --001a114148c896424a05648ec80b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On February 5, 2018 at 10:09:18 PM, Di Ma (madi@zdns.cn) wrote: Di: Hi! A new version (-05) has been submitted for you to review. There=E2=80=99s one more change I need you to make before starting the IETF= Last Call. In this latest revision you listed rfc8211 as a Normative Reference (as a replacement of draft-ietf-sidr-adverse-actions, which was listed as Informative). Please move rfc8211 back to Informative. I know this sounds like a nit, but the IETF Last Call explicitly calls out DownRefs (pointing to an Informational document as a Normative Reference in a Standards Track document), which carry additional process=E2=80=A6and in this case it is no= t needed. While you=E2=80=99re at it, please update the reference to rfc7159 -> rfc82= 59. Thanks! Alvaro. --001a114148c896424a05648ec80b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On February 5,= 2018 at 10:09:18 PM, Di Ma (madi@zdns.cn) wrote:


A new versi= on (-05) has been submitted for you to review.

There=E2=80=99s one mor= e change I need you to make before starting the IETF Last Call.

In this latest revision you l= isted rfc8211 as a Normative Reference (as a replacement of=C2=A0draft-ietf= -sidr-adverse-actions, which was listed as Informative).=C2=A0 Please move = rfc8211 back to Informative.=C2=A0 I know this sounds like a nit, but the I= ETF Last Call explicitly calls out DownRefs (pointing to an Informational d= ocument as a Normative Reference in a Standards Track document), which carr= y additional process=E2=80=A6and in this case it is not needed.

While you=E2=80=99re at it, p= lease update the reference to rfc7159 -> rfc8259.

Thanks!

= Alvaro.
--001a114148c896424a05648ec80b-- From nobody Tue Feb 6 17:09:35 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 A4B161242EA; Tue, 6 Feb 2018 17:09:27 -0800 (PST) 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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151796576761.25850.18216365589486116649@ietfa.amsl.com> Date: Tue, 06 Feb 2018 17:09:27 -0800 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-06.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: Wed, 07 Feb 2018 01:09:28 -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-06.txt Pages : 17 Date : 2018-02-06 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. In the future, ISPs also will 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-slurm-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-06 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 Feb 6 17:16:47 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 4D6E01242EA; Tue, 6 Feb 2018 17:16:44 -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 zREORF2apOLU; Tue, 6 Feb 2018 17:16:40 -0800 (PST) Received: from smtpbg352.qq.com (SMTPBG352.QQ.COM [183.57.50.167]) (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 7A75912025C; Tue, 6 Feb 2018 17:16:39 -0800 (PST) X-QQ-mid: bizesmtp13t1517966168ti6ei5iv Received: from [172.20.10.2] (unknown [61.148.244.29]) by esmtp4.qq.com (ESMTP) with id ; Wed, 07 Feb 2018 09:16:07 +0800 (CST) X-QQ-SSF: 00400000004000F0FG40B00A0000000 X-QQ-FEAT: 9DAvgbi4nJzwGzf3DihDZZx7w3JwPbtn/cTSi+K755xNyTCyc0aPs9Y+m5v3n MIO0lm7BtjrOyipVWg0MLOMiE2hGL5KjESLdelcKMgdetsiJNAsUb+6GoIZCjEHcl1igyb3 yOJDnxO0ta7tXDbqEEpCoge3kjGofTEtACajpucq0P8iucRXGdvfq1FUkD8OSo/vd/IMKWO JKtaRf7c+OBJgz7wKuhmiEDSUzgabdlbrH8TPlpMlgh+RgkMZUrihnETXNF+Nmln69MkW5F l+dR7S3XxoubYNdIUiNe9w630= 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, 7 Feb 2018 09:16:06 +0800 Cc: sidr-chairs@ietf.org, Chris Morrow , sidr@ietf.org, draft-ietf-sidr-slurm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> <3E39EC57-A0C2-4CB7-8563-F5D9F9C64291@zdns.cn> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb7 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, 07 Feb 2018 01:16:44 -0000 Hi, Alvaro, Thanks. A new version (-06) has been submitted. Di > =D4=DA 2018=C4=EA2=D4=C27=C8=D5=A3=AC01:48=A3=ACAlvaro Retana = =D0=B4=B5=C0=A3=BA >=20 > On February 5, 2018 at 10:09:18 PM, Di Ma (madi@zdns.cn) wrote: >=20 > Di: >=20 > Hi! >=20 >> A new version (-05) has been submitted for you to review. >=20 > There=A1=AFs one more change I need you to make before starting the = IETF Last Call. >=20 > In this latest revision you listed rfc8211 as a Normative Reference = (as a replacement of draft-ietf-sidr-adverse-actions, which was listed = as Informative). Please move rfc8211 back to Informative. I know this = sounds like a nit, but the IETF Last Call explicitly calls out DownRefs = (pointing to an Informational document as a Normative Reference in a = Standards Track document), which carry additional process=A1=ADand in = this case it is not needed. >=20 > While you=A1=AFre at it, please update the reference to rfc7159 -> = rfc8259. >=20 > Thanks! >=20 > Alvaro. From nobody Wed Feb 7 09:18:05 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 1F40D12D84B; Wed, 7 Feb 2018 09:18:04 -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.72.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-sidr-slurm@ietf.org, aretana.ietf@gmail.com, morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151802388410.4893.5610486270372488576.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 09:18:04 -0800 Archived-At: Subject: [sidr] Last Call: (Simplified Local internet nUmber Resource Management with the RPKI) to Proposed Standard 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, 07 Feb 2018 17:18:04 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Simplified Local internet nUmber Resource Management with the RPKI' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. In the future, ISPs also will 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 20 07:00:39 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 54D3912D873; Tue, 20 Feb 2018 07:00:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Daniel Migault To: Cc: ietf@ietf.org, draft-ietf-sidr-slurm.all@ietf.org, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151913883228.4660.15594261925083651299@ietfa.amsl.com> Date: Tue, 20 Feb 2018 07:00:32 -0800 Archived-At: Subject: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06 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: Tue, 20 Feb 2018 15:00:32 -0000 Reviewer: Daniel Migault Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits: • section 1: Introduction However, an RPKI relying party may want to override some of the information expressed via putative TAs and the certificates It seems that TA is being used for the first time here. The acronym should be extended to ease the reading of the document. I am reading it as Trust Anchor. • section 2. RPKI RPs with SLURM SLURM provides a simple way to enable RPs to establish a local, It seems to me the acronym RP is used for the first time. It seems that it should be expanded to ease the reading of the document. I am reading it as Relaying Party. • section 6 Security considerations I My reading is that the section catches the criticality of the SLURM files and that network operators are already familiar provisioning critical data. As such I believe the section is sufficiently clear. • whole document: It seems that BGPSec, and BGPsec are used together. I believe this should be harmonized to BGPsec. Yours, Daniel From nobody Tue Feb 27 01:18: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 4AFFA1241FC; Tue, 27 Feb 2018 01:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 CC8_aSl4WoWC; Tue, 27 Feb 2018 01:18:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49638124BE8; Tue, 27 Feb 2018 01:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1709; q=dns/txt; s=iport; t=1519723102; x=1520932702; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=98fciRCPdTOOi6URerbn8j7aoKN3eUT4t6iZgUNC82w=; b=lR9XivKa1tpEF3nguK50x7emiv45DqQtO4UKWRwZK2w0PXxAiUtInNq2 wzeODrPnRqvF/QJgNSPUJWRh06QJyVUj3Bi3kLV1S5S8//hbV+nKsuRUf y2IHfDH4mchtsWoheIALhLF7qEjFZvkW5F7izYf8QIjAa3CWv148EPMmV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AwCMIZVa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ1cCgEg1CLFo03AgEBEgEBAQEBAQaBDSKBABuCMpQMCiOFD4M?= =?us-ascii?q?jFAECAQEBAQEBAmsohU1WLwYCJgJfhRcNEKs4gieEcoN+ghQBAQEBAQEEAQEBA?= =?us-ascii?q?QEBAQEBH4EPh0KCLikMgkKCWn8LAoR+MIIyBYgiixeHFQmGUIofgWVOcIJ2iFq?= =?us-ascii?q?Jd4RkgkUCBAsCGQGBLjUhgVFNIxVkAYIZCDWEHT84jSIBAQE?= X-IronPort-AV: E=Sophos;i="5.47,400,1515456000"; d="scan'208";a="2264853" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 09:18:20 +0000 Received: from ams-iwijnand-88112.cisco.com (ams-iwijnand-88112.cisco.com [10.60.202.93]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1R9IKpl028517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2018 09:18:20 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Feb 2018 10:18:19 +0100 Message-Id: <50FD5EF7-509E-4A17-8321-3580EC206612@cisco.com> Cc: rtg-dir@ietf.org, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [sidr] RtgDir review: draft-ietf-sidr-slurm-06 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 Feb 2018 09:18:24 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-sidr-slurm-06=20 Reviewer: IJsbrand Wijnands=20 Review Date: 27-02-2018=20 Intended Status: Standards Track Summary:=20 =E2=80=A2 This document is basically ready for publication, but has nits = that should be considered prior to publication. Comments: This document reads ok. Minor issues: It seems to me it would be useful to have a "Terminology and = Definitions=E2=80=9D section where the various acronyms are defined. = That would help readers who are less familiar in this area (like myself) = to parse the document. Nits: 1. Introduction +++++++++++++++ * What is a "putative TAs=E2=80=9D? Its not declared anywhere. * What is a =E2=80=9CROAs=E2=80=9D? Should there be a RFC reference = here? 2. RPKI RPs with SLURM ++++++++++++++++++++++ * What are =E2=80=9CRPs=E2=80=9D? Its not declared anywhere.=20 3.3. SLURM Target ++++++++++++++++++ * "A SLURM filer=E2=80=9D, is that a filter or file? From nobody Tue Feb 27 03:14: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 49FBD129C6A for ; Tue, 27 Feb 2018 03:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 S6JCwshBVVTM for ; Tue, 27 Feb 2018 03:14:35 -0800 (PST) Received: from smtpproxy19.qq.com (smtpproxy19.qq.com [184.105.206.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB02E1274D2 for ; Tue, 27 Feb 2018 03:14:34 -0800 (PST) X-QQ-mid: bizesmtp5t1519730070t6a1y4rbg Received: from [192.168.3.3] (unknown [117.100.128.114]) by esmtp4.qq.com (ESMTP) with id ; Tue, 27 Feb 2018 19:14:27 +0800 (CST) X-QQ-SSF: 00400000004000F0FG40000A0000000 X-QQ-FEAT: pTE/Q6TrPPeyoiaMIungJVAJjjZZeojkhnuUCrPz72zbUsk/lZDRoEHQnWGkF OJs60jYpeHryq+zmoAgUMarVDJ9bAxBBymDkXewAeM+DPNYCoCjxYuPL44aLIq4Z5iWUxIs eEQO3RI3Wf8rafJaqoaJfpAx7TpN16nB1+FCIaexi1dZi7/DUpEA1fIl63mOGM9uS4jWUpS 8Acjcpu7aW/NF3kmsVFIRntGBRatZpnY6cintXCnheHQz4TzxvjPto4wAOv5tbrS02uRnxe PqtUHY93b16vRXhkuMewgYHDxlbu1VtHUtpQ== 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: <151913883228.4660.15594261925083651299@ietfa.amsl.com> Date: Tue, 27 Feb 2018 19:14:27 +0800 Cc: secdir , ietf@ietf.org, draft-ietf-sidr-slurm.all@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5DC08C9A-C97E-4E8B-918B-A33E6D401FBD@zdns.cn> References: <151913883228.4660.15594261925083651299@ietfa.amsl.com> To: Daniel Migault X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06 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 Feb 2018 11:14:39 -0000 Daniel, Thanks for your review. Please see my responses in lines. > =E5=9C=A8 2018=E5=B9=B42=E6=9C=8820=E6=97=A5=EF=BC=8C23:00=EF=BC=8CDanie= l Migault =E5=86=99=E9=81=93=EF=BC=9A >=20 > Reviewer: Daniel Migault > Review result: Has Nits >=20 > Hi,=20 >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20= > these comments just like any other last call comments. >=20 > The summary of the review is Ready with nits: >=20 > =E2=80=A2 section 1: Introduction >=20 > However, an RPKI relying party may want to override some of the > information expressed via putative TAs and the certificates >=20 > It seems that TA is being used for the first time here. The = acronym > should be extended to ease the reading of the document. I am reading = it=20 > as Trust Anchor. >=20 Yes. We will use Trust Anchor for its first use.=20 >=20 > =E2=80=A2 section 2. RPKI RPs with SLURM >=20 > SLURM provides a simple way to enable RPs to establish a local, >=20 > It seems to me the acronym RP is used for the first time. It = seems that=20 > it should be expanded to ease the reading of the document. I am = reading it=20 > as Relaying Party. Yes. We will use Relaying Party for its first use.=20 >=20 >=20 > =E2=80=A2 section 6 Security considerations >=20 > I My reading is that the section catches the criticality of the = SLURM=20 > files and that network operators are already familiar provisioning = critical=20 > data. As such I believe the section is sufficiently clear. >=20 > =E2=80=A2 whole document: >=20 > It seems that BGPSec, and BGPsec are used together. I believe = this=20 > should be harmonized to BGPsec. We will use BGPsec throughout this document as used by RFC 8205.=20 Di= From nobody Tue Feb 27 04:03: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 731F9126D85 for ; Tue, 27 Feb 2018 04:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 ky3I97HVEfQj for ; Tue, 27 Feb 2018 04:03:10 -0800 (PST) Received: from smtpbg202.qq.com (smtpbg202.qq.com [184.105.206.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A20126BF0 for ; Tue, 27 Feb 2018 04:03:09 -0800 (PST) X-QQ-mid: bizesmtp9t1519732985tpw4h95aw Received: from [192.168.3.3] (unknown [117.100.128.114]) by esmtp4.qq.com (ESMTP) with id ; Tue, 27 Feb 2018 20:03:03 +0800 (CST) X-QQ-SSF: 00400000004000F0FG40000A0000000 X-QQ-FEAT: PJL/FS1uSvIduVTEBzsqO4FUH5f/JUzoMD4lgcGSMOXPlgt/h9G8zKeO+xIm7 lX/Z9IA98rwXWWTun3KtD+V+FA4UtZdiIK9lNXI/GscVYnBrupli93RevgVM8Ci9ngHTYxn V3FmXKvTQVGnu9bZMVpoOLLMgWpKBzedHm2P64M1J+l6K2sC5jfTqETp2j1xQIp6yyvcYiV ZrIbDPBkUCzL0a8dBat5aU+F8ibmlvR9tGyhQLSIDuallixRbs4JMtF4WCS7XHEyzsbrBfs niY0oj8r0Y1zqclGOU3ZocAViFSgqRJudxm8Ypb8DG+kEJ 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: <50FD5EF7-509E-4A17-8321-3580EC206612@cisco.com> Date: Tue, 27 Feb 2018 20:03:03 +0800 Cc: "" , rtg-dir@ietf.org, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F4CB320-EB8D-4839-B9B2-5315405A0ECA@zdns.cn> References: <50FD5EF7-509E-4A17-8321-3580EC206612@cisco.com> To: IJsbrand Wijnands X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] RtgDir review: draft-ietf-sidr-slurm-06 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 Feb 2018 12:03:14 -0000 IJsbrand, Thanks for your review. Please see my responses in lines. > =E5=9C=A8 2018=E5=B9=B42=E6=9C=8827=E6=97=A5=EF=BC=8C17:18=EF=BC=8CIJsbr= and Wijnands =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >=20 > Document: draft-ietf-sidr-slurm-06=20 > Reviewer: IJsbrand Wijnands=20 > Review Date: 27-02-2018=20 > Intended Status: Standards Track >=20 > Summary:=20 >=20 > =E2=80=A2 This document is basically ready for publication, but has = nits that should be considered prior to publication. >=20 > Comments: >=20 > This document reads ok. >=20 > Minor issues: >=20 > It seems to me it would be useful to have a "Terminology and = Definitions=E2=80=9D section where the various acronyms are defined. = That would help readers who are less familiar in this area (like myself) = to parse the document. I understand your concern.=20 However, the potential readers of this document are supposed to be = familiar with the RPKI (RFC 6480) and BGPsec (RFC 8205) . All the = acronyms use throughout this document are within the discourse system = established by the RPKI and BGPsec.=20 That is, only those who totally understand the RPKI and BGPsec would = read this RFC for implementation and operations.=20 Hoping I am making sense here :-)=20 >=20 > Nits: >=20 > 1. Introduction > +++++++++++++++ >=20 > * What is a "putative TAs=E2=80=9D? Its not declared anywhere. Yes. We will use Trust Anchor for its first use.=20 >=20 > * What is a =E2=80=9CROAs=E2=80=9D? Should there be a RFC reference = here? ROA is explained as in =E2=80=98=E2=80=A6.the holder of a block of IP(v4 = or v6) addresses can issue a Route Origination Authorization (ROA) = [RFC6482]=E2=80=A6=E2=80=99 in Introduction.=20 >=20 >=20 > 2. RPKI RPs with SLURM > ++++++++++++++++++++++ >=20 > * What are =E2=80=9CRPs=E2=80=9D? Its not declared anywhere.=20 Yes. We will use Relaying Party for its first use.=20 >=20 >=20 > 3.3. SLURM Target > ++++++++++++++++++ >=20 > * =E2=80=9CA SLURM filer=E2=80=9D, is that a filter or file? Good catch. It should have been file :-) Di= From nobody Tue Feb 27 06:28: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 AEF3812D77B for ; Tue, 27 Feb 2018 06:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Dg5B25W13hPz for ; Tue, 27 Feb 2018 06:28:22 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 6159712D87B for ; Tue, 27 Feb 2018 06:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519741699; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ep7NXBAMNvdckBzLLeYtiDS1kQ2WJpxg5EUM7+DDgac=; b=NiJB61oVJ9mOL0ern/MiTdozlIeIbxcG8Ty5ToG3NT1oCCxFPoZWJerbHZQj+YVL Ndr0INCcj/lnlXlKRpjmf1XIg5DfpX6JWF4PlU/Ld8hsUvPZ6cemnTs+mkAuyj7D q/g/iLTnkibLIZu0I+Swz5dhjhgl1oJ9RBbkeJ8V7hY=; X-AuditID: c6180641-835ff70000007a40-32-5a956b022bb3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5F.98.31296.20B659A5; Tue, 27 Feb 2018 15:28:19 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0352.000; Tue, 27 Feb 2018 09:28:18 -0500 From: Daniel Migault To: Di Ma CC: secdir , "ietf@ietf.org" , "draft-ietf-sidr-slurm.all@ietf.org" , "sidr@ietf.org" Thread-Topic: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06 Thread-Index: AQHTr7wnUTKslLZqfEuSwcNPDeWDTqO4TsOw Date: Tue, 27 Feb 2018 14:28:17 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118DDDB6B@eusaamb107.ericsson.se> References: <151913883228.4660.15594261925083651299@ietfa.amsl.com> <5DC08C9A-C97E-4E8B-918B-A33E6D401FBD@zdns.cn> In-Reply-To: <5DC08C9A-C97E-4E8B-918B-A33E6D401FBD@zdns.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiC5z9tQog8vT+SxutllZPNs4n8Xi 3pNiiw8LH7JYLJt0ntGB1WPJkp9MHu+6OhkDmKK4bFJSczLLUov07RK4MvovLGIq+CZRcXBu A2MD4xKJLkZODgkBE4k9/+exgNhCAkcYJaafALK5gOzljBIbj91kBEmwCRhJtB3qZ+9i5OAQ EZCQuPaZF6SGWWAto8Tejg52kBphAXeJrtP32EBsEQEPieWTVjFC2EYSJ35eZwKxWQRUJc5P vQZm8wr4SjQu2QO1uETi/rwGMJtTwFpi14lZrCA2o4CYxPdTa8DqmQXEJW49mc8EcbSAxJI9 55khbFGJl4//sYLcJiGgLLHoTB6IySygKbF+lz5Ep6LElO6H7BBbBSVOznzCMoFRdBaSobMQ OmYh6ZiFpGMBI8sqRo7S4oKc3HQjw02MwAg5JsHmuINxb6/nIUYBDkYlHt6fIVOjhFgTy4or cw8xSnAwK4nwrlw8OUqINyWxsiq1KD++qDQntfgQozQHi5I47zlP3ighgfTEktTs1NSC1CKY LBMHp1QDo5oFjxuPEo/e5tolc6OPtHlZcQrI6S02Vdx9fWXNkd13+w7dfc3wX/zAp6x9gZNs Tym5xZRMdzUWYja3TqlWPpnwzlZluXyMWju/Qp/d1qLa58KfDizJ6645w6pYffTi7n/br1tz NPYv1U5VuxG3rHzbgufKcs0KT/X0PLd4HVr6ebfly6wSJZbijERDLeai4kQAg8GabIwCAAA= Archived-At: Subject: Re: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06 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 Feb 2018 14:28:24 -0000 SGkgRGksIA0KDQpUaGlzIGFkZHJlc3NlcyBteSBjb25jZXJucyB0aGFua3MhDQpZb3VycywgDQpE YW5pZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpIE1hIFttYWlsdG86 bWFkaUB6ZG5zLmNuXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDE4IDY6MTQgQU0N ClRvOiBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPg0KQ2M6IHNl Y2RpciA8c2VjZGlyQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zaWRyLXNs dXJtLmFsbEBpZXRmLm9yZzsgc2lkckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaWRyXSBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHItc2x1cm0tMDYNCg0KRGFuaWVs LA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpQbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBp biBsaW5lcy4NCg0KDQo+IOWcqCAyMDE45bm0MuaciDIw5pel77yMMjM6MDDvvIxEYW5pZWwgTWln YXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPiDlhpnpgZPvvJoNCj4gDQo+IFJldmll d2VyOiBEYW5pZWwgTWlnYXVsdA0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPiANCj4gSGks DQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIA0KPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgDQo+IElFU0cuICBUaGVzZSBjb21tZW50 cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgDQo+IHNlY3Vy aXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3Vs ZCB0cmVhdCANCj4gdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuDQo+IA0KPiBUaGUgc3VtbWFyeSBvZiB0aGUgcmV2aWV3IGlzIFJlYWR5IHdpdGgg bml0czoNCj4gDQo+IOKAoglzZWN0aW9uIDE6IEludHJvZHVjdGlvbg0KPiANCj4gICBIb3dldmVy LCBhbiBSUEtJIHJlbHlpbmcgcGFydHkgbWF5IHdhbnQgdG8gb3ZlcnJpZGUgc29tZSBvZiB0aGUN Cj4gICBpbmZvcm1hdGlvbiBleHByZXNzZWQgdmlhIHB1dGF0aXZlIFRBcyBhbmQgdGhlIGNlcnRp ZmljYXRlcw0KPiANCj4gPG1nbHQ+SXQgc2VlbXMgdGhhdCBUQSBpcyBiZWluZyB1c2VkIGZvciB0 aGUgZmlyc3QgdGltZSBoZXJlLiBUaGUgDQo+IGFjcm9ueW0gc2hvdWxkIGJlIGV4dGVuZGVkIHRv IGVhc2UgdGhlIHJlYWRpbmcgb2YgdGhlIGRvY3VtZW50LiBJIGFtIA0KPiByZWFkaW5nIGl0IGFz IFRydXN0IEFuY2hvci48L21nbHQ+DQo+IA0KDQpZZXMuIFdlIHdpbGwgdXNlIFRydXN0IEFuY2hv ciBmb3IgaXRzIGZpcnN0IHVzZS4gDQoNCj4gDQo+IOKAoglzZWN0aW9uIDIuICBSUEtJIFJQcyB3 aXRoIFNMVVJNDQo+IA0KPiAgIFNMVVJNIHByb3ZpZGVzIGEgc2ltcGxlIHdheSB0byBlbmFibGUg UlBzIHRvIGVzdGFibGlzaCBhIGxvY2FsLA0KPiANCj4gPG1nbHQ+SXQgc2VlbXMgdG8gbWUgdGhl IGFjcm9ueW0gUlAgaXMgdXNlZCBmb3IgdGhlIGZpcnN0IHRpbWUuIEl0IA0KPiBzZWVtcyB0aGF0 IGl0IHNob3VsZCBiZSBleHBhbmRlZCB0byBlYXNlIHRoZSByZWFkaW5nIG9mIHRoZSBkb2N1bWVu dC4gDQo+IEkgYW0gcmVhZGluZyBpdCBhcyBSZWxheWluZyBQYXJ0eS48L21nbHQ+DQoNClllcy4g V2Ugd2lsbCB1c2UgUmVsYXlpbmcgUGFydHkgZm9yIGl0cyBmaXJzdCB1c2UuIA0KDQo+IA0KPiAN Cj4g4oCiCXNlY3Rpb24gNiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KPiANCj4gPG1nbHQ+SSBN eSByZWFkaW5nIGlzIHRoYXQgdGhlIHNlY3Rpb24gY2F0Y2hlcyB0aGUgY3JpdGljYWxpdHkgb2Yg dGhlIA0KPiBTTFVSTSBmaWxlcyBhbmQgdGhhdCBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgYWxyZWFk eSBmYW1pbGlhciANCj4gcHJvdmlzaW9uaW5nIGNyaXRpY2FsIGRhdGEuIEFzIHN1Y2ggSSBiZWxp ZXZlIHRoZSBzZWN0aW9uIGlzIA0KPiBzdWZmaWNpZW50bHkgY2xlYXIuPC9tZ2x0Pg0KPiANCj4g 4oCiCXdob2xlIGRvY3VtZW50Og0KPiANCj4gPG1nbHQ+SXQgc2VlbXMgdGhhdCBCR1BTZWMsIGFu ZCBCR1BzZWMgYXJlIHVzZWQgdG9nZXRoZXIuIEkgYmVsaWV2ZSANCj4gdGhpcyBzaG91bGQgYmUg aGFybW9uaXplZCB0byBCR1BzZWMuPC9tZ2x0Pg0KDQpXZSB3aWxsIHVzZSBCR1BzZWMgdGhyb3Vn aG91dCB0aGlzIGRvY3VtZW50IGFzIHVzZWQgYnkgUkZDIDgyMDUuIA0KDQpEaQ0KDQo=