From nobody Sat Feb 4 09:32:56 2017 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 AD77712941C; Sat, 4 Feb 2017 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=q5mb/Ynb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HYWaPXWR 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 KyzyXDFJkf8Q; Sat, 4 Feb 2017 09:32:53 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0561289C4; Sat, 4 Feb 2017 09:32:53 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2115F2065B; Sat, 4 Feb 2017 12:32:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sat, 04 Feb 2017 12:32:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=zevu9DMQMVSTDPw LOMtDAcYdejE=; b=q5mb/Ynbq382ozGBfpaeWf7M0+EPOa/VdYgNVGWkC6pPWiC DKoAf52Yp6XZo/3CeBJ83lbtfftGQReXBEMfj1aHE+m0pz0/0AiO8svdNTcjhNiu bi6xRlWgGiaCSktVj80sJMcE8+KGS9xelQ3nK/exM0BtygSpuRX13+BpK/Pk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=zevu9DMQMVSTDPwLOMtDAcYdejE=; b=HYWaPXWRnB+zjZvOhnQT QiRXYGS1A70ygP/thRKjGcxqK8HcnXi/Cn0FLPSjksQQuEoa0i7CjMkpfH7/6rCD PAvpvDBNPB9eAYXV4LaPu4au5YyMGrnnVfu59DvdI9spGmkZUIupl1KOpLt6hAKO IGSpUIhvnLI9tUqIV9/c4Fw= X-ME-Sender: X-Sasl-enc: aLiw3sQcC0Lc/8gVC2RY16zDPFe+6NEPEf4gWJALQOMH 1486229572 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 061297E840; Sat, 4 Feb 2017 12:32:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: <20170131001321.2DFE04664F1A@minas-ithil.hactrn.net> Date: Sat, 4 Feb 2017 17:51:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <77892F06-8A7D-46EE-9287-8DFDEDE0545D@fastmail.fm> References: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> <20170131001321.2DFE04664F1A@minas-ithil.hactrn.net> To: Rob Austein Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 17:32:54 -0000 Hi Rob, > On 31 Jan 2017, at 00:13, Rob Austein wrote: >=20 > [Sorry for delay, was out for a while with a nasty flu, still catching up.= ] >=20 > At Sat, 14 Jan 2017 10:56:17 -0800, Alexey Melnikov wrote: > ... >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I find the document to be a bit short on normative references and some >> implementation details. Other than that the document looks fine. My >> specific questions and concern are as follows: >>=20 >> 1) Please add a normative reference for HTTP, URI and RelaxNG on first >> use. >=20 > Added, will be in -11 >=20 >> 2) Base64 needs a normative reference (including the section number, as >> there are 2 variants). >=20 > Added, will be in -11. >=20 >> 3) Section 2 says that all payloads use CMS. None of your examples show >> CMS. Can you please elaborate on how CMS is used. >=20 > The short version is already in the running text (section "Protocol > Specification" describes the CMS wrapping). Not shown in examples > because CMS is, um, rather verbose, and looks like dog food. >=20 > A full-blown exposition on use of CMS would look like RFC 6492 section > 3.1 ("CMS Profile") and all of its subsections. Sure you want that? >=20 > Should we incorporate RFC 6492 3.1 by reference? Incorporating by reference is fine. When you show examples, I think you shou= ld add a sentence saying that CMS bits are omitted to make examples more rea= dable. However, it would be a good idea to say who signs various CMS payload= s in your examples. >=20 >> 4) How can URI of the service be discovered? >=20 > Out of scope, but draft-ietf-sidr-oob-setup would be one way. I was thinking that defining a .well-known HTTP URI prefix would be a good i= dea in order to make this protocol play nicely with other HTTP based protoco= ls. Plus it allows running different HTTP protocols on the same port. >=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> In 2.5: is the list of error reasons extensible? >=20 > Probably, given sufficient cause. Then maybe add an IANA registry for it? >=20 >> Was Relax NG schema validated with a tool? >=20 > Yes, using trang and xmllint. Good to know. >=20 >> In Section 5 you should reference the document, as IANA registrations cut= >> & pasted to IANA website as separate files. >=20 > Would be happy to do so but does not appear to be on IANA website. > Chicken and egg problem? Leave for RFC Editor? IANA only does it once drafts are approved for publication as RFCs. So just a= dd [[RFCXXXX]] and RFC Editor will fix this before IANA publishes the regist= ration. Best Regards, Alexey.= From nobody Sat Feb 4 22:21:14 2017 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 D646D12945D; Sat, 4 Feb 2017 22:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 CSiMZ2KkLLjA; Sat, 4 Feb 2017 22:21:08 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 050C7127ABE; Sat, 4 Feb 2017 22:21:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1caGC7-0000EE-Jz; Sun, 05 Feb 2017 06:21:03 +0000 Date: Sun, 05 Feb 2017 15:21:00 +0900 Message-ID: From: Randy Bush To: Alexey Melnikov In-Reply-To: <77892F06-8A7D-46EE-9287-8DFDEDE0545D@fastmail.fm> References: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> <20170131001321.2DFE04664F1A@minas-ithil.hactrn.net> <77892F06-8A7D-46EE-9287-8DFDEDE0545D@fastmail.fm> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Rob Austein , morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 06:21:09 -0000 >>> 4) How can URI of the service be discovered? >> Out of scope, but draft-ietf-sidr-oob-setup would be one way. > I was thinking that defining a .well-known HTTP URI prefix would be a > good idea it rarely is. in this case it is a really bad idea. the services are not associated with the domain name; it is a coincidence. randy From nobody Sat Feb 4 22:53:16 2017 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 74B60129497; Sat, 4 Feb 2017 22:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 8xmEpD0xD1bT; Sat, 4 Feb 2017 22:53:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8F07A129488; Sat, 4 Feb 2017 22:53:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1caGhD-0000QB-6t; Sun, 05 Feb 2017 06:53:11 +0000 Date: Sun, 05 Feb 2017 15:53:07 +0900 Message-ID: From: Randy Bush To: Alexey Melnikov In-Reply-To: References: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> <20170131001321.2DFE04664F1A@minas-ithil.hactrn.net> <77892F06-8A7D-46EE-9287-8DFDEDE0545D@fastmail.fm> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Rob Austein , morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 06:53:15 -0000 >>>> 4) How can URI of the service be discovered? >>> Out of scope, but draft-ietf-sidr-oob-setup would be one way. >> I was thinking that defining a .well-known HTTP URI prefix would be a >> good idea > it rarely is. in this case it is a really bad idea. the services are > not associated with the domain name; it is a coincidence. a friend "suggested" i be clearer. :) i run a publication server. a half dozen CAs publish there. only one of the CAs has a domain name related to that of the publication server. and having to futz around with the dns would be a non-useful pita while provisioning. to be clear, this stuff has nothing to do with bgp or the dns, unlike 92.3% of the rest of the internet :) randy From nobody Tue Feb 7 09:19:24 2017 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 21654129DD0; Tue, 7 Feb 2017 09:19:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148648795513.3421.13837597218870136794.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 09:19:15 -0800 Archived-At: Cc: draft-ietf-sidr-as-migration@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'BGPSec Considerations for AS Migration' to Proposed Standard (draft-ietf-sidr-as-migration-06.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:19:15 -0000 The IESG has approved the following document: - 'BGPSec Considerations for AS Migration' (draft-ietf-sidr-as-migration-06.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-as-migration/ Technical Summary This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. Working Group Summary There was considerable discussion about this document in both SIDR and IDR working groups. Document Quality There are no implementations of the mechanisms, but this document (along with the base BGPSec specification) has been reviewed by vendors and operators. The document addresses the need to secure a common AS-migration set of mechanisms used in networks today. Personnel Document Shepherd: Chris Morrow AD: Alvaro Retana RFC Editor Note This document should be published alongside draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops so that they have consecutive RFC numbers in the following order: draft-ietf-sidr-bgpsec-protocol draft-ietf-sidr-as-migration draft-ietf-sidr-bgpsec-ops From nobody Wed Feb 8 07:03:42 2017 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 32562129B93; Wed, 8 Feb 2017 07:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ZDvegnLU; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=GdxZ+MTp 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 Gbh7kQptBYq2; Wed, 8 Feb 2017 07:03:37 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B9E129B81; Wed, 8 Feb 2017 07:03:34 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 93A85206C9; Wed, 8 Feb 2017 10:03:33 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 10:03:33 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=yCuOs7jYziZLULZnuTHW+MOSmco=; b=ZDvegn LUTWHefJ+hhXjYdokDw0Bm3q307bfJuzM+9Jg3a3uYtW1mZUgxXi0KHdphEf/hFG NQhbXvFwKS8ZigoPM2Ev8MhQuMY4JyKOWgtxbqRwji/9QD7ZIyw3RmmV/6+xXizH Xhc5cZ3eSJ0jNmmyhnxaqD5HgZ7pP9Nqcqu84= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yCuOs7jYziZLUL ZnuTHW+MOSmco=; b=GdxZ+MTpqn7y23w8xTrnUBEuFNMfjsra1WE+pu0xiEgfRc wNZb8HOUkNapIQ2ElDgGjxS0GJIUZJRbCROKgoBqgTBtoZoYuEsdLcEh6af8Lszx EwL2DTRWSLqgCn1Pb0MENrWSppmL20W3cAehzl4AJtBU+1TYq1n00ksIFKt5s= X-ME-Sender: X-Sasl-enc: qrUpfa/naqBFqoqX86gMospw/HkXy+vHbVPOQbZlorOT 1486566213 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 230B624641; Wed, 8 Feb 2017 10:03:31 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8442B271-A476-4EEE-B31E-AA0F328F2DE8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> Date: Wed, 8 Feb 2017 10:03:32 -0500 Message-Id: References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , IESG , "draft-ietf-sidr-rpki-oob-setup@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:03:38 -0000 --Apple-Mail=_8442B271-A476-4EEE-B31E-AA0F328F2DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) = wrote: >=20 > Hi! > =20 > I was going to wait for the author, but he has been out sick this = week=E2=80=A6 L > =20 > Picking up from Benoit=E2=80=99s comment =E2=80=93 the use of = =E2=80=9Cprotocol=E2=80=9D is misleading. What is described is a = process that can be followed and the necessary information exchanged = =E2=80=9Cto simplify configuration=E2=80=A6by setting up relationships = and exchanging keying material used to authenticate those = relationships.=E2=80=9D Is this going to be clarified in the document? Thanks, Alissa > =20 > Thanks! > =20 > Alvaro. > =20 >> On 1/17/17, 1:00 PM, "Alissa Cooper" > wrote: >> =20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> =20 >> (1) I agree with Mirja that this document seems to be missing the = actual >> protocol specification, unless Section 6 is meant to provide the >> normative specification of how the messages are to be exchanged. Is = it? >> If so, I would expect that to be explicit in the document. >> =20 >> (2) If there is in fact supposed to be a protocol specified here, I = have >> the same question as I had on draft-ietf-sidr-publication, which is = how >> do the entities migrate from one version to another and do version >> negotiation? >> =20 --Apple-Mail=_8442B271-A476-4EEE-B31E-AA0F328F2DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

Hi!
 
I was going to wait for the author, but he has been out sick = this week=E2=80=A6 L
 
Picking up from Benoit=E2=80=99s comment =E2=80=93 = the use of =E2=80=9Cprotocol=E2=80=9D is misleading.  What is = described is a process that can be followed and the necessary = information exchanged =E2=80=9Cto simplify configuration=E2=80=A6by = setting up relationships and exchanging keying material used to = authenticate those = relationships.=E2=80=9D

Is this going to be clarified in the = document?

Thanks,
Alissa

 
Thanks!
 
Alvaro.
 
On 1/17/17, = 1:00 PM, "Alissa Cooper" <alissa@cooperw.in> wrote:
 
---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------
 
(1) I agree with Mirja that this = document seems to be missing the actual
protocol specification, unless Section 6 is meant to provide = the
normative specification of how the messages are to be = exchanged. Is it?
If so, I would expect that to be = explicit in the document.
 
(2) If there is in fact supposed to be a protocol = specified here, I have
the same question as I had on = draft-ietf-sidr-publication, which is how
do the entities migrate from one version to another and do = version
negotiation?
 
<= br class=3D"">= --Apple-Mail=_8442B271-A476-4EEE-B31E-AA0F328F2DE8-- From nobody Wed Feb 8 07:13:54 2017 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 DDBFF129BC7; Wed, 8 Feb 2017 07:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=gOOZHgog; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=qewIgh4l 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 V5IXYj5eif9X; Wed, 8 Feb 2017 07:13:46 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A514B129BCE; Wed, 8 Feb 2017 07:13:46 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E60B32091C; Wed, 8 Feb 2017 10:13:45 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 10:13:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=r0Zar5BqAk2ROVa Nl7p7HZ3sg5g=; b=gOOZHgogMqG+wwO20TNECoclpW1Rakdno/QuQMoTkkXmwYZ odmFOwnGExjyAEhgRKoNsDeDv86fYGluE+5CSjyh6IhISvr7pwJaK+95/eMLIPYv RirG5dkWceY2JsXpZh9DxB1wSl+4aX0mNLXD80NaYzJYNZTefxOC1H9jwBFc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=r0Zar5BqAk2ROVaNl7p7HZ3sg5g=; b=qewIgh4lBwV6CfqgiVgC 4garDw789SKpvl8jPetahjKtFuA84/IiaFCN/dttmtP+mZn+ybZKC146kgv+kj/k mwSyP3j8homgZ7JhsLmrgfObxVNBWG5t6MezjtZnLP0ekn/rHOZ9nFTwJkpYdydU ElHSpNCg9c1S/YaoUOGZID8= X-ME-Sender: X-Sasl-enc: wBinBMttEM/cB1wZUv4/S6eGwjQGaz5kBDgdvg1uPnfr 1486566825 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B9EC245D9; Wed, 8 Feb 2017 10:13:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170131003328.D76804665206@minas-ithil.hactrn.net> Date: Wed, 8 Feb 2017 10:13:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22745407-7C4C-48B8-9AAC-1689445E0538@cooperw.in> References: <148466796666.31979.17532709479234975824.idtracker@ietfa.amsl.com> <20170131003328.D76804665206@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:13:48 -0000 > On Jan 30, 2017, at 7:33 PM, Rob Austein wrote: >=20 > At Tue, 17 Jan 2017 07:46:06 -0800, Alissa Cooper wrote: > ... >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> What is the upgrade path for the future when new versions of this >> protocol get published? How are clients and servers meant to agree on >> which version to use? >=20 > The schema includes a version number, so a new protocol version would > be detectable; in the most straightforward implementation, attempting > to parse an unknown protocol version would result in a schema > validation error. I think it would be useful to note that expectation (also since the = document talks about existing older versions of the protocol, presumably = not standardized). Thanks, Alissa > I don't think it's really possible to specify the > upgrade path in detail until one knows what the newer version looks > like, ie, what changed, so I'd defer this until the (hypothetical) new > version. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Although I understand why Section 6 says transport security is not >> strictly required, given that the authentication and authorization >> mechanisms that this protocol relies on are outside of the scope = here, >> isn't it possible that clients and servers may be exchanging cookies = or >> other headers in the course of using this protocol that would benefit >> from transport encryption? It seems like mentioning that transport >> security may still be beneficial although not required might be a = good >> idea. >=20 > Um, the authentication is CMS signatures, it's just the authorization > that's out of scope. >=20 > I can't think of any sane reason for stuffing cookies or the like into > this protocol, but yes, it's theoretically possible. >=20 > The protocol is currently specified in terms of plain HTTP because an > earlier version using HTTPS included a horrible authentication > hairball in which HTTPS and CMS were required to use the same BPKI > certificates for authentication, which turned out to be an > implementation nightmare. So we backed off to plain HTTP to cut free > of that mess, and we didn't think there were any privacy issues in the > real data (if there had been, we would have been using CMS encryption > too). >=20 > That said, the world has changed, and I see at least one other discuss > asking for HTTPS, so I guess we'll be going down that path, but this > time with no required linkage between CMS and HTTPS, and with the > authentication (still) just based on CMS. From nobody Thu Feb 9 13:38:48 2017 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 DED9E129C9C; Thu, 9 Feb 2017 13:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 f5nXCwTKjW7i; Thu, 9 Feb 2017 13:38:45 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920BA1295C3; Thu, 9 Feb 2017 13:38:45 -0800 (PST) Received: from minas-ithil.hactrn.net (dsl-207-183-187-238.freedom.wy.silverstar.com [207.183.187.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 300C7B868; Thu, 9 Feb 2017 21:38:45 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id C39584684B49; Thu, 9 Feb 2017 14:39:10 -0700 (MST) Date: Thu, 09 Feb 2017 14:39:10 -0700 From: Rob Austein To: Alissa Cooper In-Reply-To: References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20170209213910.C39584684B49@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, IESG , sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:38:47 -0000 At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: > > On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) wrote: > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> =20 > >> (1) I agree with Mirja that this document seems to be missing the actu= al > >> protocol specification, unless Section 6 is meant to provide the > >> normative specification of how the messages are to be exchanged. Is it? > >> If so, I would expect that to be explicit in the document. > >> =20 > >> (2) If there is in fact supposed to be a protocol specified here, I ha= ve > >> the same question as I had on draft-ietf-sidr-publication, which is how > >> do the entities migrate from one version to another and do version > >> negotiation? > > =20 > > Picking up from Benoit?s comment ? the use of ?protocol? is > > misleading. What is described is a process that can be followed > > and the necessary information exchanged ?to simplify > > configuration?by setting up relationships and exchanging keying > > material used to authenticate those relationships.? >=20 > Is this going to be clarified in the document? [Mostly offline this week, including a multi-day power outage, whee!] With respect, I don't concede the point that this is not a protocol. UUCP (RFC 976) and Batch SMTP (RFC 2442) were protocols, so is this. It has senders and receivers, rules for who initiates the conversation and what each party is allowed to say, and so forth. The only things it doesn't have are a required underlying transport protocol and corresponding channel security mechanism. These omissions are deliberate, as stated in the introduction (last two paragraphs). As Stephen observe, it's a sneakernet protocol. Sections 5 and 6 are intended to be read together. The explicit rules for what goes into each PDU are in section 5.2, but it's easier to see how the protocol operates with the worked examples in section 6. The only thing I can see in re-reading this that looks unclear (to me) is that section 5.2.3 ought to state explicitly that it comes after the / exchange. This is sort of there already in implicit form (the sub-element of the message requires an from the message), but it probably ought to be explicit. From nobody Thu Feb 9 14:03:57 2017 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 695A6129CAA; Thu, 9 Feb 2017 14:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=OgtWVAgf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Jq4OWlSl 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 iPFlhtUlV_Pa; Thu, 9 Feb 2017 14:03:50 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4FE127ABE; Thu, 9 Feb 2017 14:03:50 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7832D20C74; Thu, 9 Feb 2017 17:03:49 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Feb 2017 17:03:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=hTV3mTiTWYEBkfb oODY+pbwWavs=; b=OgtWVAgfVILVGAoF4FTBNyIx4yzXuCQtw02plDheLeZjEXn MFs/sM/4v4TphU0VlbS3+7cNJr+GoODX+EEBurDg1ymcaSpuU6c5RWTIvTX/ZC2P clg+9S+xagZZPcYUATesBI1GaDKPri2r/4R6qFmcq7wIO6pWZYK99LKLu7So= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=hTV3mTiTWYEBkfboODY+pbwWavs=; b=Jq4OWlSl3P+mdyl/G4dA pMc3YuQbBQ505uX6SpswU5eSiJFptqL+/ces7c0cAeaAmYyaD2QW9geyDZq/vzKm yvEhJ8J0WUeSecS/L9NkmMKgQ9mmKwddeK8G2zml913Bk+x1CVpd3l6gTxn6wAgV MpoZRmIo7fRBhS5AugH7xeo= X-ME-Sender: X-Sasl-enc: gzG9o++U/TA99e1GHIzpkVgpZzgR0kGM+RVIVNETOxyU 1486677829 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id F3AF67E077; Thu, 9 Feb 2017 17:03:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: <20170209213910.C39584684B49@minas-ithil.hactrn.net> Date: Thu, 9 Feb 2017 22:22:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <544C672B-D26F-449F-9CC0-B861E787BAED@fastmail.fm> References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> <20170209213910.C39584684B49@minas-ithil.hactrn.net> To: Rob Austein Archived-At: Cc: Alissa Cooper , Chris Morrow , sidr-chairs@ietf.org, IESG , sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:03:51 -0000 I don't feel strongly about this either way, but... > On 9 Feb 2017, at 21:39, Rob Austein wrote: >=20 > At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: >>>> On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) wrote: >>>>=20 >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> (1) I agree with Mirja that this document seems to be missing the actua= l >>>> protocol specification, unless Section 6 is meant to provide the >>>> normative specification of how the messages are to be exchanged. Is it?= >>>> If so, I would expect that to be explicit in the document. >>>>=20 >>>> (2) If there is in fact supposed to be a protocol specified here, I hav= e >>>> the same question as I had on draft-ietf-sidr-publication, which is how= >>>> do the entities migrate from one version to another and do version >>>> negotiation? >>>=20 >>> Picking up from Benoit?s comment ? the use of ?protocol? is >>> misleading. What is described is a process that can be followed >>> and the necessary information exchanged ?to simplify >>> configuration?by setting up relationships and exchanging keying >>> material used to authenticate those relationships.? >>=20 >> Is this going to be clarified in the document? >=20 > [Mostly offline this week, including a multi-day power outage, whee!] >=20 > With respect, I don't concede the point that this is not a protocol. >=20 > UUCP (RFC 976) and Batch SMTP (RFC 2442) were protocols, so is this. > It has senders and receivers, rules for who initiates the conversation > and what each party is allowed to say, and so forth. The only things > it doesn't have are a required underlying transport protocol and > corresponding channel security mechanism. These omissions are > deliberate, as stated in the introduction (last two paragraphs). As > Stephen observe, it's a sneakernet protocol. Right. I think you meant "protocol" in a more generic sense that is commonly= used in IETF, but I think that is Ok. I think keeping the text as is is Ok.= >=20 > Sections 5 and 6 are intended to be read together. The explicit rules > for what goes into each PDU are in section 5.2, but it's easier to see > how the protocol operates with the worked examples in section 6. >=20 > The only thing I can see in re-reading this that looks unclear (to me) > is that section 5.2.3 ought to state explicitly that it comes after > the / exchange. This is sort of > there already in implicit form (the sub-element of the > message requires an from the > message), but it probably ought to be explicit. >=20 From nobody Thu Feb 9 15:12:02 2017 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 9F94112962C; Thu, 9 Feb 2017 15:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 v4PL0g-GC_23; Thu, 9 Feb 2017 15:11:59 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF077129612; Thu, 9 Feb 2017 15:11:59 -0800 (PST) Received: from minas-ithil.hactrn.net (dsl-207-183-187-238.freedom.wy.silverstar.com [207.183.187.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 290A91398E; Thu, 9 Feb 2017 23:11:58 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 802F2468503F; Thu, 9 Feb 2017 16:12:25 -0700 (MST) Date: Thu, 09 Feb 2017 16:12:25 -0700 From: Rob Austein To: Alissa Cooper In-Reply-To: References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170209231225.802F2468503F@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , IESG , "sidr@ietf.org" , "draft-ietf-sidr-rpki-oob-setup@ietf.org" Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:12:00 -0000 Sorry, missed this part: At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> (2) If there is in fact supposed to be a protocol specified here, I have > >> the same question as I had on draft-ietf-sidr-publication, which is how > >> do the entities migrate from one version to another and do version > >> negotiation? Essentially the same answer as for draft-ietf-sidr-publication, so will include some variation of same text if that's acceptable. From nobody Fri Feb 10 00:41:45 2017 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 613DC1296A3; Fri, 10 Feb 2017 00:41:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148671610039.27760.3619946723606473873.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 00:41:40 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 08:41:40 -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 of the IETF. Title : RPKI Repository Delta Protocol Authors : Tim Bruijnzeels Oleg Muravskiy Bryan Weber Rob Austein Filename : draft-ietf-sidr-delta-protocol-06.txt Pages : 24 Date : 2017-02-10 Abstract: In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) [RFC2818] protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates [RFC6480], [RFC6481], and [RFC7730], to remove the dependency on [rsync] as the only mandatory RPKI repository distribution mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-delta-protocol-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 Fri Feb 10 05:32:36 2017 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 F303212995D; Fri, 10 Feb 2017 05:32:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148673355498.27743.10904368944432695438.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 05:32:34 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:32:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On top of the OPS DIR feedback from Stefan at https://datatracker.ietf.org/doc/review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07/, one editorial remark. Periodically, the router sends to the cache the most recent Serial Number for which it has has received data from that cache s/has has/has From nobody Fri Feb 10 15:25:20 2017 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 795881293E1; Fri, 10 Feb 2017 15:25:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148676911549.29291.4624677040596038474.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 15:25:15 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:25:15 -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 of the IETF. Title : RPKI Repository Delta Protocol Authors : Tim Bruijnzeels Oleg Muravskiy Bryan Weber Rob Austein Filename : draft-ietf-sidr-delta-protocol-07.txt Pages : 25 Date : 2017-02-10 Abstract: In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates RFC6480, RFC6481, and RFC7730. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-delta-protocol-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 10 15:30:07 2017 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 7B11A1295E8 for ; Fri, 10 Feb 2017 15:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 eFnwhg5Bv9BC for ; Fri, 10 Feb 2017 15:30:04 -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 55A471295D3 for ; Fri, 10 Feb 2017 15:30:04 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ccKdd-000B73-Al for sidr@ietf.org; Sat, 11 Feb 2017 00:30:02 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ccKdc-0004Nc-1v; Sat, 11 Feb 2017 00:30:00 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Oleg Muravskiy In-Reply-To: <148676911549.29291.4624677040596038474.idtracker@ietfa.amsl.com> Date: Sat, 11 Feb 2017 00:29:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14383101-CDA5-4496-8790-6C267FCCC84A@ripe.net> References: <148676911549.29291.4624677040596038474.idtracker@ietfa.amsl.com> To: IETF SIDR X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74c16a514c0e5635f1d7f91808696625a6 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:30:06 -0000 This version fixes idnits, no substantial changes to content. Cheers, Oleg > On 11 Feb 2017, at 00:25, internet-drafts@ietf.org wrote: >=20 >=20 > 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 of the = IETF. >=20 > Title : RPKI Repository Delta Protocol > Authors : Tim Bruijnzeels > Oleg Muravskiy > Bryan Weber > Rob Austein > Filename : draft-ietf-sidr-delta-protocol-07.txt > Pages : 25 > Date : 2017-02-10 >=20 > Abstract: > In the Resource Public Key Infrastructure (RPKI), certificate > authorities publish certificates, including end entity certificates, > Certificate Revocation Lists (CRL), and RPKI signed objects to > repositories. Relying Parties (RP) retrieve the published > information from those repositories. This document specifies a > protocol which provides relying parties with a mechanism to query a > repository for incremental updates using the HTTP Over TLS (HTTPS) > protocol, thus enabling the RP to keep its state in sync with the > repository using a secure transport channel. This document updates > RFC6480, RFC6481, and RFC7730. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-delta-protocol-07 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Sat Feb 11 18:50:13 2017 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 487B6128874; Sat, 11 Feb 2017 18:50:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148686781128.10932.14298689350848508409.idtracker@ietfa.amsl.com> Date: Sat, 11 Feb 2017 18:50:11 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 02:50:11 -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 of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI Authors : David Mandelberg Di Ma Tim Bruijnzeels Filename : draft-ietf-sidr-slurm-03.txt Pages : 17 Date : 2017-02-11 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-03 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 Sun Feb 12 19:07:06 2017 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 652AB1295C6 for ; Sun, 12 Feb 2017 19:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 y0dbcaiDNs44 for ; Sun, 12 Feb 2017 19:07:03 -0800 (PST) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (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 D49101295C4 for ; Sun, 12 Feb 2017 19:07:02 -0800 (PST) X-TM-DID: a126cc56029c545d2acabad3513a4dcd From: Declan Ma Content-Type: multipart/alternative; boundary="Apple-Mail=_02AE3866-2A0C-448B-B960-B3222843C1C9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <91A5C164-0684-45D2-A608-08AD2DFB1BA1@zdns.cn> References: <148686781128.10932.14298689350848508409.idtracker@ietfa.amsl.com> To: sidr wg list Date: Mon, 13 Feb 2017 11:02:28 +0800 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [sidr] Fwd: I-D Action: draft-ietf-sidr-slurm-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 03:07:05 -0000 --Apple-Mail=_02AE3866-2A0C-448B-B960-B3222843C1C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 Hi, all, We authors just updated the SLURM by adding a new ingredient JSON, = offered by Tim, to describe the SLURM configuration file format.=20 Looking forwards to seeing your reviews and comments. Thanks very much indeed. Di=20 ZDNS > =CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA >=20 > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org > =D6=F7=CC=E2: [sidr] I-D Action: draft-ietf-sidr-slurm-03.txt > =C8=D5=C6=DA: 2017=C4=EA2=D4=C212=C8=D5 GMT+8 10:50:11 > =CA=D5=BC=FE=C8=CB: > =B3=AD=CB=CD: sidr@ietf.org >=20 >=20 > 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 of the = IETF. >=20 > Title : Simplified Local internet nUmber Resource = Management with the RPKI > Authors : David Mandelberg > Di Ma > Tim Bruijnzeels > Filename : draft-ietf-sidr-slurm-03.txt > Pages : 17 > Date : 2017-02-11 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-slurm-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-slurm-03 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_02AE3866-2A0C-448B-B960-B3222843C1C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312
Hi, all,

We authors just = updated the SLURM by adding a new ingredient JSON, offered by Tim, =  to describe the SLURM configuration file format. 

Looking forwards to seeing your reviews and = comments.

Thanks very much indeed.

Di 

ZDNS

=CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org
=D6=F7=CC=E2: = [sidr] I-D = Action: draft-ietf-sidr-slurm-03.txt
=C8=D5=C6=DA: = 2017=C4=EA2=D4=C212=C8=D5 GMT+8 = 10:50:11
=CA=D5=BC=FE= =C8=CB: <i-d-announce@ietf.org>
=B3=AD=CB=CD: = sidr@ietf.org


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 of the IETF.

=        Title =           : Simplified = Local internet nUmber Resource Management with the RPKI
=        Authors =         : David Mandelberg
=             &n= bsp;           &nbs= p;Di Ma
=             &n= bsp;           &nbs= p;Tim Bruijnzeels
Filename =        : = draft-ietf-sidr-slurm-03.txt
Pages =           : 17
= Date =            : = 2017-02-11

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's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-sidr-slurm-03

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-slurm-03

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/

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail=_02AE3866-2A0C-448B-B960-B3222843C1C9-- From nobody Tue Feb 14 08:50:14 2017 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 19C0F1294F5; Tue, 14 Feb 2017 08:50:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709100910.9985.10477276787319190343.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 08:50:09 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:50:09 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well written document. I have one small issue I would like to discuss: In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change. From nobody Tue Feb 14 10:27:45 2017 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 A01EB129685; Tue, 14 Feb 2017 10:27:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709685964.10062.11055042165542175129.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 10:27:39 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:27:40 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. The first question is more of a nit, the second is more important. Section 9.1 I suggest saying man-in-the-middle instead of monkey-in-the-middle as we use the latter typically in documents and I don't think there's anything particularly unique to a monkey-in-the-middle attack, but correct me if I am wrong. I think it's just an alternate name for man-in-the-middle as result of Dug Song's tool sniff on monkey.org. If monkey-in-the-middle is important for some reason, could you include a reference? Section 9.3 Why isn't MD5 deprecated or discouraged more in this section? From nobody Tue Feb 14 13:40:06 2017 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 4C14D1293EC; Tue, 14 Feb 2017 13:40:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148710840030.10070.11604926737704511161.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 13:40:00 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Alia Atlas' No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 21:40:00 -0000 Alia Atlas has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This looks like it obsoletes RFC6810 or perhaps updates it. The draft header should show this so RFC meta-data is accurate. From nobody Tue Feb 14 19:34:08 2017 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 974891293E1; Tue, 14 Feb 2017 19:34:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 19:34:04 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:34:04 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have read through the document and I still was unable to figure out what the Max Len field for the IPvX PDUs is being used for. It is defined as Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. but I was not able to find any processing rules for this. i.e. what it is actually used for. An example would greatly help. From nobody Tue Feb 14 19:52:41 2017 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 42CE212947F; Tue, 14 Feb 2017 19:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 sBrnFhVidZMG; Tue, 14 Feb 2017 19:52:38 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220971288B8; Tue, 14 Feb 2017 19:52:38 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 79EB71398E; Wed, 15 Feb 2017 03:52:36 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id BF6494796E81; Tue, 14 Feb 2017 22:52:34 -0500 (EST) Date: Tue, 14 Feb 2017 22:52:34 -0500 From: Rob Austein To: "Suresh Krishnan" In-Reply-To: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170215035234.BF6494796E81@minas-ithil.hactrn.net> Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:52:39 -0000 At Tue, 14 Feb 2017 19:34:04 -0800, Suresh Krishnan wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have read through the document and I still was unable to figure out > what the Max Len field for the IPvX PDUs is being used for. It is defined > as > > Max Length: An 8-bit unsigned integer denoting the longest prefix > allowed by the Prefix element. > > but I was not able to find any processing rules for this. i.e. what it is > actually used for. An example would greatly help. Verbatim copy of the maxLength field from RFC 6482, q.v. Unchanged from RFC 6810, use explained (tersely) in RFC 6811. Perhaps references to RFC 6482 and 6811 would be appropriate? From nobody Tue Feb 14 19:53:40 2017 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 B9B22129984; Tue, 14 Feb 2017 19:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 wvIOFlDbuyYM; Tue, 14 Feb 2017 19:53:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EF667129534; Tue, 14 Feb 2017 19:53:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cdqem-0008RD-6e; Wed, 15 Feb 2017 03:53:28 +0000 Date: Wed, 15 Feb 2017 12:53:25 +0900 Message-ID: From: Randy Bush To: "Suresh Krishnan" In-Reply-To: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:53:34 -0000 > I have read through the document and I still was unable to figure out > what the Max Len field for the IPvX PDUs is being used for. It is defined > as > > Max Length: An 8-bit unsigned integer denoting the longest prefix > allowed by the Prefix element. > > but I was not able to find any processing rules for this. i.e. what it is > actually used for. An example would greatly help. wrong document. 6810 does not define prefix or prefix len either :) you want 6482 3.3, which i do not think you want to repro here, even if tersified Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies the maximum length of the IP address prefix that the AS is authorized to advertise. (For example, if the IP address prefix is 203.0.113/24 and the maxLength is 26, the AS is authorized to advertise any more specific prefix with a maximum length of 26. In this example, the AS would be authorized to advertise 203.0.113/24, 203.0.113.128/25, or 203.0.113.0/25, but not 203.0.113.0/27.) When the maxLength is not present, the AS is only authorized to advertise the exact prefix specified in the ROA. From nobody Tue Feb 14 19:56:18 2017 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 04CFC1294AC; Tue, 14 Feb 2017 19:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 yC_rmB6uyWO8; Tue, 14 Feb 2017 19:56:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4161012947F; Tue, 14 Feb 2017 19:56:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cdqhQ-0008Sy-JI; Wed, 15 Feb 2017 03:56:12 +0000 Date: Wed, 15 Feb 2017 12:56:09 +0900 Message-ID: From: Randy Bush To: Rob Austein In-Reply-To: <20170215035234.BF6494796E81@minas-ithil.hactrn.net> References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> <20170215035234.BF6494796E81@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Suresh Krishnan , Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:56:17 -0000 > Perhaps references to RFC 6482 and 6811 would be appropriate? imiho refs for all the fields will be overwhelming. From nobody Tue Feb 14 20:00:33 2017 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 D1BEC129984; Tue, 14 Feb 2017 20:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Lx6Acd4GkQ7U; Tue, 14 Feb 2017 20:00:31 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14544129586; Tue, 14 Feb 2017 20:00:31 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 667B31398E; Wed, 15 Feb 2017 04:00:30 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2E6C04798000; Tue, 14 Feb 2017 23:00:30 -0500 (EST) Date: Tue, 14 Feb 2017 23:00:29 -0500 From: Rob Austein To: "Alia Atlas" In-Reply-To: <148710840030.10070.11604926737704511161.idtracker@ietfa.amsl.com> References: <148710840030.10070.11604926737704511161.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170215040030.2E6C04798000@minas-ithil.hactrn.net> Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Alia Atlas' No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:00:32 -0000 At Tue, 14 Feb 2017 13:40:00 -0800, Alia Atlas wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This looks like it obsoletes RFC6810 or perhaps updates it. > The draft header should show this so RFC meta-data is accurate. The authors had a loooonng discussion about this with our AD. We will do whatever he tells us to do here. :) From nobody Tue Feb 14 20:03:52 2017 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 DD34612952D; Tue, 14 Feb 2017 20:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 Qzfdp9ck2bXB; Tue, 14 Feb 2017 20:03:49 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 4E1CF12947F; Tue, 14 Feb 2017 20:03:49 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id i10so182916159wrb.0; Tue, 14 Feb 2017 20:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aOFqcUyhrsnltLBWgrFN3Tg/1MipO7Znp9/RRv550uU=; b=BLzodKtzHRtss8KC+XaVHPpX8VVKPA4GuMX4uWUH6vDO5pvnVlGxKT4wBXCJ5wk0AA 8rpW4hhJ6tafh3D1fwm6IddWDWqnC8C3tYqQdCURjfABihKrk9O4I2wc2ydBfJ0Q5Yz9 k+YQYoECxkEMmzj6Hvs9cWk9vaQVWFSU/gJRIK1Ry3Nk42EaMdSrrEo0Aur8SSvPZBFN rVm+geBTilkCih2OI08OlaKBhd/XGH7g3Ehweru0m67aacf9I3IHX5ZG0FEbaLLF7a5O ahs4rLygt200wJ0I5LcFQxzZ+ezJMj7YzjMJUhoQ3XpsHivKsrlGB5Gz0vKxyyKeaSpH uNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aOFqcUyhrsnltLBWgrFN3Tg/1MipO7Znp9/RRv550uU=; b=eBAs8MJUBM6o6qPTdRR/i1Zs7yPxRxdDQXNbyZq9qpn4C/xNrzVgsdXulcnVg2IhIn Q3m0gTKidIylmZmW0n2c6UaWIiavzxO3hjRtGWT/aOqSo6eZ67x+8f2Hq1flKrqkm291 DPfdJkDn7qBLagj7pgtnf1noWUfpQagnIorJbeLnS56t9RVuekj2YCOLUwWxff1dYaRR 60uqLyYanacS8bUJKuOpxzu8grr47QNOX3JyIzP2b/4+Mmpsuqrsa79oxQU4MnO+XOEL DzGIGWhQ9fyzanYwEtPW6DBrq5q2XS4ZZBkfDrEY8gNmsQVg37TNZIOpasGMrE+Dusw4 JGUw== X-Gm-Message-State: AMke39nFGpR721od3X38ykJ1pJmRZdvCoQIHKwatQzsciL8OdJyupuCgbNKfLMR4+RUFmBPdkPb8+ePT4NnBrA== X-Received: by 10.223.147.225 with SMTP id 88mr27727642wrp.44.1487131427794; Tue, 14 Feb 2017 20:03:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.142.98 with HTTP; Tue, 14 Feb 2017 20:03:47 -0800 (PST) In-Reply-To: <20170215040030.2E6C04798000@minas-ithil.hactrn.net> References: <148710840030.10070.11604926737704511161.idtracker@ietfa.amsl.com> <20170215040030.2E6C04798000@minas-ithil.hactrn.net> From: Alia Atlas Date: Tue, 14 Feb 2017 23:03:47 -0500 Message-ID: To: Rob Austein Content-Type: multipart/alternative; boundary=94eb2c0df21c7cf783054889c432 Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Alia Atlas' No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:03:51 -0000 --94eb2c0df21c7cf783054889c432 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2017 at 11:00 PM, Rob Austein wrote: > At Tue, 14 Feb 2017 13:40:00 -0800, Alia Atlas wrote: > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This looks like it obsoletes RFC6810 or perhaps updates it. > > The draft header should show this so RFC meta-data is accurate. > > The authors had a loooonng discussion about this with our AD. > We will do whatever he tells us to do here. :) > I am not at all surprised - and that is why this is a Comment and not a Discuss. IMHO, a new implementor would want to be pointed to the most recent version of the protocol. That indicates to me that an Updates is the minimum. Then, well, I'd have to dig to see what we've done with protocol RFCs when we advance the version number. Obviously, OSPF is not a good example here :-) Regards, Alia --94eb2c0df21c7cf783054889c432 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 14, 2017 at 11:00 PM, Rob Austein <sra@hactrn.net> wrot= e:
At Tue, 14 Feb 2017 1= 3:40:00 -0800, Alia Atlas wrote:
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> This looks like it obsoletes=C2=A0 RFC6810 or perhaps updates it.
> The draft header should show this so RFC meta-data is accurate.

The authors had a loooonng discussion about this with our AD.
We will do whatever he tells us to do here. :)

I am not at all sur= prised - and that is why this is a Comment and not a Discuss.
IMHO, a new implementor would want to be pointed to the = most recent version
of the protocol. =C2=A0= That indicates to me that an Updates is the minimum.=C2=A0 Then,
well, I'd have to dig to see what we've done= with protocol RFCs when we advance
the ver= sion number.=C2=A0 Obviously, OSPF is not a good example here :-)

Regards,
<= div class=3D"gmail_extra">Alia

--94eb2c0df21c7cf783054889c432-- From nobody Tue Feb 14 20:07:31 2017 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 A20A81299A2; Tue, 14 Feb 2017 20:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 vddlkNeUPN8A; Tue, 14 Feb 2017 20:07:26 -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 A2ED01294BE; Tue, 14 Feb 2017 20:07:25 -0800 (PST) X-AuditID: c6180641-c3fff70000000a06-83-58a38da60aa3 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id CF.26.02566.6AD83A85; Wed, 15 Feb 2017 00:07:21 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 23:07:21 -0500 From: Suresh Krishnan To: Rob Austein , Randy Bush Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) Thread-Index: AQHShzxeULVw1W9ooEu0dmXhdYJP8KFpwzkAgAAD0gA= Date: Wed, 15 Feb 2017 04:07:05 +0000 Message-ID: References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> <20170215035234.BF6494796E81@minas-ithil.hactrn.net> In-Reply-To: <20170215035234.BF6494796E81@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_3207D1CE-F396-416C-897F-10E43D535263"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyuXSPt+7K3sURBktO6Fn8/bmV0eL8zY1s FjP+TGS2uLzwI5vFs9aXTBbf519gtVg26TyjxZSt71gcODym/N7I6tF25zKTx5IlP5k8Hkw6 yu4xdeZsxgDWKC6blNSczLLUIn27BK6MGfP8CmZYVHx7/pClgfG+SRcjJ4eEgInEnNPbmbsY uTiEBNYzSpxrfw3lLGeUWHK8gxGkig2oasPOz0wgtoiAjcSr/VPYQGxmgeVMEvMuq4LYwgIZ Es8232aHqMmUODexjRHCtpJ4fOgeSxcjBweLgKrE7fNgrbwC9hLzd/6E2tXCKHHs7mmwBKeA o8TZ491guxgFxCS+n1rDBLFLXOLWk/lMEFeLSDy8CFEvISAq8fLxP1YIW0ni4+/57CBDmQWm MErMv3kbapugxMmZT1gmMIrMQjJrFrK6WUjqIIq0JZYtfM08C+hwZgEdickLGSHCphKvj36E sq0lZvw6yAZhK0pM6X7IvoCRYxUjR2lxQU5uupHhJkZgxB6TYHPcwbi31/MQowAHoxIPr8Hj RRFCrIllxZW5hxhVgFofbVh9gVGKJS8/L1VJhFfg0uIIId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rzXQ+6HCwmkJ5akZqemFqQWwWSZODilGhgd+X9e1H97N3F68+LLejkf9ybPOqdhV2TEnu2w eWptZNbCi8qnLkWdDGG8mzv7oviFut/x76y2Ox0OVGg8+K1h7qGfCcJ68c96z8lcSCx9VsYn lD7b8MKXTzcSrv+OZf6+oniu7f/QcNm87vt7OZ5UVfBXO6baFR54qBnpvqaE5XW6PvPv97lK LMUZiYZazEXFiQAgGK7c4AIAAA== Archived-At: Cc: "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:07:27 -0000 --Apple-Mail=_3207D1CE-F396-416C-897F-10E43D535263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob and Randy, Thanks. The reference to RFC6482 clarified the field for me. I leave = it to your discretion on whether you want to add a reference or not, but = I personally found it extremely helpful. As a followup, why is there no = associated error checking for the Max Length field in the IPvX PDUs (to = ensure the MUST NOT be less than Prefix Length)? Regards Suresh > On Feb 14, 2017, at 10:52 PM, Rob Austein wrote: >=20 > At Tue, 14 Feb 2017 19:34:04 -0800, Suresh Krishnan wrote: >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I have read through the document and I still was unable to figure out >> what the Max Len field for the IPvX PDUs is being used for. It is = defined >> as=20 >>=20 >> Max Length: An 8-bit unsigned integer denoting the longest prefix >> allowed by the Prefix element. >>=20 >> but I was not able to find any processing rules for this. i.e. what = it is >> actually used for. An example would greatly help. >=20 > Verbatim copy of the maxLength field from RFC 6482, q.v. > Unchanged from RFC 6810, use explained (tersely) in RFC 6811. >=20 > Perhaps references to RFC 6482 and 6811 would be appropriate? >=20 --Apple-Mail=_3207D1CE-F396-416C-897F-10E43D535263 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE1MDQwNjE1WjAjBgkqhkiG9w0B CQQxFgQU9F1BTBhP38fmR2kp69psc7b+kdMwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQAw0rAo6qKgVDPMHSMy6uJ7oNa36twNN1/fWmibuuhOQEvwgZw+PXWbbLMgU3Zl JB3+2OS3O235lWKq/PaQBEp6jb7idATY4G5IAszfRR4OJuMYF7cTOvuyuhefyanK2+1j5KuuKR1F qH2uHcnQcxCXD4YZeV8TzwWoVr0fqVYw1maOrQwgm/rSMfWhmSB392onVLp5zNVNyQkZatflJlGJ A9wIJegoaLgqyay5rpsVSh8GmMasmG2iNrhnDPzDO5Es10RpuV47subMSwkJTnPAMtfC6a7osEkM +/AP0k6xiQ+QlN9oqgJ54Zub/JWoCbtqdT2EFFUYXoILR65GBaMTAAAAAAAA --Apple-Mail=_3207D1CE-F396-416C-897F-10E43D535263-- From nobody Tue Feb 14 20:15:47 2017 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 70869129463; Tue, 14 Feb 2017 20:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 ErTdqMlttdNq; Tue, 14 Feb 2017 20:15:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 185D712943E; Tue, 14 Feb 2017 20:15:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cdr0A-00008l-J5; Wed, 15 Feb 2017 04:15:34 +0000 Date: Wed, 15 Feb 2017 13:15:31 +0900 Message-ID: From: Randy Bush To: Suresh Krishnan In-Reply-To: References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> <20170215035234.BF6494796E81@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , Rob Austein , Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:15:40 -0000 > why is there no associated error checking for the Max Length field in > the IPvX PDUs it is assumed any error checking was done *before* they are sent to the router. a major goal of this protocol is to relieve the router of any load. so, if field consistency is to be done, it should be in the protocols at the rpki level, e.g. at the latest when the cache receives and validates the data. randy From nobody Tue Feb 14 20:28:30 2017 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 ECB111299C9; Tue, 14 Feb 2017 20:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 tFTUx9ubHI4P; Tue, 14 Feb 2017 20:28:22 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69331299C4; Tue, 14 Feb 2017 20:28:22 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 534381398E; Wed, 15 Feb 2017 04:28:21 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1220447982A2; Tue, 14 Feb 2017 23:28:21 -0500 (EST) Date: Tue, 14 Feb 2017 23:28:20 -0500 From: Rob Austein To: "Kathleen Moriarty" In-Reply-To: <148709685964.10062.11055042165542175129.idtracker@ietfa.amsl.com> References: <148709685964.10062.11055042165542175129.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170215042821.1220447982A2@minas-ithil.hactrn.net> Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:28:24 -0000 At Tue, 14 Feb 2017 10:27:39 -0800, Kathleen Moriarty wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. The first question is more of a nit, > the second is more important. > > Section 9.1 > I suggest saying man-in-the-middle instead of monkey-in-the-middle as we > use the latter typically in documents and I don't think there's anything > particularly unique to a monkey-in-the-middle attack, but correct me if I > am wrong. I think it's just an alternate name for man-in-the-middle as > result of Dug Song's tool sniff on monkey.org. If monkey-in-the-middle > is important for some reason, could you include a reference? Authors are unrepentant middle-aged hippies who prefer to avoid gratuitously sexist language even when it is traditional. > Section 9.3 > Why isn't MD5 deprecated or discouraged more in this section? Unchanged from RFC 6810, as, sadly, is the implementation status of better channel security mechanisms on the relevant platforms. Since we have no realistic hope of belling that particular cat anytime soon, we did not think it productive to reopen that discussion. See discussion of Transport Security in Security Considerations. From nobody Wed Feb 15 02:58:06 2017 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 6D6FE1204D9; Wed, 15 Feb 2017 02:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=btconnect.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 dcO2tou1F__s; Wed, 15 Feb 2017 02:57:58 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC7B12952F; Wed, 15 Feb 2017 02:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+9wKR4W34yE2DSKTXTqB2AtdcdAb0d5EImNZqqwlvmI=; b=eetNoLTRIQcM4GYqqB+r5lOBKrJJjtcv3kALiHWEy0PNqV38DBUFJ9T13myBtqwgo6DL11xgw3YFUZ1T6y/4xosQO4MJL/mTSDxCRZFxtZoVaBqV3ekGxXREJG0hrDkvFh+f4eKHB5C37N/onetqd7lq0hRDme2NherUpoZHBNQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Wed, 15 Feb 2017 10:57:54 +0000 Message-ID: <050501d2877a$007393a0$4001a8c0@gateway.2wire.net> From: t.petch To: Alia Atlas , Rob Austein References: <148710840030.10070.11604926737704511161.idtracker@ietfa.amsl.com> <20170215040030.2E6C04798000@minas-ithil.hactrn.net> Date: Wed, 15 Feb 2017 10:39:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB6PR0301CA0023.eurprd03.prod.outlook.com (10.168.49.33) To AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) X-MS-Office365-Filtering-Correlation-Id: cb93ce6b-86a5-4087-55f7-08d455917ee6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:QPTZC1UwpSGXmW0suNpbNMr/QGetIwdwWP77G8ehGV+F972+IlWowoLnv7PShISlsrvt1CG9JcPkN15jfSXyySdy8CJ2lvl7felq+N6ruhAZYxkOD66FyF3HHAMy0MHQO4CpIL24Wq/6eL8Wz6F6++IMHGVO6Wdg0AT9gPQKEVkKgE1fVfX8NyJypul3eUYnPRo4PsVKjfBsyCzuh/hIZeMSX4o6cBqisEAnL13EZQFILlHDXdQ6vLylMYbpgdOGkPgO87glG2DQwrmrs7uu1Q==; 25:gLEiOdheAnwDbNS+lBVlByb6MuTlm7IeCjkFHq2vvu2HLEDsTDYWxTkThgppSaZVbipV+ha3YuzY2DZ7svrBfaIl+1YYIHQqHL+JrobUJDYluyPVIdUH5ycdfRjZsjmWcx+7AURGPnLTcbMVqlpNb3/1NqxUlJbAUdE8DUnO3eW81tkXkzy1GTN5AACIW6pGDoOQW9E7CielRdLgo1yarCXkuVHGMzW/Eo0EA4ohCLq9khz5QImlrWTMIZutlieN80AivHoKss9ftTvDG6Nr1zi8YB3Y4hMI3IA/fhQPRdQfHkRSl4Ju1ebQSwzlBNud/4CVcGc8qkzKV4jq4ahKBa9nW9MLfBEImmsixWdFNsMhW13SLrOlwFK0Czj4LJtIwJOaH01cZtmvYF8eJNh/z75ELUK4MVVzO8MKH4PXvryBozgvdrnpdPBSRvQXuY/zIVv/uihckBSYXKKbTZsoQw== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:lROMHYh1i4E0rZ0liWQkDFxaY3e5SJSbUz1LVhYA3vTHC0EsgBr27g6pZiQbvv/kxzLfmzGJWwB+eBZYcS2oTRN7nSTzxCQAQ7wR6d7dS6ENn+5yEiWuZHEBhpHnXHgC7RoP0krrkidqIzkZQOXEwkil2Ei4s6BguwYg4lJQSwlrSAnU1yd1Kf2YP+vEe118xGustVh+UPDX1B4KsUFuaITFrAZsZkIeXbsF1azhdPBdN5aWhp30OcMqza0O8hMRZE0JCkrCm6cRxa+95qk9bQ==; 4:Kts3kFPqvwdupX7BOaIlz23a7eTbkTwUQWRMWThbb0T7NyXcmvRsbNhAorBsbScMd49bMERc8+Z5uh+V6Ah6P5KZZSMrUJPciSAUOiDf9d6Q/q10MTW8wLHhlf99gKjDCLbM8Ow7KBKNYhp1O9/IY0cARid58p8Gy/12Y6wWhSfkXG3cvzv59NJH2vETAo1mh9Pyiu0Fy2abUIMaCXZlC2kYC3zfkwUkTdoasaLntPiv9EMrQqYQj8nxZw8fOXaTC9JfpBpUmGLZDr+pPpDWs/8KR4RXPHzkyldDAKckNloXyIoQzJII9dpYx+nbyFdCz9om4Rvb5iIchLHgb+FDb/yFRlRhjI58vL+YLKr4+BpTIJGALJV9b34+Gccyc4z7KOQpJRiqDLj+ARKi9sLQutfURBtrNY9FeHjSHJ7vSVPX5wEzOf8C6QJaXQiqGuxAnil+6nLGciRwSxpWuFm7CX/RlAzluv/FY+tvw8ZkuFoXnph82+AdaAvNZNh9UPf+zcab0jhOJQbO1UpV10u36HrNoyMM7A0MLOLEW+UyrYZJh+Tm/vKOAAi/kQM4gonsXQCgNWx0eyK8BS0ZwbppnPROjQ2LYgHGsNcqxx1VZpk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2993; X-Forefront-PRVS: 021975AE46 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(377454003)(24454002)(13464003)(189002)(199003)(47776003)(6666003)(50466002)(5820100001)(92566002)(44716002)(66066001)(62236002)(23676002)(25786008)(84392002)(230700001)(6246003)(4326007)(4720700003)(54906002)(6306002)(1456003)(1556002)(44736005)(6496005)(6486002)(389900002)(38730400002)(33646002)(5660300001)(189998001)(68736007)(9686003)(97736004)(105586002)(6116002)(229853002)(116806002)(3846002)(86362001)(230783001)(106356001)(61296003)(42186005)(53936002)(2906002)(50986999)(8676002)(81156014)(81166006)(101416001)(305945005)(14496001)(7736002)(50226002)(81686999)(81816999)(76176999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7MjM6bkhnUDBiMitYZnFTVXFWdjhVd1JVZjVt?= =?utf-8?B?MkF3MW1vMGFRalFQeWozRWdNQTl0TWFlbDc2NUxhWU5rcHBibDlyT1ZxVnM3?= =?utf-8?B?WU95TXhsMDV3ZGRUT09rUWs3aDRVN1BDbjdDRkoyYms0clBUMWgxUlRsZ1dF?= =?utf-8?B?eUk1bzdrSVE3ZUVWRmh5QVh0N1YxanVmZ2ZRTXVYeXFjcjF6QTB6SGJ1QS9H?= =?utf-8?B?RmZ2TnJDd05nMjFUclpSWjZHdFNOcDJYRWFmSnVhZnkwcU5xL3F2cWhQeUVl?= =?utf-8?B?aDVkZGJEWjhRSDdqZTJ5QVhrZisxd2NUQVhzWWxWNGc5azZjWngrdmpXdUlh?= =?utf-8?B?YUd5K0ZjbWRQVUU5djlDRHQrVFlwR2toZk56OTFrOStpWVpUYW9JRFVESDNO?= =?utf-8?B?djU3ZTVLckRxTGFkbEN2eGxLaE1ZYllwVEsyNitScHdlUGJML1BSS3pVZDJZ?= =?utf-8?B?bkdEZlBrTHRmcWJhOXB1cHcrTXA3MkZPV3R6NDhSRU1ZMWliY25seTQ3blFu?= =?utf-8?B?NklmLzcvQk5laXo5REhCSWUzSzFaTjFuSVFFbTBLbXZ6cDROSmtYRlUyNDA3?= =?utf-8?B?UDBHNXFVcHFtREVEd09WWTU3c1ZSTVFFcTlzM3UxQU5hZmw3NUNNdjFKS0tz?= =?utf-8?B?Mldqa0xtZkFacnZPMmxUaWlmNnlRL2JkT2tLRE9UYVMrSHFoS29IamFrNkpl?= =?utf-8?B?bzB1WWhJajRpbklFTUhNVFl0eU9TQ09OMXpJMXhaS1BoRlluTWIzZ1VFSzVh?= =?utf-8?B?VTNhUWdsc2VwNUJUSG1FdER6MFJBbUtrM1d5OFA0dnMxajhaZFNPVzlqbTVa?= =?utf-8?B?dTR4WDRuS1lsaWw2R3JDejhyL0htaGRURFM0a1c5bEhOdnZEZkVLV1BZUEx4?= =?utf-8?B?ZUhhSnVnOFUrM0FLTjZvRXJ0Z01lbnVpSjNtUlN5UldIWWJCZ0t3VFlERnBF?= =?utf-8?B?OVhRY3pHMC92dDR0TXlUV2dpa2syZGx6TWJCMDVYYnNudEtMS2wvdlYwYVdv?= =?utf-8?B?MFg3WCtRR1cvMVA0a2R4ak5LcS80SVdaUnFiV25EcUVBaFo5N0J5Y2NzTXcw?= =?utf-8?B?OG1ZUnBobEswOUxxdmovV0o1TEo4bDE2anBab0d6aGQ0Y0tUWmN5dFUrWHZo?= =?utf-8?B?elZKQ3h3T1dJTi85VmY2dEZ0bk1Wd296akpEdmRWd2RNL0FWQnM5VHdWdGVU?= =?utf-8?B?c2VReUVZbjgwYWZpdW5WQkZqbjlPWmpOT1VOTEdIODFVRTFtYWNOZDJ4clIy?= =?utf-8?B?cEljenZxTnVKbDRadXpJSXhLQzRZbUFBa0wxZzR4NTVyMHJGNHNxeEJjM1R0?= =?utf-8?B?Vmpid0xmY3F1UVJTSDgrTnRvd1RJUjY4MUhqWVRUZUQ3RCtDREY0YnRpS1NT?= =?utf-8?B?YnFwT0xjMWtqcXpMWnJScjZubHhCMFdZajRsaWhvVXpIS2Q1OWxHM1ZSZ3lU?= =?utf-8?B?QmZKdkI1R0tOL0oxUlRNMVNvYXhKdENtVFc4YUlYdW9pSTZmZ1J6VWxyelFv?= =?utf-8?B?bDVSaGRoZS93QUdUUFRrWWVmK2RDWkkrZWpybzIrMXpDKzlFRXNRTlc5cHJN?= =?utf-8?B?WmRSeERPdEZRQ1g2N1Baam1ObG5pSEVwc0liTTUreXR2dDdyYXBGZTNUWWxV?= =?utf-8?B?d3ZjSFBqWkljTGhCaitNaGhIU0xRSkJ4VE9Jc3d4YkZtWFVoUXdUUHFweWEx?= =?utf-8?B?anQvK0VSNEhBcU5ER0FBY3BBT25GeU91MG1hS3Era0N3RUxVdzlVOVlLcTVi?= =?utf-8?B?bkIvOHduNjhaV2p0MlZtaHQvRndiOW5xck9oRzRaUk01Y0loWGtLQnZGR0l1?= =?utf-8?B?K215UWM0YU9uZ2JIVlhPa0UxQmprTHdtWnNVUVZ4RmV2RzltZTZNbG9iSFJh?= =?utf-8?B?aTB3QS94bHVPR2VhMnN0dStwN0dNaUdIQ1dTUjVneDdhaFdMYWpDNEV0enNY?= =?utf-8?B?M3FSWHhjWXJQZVpMTE5WOEFWNWVSenNFdks0U0xNQ251N3JscnZCSlN6TWk3?= =?utf-8?B?UjNacCtGRVRCUFplVEdoQ25Id0c1YS9UU1h6bk5sZExaaDlHRGE1d3pSUzVL?= =?utf-8?Q?IwW0b0=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:e1ld429P5hyI0lLE5vkNJwA5yejD305+MUDxbU57hnU3BzSn5ySE7faEF2bpkJSGKqHr/vW4RAJ0qmA+8lgmP9+pJdXrq8fjSfnS5gDHBTbLggHzEwzhuE5DQV9oiDIifemE/fwtLBACAvzOn+0KXCL+b/3g1mDVHthzvAI8PX9cDAyD+O2jY8D/7cS2itmgMqFDwn0agvT1nKM0qhi7op3pdj7QwE9QZd8pYjL9fs8Pa+/aX/G19NdGGbv2TJ1qyyfxeWx53v9kXT+BEtsUK7NQ3GZhR6eXm4DZ8amIhMhhSiweV4JqlJ+BOnRl48H182fh1a5dTu1cZr+hLbKJALpsTO20MvkczSt6nh/SxGWSIkguv5xBfVxjyo/yh7+B9St5tZvfLTh3+iiGXfpmSA==; 5:yGTDdAmVAVgG4uMiwteaEEeiyZnmWSQN4DRB+frUiBuc8zveb6/gi+gyLHzKZN9RxwwRwfi0xm9vDECyn6RawZoGK02YsYSxBHDmLSNeGlfJZwPnGAxBqf/e8Xuyt3EKNhcyKN4J56Tp4+fvv8XUHw==; 24:SLZbIMM+OgeLbzsUzmevOKa0BSJQefHzEXXVT2wwPwIAED69JcBUkjVZfAv8ZOvx4iABa9qUORcEAmBzO0C1pA+RPBHHsPKyi2XpmE/SvPk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:J4CyCAvLVuEjhAyhoSPUbzxR6xH6IOi50qCSVnMI41EfiVuSCTg5wTAcXrrjmZLgilYG0eiy7WylRvsoEgtVElYtGTEbadmcANvsWjc+ATAiVnWV6+KWkQLWtxqfz2K5p1MbjmCbvYpL6N5cLY4V02N8DMxpPtNGMGuibFI1F6RI9tJeZTgyt1tKVTnNwSQLF0Wakn4/7V1QF70kdZPal/j/9nVk0EjPejZhJX7OMFuK46tsbn+S8r52YsuH+pSj4+vrUh34GCMH3YVesABRkm9qozuCDLLpbZ1wpQHMbtUAHB86quhB2KsJD5ASejTWJyHk9Al9xoiCx0cmdV3pOf51IF6lCBbHnhGwaBMAA2Rtbctl9yFTFAOodfnOMzTeKFs9j6SOf3F1REJ3s27p1KGEfYTox+E6/xLMhpKxuo5dedTwvfEXwEWlhhRUjPOWWjgZUZTe1Gt/r1pm8T0OY3cka1kzqmFHUjYWEDvo3T0CqlWv7xVH6HId90VxDo7DPKJ3MS4CmJZqxuvCMhvpKQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2017 10:57:54.7200 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Alia Atlas' No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:58:00 -0000 ----- Original Message ----- From: "Alia Atlas" To: "Rob Austein" Sent: Wednesday, February 15, 2017 4:03 A > On Tue, Feb 14, 2017 at 11:00 PM, Rob Austein wrote: > > > At Tue, 14 Feb 2017 13:40:00 -0800, Alia Atlas wrote: > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > This looks like it obsoletes RFC6810 or perhaps updates it. > > > The draft header should show this so RFC meta-data is accurate. > > > > The authors had a loooonng discussion about this with our AD. > > We will do whatever he tells us to do here. :) > > I am not at all surprised - and that is why this is a Comment and not a > Discuss. > IMHO, a new implementor would want to be pointed to the most recent version > of the protocol. That indicates to me that an Updates is the minimum. > Then, > well, I'd have to dig to see what we've done with protocol RFCs when we > advance > the version number. Obviously, OSPF is not a good example here :-) Alia SMIv2 and SMIv1 are both INTERNET STANDARD. SNMPv1 was not obsoleted but eventually declared HISTORIC many years later. YANG 1.1 has no defined relationship to YANG 1.0 I think it unusual for Version N+1 to do anything other then coexist with Version N. Sometimes there is another document that spells it out, such as RFC3584 for SNMP or 6087bis for YANG but a user might never know of them (well, quite a few do not judging by the posts). Tom Petch > Regards, > Alia > ------------------------------------------------------------------------ -------- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Wed Feb 15 08:00:59 2017 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 E51BF12960B; Wed, 15 Feb 2017 08:00:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Susan Hares To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717445293.17297.12773284406281280107.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 08:00:52 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-delta-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:00:53 -0000 Reviewer: Susan Hares Review result: Has Nits Rob, Tim, Oleg, Bryan: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status: Ready with NITS – Overall comment: Thank you for creating this draft that helps the SIDR RPKI repositories better. What I’ve checked (for OPS-AD/NM-ADs): Check texted, updates to other protocols The details are belowl Sue Hares ------------------------ Editorial NITS list: Overall –comment: Each of these nits has a sub-status a) Really needed – confusing – the document suffers from being confusing unless you fix it b) Style – your choice, but the style of the text made it a bit confusing c) Go Check – security section that is out of my depth as reviewer #1 comment, 3.3.2 Publishing Updates, p. 6 Status: really needed – confusing Why: You are describing the delta files and then the handling of the file is a different bullet. Please make it one format. Old:/ o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. o The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / New: / o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / #2, comment, 3.3.2, Publishing updates, p. 6 #2 Status; really needed – confusing Why: you are describing the snapshot and then the file handling. It should be one bullet. Old:/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. o The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / New/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / #3, comment, 3.3.2, Publishing updates, p. 6 Status: really needed – confusing Why: You are describing the notification files and then the file format. Old:/ o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. o The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / New: / o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / #4 section 3.4.1:entire section Status: style/confusing Comment: The first paragraph is the description of how Relying Party (RP) when it learns about a valid certificate with a SIA entry for the RRDP protocol. The section does not make it clear. Easy fix: Old/this protocol as follows/ New/this protocol as follows:/ + indent each paragraph as part of list #5 page 8 section 3.4.2 –general comment Status: really-needed The last paragraph “RP SHOUD NOT Remove objects”, the sentences as follows: The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest. If you suggest this, I suspect that all of you know what your implementations are doing. However, the specification is for other people who want to also implement this protocol or checks to this protocol. An example or a pointer to an example would be very useful. It does not break the protocol, so this did not rise to the level of “minor”. However it is piece of the specification you could tie down operationally. #6 page 14, section 3.5.3.3 – file format and validation Status: style/nice to have – makes it easier for reader. Old:/ Note that a formal RELAX NG specification of this file format is included later in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed./ New:/ Note that a formal RELAX NG specification of this file format is included in section 3.5.4 in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed. / #7 section 6, paragraph 3 status: Status: Please check with security person Paragraph: / Supporting both RRDP and rsync necessarily increases the number of opportunities for a malicious RPKI CA to perform denial of service attacks on relying parties, by expanding the number of URIs which the RP may need to contact in order to complete a validation run. However, other than the relative cost of HTTPS versus rsync, adding RRDP to the mix does not change this picture significantly: with either RRDP or rsync a malicious CA can supply an effectively infinite series of URIs for the RP to follow. The only real solution to this is for the RP to apply some kind of bound to the amount of work it is willing to do. Note also that the attacker in this scenario must be an RPKI CA, since otherwise the normal RPKI object security checks would reject the malicious URIs./ I’m really out of my depth to state how this works as security expert or As operational expert. It just raised questions of “oh really.. “ From nobody Wed Feb 15 08:06:22 2017 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 82BC2129647; Wed, 15 Feb 2017 08:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 08:06:17 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-s?= =?utf-8?q?idr-rpki-rtr-rfc6810-bis-08=3A_=28with_DISCUSS=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:06:17 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it. This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignor unknown types which is exactl what you want. There in this case I don't see that a new version necessary. Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that doublicating all the text is the best option. I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibily mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other calrification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice. From nobody Wed Feb 15 08:26:21 2017 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 A504B1298C1; Wed, 15 Feb 2017 08:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 CfMwj7RwrCDe; Wed, 15 Feb 2017 08:26:14 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3F2129661; Wed, 15 Feb 2017 08:26:14 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id C1BD61398E; Wed, 15 Feb 2017 16:26:12 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5C79447A4F05; Wed, 15 Feb 2017 11:26:11 -0500 (EST) Date: Wed, 15 Feb 2017 11:26:11 -0500 From: Rob Austein To: "Mirja Kuehlewind" In-Reply-To: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com> References: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170215162611.5C79447A4F05@minas-ithil.hactrn.net> Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf?= =?iso-8859-1?q?-sidr-rpki-rtr-rfc6810-bis-08=3A_=28with_DISCUSS=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:26:15 -0000 At Wed, 15 Feb 2017 08:06:17 -0800, Mirja Kuehlewind wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a general discuss on the principle of using extension mechanisms > (like versioning) and how and when to use it. > > This document increases the version number to add one new PDU type as > well as to clarify some questions on timing parameters. However, > versioning is just one extensibility mechanism out-of a whole set of > option. In this case the protocol also has an (8 bit) type field to > define new PDU types. Only 8 types are used so far (in version 0 of the > protocol) out of 2^8 which leaves another option for extending the > protocol. The usually specification here is that the receiver will ignore > unknown types which is exactl what you want. There in this case I don't > see that a new version necessary. The format of the End Of Data PDU also changed. > Further there is an issue on how the versioning is done. This document > looks like a bis document and used to obsolete the old spec till the last > version (-07) but now neither updates nor obsolete it. Correct. Our AD told us that we could not both obsolete version zero and specify how to fall back from version one to version zero. Please feel free to take this up with our AD. > If you actually decide to have a new version, that might be right > (also updating might be an option which I would actually recommend > in this case because I believe the expectation is that new > implementation should always implement this version) but I don't > really see in this case that doublicating all the text is the best > option. > > I would actually not recommend to increase the version because I really > don't see a need for this, given the (much easier) extensibily mechanism > you have with the type. If you'd only would like add the new type, then > actually a short draft that defines the type and updates rfc6810 would be > sufficient. Regarding the other calrification, I think this could also be > done in a short (potentially the same) updating draft. If you still think > it better to copy all the text and have one clean draft than obsoleting > is the right choice. From nobody Wed Feb 15 13:20:49 2017 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 25643129861; Wed, 15 Feb 2017 13:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 M5DDwbP3pKZY; Wed, 15 Feb 2017 13:20:39 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8FB124281; Wed, 15 Feb 2017 13:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8218; q=dns/txt; s=iport; t=1487193639; x=1488403239; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OFaZ8XXQl7lGVJaPYjoa2kI8lLQ3r/OFLOr4ZO8LYrM=; b=V8c+9XcDwKURUoOT7C3flbFfTHs6zryiaSH6kLjOdQF/8Fhqo6L5ypUt HLaWxdK1nQ2QOv9rPI5WnToWBprpItqa1zExyOtlMrla7TPrtW1qq9KEq DJlwnMVr7kDDsIbHIkjsgfl3R/LNfl/FoAxLjuHahe49vP8k6OcxZUhEg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAwBhxaRY/5tdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9jRxqBCQeDUooIohpRgkyCD4IMhiICGoF6PxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xBiNWEAIBCA4xAwICAjAUBgsCBAENBYlrsEWCJSuLCwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GTYIFgmqHWi6CMQWVVYYiAZITgXuFF4l0kxYBHziBAFEVTgGEaYF?= =?us-ascii?q?IdYlFgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208,217";a="180991269" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 21:20:38 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1FLKcSC026576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 21:20:38 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 15:20:37 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 15:20:37 -0600 From: "Alvaro Retana (aretana)" To: Rob Austein , Mirja Kuehlewind Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zaWRy?= =?utf-8?Q?-rpki-rtr-rfc6810-bis-08:_(with_DISCUSS)?= Thread-Index: AQHSh6WJGdr5LSSJWEuaTdEK84VyJaFqpbqA///+cYA= Date: Wed, 15 Feb 2017 21:20:37 +0000 Message-ID: References: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com> <20170215162611.5C79447A4F05@minas-ithil.hactrn.net> In-Reply-To: <20170215162611.5C79447A4F05@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CA62DA71CE9F484F9D131996A0457D52ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-s?= =?utf-8?q?idr-rpki-rtr-rfc6810-bis-08=3A_=28with_DISCUSS=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:20:44 -0000 --_000_CA62DA71CE9F484F9D131996A0457D52ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJvYiENCg0KDQpZZXMsIGluaXRpYWxseSB0aGlzIGRvY3VtZW50IHdhcyBtYXJrZWQg dG8gb2Jzb2xldGUgcmZjNjgxMCwgYnV0IGF0IHRoZSBzYW1lIHRpbWUgaXQgbWFuZGF0ZWQgdGhl IHVzZSBvZiB0aGUgcHJldmlvdXMgdmVyc2lvbiBhcyBwYXJ0IG9mIHRoZSBQcm90b2NvbCBWZXJz aW9uIE5lZ290aWF0aW9uLiAgR2l2ZW4gdGhhdCBpdCBtYXkgdGFrZSBhIHdoaWxlIGJlZm9yZSBj YWNoZXMgYW5kIHJvdXRlcnMgYm90aCBpbXBsZW1lbnQgdGhpcyBuZXcgdmVyc2lvbiwgd2UgZGVj aWRlZCB0byBzZXR0bGUgb24gbGVhdmluZyByZmM2ODEwIGFsb25lIGZvciBub3csIGFuZCBkZWNs YXJpbmcgaXQgSGlzdG9yaWMvT2Jzb2xldGUgbGF0ZXIgb24uDQoNCkFsdmFyby4NCg0KT24gMi8x NS8xNywgMTE6MjYgQU0sICJSb2IgQXVzdGVpbiIgPHNyYUBoYWN0cm4ubmV0PG1haWx0bzpzcmFA aGFjdHJuLm5ldD4+IHdyb3RlOg0KDQoNCkZ1cnRoZXIgdGhlcmUgaXMgYW4gaXNzdWUgb24gaG93 IHRoZSB2ZXJzaW9uaW5nIGlzIGRvbmUuIFRoaXMgZG9jdW1lbnQNCmxvb2tzIGxpa2UgYSBiaXMg ZG9jdW1lbnQgYW5kIHVzZWQgdG8gb2Jzb2xldGUgdGhlIG9sZCBzcGVjIHRpbGwgdGhlIGxhc3QN CnZlcnNpb24gKC0wNykgYnV0IG5vdyBuZWl0aGVyIHVwZGF0ZXMgbm9yIG9ic29sZXRlIGl0Lg0K DQpDb3JyZWN0LiAgT3VyIEFEIHRvbGQgdXMgdGhhdCB3ZSBjb3VsZCBub3QgYm90aCBvYnNvbGV0 ZSB2ZXJzaW9uIHplcm8NCmFuZCBzcGVjaWZ5IGhvdyB0byBmYWxsIGJhY2sgZnJvbSB2ZXJzaW9u IG9uZSB0byB2ZXJzaW9uIHplcm8uICBQbGVhc2UNCmZlZWwgZnJlZSB0byB0YWtlIHRoaXMgdXAg d2l0aCBvdXIgQUQuDQoNCg== --_000_CA62DA71CE9F484F9D131996A0457D52ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2FEDCE6DDD898F4CB46489DD8F221E73@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgUm9iITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlllcywgaW5pdGlhbGx5 IHRoaXMgZG9jdW1lbnQgd2FzIG1hcmtlZCB0byBvYnNvbGV0ZSByZmM2ODEwLCBidXQgYXQgdGhl IHNhbWUgdGltZSBpdCBtYW5kYXRlZCB0aGUgdXNlIG9mIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGFz IHBhcnQgb2YgdGhlIFByb3RvY29sIFZlcnNpb24gTmVnb3RpYXRpb24uJm5ic3A7IEdpdmVuIHRo YXQgaXQNCiBtYXkgdGFrZSBhIHdoaWxlIGJlZm9yZSBjYWNoZXMgYW5kIHJvdXRlcnMgYm90aCBp bXBsZW1lbnQgdGhpcyBuZXcgdmVyc2lvbiwgd2UgZGVjaWRlZCB0byBzZXR0bGUgb24gbGVhdmlu ZyByZmM2ODEwIGFsb25lIGZvciBub3csIGFuZCBkZWNsYXJpbmcgaXQgSGlzdG9yaWMvT2Jzb2xl dGUgbGF0ZXIgb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJvLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERG IDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE1 LzE3LCAxMToyNiBBTSwgJnF1b3Q7Um9iIEF1c3RlaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzcmFAaGFjdHJuLm5ldCI+c3JhQGhhY3Rybi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW47Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4IiBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCkZ1cnRoZXIgdGhlcmUgaXMgYW4gaXNzdWUg b24gaG93IHRoZSB2ZXJzaW9uaW5nIGlzIGRvbmUuIFRoaXMgZG9jdW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+bG9va3MgbGlrZSBhIGJpcyBkb2N1bWVudCBhbmQgdXNlZCB0byBv YnNvbGV0ZSB0aGUgb2xkIHNwZWMgdGlsbCB0aGUgbGFzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj52ZXJzaW9uICgtMDcpIGJ1dCBub3cgbmVpdGhlciB1cGRhdGVzIG5vciBvYnNvbGV0 ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNvcnJlY3QuJm5ic3A7Jm5ic3A7T3VyIEFE IHRvbGQgdXMgdGhhdCB3ZSBjb3VsZCBub3QgYm90aCBvYnNvbGV0ZSB2ZXJzaW9uIHplcm88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YW5kIHNwZWNpZnkgaG93IHRvIGZhbGwgYmFjayBm cm9tIHZlcnNpb24gb25lIHRvIHZlcnNpb24gemVyby4mbmJzcDsmbmJzcDtQbGVhc2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ZmVlbCBmcmVlIHRvIHRha2UgdGhpcyB1cCB3aXRoIG91 ciBBRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_CA62DA71CE9F484F9D131996A0457D52ciscocom_-- From nobody Wed Feb 15 15:45:31 2017 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 68410129BEA; Wed, 15 Feb 2017 15:45:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 15:45:27 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:45:27 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Review based on diff. [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc6810&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt - 5.1: To get around the hard-coded-sha1 thing could we do the same with the 20 byte SKI value as we did on some other recent RPKI spec? (IIRC, that was to say that if actual SKI is longer truncate left, and if shorter pad left with zero, but please check.) - section 9: What's the background to removing the statement that one of TCP-AO ssh etc SHOULD be used? What is the reality of deployments here? I assume it is not TCP-AO anyway but does TLS or SSH get used? - various places: I think 6810 was correct in using "that" and not "which" in many places. I realise that's a fairly frequent style thing that gets toggled though, but I bet the RFC editor sets a load of those back to "that" :-) From nobody Wed Feb 15 16:29:02 2017 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 C26BF129C1A; Wed, 15 Feb 2017 16:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 A0Qvr4AFTqUA; Wed, 15 Feb 2017 16:29:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7EFAB129C13; Wed, 15 Feb 2017 16:29:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ce9wN-00069f-Fe; Thu, 16 Feb 2017 00:28:55 +0000 Date: Thu, 16 Feb 2017 09:28:53 +0900 Message-ID: From: Randy Bush To: "Stephen Farrell" In-Reply-To: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> References: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:29:02 -0000 > - section 9: What's the background to removing the statement > that one of TCP-AO ssh etc SHOULD be used? What is the reality > of deployments here? I assume it is not TCP-AO anyway but does > TLS or SSH get used? TCP-AO never maaterialized. off-hand, i can not think of a way to measure who is using what, but i have this horrible suspicion it's all "it's all inside our domain of control, so let's just run nekkid." > - various places: I think 6810 was correct in using "that" and > not "which" in many places. I realise that's a fairly frequent > style thing that gets toggled though, but I bet the RFC editor > sets a load of those back to "that" :-) chicago style. the rfced and we amuse ourselves over that one. which is why rfced gets the big bucks. randy From nobody Wed Feb 15 16:45:15 2017 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 E153712960A; Wed, 15 Feb 2017 16:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 2FuQJeFC8Xnm; Wed, 15 Feb 2017 16:45:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD27F129407; Wed, 15 Feb 2017 16:45:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B9F1BE58; Thu, 16 Feb 2017 00:45:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi8rdNUW7y7J; Thu, 16 Feb 2017 00:45:05 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A3F7BE51; Thu, 16 Feb 2017 00:45:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487205904; bh=FWZnWsH6w5rvPpo+MlH0OVBM6pXe/LrqUTumyHEbsws=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Gg1c3nTgpPsZ5P8I+KhJhhJLSPKp3QPvcff1ldHW+FPYPZlY7QurBPgpmFJq7JUB1 TbLY8V2VlkOIgYou6QQRj1+BNZkhVonwjv5CWURsBwQqqx7jnOsEezv430aAU5Xs+B hwuGQH6xCaVRLNWrHFdqDwm7ykZdU171pjPAXbEM= To: Randy Bush References: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 16 Feb 2017 00:45:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hGCN5ljpumpdFX3Ifnu8heS1h9291h2xe" Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:45:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hGCN5ljpumpdFX3Ifnu8heS1h9291h2xe Content-Type: multipart/mixed; boundary="qXNIUAQPdjPhp3mHNkVR8QXPj3X9W3fK4"; protected-headers="v1" From: Stephen Farrell To: Randy Bush Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, aretana@cisco.com Message-ID: Subject: Re: Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) References: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> In-Reply-To: --qXNIUAQPdjPhp3mHNkVR8QXPj3X9W3fK4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/02/17 00:28, Randy Bush wrote: >> - section 9: What's the background to removing the statement >> that one of TCP-AO ssh etc SHOULD be used? What is the reality >> of deployments here? I assume it is not TCP-AO anyway but does >> TLS or SSH get used? >=20 > TCP-AO never maaterialized. >=20 > off-hand, i can not think of a way to measure who is using what, but i > have this horrible suspicion it's all "it's all inside our domain of > control, so let's just run nekkid." Yeah that's the concern. If the answer was "seems mostly folks use ssh" (or tls, or ipsec, whatever), I'd have asked if we could get away with at least a SHOULD-use for that. Such encouragement would be good IMO, if it's non-fiction. Cheers, S. >=20 >> - various places: I think 6810 was correct in using "that" and >> not "which" in many places. I realise that's a fairly frequent >> style thing that gets toggled though, but I bet the RFC editor >> sets a load of those back to "that" :-) >=20 > chicago style. the rfced and we amuse ourselves over that one. which > is why rfced gets the big bucks. >=20 > randy >=20 --qXNIUAQPdjPhp3mHNkVR8QXPj3X9W3fK4-- --hGCN5ljpumpdFX3Ifnu8heS1h9291h2xe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpPYPAAoJEC88hzaAX42i//QH/RQbbswcGzc8jFaIrkR8R/Kp M8fGPCIFKagHwMoVd/dD2FUoIccvYjG0/w+2XL1Y5gCWmDRNzpLb5sVClCXcW/uP gvX41/cDhKqErn9jK6T6/fHkbJF6ZwtZLXPHFUzGTLirPbQQ4pHIEFnjZxgbWWdW TCugTTezg1ZundnGRowSqzwx7FHcDd133hL9ockbdgcpfkqUdmzdH6tl5ZMevK52 S9KytS0X0VyhDHdLNxdupl0E9P01h8fhfzfkI9sPEbu0D7juaA2yYW1WWBlofg9s W51WE+Jky4Aeq/1snw2eBnnpof4M5DCGEznAj+m+mufzArjfPShKDbscti8g8Dw= =7Zvo -----END PGP SIGNATURE----- --hGCN5ljpumpdFX3Ifnu8heS1h9291h2xe-- From nobody Wed Feb 15 17:05:09 2017 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 130BC129C2C; Wed, 15 Feb 2017 17:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 GjNGh4cp5wN2; Wed, 15 Feb 2017 17:05:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EA959129C27; Wed, 15 Feb 2017 17:05:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ceAVJ-0006Lx-6x; Thu, 16 Feb 2017 01:05:01 +0000 Date: Thu, 16 Feb 2017 10:04:57 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: References: <148720232741.31605.15317084262605753406.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:05:07 -0000 >>> - section 9: What's the background to removing the statement >>> that one of TCP-AO ssh etc SHOULD be used? What is the reality >>> of deployments here? I assume it is not TCP-AO anyway but does >>> TLS or SSH get used? >> >> TCP-AO never maaterialized. >> >> off-hand, i can not think of a way to measure who is using what, but i >> have this horrible suspicion it's all "it's all inside our domain of >> control, so let's just run nekkid." > > Yeah that's the concern. If the answer was "seems mostly folks > use ssh" (or tls, or ipsec, whatever), I'd have asked if we > could get away with at least a SHOULD-use for that. > > Such encouragement would be good IMO, if it's non-fiction. i hack routers and servers daily to keep from becoming a complete bs artiste. so of course i tried setting up and running each transport. ssh was painful; key-based did not work for many platforms, ... no AO on any platform i could find. no TLS client side support. and there is a special hell where you have to do a device-diverse deployment of ipsec once a day ( smb has a student who did a good paper on this). luckily, ipv6 comes with secure transport built in. oh wait. i fear we are in yet another case of security software is not easy to use so we shift the blame to the user. we've gotten good at that. i think that all this is designed to make me happy to go back to hacking on a paper in latex. randy From nobody Wed Feb 15 18:03:25 2017 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 27F601294B7; Wed, 15 Feb 2017 18:03:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 18:03:19 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:03:19 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this work, it is clear and well written. While I have never (ever) been enamoured by RSYNC, and I much prefer this direction on a personal level, the updates to the existing RFCs regarding RSYNC does two things. The first is it demotes RSYNC to 'just another access mechanism', and the second is it appears to remove the quality of a mandatory to implement retrieval mechanism. Am I reading that correctly? If this is intentional and has workgroup consensus so be it and onwards we move.. From nobody Wed Feb 15 19:12:51 2017 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 8688112950B; Wed, 15 Feb 2017 19:12:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721476654.31580.4605680126089280302.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:12:46 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:12:46 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Mirja's questions about versioning, and whether this updates or obsoletes 6810. - 5, 2nd paragraph: Why is the SHOULD not a MUST? When might it make sense not to ignore the contents of a reserved field? - 5.1, 6th paragraph: I'm not sure I understand the use of the word "commensurate" in this context. - 9.2: Seems like a reference to RFC 7525 would be useful here. From nobody Wed Feb 15 19:31:07 2017 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 A66CF129507; Wed, 15 Feb 2017 19:31:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721586667.31507.17178698587667640093.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:31:06 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:31:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.4.1, 3rd paragraph: In a number of other protocols, a "User-Agent" header can be used for implementation fingerprinting, so that an attacker can guess what vulnerabilities might exist in that instance. Is that a concern here? - 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of fact than permission. - 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact as worded. From nobody Wed Feb 15 20:57:45 2017 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 8810412998B; Wed, 15 Feb 2017 20:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 pvALieEqdaum; Wed, 15 Feb 2017 20:57:42 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 258981294CC; Wed, 15 Feb 2017 20:57:42 -0800 (PST) X-AuditID: c618062d-d73ff700000009d8-4d-58a54149b445 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 58.27.02520.94145A85; Thu, 16 Feb 2017 07:06:05 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 23:57:37 -0500 From: Suresh Krishnan To: Randy Bush Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) Thread-Index: AQHShzxeULVw1W9ooEu0dmXhdYJP8KFpwzkAgAAD0gCAAAKYgIABnf6A Date: Thu, 16 Feb 2017 04:57:36 +0000 Message-ID: <616AA33D-2E97-4AB1-989C-050101160D9F@ericsson.com> References: <148712964461.10063.7241437094221866804.idtracker@ietfa.amsl.com> <20170215035234.BF6494796E81@minas-ithil.hactrn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_BACC9416-1FD0-4A4E-80F8-7239EB66A4C1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUyuXRPoK6v49IIg9PrBC3+/tzKaHH+5kY2 ixl/JjJbXF74kc3iWetLJovv8y+wWiybdJ7RYsrWdywOHB5Tfm9k9Wi7c5nJY8mSn0weDyYd ZfeYOnM2YwBrFJdNSmpOZllqkb5dAlfG+f8/WAteGFasnXuJqYFxl34XIweHhICJxMdVWV2M XBxCAusZJZbMWcPexcgJ5CxnlLi9HcxmA6rZsPMzE4gtIiAncfHEO0aQBmaB40wSn49PBCsS FsiQeLb5NjtEUabEuYltjCALRATcJD6d0QMJswioSjR+n8UCYvMK2EtM3fOUDWLxLUaJ1d2N YL2cAloSnSsPgC1jFBCT+H5qDZjNLCAucevJfDBbQkBE4uHF02wQtqjEy8f/WCFsJYmPv+ez Q9RPYZTofFsFsUxQ4uTMJywTGEVmIRk1C0nZLCRlEHF5ie1v5zDPAnqBWUBHYvJCRoiwqcTr ox+hbGuJGb8OskHYihJTuh+yL2DkWMXIUVpckJObbmSwiREYrcck2HR3MN6f7nmIUYCDUYmH 12Dpkggh1sSy4srcQ4wqQK2PNqy+wCjFkpefl6okwtvGvDRCiDclsbIqtSg/vqg0J7X4EKM0 B4uSOG/c6vvhQgLpiSWp2ampBalFMFkmDk6pBsa+Sz9jDs2Yxe38OIlh0x4DmRd7In08u7gu +kiWLM0xF9W5sp352QdfwSPHL2w/pvxo4rz0z4pbvVzrVRjkGi7v23PDiSnqr7DFuTJWHQkn 06cfeDpUDRYcXre9YrlRcnzJsd3iK7cJHquJ33ayP+Oeg9KcWU/in7gvtDn+Xk+aa4pUZ/70 5V+VWIozEg21mIuKEwG1z6PE3gIAAA== Archived-At: Cc: "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , Rob Austein , Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 04:57:43 -0000 --Apple-Mail=_BACC9416-1FD0-4A4E-80F8-7239EB66A4C1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Feb 14, 2017, at 11:15 PM, Randy Bush wrote: > >> why is there no associated error checking for the Max Length field in >> the IPvX PDUs > > it is assumed any error checking was done *before* they are sent to the > router. a major goal of this protocol is to relieve the router of any > load. so, if field consistency is to be done, it should be in the > protocols at the rpki level, e.g. at the latest when the cache receives > and validates the data. OK. Sounds good to me. Thanks Suresh --Apple-Mail=_BACC9416-1FD0-4A4E-80F8-7239EB66A4C1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE2MDQ1NzE1WjAjBgkqhkiG9w0B CQQxFgQUAbApDTofWNWKK751UFfNFkSqfkEwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQCEKnQBUn80HF2Oj5v/2mdh6wdFcDimSFo+hUJ5DlvGja29fYp/mbQCnoHme681 2sIr7e06tRqpcUTcg0u/phhzNda5yjRzuQJOOopN6lJ1UBItD2ovlrXO9HIgWYxJ0DvAmErC0rFA Zw9PK/YvMr2NRyT+YmEomc2qwdZbuZEXXsAykMn0TvjV9S99u0stl4WYN2PCelLO3LLSfaMjDe7E mZK04+6kOMsvjbheSY983+zGYj0nqMgdqsJoZE6VnB5sgkbJ1dosxcMAquyOfibnt3f2Ib0Jm+O7 kBIcvtEv8lDQp8XTWnEFgxpy9DMvbS+49oXCfxZnxA3lkKvYlvSjAAAAAAAA --Apple-Mail=_BACC9416-1FD0-4A4E-80F8-7239EB66A4C1-- From nobody Wed Feb 15 21:47:55 2017 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 7BEFC1295AC; Wed, 15 Feb 2017 21:47:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 21:47:46 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 05:47:46 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I’m not skilled in the art of RPKI, so perhaps I lack imagination, but I'm not understanding why these two SHOULDs aren't MUSTs. I'm not asking for a change, but if the document included explanations of why an implementation might not do the SHOULDs, some readers might thank you. The RP SHOULD add all publish elements to a local storage and update its last processed serial number to the serial number of this delta file. The RP SHOULD NOT remove objects from its local storage solely because it encounters a "withdraw" element, because this would enable a publication server to withdraw any object without the signing Certificate Authority consent. The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest. From nobody Thu Feb 16 01:55:49 2017 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 42104129408; Thu, 16 Feb 2017 01:55:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148723894826.15933.1431914927618532341.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 01:55:48 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 09:55:48 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well written document. I share Mirja's concern about versioning, her concern is related to my comment below. Regarding obsoleting the original RFC: I am Ok with not doing that if both are going to be used at the same time, but I would like to hear from the WG whether this is the case. I have one small issue I would like to discuss: In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change. From nobody Thu Feb 16 05:32:57 2017 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 ADFB7129602; Thu, 16 Feb 2017 05:32:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725196870.15981.9618737956860413364.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 05:32:48 -0800 Archived-At: Cc: skh@ndzh.com, morrowc@ops-netman.net, sidr-chairs@ietf.org, sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:32:49 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sue Harres' OPS DIR review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status: Ready with NITS – Overall comment: Thank you for creating this draft that helps the SIDR RPKI repositories better. What I’ve checked (for OPS-AD/NM-ADs): Check texted, updates to other protocols The details are belowl Sue Hares ------------------------ Editorial NITS list: Overall –comment: Each of these nits has a sub-status a) Really needed – confusing – the document suffers from being confusing unless you fix it b) Style – your choice, but the style of the text made it a bit confusing c) Go Check – security section that is out of my depth as reviewer #1 comment, 3.3.2 Publishing Updates, p. 6 Status: really needed – confusing Why: You are describing the delta files and then the handling of the file is a different bullet. Please make it one format. Old:/ o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. o The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / New: / o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / #2, comment, 3.3.2, Publishing updates, p. 6 #2 Status; really needed – confusing Why: you are describing the snapshot and then the file handling. It should be one bullet. Old:/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. o The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / New/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / #3, comment, 3.3.2, Publishing updates, p. 6 Status: really needed – confusing Why: You are describing the notification files and then the file format. Old:/ o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. o The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / New: / o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / #4 section 3.4.1:entire section Status: style/confusing Comment: The first paragraph is the description of how Relying Party (RP) when it learns about a valid certificate with a SIA entry for the RRDP protocol. The section does not make it clear. Easy fix: Old/this protocol as follows/ New/this protocol as follows:/ + indent each paragraph as part of list #5 page 8 section 3.4.2 –general comment Status: really-needed The last paragraph “RP SHOUD NOT Remove objects”, the sentences as follows: The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest. If you suggest this, I suspect that all of you know what your implementations are doing. However, the specification is for other people who want to also implement this protocol or checks to this protocol. An example or a pointer to an example would be very useful. It does not break the protocol, so this did not rise to the level of “minor”. However it is piece of the specification you could tie down operationally. #6 page 14, section 3.5.3.3 – file format and validation Status: style/nice to have – makes it easier for reader. Old:/ Note that a formal RELAX NG specification of this file format is included later in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed./ New:/ Note that a formal RELAX NG specification of this file format is included in section 3.5.4 in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed. / #7 section 6, paragraph 3 status: Status: Please check with security person Paragraph: / Supporting both RRDP and rsync necessarily increases the number of opportunities for a malicious RPKI CA to perform denial of service attacks on relying parties, by expanding the number of URIs which the RP may need to contact in order to complete a validation run. However, other than the relative cost of HTTPS versus rsync, adding RRDP to the mix does not change this picture significantly: with either RRDP or rsync a malicious CA can supply an effectively infinite series of URIs for the RP to follow. The only real solution to this is for the RP to apply some kind of bound to the amount of work it is willing to do. Note also that the attacker in this scenario must be an RPKI CA, since otherwise the normal RPKI object security checks would reject the malicious URIs./ I’m really out of my depth to state how this works as security expert or As operational expert. It just raised questions of “oh really.. “ From nobody Thu Feb 16 05:48:25 2017 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 AEEF8126BF7; Thu, 16 Feb 2017 05:48:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725290471.15905.9914176554016381260.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 05:48:24 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:48:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.5.1.3: hard-coding a hash algorithm again? Why is that a good idea? sha256 is the right hash to choose today, but having to rev the rrdp version to move to some other hash alg seems like a bad plan. I suggest you either add a "hashalg" attribute to the xml or else use a ni schemed URI for the value of the uri attribute (or something along those lines). Same thing in 3.5.3.3. From nobody Thu Feb 16 06:31:20 2017 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 DF71D129605; Thu, 16 Feb 2017 06:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 79y7bP1KR87j; Thu, 16 Feb 2017 06:31:12 -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 856541294D7; Thu, 16 Feb 2017 06:31:12 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ceN5L-0005ZT-TW; Thu, 16 Feb 2017 15:31:05 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-196.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ceN5L-0008DU-PD; Thu, 16 Feb 2017 15:31:03 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <148721586667.31507.17178698587667640093.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 15:31:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE13EA4-CFDF-4FF0-BC4C-88CE7323571A@ripe.net> References: <148721586667.31507.17178698587667640093.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0002] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c066571be4ee67e09ece1face6815a53 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:31:19 -0000 Dear Ben, all, > On 16 Feb 2017, at 04:31, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-sidr-delta-protocol-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - 3.4.1, 3rd paragraph: In a number of other protocols, a "User-Agent" > header can be used for implementation fingerprinting, so that an = attacker > can guess what vulnerabilities might exist in that instance. Is that a > concern here? TL;DR: This is not strictly required by the delta protocol and can be taken out = if big concerns exist. But I believe that this will help with = operational planning of changes in RPKI standards. I do not see big = security concerns - obviously if I did I would not have insisted to my = co-authors that we should have this :) Longer: The "User-Agent" was introduced here solely to help capability tracking = that may help in operations of *other* changes in the RPKI standards. For example: validation-reconsidered introduces new OIDs that when = present will lead to current RPs rejecting objects that use them. If = this happens at the trust anchor level that can be problematic. Because = of this, the reconsidered document includes an intended timeline where = RP software MUST be updated with this capability before CAs MAY use = this. A timeline is one way to do this, but being able to also actually = track if updated RP software is really deployed is useful. Similarly capability tracking can help with other (currently unplanned) = changes in the RPKI: new object types, or changes to existing ones. And = it can help if we ever need to do an algorithm roll-over, e.g. to = elliptic-curve instead of RSA - then again knowing which proportion of = RPs supports the new algorithm can help. On the other hand I do not see a huge security concern with this because = even though Repository Servers would know which version of RP software = is deployed where, they would not be able to attack them easily because = RPs can normally be contacted only inside the trusted network where they = are operated: e.g. routers using rpki-rtr. > - 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of fact > than permission. yes, but whether the files *are* cached is a choice, so I thought a = normative MAY was in order. I don't particularly mind changing this = though, because I don't think it will lead to ambiguity. >=20 > - 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact = as > worded. >=20 I am not sure that I understand your comment. We RECOMMEND that RP software polls the Update Notification File for = changes. We believe that is useful to mention here because new = implementations may find it useful and it sends a message to Repository = Servers that they should be prepared to deal with this. However, another strategy can also be used. For example the current RIPE = NCC RPKI Validator will actually re-trigger a complete validation = process every X (configurable) minutes and then try to fetch updates. = This works, but is somewhat resource intensive for the RP. Would it be better if we did not RECOMMEND, but rather said something = like this? RPs MAY poll the Update Notification File for changes, so that a = potentially resource intense RPKI validation process can be avoided if = there is no new content available. From nobody Thu Feb 16 07:15:58 2017 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 235281293DF; Thu, 16 Feb 2017 07:15:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725815613.16000.13759828131194056664.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 07:15:56 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-rpki-rtr-rfc6810-bis-08=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:15:56 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: 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-rtr-rfc6810-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document should update rfc6810 as discussed with responsible AD. Here is my old discuss for the record: This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it. This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignore unknown types which is exactly what you want. There in this case I don't see that a new version necessary. Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that duplicating all the text is the best option. I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibility mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other clarification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice. From nobody Thu Feb 16 07:17:40 2017 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 2E594129509; Thu, 16 Feb 2017 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 yDVEabBEGBUU; Thu, 16 Feb 2017 07:17:37 -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 8E2351293DF; Thu, 16 Feb 2017 07:17:37 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ceNoM-0009oD-G4; Thu, 16 Feb 2017 16:17:35 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-196.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ceNoM-0004lK-BO; Thu, 16 Feb 2017 16:17:34 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 16:17:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0001] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719dba7a7c4e2256e22ff301fcd746ad50e Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:17:39 -0000 Hi Terry, all, > On 16 Feb 2017, at 03:03, Terry Manderson = wrote: >=20 > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-delta-protocol-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for this work, it is clear and well written. While I have = never > (ever) been enamoured by RSYNC, and I much prefer this direction on a > personal level, the updates to the existing RFCs regarding RSYNC does = two > things. The first is it demotes RSYNC to 'just another access = mechanism', > and the second is it appears to remove the quality of a mandatory to > implement retrieval mechanism. Am I reading that correctly? If this is > intentional and has workgroup consensus so be it and onwards we move.. Initially this was written as an additional protocol, next to rsync. The = idea was that rsync would be replaced altogether at some point, but the = way to get there was intentionally left out of this document because we = felt it should just focus on protocol. The changes you mention were made following AD review comments on 7 = January. The intent as I understood it was to defer the question which = retrieval mechanism is mandatory to another document, but leave the = specifications generic.=20 In itself I understood that this is okay. Because current deployment can = follow the unaltered specifications. It does leave the question of = defining this better for future implementation though - to make RRDP = formally usable. I am not sure how to deal with this and would value = direction :) I believe we need 'something' saying that: - currently: =3D rsync is mandatory =3D RRDP is allowed as an additional mechanism - on date x: =3D RRDP is mandatory and rsync is no longer allowed =3D at this point we will also need to address the "URI" in the = publication protocol I am not sure if that A) needs to be described in one migration document = with a time line, or that B) it would be better to do something similar = to RFC7935 (defining algorithms and key sizes) and have a document that = describes the "currently" required and allowed retrieval mechanisms and = update it in due time. And I may be missing options C, D, etc here. Myself I am leaning to doing B in sidr-ops, but again pointers are = appreciated. Thanks Tim >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Feb 16 07:26:27 2017 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 89466129494; Thu, 16 Feb 2017 07:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 NbwkGfvRv6G8; Thu, 16 Feb 2017 07:26:20 -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 EBD75129A55; Thu, 16 Feb 2017 07:26:19 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ceNwn-000ARG-2S; Thu, 16 Feb 2017 16:26:18 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-196.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ceNwm-0007ak-TT; Thu, 16 Feb 2017 16:26:16 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 16:26:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e647353be331b8a7f0fa972199101457 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:26:21 -0000 Hi Spencer, all, On 16 Feb 2017, at 06:47, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-sidr-delta-protocol-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I=E2=80=99m not skilled in the art of RPKI, so perhaps I lack = imagination, but > I'm not understanding why these two SHOULDs aren't MUSTs. I'm not = asking > for a change, but if the document included explanations of why an > implementation might not do the SHOULDs, some readers might thank you. >=20 > The RP SHOULD add all publish elements to a local storage and > update its last processed serial number to the serial number of > this delta file. corner cases: the RP already added this same object so strictly speaking = it's1 already there, the object is 5TB in size? I don't think I can = enumerate all corner cases, and believe the document should not try to = go there. >=20 > The RP SHOULD NOT remove objects from its local storage solely > because it encounters a "withdraw" element, because this would > enable a publication server to withdraw any object without the > signing Certificate Authority consent. The RP could use > additional strategies to determine if an object is still relevant > for validation before removing it from its local storage. In > particular objects should not be removed if they are included in > a > current validated manifest. I can live with a "MUST NOT remove" here, but not sure that others = agree. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Feb 16 08:20:00 2017 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 DA52F1294B5; Thu, 16 Feb 2017 08:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 0QwrCLAYf6UK; Thu, 16 Feb 2017 08:19:48 -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 9FCFB12949B; Thu, 16 Feb 2017 08:19:48 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ceOmX-0009Gv-Ia; Thu, 16 Feb 2017 17:19:46 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ceOmW-0002eJ-Dc; Thu, 16 Feb 2017 17:19:44 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Oleg Muravskiy In-Reply-To: Date: Thu, 16 Feb 2017 17:19:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74eaab4746766417fce4b6a387fe00cb53 Archived-At: Cc: morrowc@ops-netman.net, sidr chairs , Spencer Dawkins , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, The IESG Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:19:55 -0000 Hi Tim, all, > On 16 Feb 2017, at 16:26, Tim Bruijnzeels wrote: >=20 > Hi Spencer, all, >=20 > On 16 Feb 2017, at 06:47, Spencer Dawkins = wrote: >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I=E2=80=99m not skilled in the art of RPKI, so perhaps I lack = imagination, but >> I'm not understanding why these two SHOULDs aren't MUSTs. I'm not = asking >> for a change, but if the document included explanations of why an >> implementation might not do the SHOULDs, some readers might thank = you. >>=20 >> The RP SHOULD add all publish elements to a local storage and >> update its last processed serial number to the serial number of >> this delta file. >=20 > corner cases: the RP already added this same object so strictly = speaking it's1 already there, the object is 5TB in size? I don't think I = can enumerate all corner cases, and believe the document should not try = to go there. >=20 >>=20 >> The RP SHOULD NOT remove objects from its local storage solely >> because it encounters a "withdraw" element, because this would >> enable a publication server to withdraw any object without the >> signing Certificate Authority consent. The RP could use >> additional strategies to determine if an object is still relevant >> for validation before removing it from its local storage. In >> particular objects should not be removed if they are included in >> a >> current validated manifest. >=20 > I can live with a "MUST NOT remove" here, but not sure that others = agree. I wouldn't go for MUST here, because, strictly speaking, there might not = even be a local cache, it depends on how the validation is implemented. We could either say "NOT RECOMMENDED ... if the local cache is used", or = change this whole paragraph to a non-normative text, and possibly move = it to Security Considerations. And in this case the previous paragraph could change into "MUST update = its last processed serial number", leaving the local cache out. Oleg= From nobody Thu Feb 16 09:22:14 2017 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 9F7D31294B9; Thu, 16 Feb 2017 09:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 lQK81A3O-_jR; Thu, 16 Feb 2017 09:22:11 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 3DAED129483; Thu, 16 Feb 2017 09:22:11 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id w194so6137049ybe.0; Thu, 16 Feb 2017 09:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JCR3Qn1GYWFZ31lgC2sKExmAvoR3VpgvBOvFgiQhgAc=; b=N9CFLTGQnF1uGS8x8rkJ+dpqTmu5TCL1ZQ7rtEYlmLX78qBvMTBXKChE3Gf3BGkPUn ZybysIyPdFS7GSGEcLE0g+YAaBd3/R9TwCeyvwQd1Q7tDg1uI3/p4/I6F++RVUpPf8og xyyKu1+5NOKUv4Q+Uov386H6d2Gq9JV9frvjgZS7v0RiujXnNR7GBfCzIB7h+OicgEUG bjA549ACqO4TeX4a7pr60DthvlIHI+ia28MK8mx2tTjDzWwHeW3IptThzUUleun6P9Re s7B98lP4+CBL9x6BzZHa0q8/9tA/5a4/jWBYyUMeB2UFPYmPUQbzoE30ywmkPbQ/Lc6T NgpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JCR3Qn1GYWFZ31lgC2sKExmAvoR3VpgvBOvFgiQhgAc=; b=hTd64i/+U4RENw2kROeV4bPFAmd4itugwVQboVbmXCqI3MMIOaUrMbQdVMkgnVpiUg Fgup56eP+iNniA0WCsrPx5R3ptt7t0LOVji9UIlNrp+SK3PqZXyK9i4NA2hvEVja3Vh1 Fi6gYZrtySpUgc2mK71/4quGDcKCLFIYNJ4ET6yxqKfrKbUbKANKLAIFBTu52x8WmaoB cY+Z/bB5iqtvyxrOivBnSY9+s7nMk43t5UA2t8K/Rdkx/DP82ZLjCCOPGATKLTZfkFiF casJHuUVifMyowwnaYr23OeMxQtNswu815pTVyX6D2uFukvpRAW15q/PtxiGrHoNePcF 1/ag== X-Gm-Message-State: AMke39kR2zZS1bh0l+YlfmcFapFrKdCeQe43cUMiAMINREC+Zqc+++GwNhlaNd8ZWNW9II2qSxYUzXF4dzUMLQ== X-Received: by 10.37.44.199 with SMTP id s190mr2466547ybs.22.1487265730333; Thu, 16 Feb 2017 09:22:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.234.9 with HTTP; Thu, 16 Feb 2017 09:22:09 -0800 (PST) In-Reply-To: References: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 16 Feb 2017 11:22:09 -0600 Message-ID: To: Tim Bruijnzeels Content-Type: multipart/alternative; boundary=001a114320908b330e0548a90983 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr wg list Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:22:12 -0000 --001a114320908b330e0548a90983 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Tim (responding here, but I also saw Oleg's reply), On Thu, Feb 16, 2017 at 9:26 AM, Tim Bruijnzeels wrote: > Hi Spencer, all, > > On 16 Feb 2017, at 06:47, Spencer Dawkins > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-sidr-delta-protocol-07: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I=E2=80=99m not skilled in the art of RPKI, so perhaps I lack imaginati= on, but > > I'm not understanding why these two SHOULDs aren't MUSTs. I'm not askin= g > > for a change, but if the document included explanations of why an > > implementation might not do the SHOULDs, some readers might thank you. > > > > The RP SHOULD add all publish elements to a local storage and > > update its last processed serial number to the serial number of > > this delta file. > > corner cases: the RP already added this same object so strictly speaking > it's1 already there, the object is 5TB in size? I'm sorry this wasn't clear - the SHOULD applies to two actions ("and"), and I was thinking about the second action. Why would an implementation not update its last processed serial number? Would things still work? I agree that many RPs might not have a few terabytes lying around ... > I don't think I can enumerate all corner cases, and believe the document > should not try to go there. Agreed. I was trying to understand what a corner case would look like, not asking for a complete list of all corner cases. > > > > The RP SHOULD NOT remove objects from its local storage solely > > because it encounters a "withdraw" element, because this would > > enable a publication server to withdraw any object without the > > signing Certificate Authority consent. The RP could use > > additional strategies to determine if an object is still relevant > > for validation before removing it from its local storage. In > > particular objects should not be removed if they are included in > > a > > current validated manifest. > > I can live with a "MUST NOT remove" here, but not sure that others agree. > I saw that Oleg replied "but what if you don't even have local storage?" That's fair, but is that the only reason this isn't a MUST? Removing an object without consent from the signing Certificate Authority just seems unfortunate, and the SHOULD allows that. And thanks for the quick responses, both of you. Spencer > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > --001a114320908b330e0548a90983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tim (responding here, but I also saw Oleg's reply)= ,

On Thu, Feb 16, = 2017 at 9:26 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
Hi Spencer, all,

On 16 Feb 2017, at 06:47, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-sidr-delta-protocol-07: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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-delta-protocol/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I=E2=80=99m not skilled in the art of RPKI, so perhaps I lack imaginat= ion, but
> I'm not understanding why these two SHOULDs aren't MUSTs. I= 9;m not asking
> for a change, but if the document included explanations of why an
> implementation might not do the SHOULDs, some readers might thank you.=
>
>=C2=A0 =C2=A0 =C2=A0The RP SHOULD add all publish elements to a local s= torage and
>=C2=A0 =C2=A0 =C2=A0 update its last processed serial number to the ser= ial number of
>=C2=A0 =C2=A0 =C2=A0 this delta file.

corner cases: the RP already added this same object so strictly spea= king it's1 already there, the object is 5TB in size?
=
I'm sorry this wasn't clear - the SHOULD applies to = two actions ("and"), and I was thinking about the second action. = Why would an implementation not update its last processed serial number? Wo= uld things still work?

I agree that many RPs might= not have a few terabytes lying around ...
=C2=A0
I don't think I can enumerate all corner cases, an= d believe the document should not try to go there.

Agreed. I was trying to understand what a corner case would look li= ke, not asking for a complete list of all corner cases.
=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 The RP SHOULD NOT remove objects from its local st= orage solely
>=C2=A0 =C2=A0 =C2=A0 because it encounters a "withdraw" eleme= nt, because this would
>=C2=A0 =C2=A0 =C2=A0 enable a publication server to withdraw any object= without the
>=C2=A0 =C2=A0 =C2=A0 signing Certificate Authority consent.=C2=A0 The R= P could use
>=C2=A0 =C2=A0 =C2=A0 additional strategies to determine if an object is= still relevant
>=C2=A0 =C2=A0 =C2=A0 for validation before removing it from its local s= torage.=C2=A0 In
>=C2=A0 =C2=A0 =C2=A0 particular objects should not be removed if they a= re included in
> a
>=C2=A0 =C2=A0 =C2=A0 current validated manifest.

I can live with a "MUST NOT remove" here, but not sure tha= t others agree.

I saw that Oleg replied= "but what if you don't even have local storage?"=C2=A0
=

That's fair, but is that the only reason this isn&#= 39;t a MUST? Removing an object without consent from the signing Certificat= e Authority just seems unfortunate, and the SHOULD allows that.
<= br>
And thanks for the quick responses, both of you.
Spencer
=C2=A0
&= gt;
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

--001a114320908b330e0548a90983-- From nobody Thu Feb 16 14:50:45 2017 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 CFEFF129632; Thu, 16 Feb 2017 14:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UL68ur462uBJ; Thu, 16 Feb 2017 14:50:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 807CE124281; Thu, 16 Feb 2017 14:50:39 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1GMobWW043386 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Feb 2017 16:50:38 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Tim Bruijnzeels" Date: Thu, 16 Feb 2017 16:50:36 -0600 Message-ID: <8B6A4F38-3C47-4EA2-92FC-BCA71EFEB947@nostrum.com> In-Reply-To: <6FE13EA4-CFDF-4FF0-BC4C-88CE7323571A@ripe.net> References: <148721586667.31507.17178698587667640093.idtracker@ietfa.amsl.com> <6FE13EA4-CFDF-4FF0-BC4C-88CE7323571A@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:50:41 -0000 Hi, thanks for the response. Please see comments inline. Thanks! Ben. On 16 Feb 2017, at 8:31, Tim Bruijnzeels wrote: > Dear Ben, all, > > >> On 16 Feb 2017, at 04:31, Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-sidr-delta-protocol-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - 3.4.1, 3rd paragraph: In a number of other protocols, a >> "User-Agent" >> header can be used for implementation fingerprinting, so that an >> attacker >> can guess what vulnerabilities might exist in that instance. Is that >> a >> concern here? > > TL;DR: > > This is not strictly required by the delta protocol and can be taken > out if big concerns exist. But I believe that this will help with > operational planning of changes in RPKI standards. I do not see big > security concerns - obviously if I did I would not have insisted to my > co-authors that we should have this :) > > Longer: > > The "User-Agent" was introduced here solely to help capability > tracking that may help in operations of *other* changes in the RPKI > standards. > > For example: validation-reconsidered introduces new OIDs that when > present will lead to current RPs rejecting objects that use them. If > this happens at the trust anchor level that can be problematic. > Because of this, the reconsidered document includes an intended > timeline where RP software MUST be updated with this capability before > CAs MAY use this. A timeline is one way to do this, but being able to > also actually track if updated RP software is really deployed is > useful. > > Similarly capability tracking can help with other (currently > unplanned) changes in the RPKI: new object types, or changes to > existing ones. And it can help if we ever need to do an algorithm > roll-over, e.g. to elliptic-curve instead of RSA - then again knowing > which proportion of RPs supports the new algorithm can help. > > On the other hand I do not see a huge security concern with this > because even though Repository Servers would know which version of RP > software is deployed where, they would not be able to attack them > easily because RPs can normally be contacted only inside the trusted > network where they are operated: e.g. routers using rpki-rtr. There is a mention in the security considerations that the repository is not trusted. I recognize the risk is not high. Making User-Agent a SHOULD is not my favorite thing, but I'm not going to push the point. Do I understand correctly that RRDP is only defined for use with TLS? (Did I miss a MUST NOT use without TLS requirement)? If there's any chance of using this without TLS, then it might be worth a security consideration mention. > >> - 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of >> fact >> than permission. > > yes, but whether the files *are* cached is a choice, so I thought a > normative MAY was in order. I don't particularly mind changing this > though, because I don't think it will lead to ambiguity. My point is the fact people can do that is natural outcome of the fact the files do not change. You aren't offering permission so much as noting the possibility. But I will leave the choice to you. > >> >> - 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact >> as >> worded. >> > > I am not sure that I understand your comment. > > We RECOMMEND that RP software polls the Update Notification File for > changes. We believe that is useful to mention here because new > implementations may find it useful and it sends a message to > Repository Servers that they should be prepared to deal with this. > > However, another strategy can also be used. For example the current > RIPE NCC RPKI Validator will actually re-trigger a complete validation > process every X (configurable) minutes and then try to fetch updates. > This works, but is somewhat resource intensive for the RP. > > Would it be better if we did not RECOMMEND, but rather said something > like this? > > RPs MAY poll the Update Notification File for changes, so that a > potentially resource intense RPKI validation process can be avoided if > there is no new content available. So this is was just a very pedantic NIT about the use of 2119 keywords, where the sentence makes it sound like the fact of the recommendation comes from some authority other than the sentence itself. But on re-reading it, I don't think it creates ambiguity. It's probably not worrying about. From nobody Fri Feb 17 06:56:47 2017 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 6CFDB1294A7; Fri, 17 Feb 2017 06:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 A34bQpMFclXC; Fri, 17 Feb 2017 06:56:43 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E5B1293E8; Fri, 17 Feb 2017 06:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22748; q=dns/txt; s=iport; t=1487343403; x=1488553003; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IUHqqO3JxND1rb+HU5vLtIbUckj9T7jJweEfNMgmDEQ=; b=d8F4+0HQSfKJOtNNwu7zNaNj7UOT6256CNRlJTEAcgcY+wIwts8UW/jJ uS87qpwuiVBj8JrwyGZ6spgZVy73A/bOFdq2QmlVKXQhw/Be67c+5EUcX er8pKXT36C40di4HIH0yGuxj2snJg/DKTqUlwiSahZJbX7e75qEPYi0rJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQCjDqdY/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYTFYB4NSigiiHYMdgg+CDC6FdAIaggU/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHEGI1YQAgEIPwMCAgIwFBECBAENBYlsDrBWgiUriywBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZMggWCaoMXgQYJEQGDIi6CMQWJDoxPhiQBhnCLKIF7hReJdog?= =?us-ascii?q?wim0BHzh4CFEVPREBhDQdGYFIdQEEiDiBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,172,1484006400"; d="scan'208,217";a="386842918" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 14:56:41 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1HEufMe025239 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 14:56:41 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 08:56:41 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 17 Feb 2017 08:56:41 -0600 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels , Terry Manderson , "sidr-chairs@ietf.org" , "morrowc@ops-netman.net" , "sandy@tislabs.com" Thread-Topic: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) Thread-Index: AQHSh/jZg3PcEJPtD0S+zGbVhzl8aqFsJDuAgAE4rIA= Date: Fri, 17 Feb 2017 14:56:41 +0000 Message-ID: <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> In-Reply-To: <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_3A008C78B8464F8FA813C54C276FAEFDciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 14:56:45 -0000 --_000_3A008C78B8464F8FA813C54C276FAEFDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkganVzdCB3YW50IHRvIHByb3ZpZGUgYSBsaXR0bGUgYml0IG1vcmUgYmFja2dyb3Vu ZCBvbiB0aGUgdG9waWMgYmVsb3cg4oCTIGFuZCBhc2sgdGhlIENoYWlycyB0byB0YWtlIGFuIGFj dGlvbiB0byBjb25maXJtIHdpdGggdGhlIFdHLg0KDQpEdXJpbmcgdGhlIGRpc2N1c3Npb24gcmVz dWx0aW5nIGZyb20gbXkgQUQgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgWzFdLCB0aGUgdG9waWMg b2Ygd2hldGhlciB0aGUgaW50ZW50IG9mIHRoZSBkb2N1bWVudCB3YXMgdG8gcmVwbGFjZSByc3lu YyBvciBub3QgY2FtZSB1cCAoc2VlIE0xNiBpbiBteSByZXZpZXcpIOKAkyBhZnRlciBzb21lIGRp c2N1c3Npb24gd2UgY2FtZSB0byBhIHdheSBmb3J3YXJkIFsyXSwgd2hpY2ggd2FzIHRvIGZvcm1h bGx5IFVwZGF0ZSBpbiBSRkM2NDgwLCBSRkM2NDgxLCBhbmQgUkZDNzczMCB0byBjaGFuZ2UgdGhl IG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgcmVxdWlyZW1lbnQgZm9yIHJzeW5jIGFuZCBsZWF2ZSBp bnN0ZWFkIOKAnGEgcmV0cmlldmFsIG1lY2hhbmlzbShzKSBjb25zaXN0ZW50IHdpdGggdGhlIGFj Y2Vzc01ldGhvZCBlbGVtZW50IHZhbHVlKHMp4oCdLg0KDQpFdmVuIHRob3VnaCB0aGlzIGRpc2N1 c3Npb24gaGFwcGVuZWQgb24gdGhlIHNpZHIgbGlzdCwgSSBzZW50IGEgbWVzc2FnZSB0byB0aGUg V0cgYXNraW5nIGZvciByZXZpZXcgb2YgdGhlIGNoYW5nZXMgWzNd4oCmYnV0IG5vIHJlcGx5IHdh cyByZWNlaXZlZC4NCg0KQXMgVGVycnkgbWVudGlvbnMgYmVsb3csIHRoZXNlIGNoYW5nZXMgcmVt b3ZlZCDigJx0aGUgcXVhbGl0eSBvZiBhIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgcmV0cmlldmFs IG1lY2hhbmlzbeKAnTogcnN5bmMgaXMgbm8gbG9uZ2VyIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQs IGJ1dCBuZWl0aGVyIGlzIFJSRFAuICBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCBpcyBvayBiZWNh dXNlIGl0IGFsc28gYWxsb3dzIHRvIG1vcmUgZmxleGliaWxpdHk7IHJzeW5jIG9yIFJSRFAgKG9y IGFueXRoaW5nIGVsc2Ug4oCcY29uc2lzdGVudCB3aXRoIHRoZSBhY2Nlc3NNZXRob2QgZWxlbWVu dCB2YWx1ZShzKeKAnSksIG9yIGJvdGggY2FuIGJlIGltcGxlbWVudGVkIGFzIHByaW1hcnkgYW5k L29yIGJhY2t1cC4NCg0KKipDaGFpcnMqKjogIEdpdmVuIHRoYXQgdGhpcyBpcyBhIHNpZ25pZmlj YW50IGNoYW5nZSwgYW5kIHRoYXQgdGhlIFdHIG1heSBoYXZlIG5vdCBiZWVuIGZvY3VzZWQgb24g dGhlIGRpc2N1c3Npb24sIGFuZCB0aGF0IHdlIG5vdyBoYXZlIGEgbGl0dGxlIG1vcmUgdGltZSBn aXZlbiB0aGUgZmFjdCB0aGF0IHRoZSBJRVNHIHJldmlldyBvZiB0aGlzIGRvY3VtZW50IHdhcyBk ZWZlcnJlZCB1bnRpbCBNYXIvMuKApiAgUGxlYXNlIGV4cGxpY2l0bHkgYXNrIHRoZSBXRyB0byBy ZXZpZXcgdGhlIFVwZGF0ZXMgdG8gUkZDNjQ4MCwgUkZDNjQ4MSBhbmQgUkZDNzczMC4gIEkgdGhp bmsgdGhhdCBhIHdlZWsgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBzaG91bGQgYmUgZW5vdWdo Lg0KDQpUaGFua3MhIQ0KDQpBbHZhcm8uDQoNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc2lkci91MVdPOGpObHZuLUp6b1ZkdWhwUE9LSGpNZkkvP3FpZD02MTcx N2MzMTI2YTYyNDU0YjQ1YzQyNmNlZDVkMzM0NA0KWzJdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc2lkci9hNmtRVWU3eTQ1Nm9MbVREcnZyQnF3UjVvUkkvP3FpZD02MTcx N2MzMTI2YTYyNDU0YjQ1YzQyNmNlZDVkMzM0NA0KWzNdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc2lkci8yZF9kREo1Q2syUE1wdEtfTjJ0UkdRTkVEQmsvP3FpZD02MTcx N2MzMTI2YTYyNDU0YjQ1YzQyNmNlZDVkMzM0NA0KDQpPbiAyLzE2LzE3LCAxMDoxNyBBTSwgImll c2cgb24gYmVoYWxmIG9mIFRpbSBCcnVpam56ZWVscyIgPGllc2ctYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgdGltQHJpcGUubmV0PG1h aWx0bzp0aW1AcmlwZS5uZXQ+PiB3cm90ZToNCg0KDQpPbiAxNiBGZWIgMjAxNywgYXQgMDM6MDMs IFRlcnJ5IE1hbmRlcnNvbiA8dGVycnkubWFuZGVyc29uQGljYW5uLm9yZzxtYWlsdG86dGVycnku bWFuZGVyc29uQGljYW5uLm9yZz4+IHdyb3RlOg0KVGVycnkgTWFuZGVyc29uIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zaWRyLWRlbHRh LXByb3RvY29sLTA3OiBObyBPYmplY3Rpb24NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMN CmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc2lkci1kZWx0YS1wcm90b2NvbC8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGFuayB5b3UgZm9yIHRoaXMgd29yaywgaXQgaXMgY2xlYXIgYW5kIHdlbGwgd3Jp dHRlbi4gV2hpbGUgSSBoYXZlIG5ldmVyDQooZXZlcikgYmVlbiBlbmFtb3VyZWQgYnkgUlNZTkMs IGFuZCBJIG11Y2ggcHJlZmVyIHRoaXMgZGlyZWN0aW9uIG9uIGENCnBlcnNvbmFsIGxldmVsLCB0 aGUgdXBkYXRlcyB0byB0aGUgZXhpc3RpbmcgUkZDcyByZWdhcmRpbmcgUlNZTkMgZG9lcyB0d28N CnRoaW5ncy4gVGhlIGZpcnN0IGlzIGl0IGRlbW90ZXMgUlNZTkMgdG8gJ2p1c3QgYW5vdGhlciBh Y2Nlc3MgbWVjaGFuaXNtJywNCmFuZCB0aGUgc2Vjb25kIGlzIGl0IGFwcGVhcnMgdG8gcmVtb3Zl IHRoZSBxdWFsaXR5IG9mIGEgbWFuZGF0b3J5IHRvDQppbXBsZW1lbnQgcmV0cmlldmFsIG1lY2hh bmlzbS4gQW0gSSByZWFkaW5nIHRoYXQgY29ycmVjdGx5PyBJZiB0aGlzIGlzDQppbnRlbnRpb25h bCBhbmQgaGFzIHdvcmtncm91cCBjb25zZW5zdXMgc28gYmUgaXQgYW5kIG9ud2FyZHMgd2UgbW92 ZS4uDQoNCkluaXRpYWxseSB0aGlzIHdhcyB3cml0dGVuIGFzIGFuIGFkZGl0aW9uYWwgcHJvdG9j b2wsIG5leHQgdG8gcnN5bmMuIFRoZSBpZGVhIHdhcyB0aGF0IHJzeW5jIHdvdWxkIGJlIHJlcGxh Y2VkIGFsdG9nZXRoZXIgYXQgc29tZSBwb2ludCwgYnV0IHRoZSB3YXkgdG8gZ2V0IHRoZXJlIHdh cyBpbnRlbnRpb25hbGx5IGxlZnQgb3V0IG9mIHRoaXMgZG9jdW1lbnQgYmVjYXVzZSB3ZSBmZWx0 IGl0IHNob3VsZCBqdXN0IGZvY3VzIG9uIHByb3RvY29sLg0KDQpUaGUgY2hhbmdlcyB5b3UgbWVu dGlvbiB3ZXJlIG1hZGUgZm9sbG93aW5nIEFEIHJldmlldyBjb21tZW50cyBvbiA3IEphbnVhcnku IFRoZSBpbnRlbnQgYXMgSSB1bmRlcnN0b29kIGl0IHdhcyB0byBkZWZlciB0aGUgcXVlc3Rpb24g d2hpY2ggcmV0cmlldmFsIG1lY2hhbmlzbSBpcyBtYW5kYXRvcnkgdG8gYW5vdGhlciBkb2N1bWVu dCwgYnV0IGxlYXZlIHRoZSBzcGVjaWZpY2F0aW9ucyBnZW5lcmljLg0KDQo= --_000_3A008C78B8464F8FA813C54C276FAEFDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <97D660A943B06340AE44B468508B5BB6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+SSBqdXN0IHdhbnQgdG8gcHJvdmlkZSBhIGxpdHRsZSBiaXQgbW9yZSBiYWNrZ3JvdW5kIG9u IHRoZSB0b3BpYyBiZWxvdyDigJMgYW5kIGFzayB0aGUgQ2hhaXJzIHRvIHRha2UgYW4gYWN0aW9u IHRvIGNvbmZpcm0gd2l0aCB0aGUgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RHVyaW5n IHRoZSBkaXNjdXNzaW9uIHJlc3VsdGluZyBmcm9tIG15IEFEIHJldmlldyBvZiB0aGlzIGRvY3Vt ZW50IFsxXSwgdGhlIHRvcGljIG9mIHdoZXRoZXIgdGhlIGludGVudCBvZiB0aGUgZG9jdW1lbnQg d2FzIHRvIHJlcGxhY2UgcnN5bmMgb3Igbm90IGNhbWUgdXAgKHNlZSBNMTYgaW4gbXkgcmV2aWV3 KSDigJMgYWZ0ZXINCiBzb21lIGRpc2N1c3Npb24gd2UgY2FtZSB0byBhIHdheSBmb3J3YXJkIFsy XSwgd2hpY2ggd2FzIHRvIGZvcm1hbGx5IFVwZGF0ZSBpbiBSRkM2NDgwLCBSRkM2NDgxLCBhbmQg UkZDNzczMCB0byBjaGFuZ2UgdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgcmVxdWlyZW1lbnQg Zm9yIHJzeW5jIGFuZCBsZWF2ZSBpbnN0ZWFkIOKAnGEgcmV0cmlldmFsIG1lY2hhbmlzbShzKSBj b25zaXN0ZW50IHdpdGggdGhlIGFjY2Vzc01ldGhvZCBlbGVtZW50IHZhbHVlKHMp4oCdLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkV2ZW4gdGhvdWdoIHRoaXMgZGlzY3Vzc2lvbiBoYXBwZW5l ZCBvbiB0aGUgc2lkciBsaXN0LCBJIHNlbnQgYSBtZXNzYWdlIHRvIHRoZSBXRyBhc2tpbmcgZm9y IHJldmlldyBvZiB0aGUgY2hhbmdlcyBbM13igKZidXQgbm8gcmVwbHkgd2FzIHJlY2VpdmVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFzIFRlcnJ5IG1lbnRpb25zIGJlbG93LCB0aGVzZSBj aGFuZ2VzIHJlbW92ZWQg4oCcdGhlIHF1YWxpdHkgb2YgYSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 IHJldHJpZXZhbCBtZWNoYW5pc23igJ06IHJzeW5jIGlzIG5vIGxvbmdlciBtYW5kYXRvcnkgdG8g aW1wbGVtZW50LCBidXQgbmVpdGhlciBpcyBSUkRQLiZuYnNwOyBJIHBlcnNvbmFsbHkNCiB0aGlu ayB0aGF0IGlzIG9rIGJlY2F1c2UgaXQgYWxzbyBhbGxvd3MgdG8gbW9yZSBmbGV4aWJpbGl0eTsg cnN5bmMgb3IgUlJEUCAob3IgYW55dGhpbmcgZWxzZSDigJxjb25zaXN0ZW50IHdpdGggdGhlIGFj Y2Vzc01ldGhvZCBlbGVtZW50IHZhbHVlKHMp4oCdKSwgb3IgYm90aCBjYW4gYmUgaW1wbGVtZW50 ZWQgYXMgcHJpbWFyeSBhbmQvb3IgYmFja3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPioq Q2hhaXJzKio6Jm5ic3A7IEdpdmVuIHRoYXQgdGhpcyBpcyBhIHNpZ25pZmljYW50IGNoYW5nZSwg YW5kIHRoYXQgdGhlIFdHIG1heSBoYXZlIG5vdCBiZWVuIGZvY3VzZWQgb24gdGhlIGRpc2N1c3Np b24sIGFuZCB0aGF0IHdlIG5vdyBoYXZlIGEgbGl0dGxlIG1vcmUgdGltZSBnaXZlbiB0aGUgZmFj dCB0aGF0IHRoZSBJRVNHIHJldmlldw0KIG9mIHRoaXMgZG9jdW1lbnQgd2FzIGRlZmVycmVkIHVu dGlsIE1hci8y4oCmJm5ic3A7IFBsZWFzZSBleHBsaWNpdGx5IGFzayB0aGUgV0cgdG8gcmV2aWV3 IHRoZSBVcGRhdGVzIHRvIFJGQzY0ODAsIFJGQzY0ODEgYW5kIFJGQzc3MzAuJm5ic3A7IEkgdGhp bmsgdGhhdCBhIHdlZWsgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBzaG91bGQgYmUgZW5vdWdo LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyEhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlsxXSA8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NpZHIvdTFXTzhqTmx2bi1Kem9WZHVocFBPS0hqTWZJLz9x aWQ9NjE3MTdjMzEyNmE2MjQ1NGI0NWM0MjZjZWQ1ZDMzNDQiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9zaWRyL3UxV084ak5sdm4tSnpvVmR1aHBQT0tIak1mSS8/cWlk PTYxNzE3YzMxMjZhNjI0NTRiNDVjNDI2Y2VkNWQzMzQ0PC9hPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+WzJdIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc2lkci9hNmtRVWU3eTQ1Nm9MbVREcnZyQnF3UjVvUkkvP3FpZD02MTcx N2MzMTI2YTYyNDU0YjQ1YzQyNmNlZDVkMzM0NCI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NpZHIvYTZrUVVlN3k0NTZvTG1URHJ2ckJxd1I1b1JJLz9xaWQ9NjE3MTdj MzEyNmE2MjQ1NGI0NWM0MjZjZWQ1ZDMzNDQ8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5bM10gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9zaWRyLzJkX2RESjVDazJQTXB0S19OMnRSR1FORURCay8/cWlkPTYxNzE3YzMxMjZh NjI0NTRiNDVjNDI2Y2VkNWQzMzQ0Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvc2lkci8yZF9kREo1Q2syUE1wdEtfTjJ0UkdRTkVEQmsvP3FpZD02MTcxN2MzMTI2YTYy NDU0YjQ1YzQyNmNlZDVkMzM0NDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE2LzE3LCAxMDoxNyBBTSwgJnF1b3Q7 aWVzZyBvbiBiZWhhbGYgb2YgVGltIEJydWlqbnplZWxzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86aWVzZy1ib3VuY2VzQGlldGYub3JnIj5pZXNnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJl aGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnRpbUByaXBlLm5ldCI+dGltQHJpcGUubmV0PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluO2Zv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp ZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpPbiAxNiBG ZWIgMjAxNywgYXQgMDM6MDMsIFRlcnJ5IE1hbmRlcnNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl cnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmciPnRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGVycnkgTWFuZGVyc29uIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5kcmFmdC1pZXRmLXNpZHItZGVsdGEtcHJvdG9jb2wtMDc6IE5vIE9i amVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSByZWZlciB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpZHItZGVsdGEtcHJvdG9jb2wvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpZHItZGVsdGEtcHJvdG9j b2wvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNPTU1FTlQ6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsg eW91IGZvciB0aGlzIHdvcmssIGl0IGlzIGNsZWFyIGFuZCB3ZWxsIHdyaXR0ZW4uIFdoaWxlIEkg aGF2ZSBuZXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4oZXZlcikgYmVlbiBlbmFt b3VyZWQgYnkgUlNZTkMsIGFuZCBJIG11Y2ggcHJlZmVyIHRoaXMgZGlyZWN0aW9uIG9uIGE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+cGVyc29uYWwgbGV2ZWwsIHRoZSB1cGRhdGVzIHRv IHRoZSBleGlzdGluZyBSRkNzIHJlZ2FyZGluZyBSU1lOQyBkb2VzIHR3bzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj50aGluZ3MuIFRoZSBmaXJzdCBpcyBpdCBkZW1vdGVzIFJTWU5DIHRv ICdqdXN0IGFub3RoZXIgYWNjZXNzIG1lY2hhbmlzbScsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPmFuZCB0aGUgc2Vjb25kIGlzIGl0IGFwcGVhcnMgdG8gcmVtb3ZlIHRoZSBxdWFsaXR5 IG9mIGEgbWFuZGF0b3J5IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmltcGxlbWVu dCByZXRyaWV2YWwgbWVjaGFuaXNtLiBBbSBJIHJlYWRpbmcgdGhhdCBjb3JyZWN0bHk/IElmIHRo aXMgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+aW50ZW50aW9uYWwgYW5kIGhhcyB3 b3JrZ3JvdXAgY29uc2Vuc3VzIHNvIGJlIGl0IGFuZCBvbndhcmRzIHdlIG1vdmUuLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+SW5pdGlhbGx5IHRoaXMgd2FzIHdyaXR0ZW4gYXMgYW4gYWRkaXRp b25hbCBwcm90b2NvbCwgbmV4dCB0byByc3luYy4gVGhlIGlkZWEgd2FzIHRoYXQgcnN5bmMgd291 bGQgYmUgcmVwbGFjZWQgYWx0b2dldGhlciBhdCBzb21lIHBvaW50LCBidXQgdGhlIHdheSB0byBn ZXQgdGhlcmUgd2FzIGludGVudGlvbmFsbHkNCiBsZWZ0IG91dCBvZiB0aGlzIGRvY3VtZW50IGJl Y2F1c2Ugd2UgZmVsdCBpdCBzaG91bGQganVzdCBmb2N1cyBvbiBwcm90b2NvbC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlRoZSBjaGFuZ2VzIHlvdSBtZW50aW9uIHdlcmUgbWFkZSBmb2xsb3dpbmcgQUQgcmV2aWV3IGNv bW1lbnRzIG9uIDcgSmFudWFyeS4gVGhlIGludGVudCBhcyBJIHVuZGVyc3Rvb2QgaXQgd2FzIHRv IGRlZmVyIHRoZSBxdWVzdGlvbiB3aGljaCByZXRyaWV2YWwgbWVjaGFuaXNtIGlzIG1hbmRhdG9y eQ0KIHRvIGFub3RoZXIgZG9jdW1lbnQsIGJ1dCBsZWF2ZSB0aGUgc3BlY2lmaWNhdGlvbnMgZ2Vu ZXJpYy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3A008C78B8464F8FA813C54C276FAEFDciscocom_-- From nobody Fri Feb 17 09:27:23 2017 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 ED074129ADA; Fri, 17 Feb 2017 09:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 DcyGJXhHrUx1; Fri, 17 Feb 2017 09:27:13 -0800 (PST) Received: from dfw-mailout20.raytheon.com (dfw-mailout20.raytheon.com [199.46.199.221]) (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 A1E9D129AD9; Fri, 17 Feb 2017 09:27:13 -0800 (PST) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by dfw-mailout20.ext.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1HHQnRv009855 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Feb 2017 17:26:49 GMT Received: from 008-smtp-out.ray.com ([23.103.8.216]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1HHQmmC003867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 17 Feb 2017 17:26:48 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB024.008f.mgd2.msft.net (23.103.8.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.16; Fri, 17 Feb 2017 17:26:47 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.0860.012; Fri, 17 Feb 2017 17:26:47 +0000 From: Steve KENT To: "Alvaro Retana (aretana)" , Tim Bruijnzeels , Terry Manderson , "sidr-chairs@ietf.org" , "morrowc@ops-netman.net" , "sandy@tislabs.com" Thread-Topic: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) Thread-Index: AQHSh/jc+D7LiTjdNkeAgX5msN87YaFrv6WAgAGMgYCAACgCog== Date: Fri, 17 Feb 2017 17:26:47 +0000 Message-ID: <5c3ee940068042b592026fd52d223cc2@CY1PR0601MB023.008f.mgd2.msft.net> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net>, <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> In-Reply-To: <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.8.133] Content-Type: multipart/alternative; boundary="_000_5c3ee940068042b592026fd52d223cc2CY1PR0601MB023008fmgd2m_" MIME-Version: 1.0 X-CC: aretana@cisco.com, tim@ripe.net, terry.manderson@icann.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, draft-ietf-sidr-delta-protocol@ietf.org, iesg@ietf.org, sidr@ietf.org X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-17_14:, , signatures=0 X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-17_14:, , signatures=0 X-DMZ-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702170161 X-DMZ-Spam-Reason: mlx Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , The IESG , "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:27:17 -0000 --_000_5c3ee940068042b592026fd52d223cc2CY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alvaro, Sorry I faukled to rely when you posted you comment on this topic to the S= IDR list. I don't support revising 6480, 6481, and 7730 to remove mandatory= support for rsynch, at this time. The issue, for me, is not whether rysnc = is better or worse than the delta protocol. The issue is that if we have no= MTI protocol for disseminating RPKI repository data, we fail to ensure int= eroperability between repositories and relying parties. Given the fact that= the delta protocol is still quite new, it seems more appropriate to retain= rsync as MTI for now, and to generate another doc establishing a timeline = for transition to the delta protocol. This is analogous to what we did in R= FC 6489 and RFC 6916, where we specified an orderly transition process for = key rollover and algorithm agility, respectively. Steve ________________________________ From: sidr on behalf of Alvaro Retana (aretana) Sent: Friday, February 17, 2017 9:56:41 AM To: Tim Bruijnzeels; Terry Manderson; sidr-chairs@ietf.org; morrowc@ops-net= man.net; sandy@tislabs.com Cc: draft-ietf-sidr-delta-protocol@ietf.org; The IESG; sidr@ietf.org Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta= -protocol-07: (with COMMENT) Hi! I just want to provide a little bit more background on the topic below =96 = and ask the Chairs to take an action to confirm with the WG. During the discussion resulting from my AD review of this document [1], the= topic of whether the intent of the document was to replace rsync or not ca= me up (see M16 in my review) =96 after some discussion we came to a way for= ward [2], which was to formally Update in RFC6480, RFC6481, and RFC7730 to = change the mandatory to implement requirement for rsync and leave instead = =93a retrieval mechanism(s) consistent with the accessMethod element value(= s)=94. Even though this discussion happened on the sidr list, I sent a message to = the WG asking for review of the changes [3]=85but no reply was received. As Terry mentions below, these changes removed =93the quality of a mandator= y to implement retrieval mechanism=94: rsync is no longer mandatory to impl= ement, but neither is RRDP. I personally think that is ok because it also = allows to more flexibility; rsync or RRDP (or anything else =93consistent w= ith the accessMethod element value(s)=94), or both can be implemented as pr= imary and/or backup. **Chairs**: Given that this is a significant change, and that the WG may h= ave not been focused on the discussion, and that we now have a little more = time given the fact that the IESG review of this document was deferred unti= l Mar/2=85 Please explicitly ask the WG to review the Updates to RFC6480, = RFC6481 and RFC7730. I think that a week of discussion on the list should = be enough. Thanks!! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/= ?qid=3D61717c3126a62454b45c426ced5d3344 [2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/= ?qid=3D61717c3126a62454b45c426ced5d3344 [3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/= ?qid=3D61717c3126a62454b45c426ced5d3344 On 2/16/17, 10:17 AM, "iesg on behalf of Tim Bruijnzeels" on behalf of tim@ripe.net> wrote: On 16 Feb 2017, at 03:03, Terry Manderson > wrote: Terry Manderson has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this work, it is clear and well written. While I have never (ever) been enamoured by RSYNC, and I much prefer this direction on a personal level, the updates to the existing RFCs regarding RSYNC does two things. The first is it demotes RSYNC to 'just another access mechanism', and the second is it appears to remove the quality of a mandatory to implement retrieval mechanism. Am I reading that correctly? If this is intentional and has workgroup consensus so be it and onwards we move.. Initially this was written as an additional protocol, next to rsync. The id= ea was that rsync would be replaced altogether at some point, but the way t= o get there was intentionally left out of this document because we felt it = should just focus on protocol. The changes you mention were made following AD review comments on 7 January= . The intent as I understood it was to defer the question which retrieval m= echanism is mandatory to another document, but leave the specifications gen= eric. --_000_5c3ee940068042b592026fd52d223cc2CY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Alvaro,


Sorry I faukled to rely when  you posted you comment on this topic = to the SIDR list. I don't support revising 6480, 6481, and 7730 to remove m= andatory support for rsynch, at this time. The issue, for me, is not whethe= r rysnc is better or worse than the delta protocol. The issue is that if we have no MTI protocol for disseminating R= PKI repository data, we fail to ensure interoperability between repositorie= s and relying parties. Given the fact that the delta protocol is still quit= e new, it seems more appropriate to retain rsync as MTI for now, and to generate another doc establishing a= timeline for transition to the delta protocol. This is analogous to what w= e did in RFC 6489 and RFC 6916, where we specified an orderly transition pr= ocess for key rollover and algorithm agility, respectively.


Steve

From: sidr <sidr-bounces= @ietf.org> on behalf of Alvaro Retana (aretana) <aretana@cisco.com>= ;
Sent: Friday, February 17, 2017 9:56:41 AM
To: Tim Bruijnzeels; Terry Manderson; sidr-chairs@ietf.org; morrowc@= ops-netman.net; sandy@tislabs.com
Cc: draft-ietf-sidr-delta-protocol@ietf.org; The IESG; sidr@ietf.org=
Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sid= r-delta-protocol-07: (with COMMENT)
 

Hi!

 

I just want to provide a little bit more background on the topic below =96= and ask the Chairs to take an action to confirm with the WG.

 

During the discussion resulting from my AD review of this document [1], th= e topic of whether the intent of the document was to replace rsync or not c= ame up (see M16 in my review) =96 after some discussion we came to a way forward [2], which was to formally Update= in RFC6480, RFC6481, and RFC7730 to change the mandatory to implement requ= irement for rsync and leave instead =93a retrieval mechanism(s) consistent = with the accessMethod element value(s)=94.

 

Even though this discussion happened on the sidr list, I sent a message to= the WG asking for review of the changes [3]=85but no reply was received.

 

As Terry mentions below, these changes removed =93the quality of a mandato= ry to implement retrieval mechanism=94: rsync is no longer mandatory to imp= lement, but neither is RRDP.  I personally think that is ok because it also allows to more flexibility; rsync or RRDP= (or anything else =93consistent with the accessMethod element value(s)=94)= , or both can be implemented as primary and/or backup.

 

**Chairs**:  Given that this is a significant change, and that the WG= may have not been focused on the discussion, and that we now have a little= more time given the fact that the IESG review of this document was deferred until Mar/2=85  Please explicitly ask t= he WG to review the Updates to RFC6480, RFC6481 and RFC7730.  I think = that a week of discussion on the list should be enough.

 

Thanks!!

 

Alvaro.

 

 

[1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qid= =3D61717c3126a62454b45c426ced5d3344

[2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qid= =3D61717c3126a62454b45c426ced5d3344

[3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qid= =3D61717c3126a62454b45c426ced5d3344

 

On 2/16/17, 10:17 AM, "iesg on behalf of Tim Br= uijnzeels" <iesg-bounces@i= etf.org on behalf of tim@ripe.net> wrote:

 


On 16 Feb 2017, at 03:03, Terry Manderson <terry.manderson@icann.org> wrote:<= /p>

Terry Manderson has entered the followin= g ballot position for

draft-ietf-sidr-delta-protocol-07: No Ob= jection

When responding, please keep the subject= line intact and reply to all

email addresses included in the To and C= C lines. (Feel free to cut this

introductory paragraph, however.)

for more information about IESG DISCUSS = and COMMENT positions.

The document, along with other ballot po= sitions, can be found here:

----------------------------------------= ------------------------------

COMMENT:

----------------------------------------= ------------------------------

Thank you for this work, it is clear and= well written. While I have never

(ever) been enamoured by RSYNC, and I mu= ch prefer this direction on a

personal level, the updates to the exist= ing RFCs regarding RSYNC does two

things. The first is it demotes RSYNC to= 'just another access mechanism',

and the second is it appears to remove t= he quality of a mandatory to

implement retrieval mechanism. Am I read= ing that correctly? If this is

intentional and has workgroup consensus = so be it and onwards we move..

 

Initially this was written as an additio= nal protocol, next to rsync. The idea was that rsync would be replaced alto= gether at some point, but the way to get there was intentionally left out of this document because we felt it should just focus on protocol= .

 

The changes you mention were made follow= ing AD review comments on 7 January. The intent as I understood it was to d= efer the question which retrieval mechanism is mandatory to another document, but leave the specifications generic. 

 

--_000_5c3ee940068042b592026fd52d223cc2CY1PR0601MB023008fmgd2m_-- From nobody Fri Feb 17 19:50:52 2017 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 86480120727; Fri, 17 Feb 2017 19:50:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148738984854.19960.7217247705019948976.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 19:50:48 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-publication-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 03:50:48 -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 of the IETF. Title : A Publication Protocol for the Resource Public Key Infrastructure (RPKI) Authors : Samuel Weiler Anuja Sonalker Rob Austein Filename : draft-ietf-sidr-publication-11.txt Pages : 19 Date : 2017-02-17 Abstract: This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs their own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-publication-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-publication-11 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 Fri Feb 17 19:53:36 2017 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 8FC8812953B; Fri, 17 Feb 2017 19:53:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148739001457.19924.18439236165958265588.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 19:53:34 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 03:53:34 -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 of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-07.txt Pages : 21 Date : 2017-02-17 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 17 20:11:40 2017 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 5E9BE1294B3; Fri, 17 Feb 2017 20:11:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148739109537.20016.250809832637493888.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 20:11:35 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 04:11:35 -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 of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt Pages : 33 Date : 2017-02-17 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the rpki-rtr protocol. RFC 6810 describes version 0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 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 Fri Feb 17 20:18:28 2017 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 3B8D31294E3; Fri, 17 Feb 2017 20:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 jf3gPmn1nqae; Fri, 17 Feb 2017 20:18:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 54F4E129452; Fri, 17 Feb 2017 20:18:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cewTZ-000698-20; Sat, 18 Feb 2017 04:18:25 +0000 Date: Sat, 18 Feb 2017 11:18:17 +0700 Message-ID: From: Randy Bush To: Alvaro Retana In-Reply-To: <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 04:18:27 -0000 > As Terry mentions below, these changes removed $B!H(Bthe quality of a > mandatory to implement retrieval mechanism$B!I(B: rsync is no longer > mandatory to implement, but neither is RRDP. this is gonna work out really well for distributed clients and distributed servers where every client must to talk to every server. not. randy From nobody Fri Feb 17 20:24:38 2017 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 9E0931296FA for ; Fri, 17 Feb 2017 20:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 yNvh5yeGzfrV for ; Fri, 17 Feb 2017 20:24:36 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4D31296F6 for ; Fri, 17 Feb 2017 20:24:36 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 1B35E1398E for ; Sat, 18 Feb 2017 04:24:36 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id B2DAB47ADEBB for ; Fri, 17 Feb 2017 23:24:35 -0500 (EST) Date: Fri, 17 Feb 2017 23:24:35 -0500 From: Rob Austein To: sidr@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170218042435.B2DAB47ADEBB@minas-ithil.hactrn.net> Archived-At: Subject: [sidr] Updated publication, rpki-rtr-bis, and rpki-oob-setup I-Ds X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 04:24:37 -0000 All three updated to address issues that came up during IESG review, along with a few items from directorate reviews that came in during the same timeframe. From nobody Mon Feb 20 07:08:29 2017 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 C8DA11294D2; Mon, 20 Feb 2017 07:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 sBvpgG38YVxa; Mon, 20 Feb 2017 07:08:16 -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 2D69812950F; Mon, 20 Feb 2017 07:08:13 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cfpZL-0007CP-LD; Mon, 20 Feb 2017 16:08:07 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-13.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cfpZL-0007lB-EN; Mon, 20 Feb 2017 16:08:03 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_156BF0B3-736B-42BD-9690-926368066804" From: Tim Bruijnzeels In-Reply-To: <5c3ee940068042b592026fd52d223cc2@CY1PR0601MB023.008f.mgd2.msft.net> Date: Mon, 20 Feb 2017 16:08:02 +0100 Message-Id: <5C100CD1-B5AF-4AC1-B670-0B059CEF7800@ripe.net> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> <5c3ee940068042b592026fd52d223cc2@CY1PR0601MB023.008f.mgd2.msft.net> To: Steve KENT X-Mailer: Apple Mail (2.3124) 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.0665] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071956a162ca6378e005b322c0bba5215ef3 Archived-At: Cc: "sidr@ietf.org" , "morrowc@ops-netman.net" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "draft-ietf-sidr-delta-protocol@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 15:08:27 -0000 --Apple-Mail=_156BF0B3-736B-42BD-9690-926368066804 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Steve, all, > On 17 Feb 2017, at 18:26, Steve KENT wrote: >=20 > Alvaro, >=20 > Sorry I faukled to rely when you posted you comment on this topic to = the SIDR list. I don't support revising 6480, 6481, and 7730 to remove = mandatory support for rsynch, at this time. The issue, for me, is not = whether rysnc is better or worse than the delta protocol. The issue is = that if we have no MTI protocol for disseminating RPKI repository data, = we fail to ensure interoperability between repositories and relying = parties. Given the fact that the delta protocol is still quite new, it = seems more appropriate to retain rsync as MTI for now, and to generate = another doc establishing a timeline for transition to the delta = protocol. This is analogous to what we did in RFC 6489 and RFC 6916, = where we specified an orderly transition process for key rollover and = algorithm agility, respectively. To make it abundantly clear let me re-state: I have no problem with this = path. I believe that Alvaro's suggestions were well-intended to make a future = transition document easier, but I don't see any reason why this could = not be done later. Having RRDP as an allowed additional mechanism, = whilst still requiring rsync as well, will allow us to use it and gain = experience. In other words I don't think that a migration document is = not a requirement for finishing the RRDP protocol document itself. I would suggest that a possible rsync phase-out is discussed in = sidr-ops. More than willing to provide text or participate otherwise, = provided that working group wants to take on the work. Tim >=20 > Steve > From: sidr on behalf of Alvaro Retana = (aretana) > Sent: Friday, February 17, 2017 9:56:41 AM > To: Tim Bruijnzeels; Terry Manderson; sidr-chairs@ietf.org; = morrowc@ops-netman.net; sandy@tislabs.com > Cc: draft-ietf-sidr-delta-protocol@ietf.org; The IESG; sidr@ietf.org > Subject: Re: [sidr] Terry Manderson's No Objection on = draft-ietf-sidr-delta-protocol-07: (with COMMENT) > =20 > Hi! > =20 > I just want to provide a little bit more background on the topic below = =96 and ask the Chairs to take an action to confirm with the WG. > =20 > During the discussion resulting from my AD review of this document = [1], the topic of whether the intent of the document was to replace = rsync or not came up (see M16 in my review) =96 after some discussion we = came to a way forward [2], which was to formally Update in RFC6480, = RFC6481, and RFC7730 to change the mandatory to implement requirement = for rsync and leave instead =93a retrieval mechanism(s) consistent with = the accessMethod element value(s)=94. > =20 > Even though this discussion happened on the sidr list, I sent a = message to the WG asking for review of the changes [3]=85but no reply = was received. > =20 > As Terry mentions below, these changes removed =93the quality of a = mandatory to implement retrieval mechanism=94: rsync is no longer = mandatory to implement, but neither is RRDP. I personally think that is = ok because it also allows to more flexibility; rsync or RRDP (or = anything else =93consistent with the accessMethod element value(s)=94), = or both can be implemented as primary and/or backup. > =20 > **Chairs**: Given that this is a significant change, and that the WG = may have not been focused on the discussion, and that we now have a = little more time given the fact that the IESG review of this document = was deferred until Mar/2=85 Please explicitly ask the WG to review the = Updates to RFC6480, RFC6481 and RFC7730. I think that a week of = discussion on the list should be enough. > =20 > Thanks!! > =20 > Alvaro. > =20 > =20 > [1] = https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qi= d=3D61717c3126a62454b45c426ced5d3344 = > [2] = https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qi= d=3D61717c3126a62454b45c426ced5d3344 = > [3] = https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qi= d=3D61717c3126a62454b45c426ced5d3344 = > =20 > On 2/16/17, 10:17 AM, "iesg on behalf of Tim Bruijnzeels" = on behalf of = tim@ripe.net > wrote: > =20 >=20 > On 16 Feb 2017, at 03:03, Terry Manderson > wrote: > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-delta-protocol-07: No Objection > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ = > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Thank you for this work, it is clear and well written. While I have = never > (ever) been enamoured by RSYNC, and I much prefer this direction on a > personal level, the updates to the existing RFCs regarding RSYNC does = two > things. The first is it demotes RSYNC to 'just another access = mechanism', > and the second is it appears to remove the quality of a mandatory to > implement retrieval mechanism. Am I reading that correctly? If this is > intentional and has workgroup consensus so be it and onwards we move.. > =20 > Initially this was written as an additional protocol, next to rsync. = The idea was that rsync would be replaced altogether at some point, but = the way to get there was intentionally left out of this document because = we felt it should just focus on protocol. > =20 > The changes you mention were made following AD review comments on 7 = January. The intent as I understood it was to defer the question which = retrieval mechanism is mandatory to another document, but leave the = specifications generic.=20 > =20 --Apple-Mail=_156BF0B3-736B-42BD-9690-926368066804 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Steve, all,

On = 17 Feb 2017, at 18:26, Steve KENT <steve.kent@raytheon.com> wrote:

Alvaro,

Sorry I faukled to rely when  you = posted you comment on this topic to the SIDR list. I don't support = revising 6480, 6481, and 7730 to remove mandatory support for rsynch, at = this time. The issue, for me, is not whether rysnc is better or worse = than the delta protocol. The issue is that if we have no MTI protocol = for disseminating RPKI repository data, we fail to ensure = interoperability between repositories and relying parties. Given the = fact that the delta protocol is still quite new, it seems more = appropriate to retain rsync as MTI for now, and to generate another doc = establishing a timeline for transition to the delta protocol. This is = analogous to what we did in RFC 6489 and RFC 6916, where we specified an = orderly transition process for key rollover and algorithm agility, = respectively.

To make it abundantly clear let me re-state: I = have no problem with this path.

I = believe that Alvaro's suggestions were well-intended to make a future = transition document easier, but I don't see any reason why this could = not be done later. Having RRDP as an allowed additional mechanism, = whilst still requiring rsync as well, will allow us to use it and gain = experience. In other words I don't think that a migration document is = not a requirement for finishing the RRDP protocol document = itself.

I would suggest that a = possible rsync phase-out is discussed in sidr-ops. More than willing to = provide text or participate otherwise, provided that working group wants = to take on the work.

Tim



Steve
From: sidr <sidr-bounces@ietf.org> on behalf of Alvaro Retana = (aretana) <aretana@cisco.com>
Sent: Friday, February 17, 2017 = 9:56:41 AM
To: Tim Bruijnzeels; Terry = Manderson; sidr-chairs@ietf.org; morrowc@ops-netman.net; sandy@tislabs.com
Cc: draft-ietf-sidr-delta-protocol@ietf.org; The IESG; sidr@ietf.org
Subject: Re: [sidr] Terry = Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with = COMMENT)
 
Hi!
 
I just want to provide a little bit more background on the = topic below =96 and ask the Chairs to take an action to confirm with the = WG.
 
During the discussion resulting from my AD review of this = document [1], the topic of whether the intent of the document was to = replace rsync or not came up (see M16 in my review) =96 after some = discussion we came to a way forward [2], which was to formally Update in = RFC6480, RFC6481, and RFC7730 to change the mandatory to implement = requirement for rsync and leave instead =93a retrieval mechanism(s) = consistent with the accessMethod element value(s)=94.
 
Even though this discussion happened on the sidr list, I sent = a message to the WG asking for review of the changes [3]=85but no reply = was received.
 
As Terry mentions below, these changes removed =93the quality = of a mandatory to implement retrieval mechanism=94: rsync is no longer = mandatory to implement, but neither is RRDP.  I personally think = that is ok because it also allows to more flexibility; rsync or RRDP (or = anything else =93consistent with the accessMethod element value(s)=94), = or both can be implemented as primary and/or backup.
 
**Chairs**:  Given that this is a significant change, = and that the WG may have not been focused on the discussion, and that we = now have a little more time given the fact that the IESG review of this = document was deferred until Mar/2=85  Please explicitly ask the WG = to review the Updates to RFC6480, RFC6481 and RFC7730.  I think = that a week of discussion on the list should be enough.
 
Thanks!!
 
Alvaro.
 
 
[1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpP= OKHjMfI/?qid=3D61717c3126a62454b45c426ced5d3344
[2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrB= qwR5oRI/?qid=3D61717c3126a62454b45c426ced5d3344
[3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tR= GQNEDBk/?qid=3D61717c3126a62454b45c426ced5d3344
 
On 2/16/17, 10:17 AM, "iesg on behalf of Tim = Bruijnzeels" <iesg-bounces@ietf.org on behalf of tim@ripe.net> wrote:
 

On 16 Feb 2017, at 03:03, Terry Manderson <terry.manderson@icann.org> = wrote:
Terry Manderson has entered the following ballot = position for
draft-ietf-sidr-delta-protocol-07: No Objection
When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. = (Feel free to cut this
introductory paragraph, = however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT = positions.
The document, along with other ballot positions, can = be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol= /
---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------
Thank you for this work, it is clear and well = written. While I have never
(ever) been enamoured by RSYNC, and = I much prefer this direction on a
personal level, the updates to the existing RFCs regarding = RSYNC does two
things. The first is it demotes = RSYNC to 'just another access mechanism',
and the second is it appears to remove the quality of a = mandatory to
implement retrieval mechanism. Am I reading that = correctly? If this is
intentional and has workgroup = consensus so be it and onwards we move..
 
Initially this was written as an = additional protocol, next to rsync. The idea was that rsync would be = replaced altogether at some point, but the way to get there was = intentionally left out of this document because we felt it should just = focus on protocol.
 
The changes you mention were made following AD review = comments on 7 January. The intent as I understood it was to defer the = question which retrieval mechanism is mandatory to another document, but = leave the specifications generic. 
 
<= /div>
= --Apple-Mail=_156BF0B3-736B-42BD-9690-926368066804-- From nobody Mon Feb 20 08:02:41 2017 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 BA4DD1296C2; Mon, 20 Feb 2017 08:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 y4FKvCKPztQV; Mon, 20 Feb 2017 08:02:35 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9633C12948B; Mon, 20 Feb 2017 08:02:35 -0800 (PST) Received: from [192.168.1.40] (c-73-30-72-201.hsd1.pa.comcast.net [73.30.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sra@hactrn.net) by khatovar.hactrn.net (Postfix) with ESMTPSA id 5F0E4139A2; Mon, 20 Feb 2017 16:02:33 +0000 (UTC) Date: Mon, 20 Feb 2017 11:02:30 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <5C100CD1-B5AF-4AC1-B670-0B059CEF7800@ripe.net> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> <5c3ee940068042b592026fd52d223cc2@CY1PR0601MB023.008f.mgd2.msft.net> <5C100CD1-B5AF-4AC1-B670-0B059CEF7800@ripe.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TG8ZRP4OEHXHXD747A64EQKZFOTKSK" Content-Transfer-Encoding: 7bit To: Tim Bruijnzeels ,Steve KENT From: Rob Austein Message-ID: <0DCB3029-4B85-4D44-B7AA-D88A393B0F5A@hactrn.net> Archived-At: Cc: "sidr@ietf.org" , "morrowc@ops-netman.net" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "draft-ietf-sidr-delta-protocol@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:02:37 -0000 ------TG8ZRP4OEHXHXD747A64EQKZFOTKSK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FWIW, I would prefer to leave rsync's status alone for now (i=2Ee=2E still = mandatory) and handle the transition later via separate docs, probably in S= IDROPS, per the original plan=2E --=20 Sent from a phone, please excuse brevity and typos=2E ------TG8ZRP4OEHXHXD747A64EQKZFOTKSK Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable FWIW, I would prefer to leave rsync's status alone for now (i=2Ee=2E st= ill mandatory) and handle the transition later via separate docs, probably = in SIDROPS, per the original plan=2E
--
Sent from a phone, please excuse brevity and typos=2E ------TG8ZRP4OEHXHXD747A64EQKZFOTKSK-- From nobody Tue Feb 21 07:13:33 2017 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 BA9221294DC for ; Tue, 21 Feb 2017 07:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 VkLXZ99B28gb for ; Tue, 21 Feb 2017 07:13:23 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0095.outbound.protection.outlook.com [23.103.201.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41198129C09 for ; Tue, 21 Feb 2017 07:13:23 -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=j8H/a+hiyame3fPzSAfTfBRYpVtXX8tCihdn3/jfv+k=; b=fHhboQpvvP6VrSTdjAhG/YJ801iSWZ66WpXyjqxZAOBNgOie5nI4lYXY9NImhtAA6F7nhWgWZ7yedSb/8/B8kEDMQ6qZb90kKqkC4liO2um0u50TC1KeRGtWZQIBVW9QOxO/RaB9YR+2Ejm8z/jm3VQJx6Vd/XHaXMOArsDmdSI= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0994.namprd09.prod.outlook.com (10.167.102.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 15:13:21 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0919.018; Tue, 21 Feb 2017 15:13:20 +0000 From: "Borchert, Oliver (Fed)" To: sidr list Thread-Topic: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs Thread-Index: AQHSeBA2zrHhXkAXSUqZuVZbpiHo6qFzZh6A Date: Tue, 21 Feb 2017 15:13:20 +0000 Message-ID: <845A415C-D469-4899-B7B0-0DAF728D667F@nist.gov> References: <06FD4D79-FBDD-44E0-9CF2-4B7A039A06A9@nist.gov> In-Reply-To: <06FD4D79-FBDD-44E0-9CF2-4B7A039A06A9@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BL2PR09MB0994; 7:WODT1lwKkhVkfbwxThzGnl7pQUMDc0uOxyz07WVy4nlL7J7vW0lbQMxGB+gGdIVaLfBVWDRgh7LFZqElalzS4rXX1MXpr3whlyFcZqOao5FeH48GoYt+p394HTr0py40CFiD51eQcVzvnIjnSFNwGzBDeLYvPL0M6oy+mA+hJmKpLbJGGdxvGnfTQMcrqGZ4Ng77CVjLxemdLoYGf0grAiMiIeN0t2LB3U4CKWi/b/8hOZqbfKgF1EqZxPXP1a01tZM/92lWm4Y3pMUF5UCvJx3m27iW5LRQY9h3s0W0v3w8FYvTqFFI10mNih9gR0yhtwsHPOCAwK43p+tFgTSm/w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39850400002)(39410400002)(39840400002)(40224003)(199003)(189002)(30584003)(6116002)(53936002)(68736007)(8936002)(229853002)(189998001)(6486002)(86362001)(106356001)(105586002)(4001350100001)(106116001)(97736004)(230783001)(38730400002)(99286003)(110136004)(575784001)(2900100001)(83716003)(5890100001)(101416001)(33656002)(2950100002)(122556002)(6506006)(8676002)(102836003)(6436002)(6246003)(53946003)(77096006)(3660700001)(81156014)(6512007)(54356999)(83506001)(82746002)(5660300001)(450100001)(7736002)(6916009)(66066001)(50986999)(3280700002)(92566002)(76176999)(2906002)(25786008)(3846002)(305945005)(36756003)(99936001)(81166006)(104396002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0994; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 00de06b7-be77-4db1-8860-08d45a6c2be7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR09MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BL2PR09MB0994; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0994; x-forefront-prvs: 0225B0D5BC received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_003_845A415CD4694899B7B00DAF728D667Fnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 15:13:20.4793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0994 Archived-At: Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:13:27 -0000 --_003_845A415CD4694899B7B00DAF728D667Fnistgov_ Content-Type: text/plain; charset="utf-8" Content-ID: <808C9CE5F1F92B438BC78DBA11684E95@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 QXR0YWNoZWQgaXMgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBleGFtcGxlcy4gSGVyZSB3ZSBh ZGRlZCBhbiBJUHY2IEJHUCB1cGRhdGUgdG8gdGhlIGV4aXN0aW5nIGV4YW1wbGUuDQoNCkFnYWlu LCBmb3IgYmV0dGVyIHJlYWRpbmcgSSBhdHRhY2hlZCB0aGUgZXhhbXBsZSBhcyB0ZXh0L3BkZiBp biBjYXNlIHRoZSBmb3JtYXR0aW5nIHdpdGhpbiB0aGUgZW1haWwgZ2V0cw0KTWVzc2VkIHVwLg0K DQpPbGl2ZXINCg0KLS0tLWV4YW1wbGUtLS0tZXhhbXBsZS0tLS1leGFtcGxlLS0tLQ0KVG9wb2xv Z3k6DQoNCkFTKDY0NDk2KS0tLS1BUyg2NTUzNiktLS0tQVMoNjU1MzcpDQoNClByZWZpeCBBbm5v dW5jZW1lbnRzOiBBUyg2NDQ5NiksIDE5Mi4wLjIuMC8yNCwgMjAwMTpkYjg6Oi8zMg0KDQpGb3Ig dGhpcyBleGFtcGxlLCB0aGUgRUNEU0EgYWxnb3JpdGhtIHdhcyBwcm92aWRlZCB3aXRoIGEgc3Rh dGljIGsgdG8gDQptYWtlIHRoZSByZXN1bHQgZGV0ZXJtaW5pc3RpYy4gDQpUaGUgayB1c2VkIGZv ciBhbGwgc2lnbmF0dXJlIG9wZXJhdGlvbnMgd2FzIHRha2VuIGZyb20gUkZDIDY5NzksIA0KY2hh cHRlciBBLjIuNSA/U2lnbmF0dXJlcyBXaXRoIFNIQS0yNTYsIG1lc3NhZ2UgJ3NhbXBsZSc/Lg0K DQogIGsgPSBBNkUzQzU3REQwMUFCRTkwMDg2NTM4Mzk4MzU1REQ0QzNCMTdBQTg3MzM4MkIwRjI0 RDYxMjk0OTNEOEFBRDYwDQoNCktleXMgb2YgQVM2NDQ5NjoNCj09PT09PT09PT09PT09PT0NCnNr aTogQUI0RDkxMEY1NUNBRTcxQTIxNUVGM0NBRkUzQUNDNDVCNUVFQzE1NA0KDQpwcml2YXRlIGtl eToNCiAgeCA9IEQ4QUE0REZCRTI0NzhGODZFODhBNzQ1MUJGMDc1NTY1NzA5QzU3NUFDMUMxMzZE MDgxQzU0MDI1NENBNDQwQjkNCg0KcHVibGljIGtleTogDQogIFV4ID0gNzM5MUJBQkI5MkEwQ0Iz QkUxMEU1OUIxOUVCRkZCMjE0RTA0QTkxRTBDQkExQjEzOUE3RDM4RDkwRjc3RTU1QQ0KICBVeSA9 IEEwNUI4RTY5NTY3OEUwRkExNjkwNEI1NUQ5RDRGNUMwREZDNTg4OTVFRTUwQkM0Rjc1RDIwNUEy NUJEMzZGRjUNCg0KUm91dGVyIEtleSBDZXJ0aWZpY2F0ZSBleGFtcGxlIHVzaW5nIE9wZW5TU0wg MS4wLjFlLWZpcHMgMTEgRmViIDIwMTMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDZXJ0aWZpY2F0ZToNCiAgICBE YXRhOg0KICAgICAgICBWZXJzaW9uOiAzICgweDIpDQogICAgICAgIFNlcmlhbCBOdW1iZXI6IDM4 NjU1NjEyICgweDI0ZGQ2N2MpDQogICAgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1T SEEyNTYNCiAgICAgICAgSXNzdWVyOiBDTj1ST1VURVItMDAwMEZCRjANCiAgICAgICAgVmFsaWRp dHkNCiAgICAgICAgICAgIE5vdCBCZWZvcmU6IEphbiAgMSAwNTowMDowMCAyMDE3IEdNVA0KICAg ICAgICAgICAgTm90IEFmdGVyIDogSnVsICAxIDA1OjAwOjAwIDIwMTggR01UDQogICAgICAgIFN1 YmplY3Q6IENOPVJPVVRFUi0wMDAwRkJGMA0KICAgICAgICBTdWJqZWN0IFB1YmxpYyBLZXkgSW5m bzoNCiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3JpdGhtOiBpZC1lY1B1YmxpY0tleQ0KICAg ICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQ0KICAgICAgICAgICAgICAgIHB1Yjog DQogICAgICAgICAgICAgICAgICAgIDA0OjczOjkxOmJhOmJiOjkyOmEwOmNiOjNiOmUxOjBlOjU5 OmIxOjllOmJmOg0KICAgICAgICAgICAgICAgICAgICBmYjoyMTo0ZTowNDphOToxZTowYzpiYTox YjoxMzo5YTo3ZDozODpkOTowZjoNCiAgICAgICAgICAgICAgICAgICAgNzc6ZTU6NWE6YTA6NWI6 OGU6Njk6NTY6Nzg6ZTA6ZmE6MTY6OTA6NGI6NTU6DQogICAgICAgICAgICAgICAgICAgIGQ5OmQ0 OmY1OmMwOmRmOmM1Ojg4Ojk1OmVlOjUwOmJjOjRmOjc1OmQyOjA1Og0KICAgICAgICAgICAgICAg ICAgICBhMjo1YjpkMzo2ZjpmNQ0KICAgICAgICAgICAgICAgIEFTTjEgT0lEOiBwcmltZTI1NnYx DQogICAgICAgIFg1MDl2MyBleHRlbnNpb25zOg0KICAgICAgICAgICAgWDUwOXYzIEtleSBVc2Fn ZTogDQogICAgICAgICAgICAgICAgRGlnaXRhbCBTaWduYXR1cmUNCiAgICAgICAgICAgIFg1MDl2 MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyOiANCiAgICAgICAgICAgICAgICBBQjo0RDo5MTowRjo1 NTpDQTpFNzoxQToyMTo1RTpGMzpDQTpGRTozQTpDQzo0NTpCNTpFRTpDMTo1NA0KICAgICAgICAg ICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZTogDQogICAgICAgICAgICAgICAgMS4zLjYuMS41 LjUuNy4zLjMwDQogICAgICAgICAgICBzYmdwLWF1dG9ub21vdXNTeXNOdW06IGNyaXRpY2FsDQog ICAgICAgICAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyczoNCiAgICAgICAgICAgICAg ICAgIDY0NDk2DQogICAgICAgICAgICAgICAgUm91dGluZyBEb21haW4gSWRlbnRpZmllcnM6DQog ICAgICAgICAgICAgICAgICBpbmhlcml0DQoNCiAgICBTaWduYXR1cmUgQWxnb3JpdGhtOiBlY2Rz YS13aXRoLVNIQTI1Ng0KICAgICAgICAgMzA6NDQ6MDI6MjA6MDc6Yjc6YjQ6NmE6NWY6YTQ6ZjE6 Y2M6Njg6MzY6Mzk6MDM6YTQ6ODM6DQogICAgICAgICBlYzo3Yzo4MDowMjpkMjpmNjowODo5ZDo0 NjpiMjplYzoyYTo3YjplNjo5MjpiMzo2ZjpiMToNCiAgICAgICAgIDAyOjIwOjAwOjkxOjA1OjRh OmExOmY1OmIwOjE4OjlkOjI3OjI0OmU4OmI0OjIyOmZkOmQxOg0KICAgICAgICAgMWM6ZjA6M2Q6 YjE6Mzg6MjQ6NWQ6NjQ6Mjk6MzU6Mjg6OGQ6ZWU6MGM6Mzg6MjkNCi0tLS0tQkVHSU4gQ0VSVElG SUNBVEUtLS0tLQ0KTUlJQmlEQ0NBUytnQXdJQkFnSUVBazNXZkRBS0JnZ3Foa2pPUFFRREFqQWFN Umd3RmdZRFZRUUREQTlTVDFWVQ0KUlZJdE1EQXdNRVpDUmpBd0hoY05NVGN3TVRBeE1EVXdNREF3 V2hjTk1UZ3dOekF4TURVd01EQXdXakFhTVJndw0KRmdZRFZRUUREQTlTVDFWVVJWSXRNREF3TUVa Q1JqQXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQw0KQUFSemticTdrcURMTytFT1di R2V2L3NoVGdTcEhneTZHeE9hZlRqWkQzZmxXcUJiam1sV2VPRDZGcEJMVmRuVQ0KOWNEZnhZaVY3 bEM4VDNYU0JhSmIwMi8xbzJNd1lUQUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9CQllFRkt0Tg0K a1E5Vnl1Y2FJVjd6eXY0NnpFVzE3c0ZVTUJNR0ExVWRKUVFNTUFvR0NDc0dBUVVGQndNZU1CNEdD Q3NHQVFVRg0KQndFSUFRSC9CQTh3RGFBSE1BVUNBd0Q3OEtFQ0JRQXdDZ1lJS29aSXpqMEVBd0lE UndBd1JBSWdCN2UwYWwraw0KOGN4b05qa0RwSVBzZklBQzB2WUluVWF5N0NwNzVwS3piN0VDSUFD UkJVcWg5YkFZblNjazZMUWkvZEVjOEQyeA0KT0NSZFpDazFLSTN1RERncA0KLS0tLS1FTkQgQ0VS VElGSUNBVEUtLS0tLQ0KDQoNCg0KS2V5cyBvZiBBUyg2NTYzNik6DQo9PT09PT09PT09PT09PT09 PT0NCnNraTogNDdGMjNCRjFBQjJGOEE5RDI2ODY0RUJCRDhERjI3MTFDNzQ0MDZFQw0KDQpwcml2 YXRlIGtleToNCiAgeCA9IDZDQjJFOTMxQjExMkYyNDU1NEJDRENBQUZEOTU1M0E5NTE5QTlBRjMz QzAyM0I2MDg0NkEyMUZDOTU1ODMxNzINCg0KcHVibGljIGtleTogDQogIFV4ID0gMjhGQzVGRTlB RkNGNUY0Q0FCM0Y1Rjg1Q0IyMTJGQzFFOUQwRTBEQkVBRUU0MjVCRDJGMEQzMTc1QUEwRTk4OQ0K ICBVeSA9IEVBOUI2MDNFMzhGMzVGQjMyOURGNDk1NjQxRjJCQTA0MEYxQzNBQzYxMzgzMDdGMjU3 Q0JBNkI4QjU4OEY0MUYNCg0KUm91dGVyIEtleSBDZXJ0aWZpY2F0ZSBleGFtcGxlIHVzaW5nIE9w ZW5TU0wgMS4wLjFlLWZpcHMgMTEgRmViIDIwMTMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDZXJ0aWZpY2F0ZToN CiAgICBEYXRhOg0KICAgICAgICBWZXJzaW9uOiAzICgweDIpDQogICAgICAgIFNlcmlhbCBOdW1i ZXI6IDMxNjgxODk5NDIgKDB4YmNkNmJkZjYpDQogICAgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNk c2Etd2l0aC1TSEEyNTYNCiAgICAgICAgSXNzdWVyOiBDTj1ST1VURVItMDAwMEZGRkYNCiAgICAg ICAgVmFsaWRpdHkNCiAgICAgICAgICAgIE5vdCBCZWZvcmU6IEphbiAgMSAwNTowMDowMCAyMDE3 IEdNVA0KICAgICAgICAgICAgTm90IEFmdGVyIDogSnVsICAxIDA1OjAwOjAwIDIwMTggR01UDQog ICAgICAgIFN1YmplY3Q6IENOPVJPVVRFUi0wMDAwRkZGRg0KICAgICAgICBTdWJqZWN0IFB1Ymxp YyBLZXkgSW5mbzoNCiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3JpdGhtOiBpZC1lY1B1Ymxp Y0tleQ0KICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQ0KICAgICAgICAgICAg ICAgIHB1YjogDQogICAgICAgICAgICAgICAgICAgIDA0OjI4OmZjOjVmOmU5OmFmOmNmOjVmOjRj OmFiOjNmOjVmOjg1OmNiOjIxOg0KICAgICAgICAgICAgICAgICAgICAyZjpjMTplOTpkMDplMDpk YjplYTplZTo0Mjo1YjpkMjpmMDpkMzoxNzo1YToNCiAgICAgICAgICAgICAgICAgICAgYTA6ZTk6 ODk6ZWE6OWI6NjA6M2U6Mzg6ZjM6NWY6YjM6Mjk6ZGY6NDk6NTY6DQogICAgICAgICAgICAgICAg ICAgIDQxOmYyOmJhOjA0OjBmOjFjOjNhOmM2OjEzOjgzOjA3OmYyOjU3OmNiOmE2Og0KICAgICAg ICAgICAgICAgICAgICBiODpiNTo4ODpmNDoxZg0KICAgICAgICAgICAgICAgIEFTTjEgT0lEOiBw cmltZTI1NnYxDQogICAgICAgIFg1MDl2MyBleHRlbnNpb25zOg0KICAgICAgICAgICAgWDUwOXYz IEtleSBVc2FnZTogDQogICAgICAgICAgICAgICAgRGlnaXRhbCBTaWduYXR1cmUNCiAgICAgICAg ICAgIFg1MDl2MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyOiANCiAgICAgICAgICAgICAgICA0NzpG MjozQjpGMTpBQjoyRjo4QTo5RDoyNjo4Njo0RTpCQjpEODpERjoyNzoxMTpDNzo0NDowNjpFQw0K ICAgICAgICAgICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZTogDQogICAgICAgICAgICAgICAg MS4zLjYuMS41LjUuNy4zLjMwDQogICAgICAgICAgICBzYmdwLWF1dG9ub21vdXNTeXNOdW06IGNy aXRpY2FsDQogICAgICAgICAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyczoNCiAgICAg ICAgICAgICAgICAgIDY1NTM1DQogICAgICAgICAgICAgICAgUm91dGluZyBEb21haW4gSWRlbnRp ZmllcnM6DQogICAgICAgICAgICAgICAgICBpbmhlcml0DQoNCiAgICBTaWduYXR1cmUgQWxnb3Jp dGhtOiBlY2RzYS13aXRoLVNIQTI1Ng0KICAgICAgICAgMzA6NDU6MDI6MjE6MDA6ZGY6MDQ6YzU6 MTc6MDQ6ZDA6ZjI6Yjk6ZmE6ZjM6ZDk6NmU6M2Y6DQogICAgICAgICA2ZjphMTo1ODpkODpmZTo2 YzoxODplNDozNzpjYToxOTo3YzpjODo3NTo0MDo1Nzo2ZTo3ZToNCiAgICAgICAgIDlkOjAyOjIw OjEyOjQ1OmU4OmE4OjU4OjZiOjAwOjdiOmU2OmE5OjBlOmYyOmI2OjYyOjUwOg0KICAgICAgICAg NGI6MWM6MDE6NmY6M2I6NDE6MTE6Njk6ODg6MzA6NzM6OWY6ZDc6MDI6OWU6NjQ6NGYNCi0tLS0t QkVHSU4gQ0VSVElGSUNBVEUtLS0tLQ0KTUlJQmlqQ0NBVENnQXdJQkFnSUZBTHpXdmZZd0NnWUlL b1pJemowRUF3SXdHakVZTUJZR0ExVUVBd3dQVWs5Vg0KVkVWU0xUQXdNREJHUmtaR01CNFhEVEUz TURFd01UQTFNREF3TUZvWERURTRNRGN3TVRBMU1EQXdNRm93R2pFWQ0KTUJZR0ExVUVBd3dQVWs5 VlZFVlNMVEF3TURCR1JrWkdNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRA0KUWdBRUtQ eGY2YS9QWDB5clAxK0Z5eUV2d2VuUTROdnE3a0piMHZEVEYxcWc2WW5xbTJBK09QTmZzeW5mU1Za Qg0KOHJvRUR4dzZ4aE9EQi9KWHk2YTR0WWowSDZOak1HRXdDd1lEVlIwUEJBUURBZ2VBTUIwR0Ex VWREZ1FXQkJSSA0KOGp2eHF5K0tuU2FHVHJ2WTN5Y1J4MFFHN0RBVEJnTlZIU1VFRERBS0JnZ3JC Z0VGQlFjREhqQWVCZ2dyQmdFRg0KQlFjQkNBRUIvd1FQTUEyZ0J6QUZBZ01BLy8raEFnVUFNQW9H Q0NxR1NNNDlCQU1DQTBnQU1FVUNJUURmQk1VWA0KQk5EeXVmcnoyVzQvYjZGWTJQNXNHT1EzeWhs OHlIVkFWMjUrblFJZ0VrWG9xRmhyQUh2bXFRN3l0bUpRU3h3Qg0KYnp0QkVXbUlNSE9mMXdLZVpF OD0NCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0NCg0KDQoNCkJHUFNlYyBJUHY0IFVwZGF0ZSBm cm9tIEFTKDY1NTM2KSB0byBBUyg2NTUzNyk6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KQmluYXJ5IEZvcm0gb2YgQkdQU2VjIFVwZGF0ZSAoVENQLURV TVApOg0KDQpGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYg DQowMSAwMCAwMiAwMCAwMCAwMCBFOSA0MCAgMDEgMDEgMDIgODAgMDQgMDQgMDAgMDAgDQowMCAw MCA4MCAwRSAwRCAwMCAwMSAwMSAgMDQgQzYgMzMgNjQgNjQgMDAgMTggQzAgDQowMCAwMiA5MCAy MSAwMCBDQSAwMCAwRSAgMDEgMDAgMDAgMDEgMDAgMDAgMDEgMDAgDQowMCAwMCBGQiBGMCAwMCBC QyAwMSA0NyAgRjIgM0IgRjEgQUIgMkYgOEEgOUQgMjYgDQo4NiA0RSBCQiBEOCBERiAyNyAxMSBD NyAgNDQgMDYgRUMgMDAgNDYgMzAgNDQgMDIgDQoyMCA3MiAxNCBCQyA5NiA0NyAxNiAwQiAgQkQg MzkgRkYgMkYgODAgNTMgM0YgNUQgDQpDNiBERCBENyAwRCBERiA4NiBCQiA4MSAgNTYgNjEgRTgg MDUgRDUgRDQgRTYgRjIgDQo3QyAwMiAyMCAyRCBEQyAwMCAzQyA2NCAgQkUgN0IgMjkgQzkgRUIg REIgQzggQTQgDQo5NyBFRCA2NiAyOCA1RSBFOSAyMiA3NiAgODMgRTYgQzEgNzggQ0UgOEQgRTYg RDMgDQo1OSA1RiA0MSBBQiA0RCA5MSAwRiA1NSAgQ0EgRTcgMUEgMjEgNUUgRjMgQ0EgRkUgDQoz QSBDQyA0NSBCNSBFRSBDMSA1NCAwMCAgNDcgMzAgNDUgMDIgMjAgNzIgMTQgQkMgDQo5NiA0NyAx NiAwQiBCRCAzOSBGRiAyRiAgODAgNTMgM0YgNUQgQzYgREQgRDcgMEQgDQpERiA4NiBCQiA4MSA1 NiA2MSBFOCAwNSAgRDUgRDQgRTYgRjIgN0MgMDIgMjEgMDAgDQpDNiAxNyAxOSAzNCAwNyA0MyAw NiAzQiAgOEEgNUMgQ0QgNTQgMTYgMzkgMEIgMzEgDQoyMSAxRCAzQyA1MiA0OCAwNyA5NSA4NyAg RDAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgDQoNCg0KU2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRv IEFTKDY1NTM2KToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGln ZXN0OiAgICAyMSAzMyBFNSBDQSBBMCAyNiBCRSAwNyAgIDNEIDlDIDFCIDRFIEZFIEI5IEI5IDc3 IA0KICAgICAgICAgICA5RiAyMCBGOCBGNSBERSAyOSBGQSA5OCAgIDQwIDAwIDlGIDYwIA0KU2ln bmF0dXJlOiAzMCA0NSAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgw IA0KICAgICAgICAgICA1MyAzRiA1RCBDNiBERCBENyAwRCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4 IDA1IEQ1IA0KICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgIDE3IDE5IDM0IDA3 IDQzIDA2IDNCIDhBIA0KICAgICAgICAgICA1QyBDRCA1NCAxNiAzOSAwQiAzMSAyMSAgIDFEIDND IDUyIDQ4IDA3IDk1IDg3IEQwIA0KICAgICAgICAgICAxMyAxMyA3QiA0MSBDRCAyMyBFMiANCg0K U2lnbmF0dXJlIEZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KToNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpEaWdlc3Q6ICAgIDQ2IDRCIDU3IENFIEIxIDJEIDE4IEIw ICAgRkQgMUEgMUEgMzUgOTQgMTcgM0EgNEEgDQogICAgICAgICAgIDA5IDg4IEU1IEY0IEVEIEVE IDJGIDNEICAgODMgMDggNUEgQTggDQpTaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2 ICAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgDQogICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3 IDBEIERGICAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgDQogICAgICAgICAgIEQ0IEU2IEYyIDdD IDAyIDIwIDJEIERDICAgMDAgM0MgNjQgQkUgN0IgMjkgQzkgRUIgDQogICAgICAgICAgIERCIEM4 IEE0IDk3IEVEIDY2IDI4IDVFICAgRTkgMjIgNzYgODMgRTYgQzEgNzggQ0UgDQogICAgICAgICAg IDhEIEU2IEQzIDU5IDVGIDQxIA0KDQpUaGUgaHVtYW4gcmVhZGFibGUgb3V0cHV0IGlzIHByb2R1 Y2VkIHVzaW5nIGJncHNlYy1pbywgYSBiZ3BzZWMgDQp0cmFmZmljIGdlbmVyYXRvciB0aGF0IHVz ZXMgYSB3aXJlc2hhcmsgbGlrZSBwcmludG91dC4NCg0KU2VuZCBVcGRhdGUgTWVzc2FnZQ0KICAr LS1tYXJrZXI6IEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGDQogICstLWxlbmd0aDog MjU2DQogICstLXR5cGU6ICAgMiAoVVBEQVRFKQ0KICArLS13aXRoZHJhd25fcm91dGVzX2xlbmd0 aDogMA0KICArLS10b3RhbF9wYXRoX2F0dHJfbGVuZ3RoOiAyMzMNCiAgICAgKy0tT1JJR0lOOiBJ TkNPTVBMRVRFICg0IGJ5dGVzKQ0KICAgICB8ICArLS1GbGFnczogMHg0MCAoV2VsbC1Lbm93biwg VHJhbnNpdGl2ZSwgQ29tcGxldGUpDQogICAgIHwgICstLVR5cGUgQ29kZTogT1JJR0lOICgxKQ0K ICAgICB8ICArLS1MZW5ndGg6IDEgYnl0ZQ0KICAgICB8ICArLS1PcmlnaW46IElOQ09NUExFVEUg KDEpDQogICAgICstLU1VTFRJX0VYSVRfRElTQyAoNyBieXRlcykNCiAgICAgfCAgKy0tRmxhZ3M6 IDB4ODAgKE9wdGlvbmFsLCBDb21wbGV0ZSkNCiAgICAgfCAgKy0tVHlwZSBDb2RlOiBNVUxUSV9F WElUX0RJU0MgKDQpDQogICAgIHwgICstLUxlbmd0aDogNCBieXRlcw0KICAgICB8ICArLS1kYXRh OiAwMCAwMCAwMCAwMCANCiAgICAgKy0tTVBfUkVBQ0hfTkxSSSAoMTYgYnl0ZXMpDQogICAgIHwg ICstLUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxldGUpDQogICAgIHwgICstLVR5cGUgQ29k ZTogTVBfUkVBQ0hfTkxSSSAoMTQpDQogICAgIHwgICstLUxlbmd0aDogMTMgYnl0ZXMNCiAgICAg fCAgKy0tQWRkcmVzcyBmYW1pbHk6IElQdjQgKDEpDQogICAgIHwgICstLVN1YnNlcXVlbnQgYWRk cmVzcyBmYW1pbHkgaWRlbnRpZmllcjogVW5pY2FzdCAoMSkNCiAgICAgfCAgKy0tTmV4dCBob3Ag bmV0d29yayBhZGRyZXNzOiAoNCBieXRlcykNCiAgICAgfCAgfCAgKy0tTmV4dCBob3A6IDE5OC41 MS4xMDAuMTAwDQogICAgIHwgICstLVN1Ym5ldHdvcmsgcG9pbnRzIG9mIGF0dGFjaG1lbnQ6IDAN CiAgICAgfCAgKy0tTmV0d29yayBsYXllciByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb246ICg0IGJ5 dGVzKQ0KICAgICB8ICAgICArLS0xOTIuMC4yLjAvMjQNCiAgICAgfCAgICAgKy0tTVAgUmVhY2gg TkxSSSBwcmVmaXggbGVuZ3RoOiAyNA0KICAgICB8ICAgICArLS1NUCBSZWFjaCBOTFJJIElQdjQg cHJlZml4OiAxOTIuMC4yLjANCiAgICAgKy0tQkdQU0VDIFBhdGggQXR0cmlidXRlICgyMDYgYnl0 ZXMpDQogICAgICAgICstLUZsYWdzOiAweDkwIChPcHRpb25hbCwgQ29tcGxldGUsIEV4dGVuZGVk IExlbmd0aCkNCiAgICAgICAgKy0tVHlwZSBDb2RlOiBCR1BTRUMgUGF0aCBBdHRyaWJ1dGUgKDMz KQ0KICAgICAgICArLS1MZW5ndGg6IDIwMiBieXRlcw0KICAgICAgICArLS1TZWN1cmUgUGF0aCAo MTQgYnl0ZXMpDQogICAgICAgIHwgICstLUxlbmd0aDogMTQgYnl0ZXMNCiAgICAgICAgfCAgKy0t U2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpDQogICAgICAgIHwgIHwgICstLXBDb3VudDog MQ0KICAgICAgICB8ICB8ICArLS1GbGFnczogMA0KICAgICAgICB8ICB8ICArLS1BUyBudW1iZXI6 IDY1NTM2ICgxLjApDQogICAgICAgIHwgICstLVNlY3VyZSBQYXRoIFNlZ21lbnQ6ICg2IGJ5dGVz KQ0KICAgICAgICB8ICAgICArLS1wQ291bnQ6IDENCiAgICAgICAgfCAgICAgKy0tRmxhZ3M6IDAN CiAgICAgICAgfCAgICAgKy0tQVMgbnVtYmVyOiA2NDQ5NiAoMC42NDQ5NikNCiAgICAgICAgKy0t U2lnbmF0dXJlIEJsb2NrICgxODggYnl0ZXMpDQogICAgICAgICAgICstLUxlbmd0aDogMTg4IGJ5 dGVzDQogICAgICAgICAgICstLUFsZ28gSUQ6IDENCiAgICAgICAgICAgKy0tU2lnbmF0dXJlIFNl Z21lbnQ6ICg5MiBieXRlcykNCiAgICAgICAgICAgfCAgKy0tU0tJOiA0N0YyM0JGMUFCMkY4QTlE MjY4NjRFQkJEOERGMjcxMUM3NDQwNkVDDQogICAgICAgICAgIHwgICstLUxlbmd0aDogNzAgYnl0 ZXMNCiAgICAgICAgICAgfCAgKy0tU2lnbmF0dXJlOiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAg IDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwIA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgIDUz IDNGIDVEIEM2IEREIEQ3IDBEIERGICAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgDQogICAgICAg ICAgIHwgICAgICAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMkQgREMgICAwMCAzQyA2NCBC RSA3QiAyOSBDOSBFQiANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICBEQiBDOCBBNCA5NyBF RCA2NiAyOCA1RSAgIEU5IDIyIDc2IDgzIEU2IEMxIDc4IENFIA0KICAgICAgICAgICB8ICAgICAg ICAgICAgICAgIDhEIEU2IEQzIDU5IDVGIDQxIA0KICAgICAgICAgICArLS1TaWduYXR1cmUgU2Vn bWVudDogKDkzIGJ5dGVzKQ0KICAgICAgICAgICAgICArLS1TS0k6IEFCNEQ5MTBGNTVDQUU3MUEy MTVFRjNDQUZFM0FDQzQ1QjVFRUMxNTQNCiAgICAgICAgICAgICAgKy0tTGVuZ3RoOiA3MSBieXRl cw0KICAgICAgICAgICAgICArLS1TaWduYXR1cmU6IDMwIDQ1IDAyIDIwIDcyIDE0IEJDIDk2ICAg NDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgNTMg M0YgNUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgIDE3IDE5IDM0IDA3 IDQzIDA2IDNCIDhBIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDVDIENEIDU0IDE2IDM5 IDBCIDMxIDIxICAgMUQgM0MgNTIgNDggMDcgOTUgODcgRDAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgDQoNCg0KQkdQU2VjIElQdjYgVXBkYXRlIGZy b20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KToNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpCaW5hcnkgRm9ybSBvZiBCR1BTZWMgVXBkYXRlIChUQ1AtRFVN UCk6DQoNCkZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRg0K MDEgMEMgMDIgMDAgMDAgMDAgRjUgNDAgIDAxIDAxIDAyIDgwIDA0IDA0IDAwIDAwDQowMCAwMCA4 MCAwRSAxQSAwMCAwMiAwMSAgMTAgMjAgMDEgMDAgMTAgMDAgMDAgMDANCjAwIDAwIDAwIDAwIDAw IEM2IDMzIDY0ICA2NCAwMCAyMCAyMCAwMSAwRCBCOCA5MA0KMjEgMDAgQzkgMDAgMEUgMDEgMDAg MDAgIDAxIDAwIDAwIDAxIDAwIDAwIDAwIEZCDQpGMCAwMCBCQiAwMSA0NyBGMiAzQiBGMSAgQUIg MkYgOEEgOUQgMjYgODYgNEUgQkINCkQ4IERGIDI3IDExIEM3IDQ0IDA2IEVDICAwMCA0NiAzMCA0 NCAwMiAyMCA3MiAxNA0KQkMgOTYgNDcgMTYgMEIgQkQgMzkgRkYgIDJGIDgwIDUzIDNGIDVEIEM2 IEREIEQ3DQowRCBERiA4NiBCQiA4MSA1NiA2MSBFOCAgMDUgRDUgRDQgRTYgRjIgN0MgMDIgMjAN CjBBIDlBIEU3IDVGIDU2IENFIDQyIDlDICBEMiBEMiAyMCAzOCA2QiA4RCAyNCA3Mw0KRTkgNUMg OEEgNTAgRTUgNTggREIgOTIgIEI3IDg4IDNEIDA5IEU4IDQyIDRFIEU3DQpBQiA0RCA5MSAwRiA1 NSBDQSBFNyAxQSAgMjEgNUUgRjMgQ0EgRkUgM0EgQ0MgNDUNCkI1IEVFIEMxIDU0IDAwIDQ2IDMw IDQ0ICAwMiAyMCA3MiAxNCBCQyA5NiA0NyAxNg0KMEIgQkQgMzkgRkYgMkYgODAgNTMgM0YgIDVE IEM2IEREIEQ3IDBEIERGIDg2IEJCDQo4MSA1NiA2MSBFOCAwNSBENSBENCBFNiAgRjIgN0MgMDIg MjAgNkUgMjYgNTIgNDANCkNGIENBIDBFIEY2IDVDIDhFIEExIEFGICA2QiA2NSAyQSAxOSAxMyBE MiBGQyBCRA0KQjUgOEUgRTkgNTMgNjAgOUYgODUgRjAgIEQyIDY5IDk5IERGICANCg0KDQpTaWdu YXR1cmUgRnJvbSBBUyg2NDQ5NikgdG8gQVMoNjU1MzYpOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpEaWdlc3Q6ICAgIDhBIDBDIEQzIEU5IDhFIDU1IDEwIDQ1ICAg ODIgMUQgODAgNDYgMDEgRDYgNTUgRkMgDQogICAgICAgICAgIDUyIDExIDg5IERGIDREIEIwIDI4 IDdEICAgODQgQUMgRkMgNzcgDQpTaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICAg NDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgDQogICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBE IERGICAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgDQogICAgICAgICAgIEQ0IEU2IEYyIDdDIDAy IDIwIDZFIDI2ICAgNTIgNDAgQ0YgQ0EgMEUgRjYgNUMgOEUgDQogICAgICAgICAgIEExIEFGIDZC IDY1IDJBIDE5IDEzIEQyICAgRkMgQkQgQjUgOEUgRTkgNTMgNjAgOUYgDQogICAgICAgICAgIDg1 IEYwIEQyIDY5IDk5IERGIA0KDQpTaWduYXR1cmUgRnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1Mzcp Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRpZ2VzdDogICAgQkEg QkYgRjcgOTUgQkYgM0MgQkUgODEgICA3OSAxRiBBOSA5MCAwNiBGQyAzMCAxQiANCiAgICAgICAg ICAgMEQgQkMgRDUgNDkgMzkgNUEgMEEgNzEgICBDMiBENSBCMiBGQSANClNpZ25hdHVyZTogMzAg NDQgMDIgMjAgNzIgMTQgQkMgOTYgICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MCANCiAgICAgICAg ICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSANCiAg ICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMEEgOUEgICBFNyA1RiA1NiBDRSA0MiA5QyBEMiBE MiANCiAgICAgICAgICAgMjAgMzggNkIgOEQgMjQgNzMgRTkgNUMgICA4QSA1MCBFNSA1OCBEQiA5 MiBCNyA4OCANCiAgICAgICAgICAgM0QgMDkgRTggNDIgNEUgRTcgDQoNCg0KVGhlIGh1bWFuIHJl YWRhYmxlIG91dHB1dCBpcyBwcm9kdWNlZCB1c2luZyBiZ3BzZWMtaW8sIGEgYmdwc2VjIA0KdHJh ZmZpYyBnZW5lcmF0b3IgdGhhdCB1c2VzIGEgd2lyZXNoYXJrIGxpa2UgcHJpbnRvdXQuDQoNClNl bmQgVXBkYXRlIE1lc3NhZ2UNCiAgKy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRg0KICArLS1sZW5ndGg6IDI2OA0KICArLS10eXBlOiAgIDIgKFVQREFURSkNCiAgKy0t d2l0aGRyYXduX3JvdXRlc19sZW5ndGg6IDANCiAgKy0tdG90YWxfcGF0aF9hdHRyX2xlbmd0aDog MjQ1DQogICAgICstLU9SSUdJTjogSU5DT01QTEVURSAoNCBieXRlcykNCiAgICAgfCAgKy0tRmxh Z3M6IDB4NDAgKFdlbGwtS25vd24sIFRyYW5zaXRpdmUsIENvbXBsZXRlKQ0KICAgICB8ICArLS1U eXBlIENvZGU6IE9SSUdJTiAoMSkNCiAgICAgfCAgKy0tTGVuZ3RoOiAxIGJ5dGUNCiAgICAgfCAg Ky0tT3JpZ2luOiBJTkNPTVBMRVRFICgxKQ0KICAgICArLS1NVUxUSV9FWElUX0RJU0MgKDcgYnl0 ZXMpDQogICAgIHwgICstLUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxldGUpDQogICAgIHwg ICstLVR5cGUgQ29kZTogTVVMVElfRVhJVF9ESVNDICg0KQ0KICAgICB8ICArLS1MZW5ndGg6IDQg Ynl0ZXMNCiAgICAgfCAgKy0tZGF0YTogMDAgMDAgMDAgMDAgDQogICAgICstLU1QX1JFQUNIX05M UkkgKDI5IGJ5dGVzKQ0KICAgICB8ICArLS1GbGFnczogMHg4MCAoT3B0aW9uYWwsIENvbXBsZXRl KQ0KICAgICB8ICArLS1UeXBlIENvZGU6IE1QX1JFQUNIX05MUkkgKDE0KQ0KICAgICB8ICArLS1M ZW5ndGg6IDI2IGJ5dGVzDQogICAgIHwgICstLUFkZHJlc3MgZmFtaWx5OiBJUHY2ICgyKQ0KICAg ICB8ICArLS1TdWJzZXF1ZW50IGFkZHJlc3MgZmFtaWx5IGlkZW50aWZpZXI6IFVuaWNhc3QgKDEp DQogICAgIHwgICstLU5leHQgaG9wIG5ldHdvcmsgYWRkcmVzczogKDE2IGJ5dGVzKQ0KICAgICB8 ICB8ICArLS1OZXh0IGhvcDogMjAwMTowMDEwOjAwMDA6MDAwMDowMDAwOjAwMDA6YzYzMzo2NDY0 DQogICAgIHwgICstLVN1Ym5ldHdvcmsgcG9pbnRzIG9mIGF0dGFjaG1lbnQ6IDANCiAgICAgfCAg Ky0tTmV0d29yayBsYXllciByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb246ICg1IGJ5dGVzKQ0KICAg ICB8ICAgICArLS0yMDAxOmRiODo6LzMyDQogICAgIHwgICAgICstLU1QIFJlYWNoIE5MUkkgcHJl Zml4IGxlbmd0aDogMzINCiAgICAgfCAgICAgKy0tTVAgUmVhY2ggTkxSSSBJUHY2IHByZWZpeDog MjAwMTpkYjg6Og0KICAgICArLS1CR1BTRUMgUGF0aCBBdHRyaWJ1dGUgKDIwNSBieXRlcykNCiAg ICAgICAgKy0tRmxhZ3M6IDB4OTAgKE9wdGlvbmFsLCBDb21wbGV0ZSwgRXh0ZW5kZWQgTGVuZ3Ro KQ0KICAgICAgICArLS1UeXBlIENvZGU6IEJHUFNFQyBQYXRoIEF0dHJpYnV0ZSAoMzMpDQogICAg ICAgICstLUxlbmd0aDogMjAxIGJ5dGVzDQogICAgICAgICstLVNlY3VyZSBQYXRoICgxNCBieXRl cykNCiAgICAgICAgfCAgKy0tTGVuZ3RoOiAxNCBieXRlcw0KICAgICAgICB8ICArLS1TZWN1cmUg UGF0aCBTZWdtZW50OiAoNiBieXRlcykNCiAgICAgICAgfCAgfCAgKy0tcENvdW50OiAxDQogICAg ICAgIHwgIHwgICstLUZsYWdzOiAwDQogICAgICAgIHwgIHwgICstLUFTIG51bWJlcjogNjU1MzYg KDEuMCkNCiAgICAgICAgfCAgKy0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpDQogICAg ICAgIHwgICAgICstLXBDb3VudDogMQ0KICAgICAgICB8ICAgICArLS1GbGFnczogMA0KICAgICAg ICB8ICAgICArLS1BUyBudW1iZXI6IDY0NDk2ICgwLjY0NDk2KQ0KICAgICAgICArLS1TaWduYXR1 cmUgQmxvY2sgKDE4NyBieXRlcykNCiAgICAgICAgICAgKy0tTGVuZ3RoOiAxODcgYnl0ZXMNCiAg ICAgICAgICAgKy0tQWxnbyBJRDogMQ0KICAgICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVudDog KDkyIGJ5dGVzKQ0KICAgICAgICAgICB8ICArLS1TS0k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2NEVC QkQ4REYyNzExQzc0NDA2RUMNCiAgICAgICAgICAgfCAgKy0tTGVuZ3RoOiA3MCBieXRlcw0KICAg ICAgICAgICB8ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYg MEIgQkQgMzkgRkYgMkYgODAgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgNTMgM0YgNUQg QzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSANCiAgICAgICAgICAgfCAg ICAgICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMCAwQSA5QSAgIEU3IDVGIDU2IENFIDQyIDlD IEQyIEQyIA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgIDIwIDM4IDZCIDhEIDI0IDczIEU5 IDVDICAgOEEgNTAgRTUgNTggREIgOTIgQjcgODggDQogICAgICAgICAgIHwgICAgICAgICAgICAg ICAgM0QgMDkgRTggNDIgNEUgRTcgDQogICAgICAgICAgICstLVNpZ25hdHVyZSBTZWdtZW50OiAo OTIgYnl0ZXMpDQogICAgICAgICAgICAgICstLVNLSTogQUI0RDkxMEY1NUNBRTcxQTIxNUVGM0NB RkUzQUNDNDVCNUVFQzE1NA0KICAgICAgICAgICAgICArLS1MZW5ndGg6IDcwIGJ5dGVzDQogICAg ICAgICAgICAgICstLVNpZ25hdHVyZTogMzAgNDQgMDIgMjAgNzIgMTQgQkMgOTYgICA0NyAxNiAw QiBCRCAzOSBGRiAyRiA4MCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA1MyAzRiA1RCBD NiBERCBENyAwRCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIwIDZFIDI2ICAgNTIgNDAgQ0YgQ0EgMEUgRjYg NUMgOEUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQTEgQUYgNkIgNjUgMkEgMTkgMTMg RDIgICBGQyBCRCBCNSA4RSBFOSA1MyA2MCA5RiANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICA4NSBGMCBEMiA2OSA5OSBERiANCg0KLS0tLWV4YW1wbGUtLS0tZXhhbXBsZS0tLS1leGFtcGxl LS0tLQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdA0KTmF0aW9u YWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KKFBob25lKSAzMDEuOTc1 LjQ4NTYgLCAoRmF4KSAzMDEuOTc1LjYyMzgNCiAgICANCiAgICANCiAgICANCg0K --_003_845A415CD4694899B7B00DAF728D667Fnistgov_ Content-Type: text/plain; name="draft-ietf-sidr-bgpsec-algs-examples-v4.txt" Content-Description: draft-ietf-sidr-bgpsec-algs-examples-v4.txt Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples-v4.txt"; size=15171; creation-date="Tue, 21 Feb 2017 15:13:19 GMT"; modification-date="Tue, 21 Feb 2017 15:13:19 GMT" Content-ID: <9176985E7BDB9E4EA7BF620D18F0B12F@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 VG9wb2xvZ3k6CgpBUyg2NDQ5NiktLS0tQVMoNjU1MzYpLS0tLUFTKDY1NTM3KQoKUHJlZml4IEFu bm91bmNlbWVudHM6IEFTKDY0NDk2KSwgMTkyLjAuMi4wLzI0LCAyMDAxOmRiODo6LzMyCgpGb3Ig dGhpcyBleGFtcGxlLCB0aGUgRUNEU0EgYWxnb3JpdGhtIHdhcyBwcm92aWRlZCB3aXRoIGEgc3Rh dGljIGsgdG8gCm1ha2UgdGhlIHJlc3VsdCBkZXRlcm1pbmlzdGljLiAKVGhlIGsgdXNlZCBmb3Ig YWxsIHNpZ25hdHVyZSBvcGVyYXRpb25zIHdhcyB0YWtlbiBmcm9tIFJGQyA2OTc5LCAKY2hhcHRl ciBBLjIuNSA/U2lnbmF0dXJlcyBXaXRoIFNIQS0yNTYsIG1lc3NhZ2UgJ3NhbXBsZSc/LgoKICBr ID0gQTZFM0M1N0REMDFBQkU5MDA4NjUzODM5ODM1NURENEMzQjE3QUE4NzMzODJCMEYyNEQ2MTI5 NDkzRDhBQUQ2MAoKS2V5cyBvZiBBUzY0NDk2Ogo9PT09PT09PT09PT09PT09CnNraTogQUI0RDkx MEY1NUNBRTcxQTIxNUVGM0NBRkUzQUNDNDVCNUVFQzE1NAoKcHJpdmF0ZSBrZXk6CiAgeCA9IEQ4 QUE0REZCRTI0NzhGODZFODhBNzQ1MUJGMDc1NTY1NzA5QzU3NUFDMUMxMzZEMDgxQzU0MDI1NENB NDQwQjkKCnB1YmxpYyBrZXk6IAogIFV4ID0gNzM5MUJBQkI5MkEwQ0IzQkUxMEU1OUIxOUVCRkZC MjE0RTA0QTkxRTBDQkExQjEzOUE3RDM4RDkwRjc3RTU1QQogIFV5ID0gQTA1QjhFNjk1Njc4RTBG QTE2OTA0QjU1RDlENEY1QzBERkM1ODg5NUVFNTBCQzRGNzVEMjA1QTI1QkQzNkZGNQoKUm91dGVy IEtleSBDZXJ0aWZpY2F0ZSBleGFtcGxlIHVzaW5nIE9wZW5TU0wgMS4wLjFlLWZpcHMgMTEgRmVi IDIwMTMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KQ2VydGlmaWNhdGU6CiAgICBEYXRhOgogICAgICAgIFZlcnNpb246 IDMgKDB4MikKICAgICAgICBTZXJpYWwgTnVtYmVyOiAzODY1NTYxMiAoMHgyNGRkNjdjKQogICAg U2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTYKICAgICAgICBJc3N1ZXI6IENO PVJPVVRFUi0wMDAwRkJGMAogICAgICAgIFZhbGlkaXR5CiAgICAgICAgICAgIE5vdCBCZWZvcmU6 IEphbiAgMSAwNTowMDowMCAyMDE3IEdNVAogICAgICAgICAgICBOb3QgQWZ0ZXIgOiBKdWwgIDEg MDU6MDA6MDAgMjAxOCBHTVQKICAgICAgICBTdWJqZWN0OiBDTj1ST1VURVItMDAwMEZCRjAKICAg ICAgICBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbzoKICAgICAgICAgICAgUHVibGljIEtleSBBbGdv cml0aG06IGlkLWVjUHVibGljS2V5CiAgICAgICAgICAgICAgICBQdWJsaWMtS2V5OiAoMjU2IGJp dCkKICAgICAgICAgICAgICAgIHB1YjogCiAgICAgICAgICAgICAgICAgICAgMDQ6NzM6OTE6YmE6 YmI6OTI6YTA6Y2I6M2I6ZTE6MGU6NTk6YjE6OWU6YmY6CiAgICAgICAgICAgICAgICAgICAgZmI6 MjE6NGU6MDQ6YTk6MWU6MGM6YmE6MWI6MTM6OWE6N2Q6Mzg6ZDk6MGY6CiAgICAgICAgICAgICAg ICAgICAgNzc6ZTU6NWE6YTA6NWI6OGU6Njk6NTY6Nzg6ZTA6ZmE6MTY6OTA6NGI6NTU6CiAgICAg ICAgICAgICAgICAgICAgZDk6ZDQ6ZjU6YzA6ZGY6YzU6ODg6OTU6ZWU6NTA6YmM6NGY6NzU6ZDI6 MDU6CiAgICAgICAgICAgICAgICAgICAgYTI6NWI6ZDM6NmY6ZjUKICAgICAgICAgICAgICAgIEFT TjEgT0lEOiBwcmltZTI1NnYxCiAgICAgICAgWDUwOXYzIGV4dGVuc2lvbnM6CiAgICAgICAgICAg IFg1MDl2MyBLZXkgVXNhZ2U6IAogICAgICAgICAgICAgICAgRGlnaXRhbCBTaWduYXR1cmUKICAg ICAgICAgICAgWDUwOXYzIFN1YmplY3QgS2V5IElkZW50aWZpZXI6IAogICAgICAgICAgICAgICAg QUI6NEQ6OTE6MEY6NTU6Q0E6RTc6MUE6MjE6NUU6RjM6Q0E6RkU6M0E6Q0M6NDU6QjU6RUU6QzE6 NTQKICAgICAgICAgICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZTogCiAgICAgICAgICAgICAg ICAxLjMuNi4xLjUuNS43LjMuMzAKICAgICAgICAgICAgc2JncC1hdXRvbm9tb3VzU3lzTnVtOiBj cml0aWNhbAogICAgICAgICAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyczoKICAgICAg ICAgICAgICAgICAgNjQ0OTYKICAgICAgICAgICAgICAgIFJvdXRpbmcgRG9tYWluIElkZW50aWZp ZXJzOgogICAgICAgICAgICAgICAgICBpbmhlcml0CgogICAgU2lnbmF0dXJlIEFsZ29yaXRobTog ZWNkc2Etd2l0aC1TSEEyNTYKICAgICAgICAgMzA6NDQ6MDI6MjA6MDc6Yjc6YjQ6NmE6NWY6YTQ6 ZjE6Y2M6Njg6MzY6Mzk6MDM6YTQ6ODM6CiAgICAgICAgIGVjOjdjOjgwOjAyOmQyOmY2OjA4Ojlk OjQ2OmIyOmVjOjJhOjdiOmU2OjkyOmIzOjZmOmIxOgogICAgICAgICAwMjoyMDowMDo5MTowNTo0 YTphMTpmNTpiMDoxODo5ZDoyNzoyNDplODpiNDoyMjpmZDpkMToKICAgICAgICAgMWM6ZjA6M2Q6 YjE6Mzg6MjQ6NWQ6NjQ6Mjk6MzU6Mjg6OGQ6ZWU6MGM6Mzg6MjkKLS0tLS1CRUdJTiBDRVJUSUZJ Q0FURS0tLS0tCk1JSUJpRENDQVMrZ0F3SUJBZ0lFQWszV2ZEQUtCZ2dxaGtqT1BRUURBakFhTVJn d0ZnWURWUVFEREE5U1QxVlUKUlZJdE1EQXdNRVpDUmpBd0hoY05NVGN3TVRBeE1EVXdNREF3V2hj Tk1UZ3dOekF4TURVd01EQXdXakFhTVJndwpGZ1lEVlFRRERBOVNUMVZVUlZJdE1EQXdNRVpDUmpB d1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DCkFBUnprYnE3a3FETE8rRU9XYkdldi9z aFRnU3BIZ3k2R3hPYWZUalpEM2ZsV3FCYmptbFdlT0Q2RnBCTFZkblUKOWNEZnhZaVY3bEM4VDNY U0JhSmIwMi8xbzJNd1lUQUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9CQllFRkt0TgprUTlWeXVj YUlWN3p5djQ2ekVXMTdzRlVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01lTUI0R0NDc0dBUVVG CkJ3RUlBUUgvQkE4d0RhQUhNQVVDQXdENzhLRUNCUUF3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUln QjdlMGFsK2sKOGN4b05qa0RwSVBzZklBQzB2WUluVWF5N0NwNzVwS3piN0VDSUFDUkJVcWg5YkFZ blNjazZMUWkvZEVjOEQyeApPQ1JkWkNrMUtJM3VERGdwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0t LS0KCgoKS2V5cyBvZiBBUyg2NTYzNik6Cj09PT09PT09PT09PT09PT09PQpza2k6IDQ3RjIzQkYx QUIyRjhBOUQyNjg2NEVCQkQ4REYyNzExQzc0NDA2RUMKCnByaXZhdGUga2V5OgogIHggPSA2Q0Iy RTkzMUIxMTJGMjQ1NTRCQ0RDQUFGRDk1NTNBOTUxOUE5QUYzM0MwMjNCNjA4NDZBMjFGQzk1NTgz MTcyCgpwdWJsaWMga2V5OiAKICBVeCA9IDI4RkM1RkU5QUZDRjVGNENBQjNGNUY4NUNCMjEyRkMx RTlEMEUwREJFQUVFNDI1QkQyRjBEMzE3NUFBMEU5ODkKICBVeSA9IEVBOUI2MDNFMzhGMzVGQjMy OURGNDk1NjQxRjJCQTA0MEYxQzNBQzYxMzgzMDdGMjU3Q0JBNkI4QjU4OEY0MUYKClJvdXRlciBL ZXkgQ2VydGlmaWNhdGUgZXhhbXBsZSB1c2luZyBPcGVuU1NMIDEuMC4xZS1maXBzIDExIEZlYiAy MDEzCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCkNlcnRpZmljYXRlOgogICAgRGF0YToKICAgICAgICBWZXJzaW9uOiAz ICgweDIpCiAgICAgICAgU2VyaWFsIE51bWJlcjogMzE2ODE4OTk0MiAoMHhiY2Q2YmRmNikKICAg IFNpZ25hdHVyZSBBbGdvcml0aG06IGVjZHNhLXdpdGgtU0hBMjU2CiAgICAgICAgSXNzdWVyOiBD Tj1ST1VURVItMDAwMEZGRkYKICAgICAgICBWYWxpZGl0eQogICAgICAgICAgICBOb3QgQmVmb3Jl OiBKYW4gIDEgMDU6MDA6MDAgMjAxNyBHTVQKICAgICAgICAgICAgTm90IEFmdGVyIDogSnVsICAx IDA1OjAwOjAwIDIwMTggR01UCiAgICAgICAgU3ViamVjdDogQ049Uk9VVEVSLTAwMDBGRkZGCiAg ICAgICAgU3ViamVjdCBQdWJsaWMgS2V5IEluZm86CiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxn b3JpdGhtOiBpZC1lY1B1YmxpY0tleQogICAgICAgICAgICAgICAgUHVibGljLUtleTogKDI1NiBi aXQpCiAgICAgICAgICAgICAgICBwdWI6IAogICAgICAgICAgICAgICAgICAgIDA0OjI4OmZjOjVm OmU5OmFmOmNmOjVmOjRjOmFiOjNmOjVmOjg1OmNiOjIxOgogICAgICAgICAgICAgICAgICAgIDJm OmMxOmU5OmQwOmUwOmRiOmVhOmVlOjQyOjViOmQyOmYwOmQzOjE3OjVhOgogICAgICAgICAgICAg ICAgICAgIGEwOmU5Ojg5OmVhOjliOjYwOjNlOjM4OmYzOjVmOmIzOjI5OmRmOjQ5OjU2OgogICAg ICAgICAgICAgICAgICAgIDQxOmYyOmJhOjA0OjBmOjFjOjNhOmM2OjEzOjgzOjA3OmYyOjU3OmNi OmE2OgogICAgICAgICAgICAgICAgICAgIGI4OmI1Ojg4OmY0OjFmCiAgICAgICAgICAgICAgICBB U04xIE9JRDogcHJpbWUyNTZ2MQogICAgICAgIFg1MDl2MyBleHRlbnNpb25zOgogICAgICAgICAg ICBYNTA5djMgS2V5IFVzYWdlOiAKICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJlCiAg ICAgICAgICAgIFg1MDl2MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyOiAKICAgICAgICAgICAgICAg IDQ3OkYyOjNCOkYxOkFCOjJGOjhBOjlEOjI2Ojg2OjRFOkJCOkQ4OkRGOjI3OjExOkM3OjQ0OjA2 OkVDCiAgICAgICAgICAgIFg1MDl2MyBFeHRlbmRlZCBLZXkgVXNhZ2U6IAogICAgICAgICAgICAg ICAgMS4zLjYuMS41LjUuNy4zLjMwCiAgICAgICAgICAgIHNiZ3AtYXV0b25vbW91c1N5c051bTog Y3JpdGljYWwKICAgICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlcnM6CiAgICAg ICAgICAgICAgICAgIDY1NTM1CiAgICAgICAgICAgICAgICBSb3V0aW5nIERvbWFpbiBJZGVudGlm aWVyczoKICAgICAgICAgICAgICAgICAgaW5oZXJpdAoKICAgIFNpZ25hdHVyZSBBbGdvcml0aG06 IGVjZHNhLXdpdGgtU0hBMjU2CiAgICAgICAgIDMwOjQ1OjAyOjIxOjAwOmRmOjA0OmM1OjE3OjA0 OmQwOmYyOmI5OmZhOmYzOmQ5OjZlOjNmOgogICAgICAgICA2ZjphMTo1ODpkODpmZTo2YzoxODpl NDozNzpjYToxOTo3YzpjODo3NTo0MDo1Nzo2ZTo3ZToKICAgICAgICAgOWQ6MDI6MjA6MTI6NDU6 ZTg6YTg6NTg6NmI6MDA6N2I6ZTY6YTk6MGU6ZjI6YjY6NjI6NTA6CiAgICAgICAgIDRiOjFjOjAx OjZmOjNiOjQxOjExOjY5Ojg4OjMwOjczOjlmOmQ3OjAyOjllOjY0OjRmCi0tLS0tQkVHSU4gQ0VS VElGSUNBVEUtLS0tLQpNSUlCaWpDQ0FUQ2dBd0lCQWdJRkFMeld2Zll3Q2dZSUtvWkl6ajBFQXdJ d0dqRVlNQllHQTFVRUF3d1BVazlWClZFVlNMVEF3TURCR1JrWkdNQjRYRFRFM01ERXdNVEExTURB d01Gb1hEVEU0TURjd01UQTFNREF3TUZvd0dqRVkKTUJZR0ExVUVBd3dQVWs5VlZFVlNMVEF3TURC R1JrWkdNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRApRZ0FFS1B4ZjZhL1BYMHlyUDEr Rnl5RXZ3ZW5RNE52cTdrSmIwdkRURjFxZzZZbnFtMkErT1BOZnN5bmZTVlpCCjhyb0VEeHc2eGhP REIvSlh5NmE0dFlqMEg2TmpNR0V3Q3dZRFZSMFBCQVFEQWdlQU1CMEdBMVVkRGdRV0JCUkgKOGp2 eHF5K0tuU2FHVHJ2WTN5Y1J4MFFHN0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREhqQWVCZ2dy QmdFRgpCUWNCQ0FFQi93UVBNQTJnQnpBRkFnTUEvLytoQWdVQU1Bb0dDQ3FHU000OUJBTUNBMGdB TUVVQ0lRRGZCTVVYCkJORHl1ZnJ6Mlc0L2I2RlkyUDVzR09RM3lobDh5SFZBVjI1K25RSWdFa1hv cUZockFIdm1xUTd5dG1KUVN4d0IKYnp0QkVXbUlNSE9mMXdLZVpFOD0KLS0tLS1FTkQgQ0VSVElG SUNBVEUtLS0tLQoKCgpCR1BTZWMgSVB2NCBVcGRhdGUgZnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1 MzcpOgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpCaW5h cnkgRm9ybSBvZiBCR1BTZWMgVXBkYXRlIChUQ1AtRFVNUCk6CgpGRiBGRiBGRiBGRiBGRiBGRiBG RiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgCjAxIDAwIDAyIDAwIDAwIDAwIEU5IDQwICAw MSAwMSAwMiA4MCAwNCAwNCAwMCAwMCAKMDAgMDAgODAgMEUgMEQgMDAgMDEgMDEgIDA0IEM2IDMz IDY0IDY0IDAwIDE4IEMwIAowMCAwMiA5MCAyMSAwMCBDQSAwMCAwRSAgMDEgMDAgMDAgMDEgMDAg MDAgMDEgMDAgCjAwIDAwIEZCIEYwIDAwIEJDIDAxIDQ3ICBGMiAzQiBGMSBBQiAyRiA4QSA5RCAy NiAKODYgNEUgQkIgRDggREYgMjcgMTEgQzcgIDQ0IDA2IEVDIDAwIDQ2IDMwIDQ0IDAyIAoyMCA3 MiAxNCBCQyA5NiA0NyAxNiAwQiAgQkQgMzkgRkYgMkYgODAgNTMgM0YgNUQgCkM2IEREIEQ3IDBE IERGIDg2IEJCIDgxICA1NiA2MSBFOCAwNSBENSBENCBFNiBGMiAKN0MgMDIgMjAgMkQgREMgMDAg M0MgNjQgIEJFIDdCIDI5IEM5IEVCIERCIEM4IEE0IAo5NyBFRCA2NiAyOCA1RSBFOSAyMiA3NiAg ODMgRTYgQzEgNzggQ0UgOEQgRTYgRDMgCjU5IDVGIDQxIEFCIDREIDkxIDBGIDU1ICBDQSBFNyAx QSAyMSA1RSBGMyBDQSBGRSAKM0EgQ0MgNDUgQjUgRUUgQzEgNTQgMDAgIDQ3IDMwIDQ1IDAyIDIw IDcyIDE0IEJDIAo5NiA0NyAxNiAwQiBCRCAzOSBGRiAyRiAgODAgNTMgM0YgNUQgQzYgREQgRDcg MEQgCkRGIDg2IEJCIDgxIDU2IDYxIEU4IDA1ICBENSBENCBFNiBGMiA3QyAwMiAyMSAwMCAKQzYg MTcgMTkgMzQgMDcgNDMgMDYgM0IgIDhBIDVDIENEIDU0IDE2IDM5IDBCIDMxIAoyMSAxRCAzQyA1 MiA0OCAwNyA5NSA4NyAgRDAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgCgoKU2lnbmF0dXJlIEZyb20g QVMoNjQ0OTYpIHRvIEFTKDY1NTM2KToKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCkRpZ2VzdDogICAgMjEgMzMgRTUgQ0EgQTAgMjYgQkUgMDcgICAzRCA5QyAxQiA0RSBG RSBCOSBCOSA3NyAKICAgICAgICAgICA5RiAyMCBGOCBGNSBERSAyOSBGQSA5OCAgIDQwIDAwIDlG IDYwIApTaWduYXR1cmU6IDMwIDQ1IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkg RkYgMkYgODAgCiAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1 NiA2MSBFOCAwNSBENSAKICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgIDE3IDE5 IDM0IDA3IDQzIDA2IDNCIDhBIAogICAgICAgICAgIDVDIENEIDU0IDE2IDM5IDBCIDMxIDIxICAg MUQgM0MgNTIgNDggMDcgOTUgODcgRDAgCiAgICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIg CgpTaWduYXR1cmUgRnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1MzcpOgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpEaWdlc3Q6ICAgIDQ2IDRCIDU3IENFIEIxIDJEIDE4IEIw ICAgRkQgMUEgMUEgMzUgOTQgMTcgM0EgNEEgCiAgICAgICAgICAgMDkgODggRTUgRjQgRUQgRUQg MkYgM0QgICA4MyAwOCA1QSBBOCAKU2lnbmF0dXJlOiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAg IDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwIAogICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBE IERGICAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgCiAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIg MjAgMkQgREMgICAwMCAzQyA2NCBCRSA3QiAyOSBDOSBFQiAKICAgICAgICAgICBEQiBDOCBBNCA5 NyBFRCA2NiAyOCA1RSAgIEU5IDIyIDc2IDgzIEU2IEMxIDc4IENFIAogICAgICAgICAgIDhEIEU2 IEQzIDU5IDVGIDQxIAoKVGhlIGh1bWFuIHJlYWRhYmxlIG91dHB1dCBpcyBwcm9kdWNlZCB1c2lu ZyBiZ3BzZWMtaW8sIGEgYmdwc2VjIAp0cmFmZmljIGdlbmVyYXRvciB0aGF0IHVzZXMgYSB3aXJl c2hhcmsgbGlrZSBwcmludG91dC4KClNlbmQgVXBkYXRlIE1lc3NhZ2UKICArLS1tYXJrZXI6IEZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGCiAgKy0tbGVuZ3RoOiAyNTYKICArLS10eXBl OiAgIDIgKFVQREFURSkKICArLS13aXRoZHJhd25fcm91dGVzX2xlbmd0aDogMAogICstLXRvdGFs X3BhdGhfYXR0cl9sZW5ndGg6IDIzMwogICAgICstLU9SSUdJTjogSU5DT01QTEVURSAoNCBieXRl cykKICAgICB8ICArLS1GbGFnczogMHg0MCAoV2VsbC1Lbm93biwgVHJhbnNpdGl2ZSwgQ29tcGxl dGUpCiAgICAgfCAgKy0tVHlwZSBDb2RlOiBPUklHSU4gKDEpCiAgICAgfCAgKy0tTGVuZ3RoOiAx IGJ5dGUKICAgICB8ICArLS1PcmlnaW46IElOQ09NUExFVEUgKDEpCiAgICAgKy0tTVVMVElfRVhJ VF9ESVNDICg3IGJ5dGVzKQogICAgIHwgICstLUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxl dGUpCiAgICAgfCAgKy0tVHlwZSBDb2RlOiBNVUxUSV9FWElUX0RJU0MgKDQpCiAgICAgfCAgKy0t TGVuZ3RoOiA0IGJ5dGVzCiAgICAgfCAgKy0tZGF0YTogMDAgMDAgMDAgMDAgCiAgICAgKy0tTVBf UkVBQ0hfTkxSSSAoMTYgYnl0ZXMpCiAgICAgfCAgKy0tRmxhZ3M6IDB4ODAgKE9wdGlvbmFsLCBD b21wbGV0ZSkKICAgICB8ICArLS1UeXBlIENvZGU6IE1QX1JFQUNIX05MUkkgKDE0KQogICAgIHwg ICstLUxlbmd0aDogMTMgYnl0ZXMKICAgICB8ICArLS1BZGRyZXNzIGZhbWlseTogSVB2NCAoMSkK ICAgICB8ICArLS1TdWJzZXF1ZW50IGFkZHJlc3MgZmFtaWx5IGlkZW50aWZpZXI6IFVuaWNhc3Qg KDEpCiAgICAgfCAgKy0tTmV4dCBob3AgbmV0d29yayBhZGRyZXNzOiAoNCBieXRlcykKICAgICB8 ICB8ICArLS1OZXh0IGhvcDogMTk4LjUxLjEwMC4xMDAKICAgICB8ICArLS1TdWJuZXR3b3JrIHBv aW50cyBvZiBhdHRhY2htZW50OiAwCiAgICAgfCAgKy0tTmV0d29yayBsYXllciByZWFjaGFiaWxp dHkgaW5mb3JtYXRpb246ICg0IGJ5dGVzKQogICAgIHwgICAgICstLTE5Mi4wLjIuMC8yNAogICAg IHwgICAgICstLU1QIFJlYWNoIE5MUkkgcHJlZml4IGxlbmd0aDogMjQKICAgICB8ICAgICArLS1N UCBSZWFjaCBOTFJJIElQdjQgcHJlZml4OiAxOTIuMC4yLjAKICAgICArLS1CR1BTRUMgUGF0aCBB dHRyaWJ1dGUgKDIwNiBieXRlcykKICAgICAgICArLS1GbGFnczogMHg5MCAoT3B0aW9uYWwsIENv bXBsZXRlLCBFeHRlbmRlZCBMZW5ndGgpCiAgICAgICAgKy0tVHlwZSBDb2RlOiBCR1BTRUMgUGF0 aCBBdHRyaWJ1dGUgKDMzKQogICAgICAgICstLUxlbmd0aDogMjAyIGJ5dGVzCiAgICAgICAgKy0t U2VjdXJlIFBhdGggKDE0IGJ5dGVzKQogICAgICAgIHwgICstLUxlbmd0aDogMTQgYnl0ZXMKICAg ICAgICB8ICArLS1TZWN1cmUgUGF0aCBTZWdtZW50OiAoNiBieXRlcykKICAgICAgICB8ICB8ICAr LS1wQ291bnQ6IDEKICAgICAgICB8ICB8ICArLS1GbGFnczogMAogICAgICAgIHwgIHwgICstLUFT IG51bWJlcjogNjU1MzYgKDEuMCkKICAgICAgICB8ICArLS1TZWN1cmUgUGF0aCBTZWdtZW50OiAo NiBieXRlcykKICAgICAgICB8ICAgICArLS1wQ291bnQ6IDEKICAgICAgICB8ICAgICArLS1GbGFn czogMAogICAgICAgIHwgICAgICstLUFTIG51bWJlcjogNjQ0OTYgKDAuNjQ0OTYpCiAgICAgICAg Ky0tU2lnbmF0dXJlIEJsb2NrICgxODggYnl0ZXMpCiAgICAgICAgICAgKy0tTGVuZ3RoOiAxODgg Ynl0ZXMKICAgICAgICAgICArLS1BbGdvIElEOiAxCiAgICAgICAgICAgKy0tU2lnbmF0dXJlIFNl Z21lbnQ6ICg5MiBieXRlcykKICAgICAgICAgICB8ICArLS1TS0k6IDQ3RjIzQkYxQUIyRjhBOUQy Njg2NEVCQkQ4REYyNzExQzc0NDA2RUMKICAgICAgICAgICB8ICArLS1MZW5ndGg6IDcwIGJ5dGVz CiAgICAgICAgICAgfCAgKy0tU2lnbmF0dXJlOiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3 IDE2IDBCIEJEIDM5IEZGIDJGIDgwIAogICAgICAgICAgIHwgICAgICAgICAgICAgICAgNTMgM0Yg NUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSAKICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIwIDJEIERDICAgMDAgM0MgNjQgQkUgN0Ig MjkgQzkgRUIgCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICBEQiBDOCBBNCA5NyBFRCA2NiAy OCA1RSAgIEU5IDIyIDc2IDgzIEU2IEMxIDc4IENFIAogICAgICAgICAgIHwgICAgICAgICAgICAg ICAgOEQgRTYgRDMgNTkgNUYgNDEgCiAgICAgICAgICAgKy0tU2lnbmF0dXJlIFNlZ21lbnQ6ICg5 MyBieXRlcykKICAgICAgICAgICAgICArLS1TS0k6IEFCNEQ5MTBGNTVDQUU3MUEyMTVFRjNDQUZF M0FDQzQ1QjVFRUMxNTQKICAgICAgICAgICAgICArLS1MZW5ndGg6IDcxIGJ5dGVzCiAgICAgICAg ICAgICAgKy0tU2lnbmF0dXJlOiAzMCA0NSAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJE IDM5IEZGIDJGIDgwIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQg RDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIxIDAwIEM2ICAgMTcgMTkgMzQgMDcgNDMgMDYgM0IgOEEg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA1QyBDRCA1NCAxNiAzOSAwQiAzMSAyMSAgIDFE IDNDIDUyIDQ4IDA3IDk1IDg3IEQwIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgMTMgMTMg N0IgNDEgQ0QgMjMgRTIgCgoKQkdQU2VjIElQdjYgVXBkYXRlIGZyb20gQVMoNjU1MzYpIHRvIEFT KDY1NTM3KToKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K QmluYXJ5IEZvcm0gb2YgQkdQU2VjIFVwZGF0ZSAoVENQLURVTVApOgoKRkYgRkYgRkYgRkYgRkYg RkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGCjAxIDBDIDAyIDAwIDAwIDAwIEY1IDQw ICAwMSAwMSAwMiA4MCAwNCAwNCAwMCAwMAowMCAwMCA4MCAwRSAxQSAwMCAwMiAwMSAgMTAgMjAg MDEgMDAgMTAgMDAgMDAgMDAKMDAgMDAgMDAgMDAgMDAgQzYgMzMgNjQgIDY0IDAwIDIwIDIwIDAx IDBEIEI4IDkwCjIxIDAwIEM5IDAwIDBFIDAxIDAwIDAwICAwMSAwMCAwMCAwMSAwMCAwMCAwMCBG QgpGMCAwMCBCQiAwMSA0NyBGMiAzQiBGMSAgQUIgMkYgOEEgOUQgMjYgODYgNEUgQkIKRDggREYg MjcgMTEgQzcgNDQgMDYgRUMgIDAwIDQ2IDMwIDQ0IDAyIDIwIDcyIDE0CkJDIDk2IDQ3IDE2IDBC IEJEIDM5IEZGICAyRiA4MCA1MyAzRiA1RCBDNiBERCBENwowRCBERiA4NiBCQiA4MSA1NiA2MSBF OCAgMDUgRDUgRDQgRTYgRjIgN0MgMDIgMjAKMEEgOUEgRTcgNUYgNTYgQ0UgNDIgOUMgIEQyIEQy IDIwIDM4IDZCIDhEIDI0IDczCkU5IDVDIDhBIDUwIEU1IDU4IERCIDkyICBCNyA4OCAzRCAwOSBF OCA0MiA0RSBFNwpBQiA0RCA5MSAwRiA1NSBDQSBFNyAxQSAgMjEgNUUgRjMgQ0EgRkUgM0EgQ0Mg NDUKQjUgRUUgQzEgNTQgMDAgNDYgMzAgNDQgIDAyIDIwIDcyIDE0IEJDIDk2IDQ3IDE2CjBCIEJE IDM5IEZGIDJGIDgwIDUzIDNGICA1RCBDNiBERCBENyAwRCBERiA4NiBCQgo4MSA1NiA2MSBFOCAw NSBENSBENCBFNiAgRjIgN0MgMDIgMjAgNkUgMjYgNTIgNDAKQ0YgQ0EgMEUgRjYgNUMgOEUgQTEg QUYgIDZCIDY1IDJBIDE5IDEzIEQyIEZDIEJECkI1IDhFIEU5IDUzIDYwIDlGIDg1IEYwICBEMiA2 OSA5OSBERiAgCgoKU2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRvIEFTKDY1NTM2KToKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkRpZ2VzdDogICAgOEEgMEMgRDMgRTkg OEUgNTUgMTAgNDUgICA4MiAxRCA4MCA0NiAwMSBENiA1NSBGQyAKICAgICAgICAgICA1MiAxMSA4 OSBERiA0RCBCMCAyOCA3RCAgIDg0IEFDIEZDIDc3IApTaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcy IDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgCiAgICAgICAgICAgNTMgM0YgNUQg QzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSAKICAgICAgICAgICBENCBF NiBGMiA3QyAwMiAyMCA2RSAyNiAgIDUyIDQwIENGIENBIDBFIEY2IDVDIDhFIAogICAgICAgICAg IEExIEFGIDZCIDY1IDJBIDE5IDEzIEQyICAgRkMgQkQgQjUgOEUgRTkgNTMgNjAgOUYgCiAgICAg ICAgICAgODUgRjAgRDIgNjkgOTkgREYgCgpTaWduYXR1cmUgRnJvbSBBUyg2NTUzNikgdG8gQVMo NjU1MzcpOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpEaWdlc3Q6ICAg IEJBIEJGIEY3IDk1IEJGIDNDIEJFIDgxICAgNzkgMUYgQTkgOTAgMDYgRkMgMzAgMUIgCiAgICAg ICAgICAgMEQgQkMgRDUgNDkgMzkgNUEgMEEgNzEgICBDMiBENSBCMiBGQSAKU2lnbmF0dXJlOiAz MCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwIAogICAgICAg ICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBEIERGICAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgCiAg ICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMEEgOUEgICBFNyA1RiA1NiBDRSA0MiA5QyBEMiBE MiAKICAgICAgICAgICAyMCAzOCA2QiA4RCAyNCA3MyBFOSA1QyAgIDhBIDUwIEU1IDU4IERCIDky IEI3IDg4IAogICAgICAgICAgIDNEIDA5IEU4IDQyIDRFIEU3IAoKClRoZSBodW1hbiByZWFkYWJs ZSBvdXRwdXQgaXMgcHJvZHVjZWQgdXNpbmcgYmdwc2VjLWlvLCBhIGJncHNlYyAKdHJhZmZpYyBn ZW5lcmF0b3IgdGhhdCB1c2VzIGEgd2lyZXNoYXJrIGxpa2UgcHJpbnRvdXQuCgpTZW5kIFVwZGF0 ZSBNZXNzYWdlCiAgKy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRgog ICstLWxlbmd0aDogMjY4CiAgKy0tdHlwZTogICAyIChVUERBVEUpCiAgKy0td2l0aGRyYXduX3Jv dXRlc19sZW5ndGg6IDAKICArLS10b3RhbF9wYXRoX2F0dHJfbGVuZ3RoOiAyNDUKICAgICArLS1P UklHSU46IElOQ09NUExFVEUgKDQgYnl0ZXMpCiAgICAgfCAgKy0tRmxhZ3M6IDB4NDAgKFdlbGwt S25vd24sIFRyYW5zaXRpdmUsIENvbXBsZXRlKQogICAgIHwgICstLVR5cGUgQ29kZTogT1JJR0lO ICgxKQogICAgIHwgICstLUxlbmd0aDogMSBieXRlCiAgICAgfCAgKy0tT3JpZ2luOiBJTkNPTVBM RVRFICgxKQogICAgICstLU1VTFRJX0VYSVRfRElTQyAoNyBieXRlcykKICAgICB8ICArLS1GbGFn czogMHg4MCAoT3B0aW9uYWwsIENvbXBsZXRlKQogICAgIHwgICstLVR5cGUgQ29kZTogTVVMVElf RVhJVF9ESVNDICg0KQogICAgIHwgICstLUxlbmd0aDogNCBieXRlcwogICAgIHwgICstLWRhdGE6 IDAwIDAwIDAwIDAwIAogICAgICstLU1QX1JFQUNIX05MUkkgKDI5IGJ5dGVzKQogICAgIHwgICst LUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxldGUpCiAgICAgfCAgKy0tVHlwZSBDb2RlOiBN UF9SRUFDSF9OTFJJICgxNCkKICAgICB8ICArLS1MZW5ndGg6IDI2IGJ5dGVzCiAgICAgfCAgKy0t QWRkcmVzcyBmYW1pbHk6IElQdjYgKDIpCiAgICAgfCAgKy0tU3Vic2VxdWVudCBhZGRyZXNzIGZh bWlseSBpZGVudGlmaWVyOiBVbmljYXN0ICgxKQogICAgIHwgICstLU5leHQgaG9wIG5ldHdvcmsg YWRkcmVzczogKDE2IGJ5dGVzKQogICAgIHwgIHwgICstLU5leHQgaG9wOiAyMDAxOjAwMTA6MDAw MDowMDAwOjAwMDA6MDAwMDpjNjMzOjY0NjQKICAgICB8ICArLS1TdWJuZXR3b3JrIHBvaW50cyBv ZiBhdHRhY2htZW50OiAwCiAgICAgfCAgKy0tTmV0d29yayBsYXllciByZWFjaGFiaWxpdHkgaW5m b3JtYXRpb246ICg1IGJ5dGVzKQogICAgIHwgICAgICstLTIwMDE6ZGI4OjovMzIKICAgICB8ICAg ICArLS1NUCBSZWFjaCBOTFJJIHByZWZpeCBsZW5ndGg6IDMyCiAgICAgfCAgICAgKy0tTVAgUmVh Y2ggTkxSSSBJUHY2IHByZWZpeDogMjAwMTpkYjg6OgogICAgICstLUJHUFNFQyBQYXRoIEF0dHJp YnV0ZSAoMjA1IGJ5dGVzKQogICAgICAgICstLUZsYWdzOiAweDkwIChPcHRpb25hbCwgQ29tcGxl dGUsIEV4dGVuZGVkIExlbmd0aCkKICAgICAgICArLS1UeXBlIENvZGU6IEJHUFNFQyBQYXRoIEF0 dHJpYnV0ZSAoMzMpCiAgICAgICAgKy0tTGVuZ3RoOiAyMDEgYnl0ZXMKICAgICAgICArLS1TZWN1 cmUgUGF0aCAoMTQgYnl0ZXMpCiAgICAgICAgfCAgKy0tTGVuZ3RoOiAxNCBieXRlcwogICAgICAg IHwgICstLVNlY3VyZSBQYXRoIFNlZ21lbnQ6ICg2IGJ5dGVzKQogICAgICAgIHwgIHwgICstLXBD b3VudDogMQogICAgICAgIHwgIHwgICstLUZsYWdzOiAwCiAgICAgICAgfCAgfCAgKy0tQVMgbnVt YmVyOiA2NTUzNiAoMS4wKQogICAgICAgIHwgICstLVNlY3VyZSBQYXRoIFNlZ21lbnQ6ICg2IGJ5 dGVzKQogICAgICAgIHwgICAgICstLXBDb3VudDogMQogICAgICAgIHwgICAgICstLUZsYWdzOiAw CiAgICAgICAgfCAgICAgKy0tQVMgbnVtYmVyOiA2NDQ5NiAoMC42NDQ5NikKICAgICAgICArLS1T aWduYXR1cmUgQmxvY2sgKDE4NyBieXRlcykKICAgICAgICAgICArLS1MZW5ndGg6IDE4NyBieXRl cwogICAgICAgICAgICstLUFsZ28gSUQ6IDEKICAgICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVu dDogKDkyIGJ5dGVzKQogICAgICAgICAgIHwgICstLVNLSTogNDdGMjNCRjFBQjJGOEE5RDI2ODY0 RUJCRDhERjI3MTFDNzQ0MDZFQwogICAgICAgICAgIHwgICstLUxlbmd0aDogNzAgYnl0ZXMKICAg ICAgICAgICB8ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYg MEIgQkQgMzkgRkYgMkYgODAgCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICA1MyAzRiA1RCBD NiBERCBENyAwRCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1IAogICAgICAgICAgIHwgICAg ICAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMEEgOUEgICBFNyA1RiA1NiBDRSA0MiA5QyBE MiBEMiAKICAgICAgICAgICB8ICAgICAgICAgICAgICAgIDIwIDM4IDZCIDhEIDI0IDczIEU5IDVD ICAgOEEgNTAgRTUgNTggREIgOTIgQjcgODggCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAz RCAwOSBFOCA0MiA0RSBFNyAKICAgICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVudDogKDkyIGJ5 dGVzKQogICAgICAgICAgICAgICstLVNLSTogQUI0RDkxMEY1NUNBRTcxQTIxNUVGM0NBRkUzQUND NDVCNUVFQzE1NAogICAgICAgICAgICAgICstLUxlbmd0aDogNzAgYnl0ZXMKICAgICAgICAgICAg ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkg RkYgMkYgODAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA1MyAzRiA1RCBDNiBERCBENyAw RCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1IAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgRDQgRTYgRjIgN0MgMDIgMjAgNkUgMjYgICA1MiA0MCBDRiBDQSAwRSBGNiA1QyA4RSAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEExIEFGIDZCIDY1IDJBIDE5IDEzIEQyICAgRkMgQkQg QjUgOEUgRTkgNTMgNjAgOUYgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA4NSBGMCBEMiA2 OSA5OSBERiAK --_003_845A415CD4694899B7B00DAF728D667Fnistgov_ Content-Type: application/pdf; name="draft-ietf-sidr-bgpsec-algs-examples-v4.pdf" Content-Description: draft-ietf-sidr-bgpsec-algs-examples-v4.pdf Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples-v4.pdf"; size=33460; creation-date="Tue, 21 Feb 2017 15:13:19 GMT"; modification-date="Tue, 21 Feb 2017 15:13:19 GMT" Content-ID: Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWdty20YSfddX9FvsKnE891uVK4XrrrO7dmLRSR78ApBD GTFvIUDH+vvtoQRZgS3JjgclaQCSxTlzpuec7taf8Av8CYaDscQJxxVIbUFLRqimFg4BfoMtPCt6 BoseKPQL/DglhinltMAXKMw+Pcbv4fRssYF8jp+ilDKYL4Cx6w/iqOLDfAPP5nMGeLeCJ/Pdfrfe XV75pzD/A6r5CdGn7/wHU0hKHLNSTybKLt4+0VI6/fbpDK/To1Ji8mjePn169tVA4MG1Gkqs0I6d /X3FPx/CqvsI2Xa7O24XYRO2Q+/hDrxzYI4TSvD3GZfnwJFIv2yt988ET4aOUWRZKTlBV+8OMLzr eggfm81+Hc7xKUBVlBcZNOvL3aEb3m3gr6aH/WH3oVuGJfyFL0ED/dAM3QLew7CDdCiZItoIO0G5 ad6HE7BD6I/rAZZhCIdNt+16hEAgWSwxQYlyXExiaY6UvIdjj4tfIV/Neg19d7lthiMemd0+HJCJ 3bY/0TQg1C2sDrsNvK4L0M6484T8SEUUo2bCz+Jds0dGIMMgUvDjxQiuh9/iZl38O5txpc9hE/q+ uQzwQ3/a7B9+JOl2zigiueMTZIDEPYdMV6JQpiwpy/LKUWq1ElY4K5QqS1mInJkss0YIy3Nac1lq xp10orRZVmqaDCWnighppvz9J1z1sFvhqTxJRjpx4hzPtdZTFXw+uW4C+CzK8yNi+LAGcaFIFMPJ LvTvO5ScXJaO0VqpIqsMyzhTVS2KrK5EVhRS5aqqCqZkstPENYKh08O0P3QfmgEPVPibCZx937ot GhAuaDy4Z9duA/ARoy8GkSzrvOLS2NrqytrMSMXymqIiamWow+BUWcEKJnRJLSuUpFzJIpOS5i5Z 9Anqou+6ye7sj+06KikS8i1Sdh0JyNsXnVdwSayycmTkxn8B3kRKjHAsz/Lc8YwWucgrRivlcuaq vK5zzmRFZeZYhW9mLGfCZaYUtnS0NqZSKktHiXDEGD2lBGFeRd2gKreVdkobW9E6Y9pRmaNmuFLW qqBlXShrHQauonkha6NKPOEZV3kpdF2rdDC1IwhDTHbu9e4YZRflA4pwGLpVt4ihfeOl6Bjd9hJe 7cP24uK/gFkWYWG26vZ9zIvq0KLVM5EOo5VEs8+8M2Y/33ulw+gcUYJPXeIOed+ivQ+fAMkkkYqa z04AQNkMzbdM9HCSi7ZHYuL3hYkAr1/Docf0wIOAt0/oR54w5ZRSEm7NVO7jrPG6CIeuWcPL46YN B5wfXVehsV7DkMulNgsEkywRV45w+pnXnYCMCQlkY07pISyWfTOL2eQMExTMT5JFmTSSMC7V5LSe OME/L/r+GPkoXj5//erNvHo9QwWlNdpBOi6sI1ROrW8E8Guz7pbdcJXM9hUVxGk2Te7H+eL4cjdA HjB9DR5+araAfkCVpxR/ogwZ+Nf/5neW/312rJgl1jg3nohbO/6EKOLJVlE9Ec9xPcVjJ3geS4se PqFKCGIw2xzx3JrhNZ6LY/tHWAxfjIhU1aGSFgtpPa1sRkJuIMDP17lAdJQX29UunUgpLYgW6j4K Io47c985pt1yFhbXbyGqZGdUYQ8C6/FpJj7yMY7XE89wZo+yhSIBbTckFC3lBJGG83siY4SxP7aY m6WKBWy2EOHofbI9ThpHKr0R3jHfNr5tveO+oX7RetH6wDwNXjnfMu+Cb1c+HUAuCCar01bGXWDj /ar1nHkZPCJtnGd4s4hgWesZAm+8WXph/dJ5mhKgsIRzc5/Cj+DiaIwPyqsmEqdab4PXzivtjfWB +hUi1d5RL1uvVEIGlSDsszrsLq7xHplZSr9SfkH9cuUXylvrnfIB95b6duHlyhvll9yjXqfbYW2x 6XevRY7g4tjwyNtSeL1CmHc84vs0WVtOnOW3HjHR5BFBdvGSwasXpccGVLcJqAAfWDoWnCGO3uub vyvqPghM54ewjSlcn06ODePEMmcf0J2b2aMVvIldm4QCZLgh2GWbljMj5+NYdpfdgAnkbT8p2eYb yYnGqu7x5Y/GeHLEJTZPsciKyVuyGDDKEKz+pyXJyME4ZrmXZRRiWkehKDJfGc+yKH6q8rWIr9SV F5kvCi+Vz5WvKl/guzIdVMMJNsUe8syboKliyMZm7d3oSZXoG2uIZPy+emdkjBHMOAgj2LEkBu9F ujaepZwI8aCB9u3lftYch912t9kd+4urHssgDwtsaGORvk4WyZYZwuWjKnYLBBDJEDY3RRkqSqqk wgpOmP4KSzy1ONOtXxpCrXqMgNgpic2Qcrdpui28uD3JKRnQ+C8UKh+qgq5js9u+w8p4SMeBY8Tx L1rZrXR+ZeX7y/8B5FYaowplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMTc2MgplbmRvYmoKMiAw IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRl bnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKOSAwIG9iago8PCAvTGVuZ3RoIDEwIDAgUiAvTiAx IC9BbHRlcm5hdGUgL0RldmljZUdyYXkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB hVVdaBxVFD67c2cDEgcftA0ttIM/bQnpMolWE4u12026SRO362ZTmyrKdHY2O81kZpyZ3SahT6Xg mxYE6augPsaCCLYqNi/2paXFkko1DwoRWowgKH1S8Dsz22R2QTLDnfnuueeee8537rmXqOtv3fPs tEo054R+oZybPjl9Su26TWlSqJvw6Ebg5UqlCcaO65j8b38e3qUUS+7sZ1vtY1v25KoZGNC6huZW A2OOKKURZWqG54dEXZcgHzwbeoxvAz85WynngdeAldZcQHqqYDqmbxlqwdcX1JLv1iw76etW42xj y2fObrCv/OxG6w5mJ8fx74XPF0xnahJ4H/CSoY8w7gO+27ROFGOcTnvhkXKsn842ZqdyLfnJmn90 qiW/UG+MMs4SpZcW65U3gJ8AXnVOF4+39Ndn3XG200Mk9RhB/hTws8Ba3RzjPKnAFd8tsz7Lw6o5 PAL8MvAlKxyrAMO+9EPQnGQ5sKDFep79xFoie0Y/VgLeBnzItAu8FuyIiheW2OYg8LxjF3ktxC4u m0EUL2IXP4X1ymisL6dDv8JznyaS99Sso2PA4EQerfujLIc/cujZ0d56EXjJb5Q59j3Aa7o/UgCG zcxjVX2YeX4BeIBOpHQyyaXT+Brk0L+INyCLmhHyyMdYDX2bCtBw0Hz0DGgVgHRaAColtEz0WCee o1IVPZVmollBhNjK/ahvUH7Xp9SAtE7rkNaBXqNfIsk8/Upz6OchbWBspsNuHl44tAgP2BO2+aBl 0xXbhSaeRzsoJsQrYlAMkSpeFYfFITEM6ZA4GM2JvU/6zn4+2LD0LtZN+r4MDkKsZ8MzB6xwNAE8 +AfrzkaaCbYu7mjs87yP3j/vv2MZtz74s429APoxJ7/BogtrJiXmXj/3TU/CQ3VFfPXWne7r5+h4 MktR3qqdWZLX5PvyCr735NWkDflneRXvvbZcPcoL/5O5zSFGO5LNQc48m1G0ccYbwCG4qUVz9rdZ TLLptmK0YMlClJ2ruP/LCfPDPLexUnMu7vC8tz9jNs33ig+LdL5Pu6yta59oP2p/aCvax0C/Sx9K X0rfSlekq9INUqVr0rL0nfS99Ln0NXpfQLosXenYSXHsG7sHfsZ71mjtMGaGsxQQ88LazApLH/F3 BmOb+TOh1V4Dnbt/Yy3liLJTeUYZVnYrzykTSq9yQDmsbFcG0PqVUWUvRnZusGRjPc6AhX+SZ4um I67iPLFXdbDnw0sd76ZfXMPWhjXYST0Ontnapg6vEVe/FVVjvDtdnAY6TSFii84ich86nB8nqv7O 2VyTODVSb+KUsMQu0S/GWjWYEwdQheNt9TjIVZoZyQxncqRmejNDmf7MMcZRrNH5ktmL0SF8RxLe M8sx/5s1xGcY7x3mqAlso4dbKzTncd8R5V1vwbdm6qE6oGkvqTlcr6Y65hjZPlW3bTUaClTfDEy/ aVazxHc3zyP66/XoTk5tu2E0/GYso1TqJtF/t4+TNAplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2Jq CjExMTYKZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQgOSAwIFIgXQplbmRvYmoKMTIgMCBvYmoK PDwgL0xlbmd0aCAxMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVnZUtvK Fn3nK/oxqRRNz1NVHloTOMQQD8AhlRdJlhwz2AbbGPj6u+XgwBWB3FunBYWklopeWr3H1Teoh26Q ZkhbTKngSCiDlCDYGKnRbYXO0BTtxQuKygUiaFHC2wRrKqVVHAYI2n2+hX9DuaKYKLpTXqNoCK8S QigalojSX2/DWSJLFDaCcjS8RnvDIUXwSo0+oO3BiRPCEeYYcUS7An6FU7mTtcuFq6krS6eM48px 6whvBg13H3eGFygdbr7oGdTbGNH7GBnFWlqz8wbGqnS6dAYAMjdirlaOGGdHTihXMAdPWe504Srl LHMFd6p2BQ2NkSustGFvYXxikDhLHZFO5C6nrpauII5uwDLtmHCVafhl8BEjNwqOUVIMxqLfwkhL VxPHRw073DRw5MgpgGMdl44ZZ0auqhwpN0/tRzS82Am3yEphSSVtgdttjijd7xyhOO0PO1kn9sN0 M9rM//8Y2V8cwVAsOFctR+h2OtEkiWM/+DT2607kx53UX/KzOvGH0Xh88/Py4vhbr5f4C593++N1 Nj5PTuE+8XYwpKcngT3BKswla5PUP+0su4lfd9Pvcf/Crw9+lkfdYbnuDv19NzlZN8/ONmPj9dHj i7En0GFBUkIpZroNss1MG/TZ0A+jcfnEaCd6ZrcbReujODRIpjA1tmVu3vcfL4sbfXmTfD3+lB6f FfvV3d7i53A8mB+MH9T+/XFeDy++J7y+OruJiovrq7PqOFHZPPp6OpoGXm5KBMWUtB3Wlkl9fz45 1VexGfJ/BlH+pSBsj85Yd30+9F+j8dHpQc+kke/GkQBz6IFN9slxFJ2n2eHyKDSTUmHCVIvJy549 fViVeedUPz7cCfWYnlG9yE66UXff05PRl16v2/Wz/The7PveSRatu1U3Er/vQ4PUBFshWiCjddrx vYO9yJt1kvuDrj+J/TrR5jCNo55fx+PzzuHse+fxgqTg/Ul/7dd93xlHuiL51afL0CCNxEbxFkhT 3s+OLi6Teefbou74mNydd6Yn+YOO51rODx8LncYw3I9Obn7awp9PB+Wl+tqb7I3S0iTsPjBISiCj m7Z3H8f90ff4kh52+CpJxvOwwZlSKrFuheZNEkiPkteJIWj1QamWWNF29XFYPSzQrEZ+8OODkoqr Hx9d6I+2BEve/uzPr46wiZgyIrGQsmWFi8uJQ0JnjEcZ9RHLjLcJU0aJNIoSk2QQ8WmshSAqjQMT wbjEXIvW+s9vJ3f5skKX1cMz8zv/W1H8fsFJmSSY2dfF3D36jFQcsdRyGlHKMgZEiShOYu+zxErJ vZXUeuszzmMCXClihPKMZjE8NZxqFtgdmQGobW+cr4qrSblhBoVeCysxZba1FgidNNwwk8UyS+Hz 40xmIvYRh7ORQBmQFdPUJiQlSZT6NBVMRgnLSAKkSO9Jao0NzA2n0PWIdvoErA+ANfUWVoen3GRc ZhFnNsmElUrQjEWeCJLRmPtYUW44AbuXOo68ikwkjcngpdBYucVWtbNof7ZaVrcIgg2Kq9vlpJ6U jclX9/n1/KpCq8VkOkbH82o6GHxF0O5hWu3Wk/miafKyqkCMUB4aqBTQkrYz6SYY/8s/oYEqiw1p Z9MXND5HjSCtNBiKwJpBA/2qlU7yZR58NmuxasfEbdt+Wt0uJrOpQxz9+EDu2Y+PgckVVGAIaK0k sZ1+UN1O8it0tLouqlsAQZWBWtsKtkFTlCNVjGrImC9i086/1wmoYBYL/drfERpMxtN8uQIVxV+N Z7eT5c9rh6pytMh313CzOzjwTKoXcAJIK1QIgbmVf7CHhqfOYrFqyImPPvePT4ZpfxcEGpLBEXqp pMWctv1gu1Sn+dVkNFk+hP52LTDj7I1vbyY/mi1RVNWz28qhL/kUgfIEwggBFYc0YUuj/e4wNBMG pLV2YbMlYovJ103EBUyrqzYms8H0LDuEsFlJBKh07T50C2qwKi6qcvlHK3nGEcJYJTXYmnax2cKB vv0qLJp81JnWs8AiGpWcY1Ak34gqDZgXAF548mS0W5W/HgG0F6YcZIWEwYa1E96Wme351+y7ML2D IAfBBBWT5X9FuCCrpDjWoA2/TjFbHM15viocCuw7UhusQE1+f+ZmdgKKoXF12WjElXV57cq6uRal ywvHN9dGurJwLLTCSaXl+M2s1IDbHgxQ0QbeiLiKuBHIw3kjbgrmZLFRkWGQO6qdhMwdtqGEngCL t+XsLUQ45wDOOmMbcLZwCtTZqhFfa94QClI2SLMjYNY6qYKjZBwL+qdk+gLg5lKAkg3Ceu5g5Unt QEbmuSuVo7zZC4BdA3gqdbPgeXiU3GDO34vpW7QFSOvSGSBPOFq/iBEh/FJJjpn8m1/6wRFFx53E IehdrysIEnc0tG0pg6HJfMNN/5HE3nFoH5bVtKkPF6GLUmU4Jq+bw+0aIPSEoEkgJ4t8DLk/NAHW wE7XW/l0CySZjCdLqFB/14WB7UFThi17K5s2KJ6IeErwmw6vM6qmTYvXVIWBWdFMwzbfe4m1wSS0 y5jjkcuo85FjmTPe2cQx5YxyInVR5BLjkszBbhWlLtabzUHlQPEJGyK1YFir93LuE39pY8qjarQh cGtRYSsjLTUGu/5LzqWYY9hRwBJ+NFxzEpoSzbAi7yXgRTGe7+ar5Ww6u56tFoOHBTRgDpXQ7oBs cBXaxI3G8r0Cv7Eo/xsNAjjL6vqpJ4TA89tgev8BxtXffwplbmRzdHJlYW0KZW5kb2JqCjEzIDAg b2JqCjIwMzcKZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jl c291cmNlcyAxNCAwIFIgL0NvbnRlbnRzIDEyIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+ PgplbmRvYmoKMTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoxNiAwIG9i ago8PCAvTGVuZ3RoIDE3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1WVtT GzkTfc+v6MekqAjdb1X7oLkZJ2tigyGQyosxtoEs9mIIxvz6rzUh4Cgk7NandamGGY0KnTrdfbrV cwUDuALDwVjinNEgtQUtGaGUS1hO4CPMYbu8ZjC+BgrXY1xNiWFKOS1wgsLbp0f8N5xSRpzUr8aX UAxxKcUJGI6BsW+r8a8CZiknUlgYXsL2cMgAl0zhNfz000oJ9ebV8ALqYYv0abNf7w0v7M0MEUq/ +v3ee4uvN+fzGVSLy9H5HLqnk/nN+fR8srz2b+Df4XmJC8EJN+pFLs7nZ5Pl+U1uNjQnzIln2Ng/ n81HN1/RB8JfswXufHbpYTI+vR69XeHD2/2dwJXOTYYxhDH+KzIE9VJ5yj1nnlJ/OvVU+rHyzMSb U+qn3J84Px35qfCnzuuJF1OfmzLHCX2OsdZ99dSPmFfWn1o/nXg99sz6ifTC+PHIM+fN2I+tN8pL 6pWJEM0kN0RHNUahe8aqLUZ32nJIPeORz4n1Ixsh65PIqjnxE+1HztNJy6f2mntFs2PkjFhtfoVR nng29pR5JFSceMk8w3vnrfXoBUZ4N/WnaHbuHbIsvZxmNrMTmhib6sTb+CvqTncXynpv2G26ZRjW 7WzmUHCKEUNlEgq9brc4vyhx03IWVt0izLpN+PP+4+30eFXOjrvvF5+69xe0xnerzkV93CuOO4Ed 4POqf/DFHeYmSWuieRoMh/Xh/p/DsOpVRWfvy6dOr5BH1bAWvape9YaB9Sp81yzinOxV4825FnRu kJYRJVniaSkzP4Fuvqzq1fHOA6NlGDyyW4XBuMoN0mkiVRqyg1mo3/fvpnq03T+i62WfbTXrdX27 mswHcvf2ynx5d0Jvq2HDrmb6eH51ycPWh/7u9Ho9n+4ffiryguSUMSKMTZi0y0Vd3a303dmHqth+ d7TWI3lzfEF39O5Fr1OvytVxdbhH+0UYVGE2Cb2CRp88rWaDj0Wxt5MbJNeEuzRw7cXt3dV66/18 f9QZLm+PxXq8d0cHHVOFYTHbPdzZP6irKrwvZrNlMaubAk28cxEm359zg8QaizOVMImbFmWoi+3V oN8LfFbchybMemF7e+sszA5CLyw6ZXnV2e9JV4ReGegs9OqDsjuopkXv4Cg3SKUJE2l0F7vV+ut0 ec8/yu0T3RzzvrrufBiI9dlfdr1zGA652poPurP6y9Hiqjlbhp3by6uBWd9cvhvs362y+6TBalXx hMmT+5ui/njZ7e18mLLV+8mn2v6RV6A5tYo4k+hzmwnq3ern7JC1iuVMKmJtKhdFp78/GUO3fyvh 4O/T0c0EpsvFJYT9z69jLa0/v4GbxeOj+fzmqZp99c8q+99X15xpSixNs/of/+6X2VDMKGK4TixV nM9HyzU0i+UlLKbwQN0Da59fD8v+2+qg148U5TUdp4poKROHbRp4djw/i0s3SHr1/x+LOOeUKJ2G ER7eKJ60eHvFGwq1A0kB4gscHCzOyna0r3OjEopIm6buCIm2O9dAqxZbCyfCKDUIgUfYOHARs1DS 7FwpSoRLgy+i4uAo8Ja0MrTA6m9ctYgf2MT7dkVurrQigqXJ+RtXTQFNC6Eo4+bSADQcBM4yCAXw BmwAVwFGSW5UlhIufsrG2GmooSigslA1wE1sEJSISqLVNNSIkmIvAgRecYZnR+UUwSZGEoOcxlYI k4AsOUSIqDTQAqCoQLgYiZEoCkqAaEBVuVEJhg0Tk+Zb9OiqgspEV0eurI68WQagNGgGtQWqoMIh odbRrJktKLjE3lCqDAZNFPs9wBFVay5RxpiDogaDHuWgdFCjgQsoLQSZHZVwxKXCgOm4rkBr4BZU HbWKY2tLA1gRuSkZ9rkwM4Ot4mMlsoNSklieCoNyoBqQbaTJChwGP3qPAkCJqNHHQlQMhNuIONPU 2VFpR4xMc7IIUJYgFRQK6jpyo1rFjG4fw0492PcxInK7lZVE61QYNsNuM+p+CLvNiMiNyjmibJqc N8NuM+p+CLuHiPgvpF0ySRRNQxBpYOg+DgQazoDEhiwqJsoVarkqoayiRVHBULpQxATL7VeSOyJ5 GoPoywzlsgTFQaI2GXAKLEp7hdlYxIHygMGA8DhGZXa5kkYSIdIYfOpmNo8FsZQuKYjx8akgztLq 5tI6wlXa6m6PCS9fMleeikrCTBpy1flscn3jY2cQbYfFU62iDgWUdkw1WGGh7UCgbpXA0HKoU5i5 XRzGQG6EzBHq0rzcNi2/XRzmYAqNhQYTXh3TTIOFi8WXWJVizYDvdfZ6TwlJKEvz8qNL+ef1EqUM UX2vITbFDEuI3LxJ/H4jUoHY4O2xZNnUTpQ1FIvv9cSmsGE5kRuhFsT+xrCP1cumjCJYeF7jUOJy A8RPYEanurFJ4XOSihGDCJ/TO5S73AidINqmeXwD4UvymuHTHcduL9FYcP74+ewxFuBJXn/Rb8h7 mNbCEsXTfP2yssYVG6VDFmaUIFKm36421BXPM7IAZWIFWrBYOOPptMDDNDR4G+IQChzmbKzAAsjs Lq61JUKnCXvDgagDa6P+N3iWwBoZU3QTpb8toCnW1JgWbO4yQluBH0DTwHv0qG/q2h4Ck/PZP1HX wf8A1dSaoAplbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjE5NTEKZW5kb2JqCjE1IDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxOCAwIFIgL0NvbnRlbnRzIDE2 IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTggMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAv VFQxIDggMCBSCj4+ID4+CmVuZG9iagoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWdtu4kgQfc9X1GNGm/T0/cIbGDOLNrcJRLMPkSIH HPAOGAabSSLtx28Zg0PAZGY1HQ0KucmiT586Vaeq+xt8hm9gOBhHhDSGgdQWtKREKy5gEcMXSOFj kDEYZEAhG+DjlBimlNMC/0Hh9OVP/ByuJSdOuqPBFFp9fJRSyqA/AMbKp/GnwqecJcxZ6E/hY7/P AB95gGN4eSkBogOqDYGGdhvaBih+7+ADVkOrBRY/RoNmEFqgCtoKPhz1/4Gwv9rQC6TDCOFthIYJ wpg+OoiwLSHU0EHqAqC4cQocEQaIkFIQAZIIrRBMC7iDwEHY8o6QW0KFegNhCwILTQnOQNgGrYFb UCEiDB1wBK7BimITAQNjIQi9Iyy0oMRhhLZdLN8WoByoDkgGH+D/RfEHOjOGE4uyfB3F/jiG8XIa pSjwaBjdT2KYLfP5Mockg/liNlwO4iEssyQdwf1onsWD02R2AtH6D+80WUOM22EpX0QPD8kARnEa L6J8toB8HOUIKs4QyGOyiLNxtPgKk+RrjJiTNMctkDV9R0VWe0gCyxAZtTvQenE6hJv5MMpjOI+z LBrFnsNmBSeam52wAfxxejrFTceLBnR+8PJcDqw0RMn9ZENEkzgd5eMGcKV906A5kVhHXqt3RUP+ PI8bmMkcbo9vrtrNfnj7wfeWjSHC8p3gr1Z/TPLxcBE9pncLVF2c3W04oL4ZcJyIwkB2fAJpz2d5 NLmbR/n4LsrzRQWBC+GZCEcN4Ww3QZH8FReX191P3YsGdC+Cy/Ors7AfYkgk3D8jLxgTv/XMcU6Y qPXNf1doOpNolDWAPkmKML7Ek8npX+nsMT2B/iJKsyRPvscnEMym80mcx94144QhVNW6Zomvj7rF 5Yco3pI4RMn806QYcUbtyQYjVsI4W+csW8XJt160JtbV2l65+uUiGSXpjmTegQXLiGW75rfR7fnN Wb97F/7d7d+1u70A42Aq0fptpZzTxLxBR6VZW2j2cp4nszSavFKp1yzCgsKIlm9k0ZZK92mSvrNG UK6J0mav0u7JdV1W/BYVQSUj0r6RLej0EdYU7KU3X34zRmDJIJLKOgKw0p9f3V2HzeDPu4uz625R L3QlVM+6MIwIbIx33aaKw08o1WvqCGo14ZLVEbNXT/doKoTqlyBGGWHYqx8kqKqrogyRZ53gQEao 2e1HVxWtpKM5HGJjnMFDNE0mz1hhr77L93AYwQQlWNcOM9Fb3mfxt2Wc5hC9AgXJEP+ZPCRFF3uT JoMoy9cQ/WqHSUUc229ZKzVfxE85jGdzSOP8cYazxBpoA+HUNTBHvz5RCKYpseKQGZRB3OBqAB4R ELRyRmnx9i1mo4hR+71lxQ+GcMPMfIYDVgazB8BeMxqMpxhCrIi+5e3w3OUNG7hYx2kSPceLYnYd jKP7ZJLkz5CkD7PFNCqs83X4/GqKU0WUPZSAyByWa4Y9OyX4/sil55BxTomi+3NhGbJy+fMruC6Y gZVbzBfxQ/IEm/kEEXkmRCgi+aEkq0O0KkklrELga64qoo58DO6CK4rneYcMtfXpqhcGcIWzEzRx dkrucYjDpOf0vZyVa0W4rnXWkqPKWV19D3gC4VOO5w54LlN6jPcmjFssMrbWakuIW03hIQKF2LJc T5F0ilBXO3yWsDaWy/EQcjV0VlL6yTOgt4/QhGB4iMtqm+USQC8eLPGgeKUmbM5enMNvpgkuiRO1 oyXiKJ1jw8UGhG8qhCNW7Z/H4PoVhG02evGoNIrb45fE8syKksTUD1clpJKYeTBbFo7FfDOiHdGu 1kO3l99kt+fiK6wk+lDG4sbLvTd7kC6n90W7pZUSumi2CN1KVE954hxReMBe0xv/LnFIJomUtQ1F CQm/o2G/lzgkx0slXTtXbi//TuKQUhJuay1we/VtdUiJHf3tMTZhxW/eFSKVI0WVrlcIBqKXjNIo L4ppazIbfC2Eam016/otHNJIwvih5CmFUZXTDQrP1UNahzdYteMkAigxNCejGXTbRenyS4CiAi+n alvZavGXgGyVcrf2We/6UMziZVXtTFkiKutZ769uA6TpcNHqsGaLd2zTtbm2WoatVtu2O9wwFhgp qQ4D36QJgVdVh5IKUZYQN8Ix9F1aEiUtXkGLA4lUoaii1wBBQcr1NS1eB2J/0AoAkx2QSMDzJNqC VhtQip0O8A7gQaRv4rQgWryRbkjc69fvvgEXyuDwXTvZlED3EP/Kjfjn/wDDNjEoCmVuZHN0cmVh bQplbmRvYmoKMjEgMCBvYmoKMTY3NwplbmRvYmoKMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCAzIDAgUiAvUmVzb3VyY2VzIDIyIDAgUiAvQ29udGVudHMgMjAgMCBSIC9NZWRpYUJveApb MCAwIDYxMiA3OTJdID4+CmVuZG9iagoyMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4K ZW5kb2JqCjI0IDAgb2JqCjw8IC9MZW5ndGggMjUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4Ac1ZXW/j1hV896+YxzVa39zvDwN94GcRtAE2sIK++EVr07aaWN5IcosA/fGdK2pt mlp7d9GLpARtUxRhDueeM2fO4a/4Eb8iaIQokknawfoIb5WQXkZsBvwDa3zXbBWutpDYXvFyKYJy LnnDExJnzx/5f4yORnipTq7uUS94qZRSYXEFpcar+dfBuGREvtPiHt8tFgq85Abv8Lz95/lwPGpr NBGVRQroWngPHeE6ftklaD6ARzToPBrFh0HT4fRk8U90i/0TPmN8HTLehkw+hInh5OshxzbjaQ1c guthFU7xbZC+wKLXRhjpXmfxT2dnF6vb9XL3yJW8GG7vh/XuHJfvksGH33bD9vK0NEkmCq3t6yRx vTKov31/jqq2bVKyd66puqAqrVzXm6bqO1M1jXW167pGOVsaojNCWf0liH8f1re7u3MENVJVeul8 ZIox7F9LgANRn1bvHEbCOkgNLXPCKou6QfK8zgYoD1mjbmES+h66R5TFEyBqkUJ6kziimWzOwPRw LRqmQYs2QPJ3zyuiR10jUgs8yEIXwTBuXXHIKYiY3sjZCdjxsLU5Z3vqSbPnmqolM3xAkeUEYyED LKXPw/AJqtKQg9IiKv8tLDdoWjibg4DLzzgwClplyIyHBk7Dkt+A5BAD2uKBEXQQwbyd9C+JVgbc Q501kdg1hVtPxfGkgF6HoIV3ZkZk/df3F8MVvn//L4+fPl4vdwNuNg/3qC4u33nnjL88xe7h6WO4 PD1/yvyTryt9X6gjIQbhgprh+su3bU+YypTjKLWwaSZG9Wq93PyG/mFzj4cbHJg7kHb5btG8P2t/ +uF9ZqhspY2GaGScMURZ++z++bN9P6GoRDhFG4TRcymht5F7oaBKjHtPCyWB/AV3nXVYUjO45ytK g/JaaOtmTI1A8o07qGp/Y53RQMlcPDIumY/H68qDCkEoP5eDTzc73JWSagyNJvIPvyOuA7QWdUQq zlTSQsZ51adK8t4NRXNP1sgMjw8c5bP7K/KBRF8XXr5EUV7cn0wccL+/EUsj78uyzjrEItNz6ap6 X9QrJMolra6H7VhCJ4BK2PKklUisci9dSRtz0dasf1RrFj8umEfXkCVaEq4jf/PUszEpLAfJeBHN PPNG83NsfQ7e58h6TJgqIQfJKRHcvEyP9ubY3BzczdxclA7y5L3w4SjzGDQVupB7ENotdkZWI3H5 Wp13pp1hy0cvw8iyCKY0U1EJtnszjWLT5ppsn5xE5+AYYjWSBuqAGGFayJRtIaEy0LtQGlTywql5 EWaS2RaJKU+mHJo9a1TQ7KbYavYmn+o7mApNQzdeFpSVSgk7J6p26Lrc1NLgTfNtmnCHTmCfDKUx aS+Mndfi415jzLfPeP19MpQGxfmE9nNFOO4mxnybuHkJ32X5zJa4cPJZ6bxQcV6Lmz7HDAtxz7sy 4DtUChVbICacd9BVbirohZmIfcMGrjRTQQkl54rAmCKQnIIswRKJ3aIDS09G4RNS2jdpEygFaotV ygvJQc3L2vI8nuifbLi1aWbD+bGwybTKSJHmxJx93VaaGetE5IzoJTPt6nbYclrDjTJJl8lBEpeM C0dponvjMIDfcBDQZo/JOkzL0DLIuJJN4abUKs+GLMwTbtLTMaFoDuI+cCihNd1cRGgzQouqyZBC KNzhWRWc8Gleg58iahyZvHAmv/PIxKokhVfzKJvy9gdPSKyWTjgzLzoThEee5SChGEUUxwJX1v5Z raWwbl6qJwhHQT3WU4yKimO1K43QOHHkTycAR3GdamthAdHeCU3X9FJAnhIBz9L6yoSjaP9udZRC y7la/CHSqpMTim81XjIzkda6Qs3Bwn44xgOOy+ouzyWBwLrco2I5ZE/GkWCTGx1Vl5ZWo/iO5Mj1 TaKHPQV7Hc5GOaDheM+xFlR5Kg009O8ONZ0Dp5DPbxYKtDfWaCuSn7fLTxH1fyCtxiQR5750QttR A/g7z56tcVaE9Ma4/FhZubDs1PhG66hXo3hwL6xbxie+yZvn6YTDo9Zw7xnZOX6mcRv7ttIIoxXe zCv8BOFRnzhNhBKu1eokHFuvlwKyuBtw93i/XPMN6fJ6+eGXAQ+Pu4+PO6y2+Lh5uH68Gq7xuF2t b/Hh9uN2uDpbPfwZy8OH0gtprRU2zIv4brO8uVld4XZYD5vl7mGD3d1yR1TDlkj+vdoM27vl5mf8 svp5IOjVesdnEAchOcnvhf/3Kby1wQqT5tX7Ylhffxq//zBst8vb4VnAfvwvJTdDbAplbmRzdHJl YW0KZW5kb2JqCjI1IDAgb2JqCjE2OTQKZW5kb2JqCjIzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNiAwIFIgL0NvbnRlbnRzIDI0IDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+ CmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHNWttOG0kQfecr6jHRhk7fL36ba9ZKAgQcZR8iocEeYDbGJvYQQNqP32oPHgye cbJSs7vI2GCN3GdOnTpV1e3v8Am+g+FgHJFaSgZSW9CSEiWUhkUJX2AGb5Mlg/ESKCzHeDklhinl tMA3KOw//oufIxyXRGu+N76CeISXUkoZjMbAWHM1viqQ0joi8P0reDsaMcC/zuEVwG/7+1fF4lu5 GED+k5/Xe6M/IRut8D8i6AcEuwEpKgnndq8D0bScXdSXA+DavoZ/tuhPWFDMESZ1Fw31/XU5AAAO X199PkqjUfb1dehbFpJQrbpu+baqLyeL4nZ2upjf1OXydM0BDc2AtMRZ0cnAvC6mp9dFfXla1PWi hcClCk2EFsRRvkUE0o+CPDwevhseDGB4kBx+PPqQjTIMiYSze+QFYxJYEcYSy7foQCR/rcDk0+Ji OQB6Jymi+FJOp/vvZ/Pb2RsYLYrZsqqrH+UbSOZX19OyLsNLxglihOtiqsE3Qtni8hPUbsMbomTB WdLUEq1MP00fHlKWrcIUWC6aC6KM7ifhcFFdVLNninkBFoQl0skuFlC2Hz9/GA1Psz+Go9N0eJJg HEyr2bDWqZUgkol+PlrRWi/aw+u6ms+K6ROZhs0irS0RHeWlTaMNmW7zJIOnjbaC8G2jbeGs5frg KoE9RTtLGFb156WtXX5S1AV6CtbO9SNwxhgmCLWdGeOVenR6nEXJ76cHH46HKBDuWqGGlYXhFtsR 1U/ELwg1bOoYyYnjO1JnU6jPaGJep4EJUoZYuaP8rIXKdROi0DoxnOwy1mgyWZTLJZwXV9X0Hg32 6If2gglPhDVEG9evlJObs2X5/aac1VA8AQXVBN+szivfw36eVeNiWSNE7/5hpWMpJ8qZftc9KO9q uJxfw6ysb+eLb2ugAw/nIX5PiNsL0EZbZohinZmODULTI6yBYUeNs8EAfyk+0a2nsRZioHEqCc2c 4EQK2c8cBnfN2fW8mtVLmJ8D9qDF+PIKg4tWGTjvrDREqO0uuHXog4cQTov7coFTGSIpzqppVd9D NTufL64KX1N9ZFXrnYHlpjnhhvWQhkDRyFfhnJzZweCt4KEpMoYw25eRzfofj+DYUwOrQnK9KM+r O1hPLogoMCOOE0a3J8YmaF2IVnbVwHrQ/oqslqm9XxutfzLJOmoI5Z0piDGK3x2dZAkc4VgFEY5V 1RnOd95DsS6+zEjjOCNOdlbdhqS26rru9vANZHd1OZuUE2jqT3AvdUITqzvLcANxowz3ESjEhpkG iqRixNjOubSB1ZZj3GJZBa+VUphdGqc16ZyymuVPyvEN7hCttIQ15XEmDptozjKiWefQiTiamrJm Yg0iNBFO44ZYHxUNhE02TsqLplJ8ffVYaYOyoihjRKrONG9YaVBdJ/MbX7JYWEYUOgwRpnP43Fx+ ndthvRc36xjhri8z8M6bm49OYHZzdeZbMa2U8L0iI3QjT4OkiaJKE477mh0DVivQf1sdhhHGd+QM AsNq8GLqsJpQ2TlyNow0y7+QOhilBK2rq1fZXH1THVI6rw5KcA/c6eAKYUwRa3fUwJPqYlbU3k3j 6Xz8zQvVvtB+jWKCEkv7ql0TmdZP1ygC2weTihjeOWkigAZDNL2YwzD13hXWOpn2ce6RR7P2Yzw2 rNzxl2mRFDOK4IFKj4EgoocK8344AGlyLuKcRTHPbeRSPJXQMovj1KY5NugsMVJSnSWhOXOUSNM5 bvpwrSGudWPoSzQkCrtUIjBTu522RdFGbwCC4mETUI6zpj/mwv4gTgA/AZBIwDGYxhCneGqF503A c8AdysDEcU7xpGuH2jC2T39wEBQ5qBQSDWkKqQGKzzleZDXEMVg8QdOgGWQWsGtPVXDIQhEu+qor 4tiCnErINOR4jJg8cE0jcBFemhlQeDMakgxwZ8klkHL/CM2yooSpzvG0IXcLMupB4Ekn0pkCl2AE ZA5U4lmOQFHIFCgLaQyY9bEBa4ND1gqP3/pKdBfLIgXqfNSRSJl5agO7MsdTYId32pte2DK0uQXd zhjWqrmTeDTXV8qb0HpQ3hmjWKaO0VypJMoMizhTWS6SKM9ElCRSxSrLEqYCbycpQR0e2XXu7jf4 8BkhvrAzCjx2N7JzC2kTRRu9/4EzCuFW3xToVVsLfP3Hf+6MQkmiOrd81hCfvW4bo87wiwR4lcIc ppDkkERAM8i1Nx+bhXYZofGLHW6HyzwDDBAxiHJvjFoBj4A5YMI7NkCe+FoZKw/Tm6UATcHlG5A/ /Q1s5XSDCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKMTcwNwplbmRvYmoKMjcgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDMwIDAgUiAvQ29udGVudHMgMjgg MCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagozMCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9U VDEgOCAwIFIKPj4gPj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9MZW5ndGggMzMgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AX2PvQrCQBCE+zzFV2rhuZvc3k+rMX3gwAc4tBAixLw/ eGJh5zTDDh/DzsrMSuwJOTnLYviQ6NV5yeZ53bjy5HjelLohbLXh4qKa5TC0QDj8ztbjLZjTHLu6 cCoNFRGlVFS/dHPDhuSd10hZOJaiNOTOjj9KxiSMn0/JmXFi35UHl9IWzG9IUSfQCmVuZHN0cmVh bQplbmRvYmoKMzMgMCBvYmoKMTM5CmVuZG9iagozMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDMgMCBSIC9SZXNvdXJjZXMgMzQgMCBSIC9Db250ZW50cyAzMiAwIFIgL01lZGlhQm94Clsw IDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjM0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+Pgpl bmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0Nv dW50IDcgL0tpZHMgWyAyIDAgUiAxMSAwIFIgMTUgMCBSCjE5IDAgUiAyMyAwIFIgMjcgMCBSIDMx IDAgUiBdID4+CmVuZG9iagozNSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIg Pj4KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNl Rm9udCAvT0VVWVdZK01vbmFjbyAvRm9udERlc2NyaXB0b3IKMzYgMCBSIC9FbmNvZGluZyAvTWFj Um9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjQgL1dpZHRocyBbIDYwMAow IDAgMCAwIDAgMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCAwIDAgNjAwIDAgNjAwIDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgMCAwIDYwMCAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgXSA+PgplbmRv YmoKMzYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvT0VVWVdZK01v bmFjbyAvRmxhZ3MgMzIgL0ZvbnRCQm94IFstNjEwIC00MjEgODA0IDEyMjNdCi9JdGFsaWNBbmds ZSAwIC9Bc2NlbnQgMTAwMCAvRGVzY2VudCAtMjUwIC9DYXBIZWlnaHQgNzgwIC9TdGVtViA5OCAv TGVhZGluZwo4MyAvWEhlaWdodCA1NjEgL1N0ZW1IIDc2IC9NYXhXaWR0aCA2MDYgL0ZvbnRGaWxl MiAzNyAwIFIgPj4KZW5kb2JqCjM3IDAgb2JqCjw8IC9MZW5ndGggMzggMCBSIC9MZW5ndGgxIDIz NDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZV8B3xUVdr3ObffqXdapiWZmUwK JIQEQguEZCgJbSlShLAbCSV0pKMgIqgIBlhYKaI0lSIIriEghoDiIrKCuopd0F19AUUUxV1ESmby /c+dBCG7+72/d5Ln3nvuueWUpz/PubNmzK4gZrKQ8GTA8JHTxhL9N2QpIZIyesrIafGy9gX2H4ye MysYL0vrCeGvjp02bkq8bFhFiOgZN3luw/323xHStXx8xcgx8XpSh3278TgRL9M22KeOnzLr/njZ upMQ2mby1NEN9bYqnN84ZeT9De8n7P3Be0dOqYhfP2Q8K0+bOnNWvDx4D/aHp82oaLieDkN7CgnF 2b5kGjGRfkQkHNHwV0CIfAF1PGpZPUfIgSPHpBHWgl+oTdEfd8//vLmQHby72dXmZqDuOWmq+haK qn49q8B9CokRsls4fTMQnSVNvVXDatmvbw1pnRUJ5fR7qN9LLV8aJ+RMylmbO+m9Se+tvTxJyumc 2/m9zu93vtxZrKETq7PbBV6lv9CrJEQC9Ao9V50SGNDFT2fioZf1bTmdRaYBFgK+AggkiO0qwGUA Jg7bKgBHf464ldaBuxRXwGzMC8hSXkBVWgV4rlWghr5xINUbeB1QQ3Oq9d1RtutipkfoIbII736V HlIo9ocbyoeqOy4KHKa19CAZiNMHqwNtcXNNdfoi7F6p7tgBlQdQwe55uTrQDcV9dL9+7f7q1Ja4 aG91Krulan/GooASOUR3YGjUeJdraGZ1dnagi5GmkFE0DY8INeyTSVigBwLnA+HA2Y41Ao34A1+F ewdew9UHw0WBmnC7wHYcb8veHdg6EPXVgedG6btn47st4RqKk5vDOHkgsCFcHFgSP1wc7hS4N37N 6PhuUPz+nvH6HuEegW7hGgU3d2VnqgPNR9XQtOpAs/jV6fGTaWwXMQZSwt0CIUCSXu4UGOJRPeqq ++RV5fKq/vKqiLyqUF7VSl6VK6/KkldlyquSZadiVzTFopgUg6IokiIonEIUZ039V5EshlZOSWM7 SWBbQT/WgKCUYSm2mGGFI71JtTPoLC7v7jlIKK1fvCJhTpGnyF5oyy/p/h825frJ8u5Zv/08vx3S PgPmHsbgTyYytuYDcuA7OdBbZhf0GYSaVXrNKlaz6jt5VbzGk1S1rs+gYVUvJJVWtWYH9Umlfao2 Dwr+YdhBupPuKO5+kD7PdqXDDvLb6M7igew8v6176a3L8LKduIxksx27bAsJsMtIgN/CLsMQ648j qfR5dl0e2+E6b4Sk6teleiO3Xbd3VKC4+94ANrjGHSGj9GtGuePXKPqz9g7MxjXZ2OCa1gvJQP2a ga0X6s0ayV63NxzGJR2xwSX0FAnrl4TpKf1VfPwx+jUZ8WssSxuvsSz9t2vy/+M1v439fz2q6Lqv 84OT1hZXhIvLw8UVgPKqZXPGe6oWjgoG9056kFUEq/j08lGjx7P9yIqqB8MV3asmhbsH93bW72tS vZZVdw5330vWFg8etndtpKJ7dedI5+LwyO6l+1oO6Dfujnc9futd/Qb8h3cNYA/rx97VUr+vybvG seqW7F3j2LvGsXe1jLTU31U8YVDX/9btmbNmz5yFypkzZ0L69CMBEEMOoKVQRgKE1J8CfM32sX71 X0uQPLHloIgpxE1eA3UwiP82kFr89SDz8beBnASwv1qyj06kR+tr2BmhkPyJXKP7cMyROfX1pCfZ j2t2gwW3JAuok1jJURrAmY1cADIjRBaQDbQX3RvrToykAxnKmeunk0Jygpzg/4baMvIgWUHWkk1k D7XRCC2hq+jx+t/hnYfpdHpKOFm/C+8JkBy06im9LUdxTX86HWIkgDf2xhOepDX8LGF5/ej6h+sr 698nTtT0x/mJ6AXejr/95EPyOWfgTvJb+ZOxl2Nn6wfVz6xfUA/uwf7Qh1l6O9bgHVvJAX0UTpD/ QT/X05/5Cn63UCIMrM+uH4c31IObBEk2+tCDDCF3kxlkNpmH+2rJGXKWXCM3aIBm0Ja0Gx1C56E3 n3IBrgvXl8/gS/hq/qQQEHKECuEBaUr0q9jMekt9FeRrHlowmFSQqWjFAvIQRpiNaC3eTzAqbpqJ Zw2jW+ku+h1HODfXgsvlenH9uApuCnedd/KD+SH8SGG5XB1rHtsUu1Yv1/eof6r+WZ37CRgphXhJ MskgzUkuaUeK8Lb+ettHkNFkLJmM3s8hi8kash79OIy/v+Dvbfy9S95Hry6Tf6Jf19EzBa2J964d +jeUjqaz6UJaTQ/Rv9JT9GN6ln5Hr3F9uPXcbu4wd5lX+Mn8LH45v5s/yX/Of42/a3wdRiAgZAh3 i3fVibH1sbdiP9X/BbPWDG0bR6aQR8lqsgszVkveJMfJKfIB5uEi2nCZ/EJ5aqUa2uBBK/JoG9oB f0W0N72bltLxdApaM58uomvoBrSpmp5Em37mRM7D9eaWc2u4F7jT3NdoUwZfhLkoQbu28jfRlkL8 FWFOpgiPCpXCNuGkOEv8QdLkR+WvQRsnyavkaCOB6PvdZKt8FO3chFmqxgjtJk8DAw7pMzYZms1x cgntC9AZNJGWcO3IGRok93I+uoweo/24FE6fR3o/r4BC2O8kqaHvcmXiRnKDm0L7cxzw+xSXjCct BgZvvflt3QY+te5M7FH+4boB0Q2iAvybS5aRL/knhADZQx7GyGUSEmndKjenZXaLrMzmzTLS01LD KaFgIDkp0e/zetwJLqfDbtOsFrPJaFAVWRIFnqOkRXG4pDxYlV5eJaSHe/bMZuXwSJwYeduJ8qog TpXceU1VkN03ElV3XBnBlWObXBmJXxm5dSXVggWkILtFsDgcrHq3ezhYQ4ffNQzHK7qHS4NVl/Tj vvqxkK4XzCiEQrgjWOwZ3z1YRcuDxVUlc8ZXQpZnt6AHIxhGQ3YLchDDQIzsyVWk28gHwfdJN3ZF cZUv3L24yhvGMer4tOKRY6oG3DWsuLs/FCrNblFFu40Oj6oi4a5V1qyG2/UnV8ndqqRueHRwQhU6 QJYF97Z4vXJ5jUZGlWeZxoTHjPzDsCp+JB5RXGXLqnKHu1e5553zZLeooTsGD6tSu9VQMhiy2Ve/ cK93YXcIusYri5c3XH0eV1dxaSUjKypLqiLlyzALrFjOSiOXo0Q9OXg/azTrQLwrcTGWVj4xWKWG u4bHV04sx8j7KqvIwLmhap8vchBszVccrBw8LByqKvKHS0d2T9zrJJUD5+7zRoLeO2uyWxz0LOgU wsAdzO6S3YXtO4U8C+L7bx+Jn//gdbb3LDj2FfZ9Bt4aO8qaFu6FplcFRwfRgGFhtL8D21R0IJWj O2CI8Sul6PkEjEh5pdYRnaoS07RwsPIX6N/l4Us/3HlmZMMZKU37hbBKNuW30KaKjmw8rsrKqsrM xMxjliowWWhaoX6ibXaLOVX+8DQtWOWHxCcDhuGu0o45GOxQiE3cshroOihULbxrWLwcJKP81SSS k1VaxZWzmtcba1xDWM3Cxppbt5eHgZP7mXpJXFVK+q1/q5bgKB7fsYom/H+qK/R6WDst+tQQdcCw vZT+sbQGWmkN6Z50EDYTP+Ke7BqSx5B+Qnf0H4U2LXAiM4Sjti2CJRj3Eox2abAyWNlrTGWwJDge aC2k6XtUVFSW5qDrg4ZNwHbwsFBVpNR/67CitLQjntOOPQe34PLKUjxhYsMTsNdP5URxUfsWfZim MmDYXcOqFnb3V0E3xKSCkF7HsL4OGgJa15AOt1qKFj84wdPQ5ny0uUMm6jvGnwKldyEeUVpZyZ45 iOHn65WV/kpG+vEyaKbpiUjDiRrCLmG0UEMXDsC92IVDfnYiHAqH0KzS7nhVpxbQrRuIW3iXrAYQ 4V16GHsGmwA9UN6J/Vns38A+FD+n16/F8Z8AuQB27VjANsBiALuPXY89eQ/A7tsDmAPYAHgbgGfq 5QXYs7p7Aew5ZwAdAOw8u7+qYc/ex+rZ+1gde2ZiQ7kN9vMA7HrWjhUA1pYZgIcBzzccs3dvBrD3 vQuYC2D3sPNDAew+ds8NAOt3OWAlgL3LCWDtCgLQR84FhI7b+AQeAIkcQzkIjYoh+m8/DgY0zC3o LxJMIAUYa4COZ4JPxAItUCM2YicOaGPsx56YAHATD3QRH/GTRJIEnSSA54ZICgmTVJJG0qGjNIOW kkmySAvoWC2h9+Wy2/VfK2xbQ1dqQ9pCi2kPbTKfdCSd4JfoDG2sCJy/C+lKupHupJiUQDvrSXpB P+yDu+BT0X8dcM9ASOv/oRbomsPpArqHm8W9z48RJGEY5P5k8YJUK98jr5ePKr1VTt1vSDc8Znjf qBiXGl831pl6m2pMX5lXmf9pud/ykfV1bbzNYOtoW2fX7DcccxznnC2cPZ0/uha4riY87Nbc4z0t PJs9X3n7eY95r/me81v8yxODiXuShKQfk+9OPhZoEagNFgTfCdlDudBxV8MvNAU6O4+xLI6ospRE BTGJ52ro1ogd02EQ5CSe+FRRSuKoV6mlLSglnqx+2pWCvtGCftpVtiNFBVq0IMo2rXKbU1tIDtlC /JRoOnd6XWwg/bOkrbuZyIaC0sPQxmywFXjiiRjpVY4jlL+HE4Wcjz6J5ueTokutcmmYD3G7H5tA h/Bfw1qg5HBsuZAL+8FGIpFMySAZJaukuQwurdhYbC3lSiUDsTnUNEWzpRG7Ms88SPDaO8zXG9n3 0iU8s+gStefn48llNJVwbdvYSZpLEjiX0y64hdzY97FHz56FDuc6Fftwzx6afSq2nKm/p3/8kZ6m bvtGx79iSz/9NLb0nzpSUbIJ7bHp7ekeaakaVKNqVTWfwaf1Nva23s3dLQ0zDrOaFNWM9mholx0t mke89skj422K3tkmh0DsLidHxLbtUu1t23CpGZuoi84/ezb2aOz7UzT7xRdjH56Spthj38XSf/wx lh77zrbB+U96/6ef0vv/5cD49ACXWQwLyUjSI05DBZGTqFQhGEiFgU9ShQrJpH1yBbNzjhTpO4yD K2QL20JtQ7Y8m7A4lrMxlkNPbeSmxPf0VCxHn6udsX58Ks3AuGdEXDRERhh7iUb6O0UcbZmheO2t +zR2R8OjL11hU9e2kGubkt62Tbu81tD9LJTu7Nknu2zYqC6D55Vvj/Wb7+gxpe+EguIRf1pw7xuV jNrPchn899xR4IMvYqJJhPOJxCu8uoc9+pz2DcnpG22V62gbcp2F4pqxYQPDoTfqT/EqdaO/3ohJ mkaM6j2819TYHDa4rXLF31ohcWO7lY/s2nVkeU55t+4jRnTvVo7u4d2h+lPCixLzLBZFfBylSUB4 Hi6bD3meQz0n8D6R8wo1tP/e9Z4sr94gGxCJeIoK+mpRW/4SsWXWg9qxVrnuMM377BX+zN4cZuay p/TAsxfj2UbwoGTqjOz0mr2WBHeCJ5VrIbdQcmku11nurHSnEa633E8ZTO/ifi+PUEbTkdxE+V5l gml8wgw6g5srP6is5jYKG5XVhh2WfYlvJH6knDZ8bPrS/nHiT8p5wxXlSmJ246PTaBo30TTOPM5y 2LLPts9z2P+m3dJNMZtM3exuk9ON15tNgk/rSkRfV8mslxxJA3lf0DHwIZWq3sD+T/UpLet7CZTd 95LNzSiyiO2XKC2zLHpfPd3mRnI9idTuF5PKqVeG88bjtlJzhFrMNqOjHCLEV048ii9CLJwWoXaD Vk4J8yHQLK2A/WctWkTLSBkNEhtMdX3Lw3QNp3A2Z4JKk2lea7utDTeWqjQhdjH2a+xa7DvqzuC8 efdFnv+zws2Lfp81rfi1Z6TCWLfYkthjsW7whM6jc+mrNxfwvcq6xFbEznZZx2l11b16wXjln8Fc HwaNjAOfM5OHI0UGauD81M/5eb8AY44rEe8W59LF9En6JLeD7uCuijYJbFCSeCoI3eyiKIsC5WXB YO5mNJkMNfTBfYo6ysz2VOZgRz34MhGo4LXU0iAFZ2PssazvVXfBOZ3qQHtFGMEGXCHTy9JsFiq3 bdc+zxZyhdpyHQZvrjzzbC2dXTdkg/Dnbve02lm25sYyHdfhoyBCBHgUJocig5qrzRN3efh0MV1K l9OVEkev0FBHaWhi4sSkickTA5NDs8X7pPvkuf75ifOT5iXPC8wNrfc8lfh88nH/d6rfqwQT7aoo pjgSLEFV5FMSfUZLDT28L0EMp9TQQxEjoSbjQN8i4ktDOfSKYxH1ppauiVP5OR0lroC6WHcuURCC HegR37XKBVJobq/J7Ekzu40RavJaIhQTjqnGRJc1p23bFMJmBndokx5OYb0vxCwnU5dTsnIohoRI 3ZB264dMDH5W/MyY/BUT71sQHTj37dEPVc0o//00ibu4u+uTh4dODl1eWDhmii/cbntBdv8d90z4 4sXp9/xhz32Y3z+B3vpgnNLJqcjM3rahgbtTJtpOCO+aT4Q/FU6bPwr/aL4BI1RJAhextBE7ym0s feRi13DnJDLG9QB5QJ7tmu2tJI+6HvU+TZ6W17p2k22ubd4a5U3yJj3hOiOecV0UL8rJEpVcalKC y5skUpKapLqcblOS1WjCOO5X1dQedhxUu0Ueu4gp1Wwd6JsjDQz5mhlr6IhXXIuIN6NxQK+c02mM jShIbI49P8ejjyob0nx7vo0JLOAKnV7Wvm1CXut2GLlQuG38IJwC9MkLgsVKcjLkGAmlpP/p/M6n T3wZ+3Xcyjf+/MfV2197bTP1fzrjqSWVPWKv1pPeLyUem3Vo9ZraDS9NGrm4bG+Pf6ycWNur2azN o07HzjEVCboAdB5hE2jEACoZGwn8w0SfMv3dxH1kpk8Ja8ycyWweZed5gZc5czcFGsLDETcxCYKZ cLJsNZgEjowSDVaes1pyjn1SoH1UEHUXaLb8HHSIFDHZ4y6QRS1LeFD7CKJixnQyYzr0hLZUJwMb b6PcG9Ep3OpDNBD7+lAsj1Zv5I/WFW6M9YPPaWcUESLM8ybMc3+00UcqI23yjZ1c07hpfKUs+jxp rhaeEu1ubZJ1nnWep9K6wbpD2W3dkXBAPu66YdWMVsXLaQ5fDX11vyiaebD1Q/s4KjjYTLnNZo7n e7gHqr5EQRxFySKr139rooDw+lTNwRRB17nEKADTdcnWMENlDkbHtrwgwXwI4ZSMtoyFFQLnU0OH +YrokCBcKxOfiF1dt+7ikA9KS1+4J1Yfq+EzuO/2QcRfuLTuxyW93m7Z6e7td//pBJuHsQ2ywwPd 9M1I707udv5OyX0s/dx9kvukjCFj6Gwym64la+kO5U3pTeV901mT3W/NMmb5swL5/sEJfwhMsI5N Wyy8YzzDnRG+tJ5Ls5Kg1+HSkVKdGnwpyAWDBhfDVE30sv6HDWZH0nOaHJRzZV72ZZAwjORwLkz8 geEx4YVhJdzDA44QMWjmoDnXzJu96TXUvbdRWkTnvFPmwRCV9Y3GBQZGpwzyERPPlC5wgEZqJ+E4 02/tdoEPcDaqDxMOJZczgab2/Hjh3M9nxM5/G7sc+xf8a6mb1uxY/f45OqXP+qGrl654eS/32aQl cz5c/mXsIHx/I+ij9I2Wh/vHHo6diU4uPTjljwc+fHL9X3Q82QZcfhB44iHbI8UK34Hv4OqjTlTn S/Pl+cp8db72uPSU9JT8lLJeO86flk7LF6WLslNSVdHu0CwGYvGZHJo2yo4TDk3kiQqufyiSZjIK BBWqKAD1NRNn8vncAx+ilP4PMWgGzuD1ljYOypUycMxvynQZCn0hWsCkqEUXAox5MjKXLQVLNAv0 B1oWgs5kL+LatYdWxqhaslILl0RpUe/aDs917Jpbd4b/vNPa1PD4MeWtlm39O9V6f9KndPah+b0X /K1VqydW7DywZhn6zZPFwJ27wQd9sGnyqBJ5AcYHJFwvMpwMzRqeM0balfKu+y3/W4lfus+3uE6u 0+vcTckuq6JB9WTY0nzp/vSMfL67vySxJKkkrSS9e0ZJVknOYP/gxMHpgzOGZA3JqfBXJE4MTAxX pFdkTGo2pfmYrDE5k1tNaT0pb5Zhun964vT06Rnzms1vPr/V/Nbz8x41VLbaYH3efJAcpAe5g77P tc9af5Z3PvF80vlW51tfzbqaU+gnzaxCdgg29eFqWcxm+BhMMJNmXGay38rlpiY/Z5zTI3egw9c2 9TlhTo/MgV5vmxrq39sgmC7NueKJqyvswAahxCCut+AATBQCiGa0BDlCK2UiB/LGrYueMFMSgZu6 UGIY6JYFbOM8NoO+ndJj6ZXDM2vGtPz9ksGrx1658ssVTlzR49Hx02aPmizErv35vil7TjXni72t 35i94cyg58q7PjD33m73/3nyzl+/3V1Pu05aVdjngcd6lszve+7tvRNWVY6reD/I6JvphmMxR4y+ T0SGpie3dXdLHpg8kUyk88g8upFspC8ouxyHpJfdX6RcTGWzdDPVIaZQu9WflqakGdP87ZQ2/raB scbZvuPKm+obxjf9H3Cn1fetl9SLaQ4H7yLeOLGXB59hxK4xKq82iHGaN+u0HM4Kdwr3DZeFJ4Uf CC8LrwlvC6th2ezLcIAVrJSp7E3ff/A3beZSfg4o3JYP3VAfW0bilyCmGkgcgsoCDY6NMgEjZIod +CCG0m6jkPe3RpXfGadx6v+WatQceyH2RZzGY6sbaZzvMGnJ7I+Wf0F7xPJjz8bmxzrnHOoHozmN W11ac++KAx+u02mci9sBwnzo2G7SLOIyTbPLzBpw3WNVp/G81etpMAmgrF/S4q2+0zDg/5OR0K2p scBX3DIbMHc0ICzm3aA0mWQeJDw9Us1NlWvoEVgiIuxkmYOa1UJXmQpgHDP75SozjKDnMRAW3zwq FN48yrs3bIhtZSoe8OE94EMS8CEI78OySHq+kq/udvEVQoU41zTXLNhG21VFEr0+f6IStFvSYCoG p2YgPyCSGDKKkqIKRsLc7ULQOMh93W63TUkN3ksya+jRiCFAqBVSs6BHag1tuy+7EhaodmXOuenT PRgRtE+LXrpFMNGr0OvywaU0NFgnmrjS1q6IMuUDPJopHcyus/IWmkRvHz36p8T+/QvtKV0H379k 6MtzD5786vv1Xfv1yCgY3HHIkI6dhtxNa8ODpt43uKsja9D435VMzum+f/grT6za0P2uXi1mjG0Z cw/p1GnwoIKCwWw8QuDdL4J3y8RE20XWS0QVuRzjSsNK40rTFsMW4xbTEcMR4xGToRnfXMgxpJvG kXF0PDeOnygslRbLjyqPq5WGteRpca3ytPqUYZ1pN7edf0s6Ln9CPhfPk4viL+RXel24JgZlheeJ pBqNRBQ5WTEZUTAYjaKMqL2kijuMHB/kjaKYahcQuDAS0txOKWdUeI6TMOlVkc5qQKHKj1QUBPhF FBiPvGgUOgmThAeE3cIhOHh+Nho7GScZHzDuNh4ySsaf36M/UXhSepg7rdNtyjlXyjx9o2WXyjxM 6wPfKtDYX7SMqdlQM5iNueTBY0taetguC2ohSC6fiQ2xoGAJtseOLdEUFLA7posSTN30PBikzI/S PsRnyGeP0r+/S7/+eGL077n0zUMtMiTt+mU6ZAPXd+NGJjOQiyN0wHjbiB8c6XJk6iPiGnGdc5u4 zXnccNx53PWJ4RPnJ65vDeed5103lZuqBteUyj3Cv+b8PPn75Jsp4kAlJcmQ5vQ7UpwOg+BOTOpJ /D1pWk+rgwYcRxz/cPzkEBxwVXBEcedJE4N55rUZ/sRUptB1zkjPORYtY86jc79cgZ7IGMt0hp1M G26wMKAN6yZGRz6spLvShDRrekq6U3UX8l7eXUiTtWAhDRuDhXyC7CiErHY6PKKvkAYsSYUkZEot pEYDszthfGIHq6Thx8zQ6WVQP4MNYiG+C/N5uqGSRW26KGgJS2YPzaG2g39oN7Hi4CNT3/ripY/G jchZdGjFkWeeGlx1GIM36LnxA1fPbdf7s8njjo7nh2SNmF1y7+SbGU9O7PdIX9bNOaDxiFQEL+SK SMEvItDEJHMzyHTTdPMM78vCy8q76o/8j6raUjGfNZms+QbeexZ+y3xOhfkO16XfkSd5fZ1Xx40x Ju8K0BdS1PcSyBVky2gWNlhQS+BVV7qQZktT0hN4RxYcUNg4RXcWsctW1veG7us2OExRKZySylxi qXlxnUxibjHw7fZC5M+VB2J/e2EnbV1T+ednt9z/13kLjt23+Tl7lzfoon/9TBce71JTti32Ru2r sde3lDG6BTcT5gOPDPB5zIzkvGH9u3hK/kk8K5+1/GSXeYEusyyzc1mK6Sxx9WS4oOVJa90uYyqw wJ2Qc+wXoLz2Cxh1ESZf704y71DSLZhve7pZ1bKog8fGKpuyiE103t6ZxolsncBcaVI4AxMHXxqb uQ10WuzX+Y9cju1Y8u5LfYZtO/SkpO2NPf3Lhdizr+5+gvLn/nF5Edgw5uhttN+G9hvJmAMD4G/l FEbjBwwGVeVEiWVFgQkQWHJVER/llFXqM2qV+roqqBPFIuIzS8ZUnvPCEgzvfSIuAOIe0r5XzpXF rea43RB3k9KyNNgMzG5gINjqavl20TVcy+gHu3dL2sbozxuiX6NNQAKdNlXSI9JMEjMURZYJL2Rw bPxWyc/IVfLrsiBP5HxGQcVAeg2H4zjS4J7ty97dYLDEXxy3tthLz/JDorO5vtF9De9rdxueJpJn Ir0OCAeU99Qv1O+BmZLkol/YaZaS2LO/jxb5aI6PBnzU5yONCOspStDRtYj4N3k9qYnEl8yQNukO pMWQnIPvmBRFz+lYy6gdv4bp1ly8Gsdd1224m9AEd3Wfwn9DXWCuLdwW/oRtjx+NndoD7H0ljr1z v7kWbLWBVtDc1+kjV37D38N1sVEivcJEMfq/AOPN7EsjfIIBgc9QDT0MIgeWr4hKqixLPjPH8NVr 6vzg7XPM/IHMDV5UkD8HRiLzg+fBucocrHC02hac5ApPnIgelbToGG7j9cvc59GM+PsY7w3q7+sZ yRBEjhiMZkkWMiSRM9AMI1Gki4oKvLpIyBGQmNf0+zhulfVtcOnqYiJawEwKXTLgxW2ZVR3HrD10 SGw3Pyu2G+xe+HzjxpsZDf28Fz7Uw3ivjZRFkr+33bDh2QrRKK+oGUYDx+drCNenmow9HDB8cquJ ww6b/pw25xPWuQYb2AaBpZOpJlgt6WKaYJULqWTmC4nOZHTPj+67gIate5uheYdT7j29uu9DfWJb uYzp72ypTnltZsGKb/mhG+uUa6dnx8dkE8bkHbTNQHZFQhel6xLXWegsLpGXKOuUXcJB+YxwQbiq GAyy7qOrofsjJXZeAoNRUu2YIikVVpuiqrwAqcxxSNyTkbon8Kr4CJE1WLjl8jRZlH0mnhEMIka5 kIFe4/CX9AktY4QDX+9ViOVzTP4wgczAixHOgTSGHNbELPhDcSA+yCTudFi4bLZpnkrD1LbpJNfl k+iH3APR6HpMuMxdjwbqTvHuuu+AX2fQtxD6JpKW+8BMkE9aFdHATIhPFkTGP6TDtzOPb/B6tKeo VS7jFvDWh+pqTzIGcaNhHjvgeWvxPDv1RAaKvEFM4L2CT0yDZpQpdhA6iHMtj1s2CH8S15s2mTdY dgvbxT3m3ZZDwn7xsPmw5Rj/tvltS+Kj5mUWzmuhVuSlZAsLhD8KSy0S0TRjTf3liIXXLJbm9mKo QKLRDK/n/ojd3l3A6JotkKu2H0SeU+BIzI34iCKaFd5ChJXyFpmTm5coxs8MRQuhItXQYxHDQmGV 8IxQJQhwvhyLaKSH9pmtaCXZQl4Ccgvwo357oAf1OiY9FJdyc6JlnivfzPHCmQol6co32hxoSQzP dT3pHGYlWlBQAI0IszInyxPXkuIHtEOHuPdsBuR72IaJYYTYPizzYT4j7D6z9W06lo49XiuKLS6f /FeGKEpaHcfHrl/mv1y6NFrKPb906Z38wEKWRJovNz0pPG3aKghrhV38dmG3udYsmpozn5jQ3G40 mgQTJhLKIWTF/EgqtEpFP2OU2Qg072FQfRpvWQksaN4DKqD1FgthHS04xmR6XxwWHIsbsAUQ7AXs UGYqoKBlxX0pIXSHuvMyGGuhGW7aofYAl1YgirW10Yt9BEm7+evTTwsqenJt67OsD3F7Mx6LcIOi Srebt9tecLzg/p5+L56Tzxlv0BviL/Ivxl8dv7otj1qWacucjyY8YdmkbXI+kfCG5W3tbecbCR9w XwgfWL7QvnB+kGBvr9jzJd6UT1RrnurzuvJ4r2fS2vikxU1x3UTUeUMmdZuNUDzc1AWpzVQQh4gj iwFCPIHDRlPsWdQpYMO0Mn2jcw7xtvBAGsxIjWMOI83OjY3HA5AW1hAfeOKNN54A5DRGARqjAhtp HzoAf32Qe1eFv5cxFlWgl3tBLybEhSdEmtUav3D+4OQ5kTZTEnrypp4WCwflXrHnBZXXkeu71gOv FNfZrV2BanK1jOkm4AKN6kmi6DSka2lSmtXI+iDaC6lNtWQRh+wqREf0vmQtAn+gTArovgdOYLqJ 7nIIhem8k/ThH0/P2hj77qeBQw8dGPVSLDaXaxc9KWmT/vbQ2lhs2YaRByY+tpHNYayf8LbuM0il QyO7BMJzgodf4X8k6ZHQivA68zrPZv8TSU+ENodfIDvMWy073C94difvDh6z/M1/NOlo6G/hDy1n tDPOL/wfJn0Y+iL8AzlvOa+dd/6U8IP7B88Vyw3/laQM0WJCUEcKmcIi3LwiL/GyQTGomqCJGjLT xtDR3Bh+DVlD16hrDGuMu33bU/epnxp+MP1g/sn2leMquWn7lyPpHoUYUxJFKd0l54PQJ0QCxkA+ 8ebb4UUzqil5QRd1+dIT84JWavWmNeBNPOSkOxd09U+7qjvDG0QaNNtumId0Nc2c5k7nFQTeKTGk OlKyqM+WmEWSTdgEPSgiYI1gidObRf0aNkmWQBYxGUMJ2HnA6+Pxp4apYcYA+8XNADpdTOY6URdz YsBbxLWNx6agTVId75grQ+O4iyX3Vk2y5/ylamPklY/nw+lhAyK6e+2LfdmAhkmzhrfYMGDHSufr 9Ilv6UD6Tqx7bPH+2CvXxSca8bARLzGvLL6zH/hohWVwJfLAY6YdhmPqMcMx0zHHx+rHho8d59Rz hnOO806zaqIHza9YvrFehDEqYiRNqtnsFlspJq/XbPdqNrvJYrWm2k0ms0kj3p68lWTYNEh0zmI2 U8UEh6IrbwQY0aaVZjrATM0+v5emsngn5/UNhzHKgla3hB/0izJPlEUh4gIQWA9uq8G/1hj1ZCF1 5sSMezBZVDAoug3pDpCD3egCwYsgAqdqyyJGk92WIHsKEQW8zQBjdMHiG7dIA245iM+MUIPtRUec pFvefn1CyQOz6F8uxypOUv+Istwtp57kVkeRsTBo58jhB1ZGolnc6o1tJs/rPIUp8Y3xARYHei/y yO/Mv/MM91RY55lnBaYFl5i2K2+lX0w3KlZFk1PkcLo/LdhHKBWHm8f6xwZf1arDZzQLrH23GuZZ nC8pOZAYNPDmhMRAINVuMJgCiSaDkMA7z0YcE+0J+Taeno2QiXY+P1XVq2Sv8xE5D9Eeb54Fpl7G 8LiO2PdKnCmea3BMIoutivhK63ww3H47ZpUN/mGiu87hHS6QNQtUSV3DaNSk2qTncKnwZYYa7DW4 1gI8nDIsBrTp8rGB6/pOfGLsuNjlf1Fux4bdzy3aMm9Ev5ED62M3Yv/4w/Oh12YUzSm+awXcLc/+ 9NJPuS92XVo+YkHbnE65G3/YH4uxzFB6Kw4kk4K9IuI8VS8zu0cBLXfaL8nQmXAQMU/lfuLqwSy9 Sqe4vL6lkjK5jEY3aqEcjeUIU2ItxYrdu6G2QMeGLcx0bBeZFsn4ynLeeVW5qv5iEbMUI+WkfJtq NDQ3m00+N+VSXXBlJtwSlFCydSmpK9uQjg1GotOarqQJQD1ZMxRS0c7BB2ABs+Sd2DTyYZA5KXPk 2ZwNwRnIT10fbUmhnndbNmT4im61i97f/MTfZ0AXEE+s7jto7xV+T53x81/mT/6M+tDuEGiV+aUU cjySuk/+UP5W4ZuRDC6TzxAzpGbKXHKfyMwz+JIUmUiyWFM/PFIu81wQng+uOXRTgvxXnimposzH XUYYQAWHhDPCVO1EH6C7kdb8PSjhZ6OcJXeSH5B3y4fk72VZ/lkQNCFVaCPMQrLwfuGcoAhetcGJ 1OhDanQhxZ1I/+Y8gruI/cNdFFclmI8I4G7Pf380lvJuLPAxvSvuHYIacWzzJvQZaTvCXjZX9JFI 1WKe9iIl/O/kYqVE7aUtk5eaFKfiUhNNw5U/qKIG6aw5NOcDwgOi5JO9tgRnMznTlu7Mt7Vzlsi/ U3ppvWwlzhJXqTJcK7UNcU2QxssLyIM8u2GuPNM03bqQLJJWqiutK7WFrnX8WnUH/5L0krxDfcn0 kvmIdFh+WTlietX8jvSO/KZyTH3H9I75Y/4Mojcfq1+YTpu/5S9K55Vv1RvSDVMEFgBTVY32Hppm k6UAIrc1dN8r9hKXywmfCqtrbi+xWiHw+eZ25NAgf0GRwQ1dmpUoNqcim1SrJvFEkV1aLf2MWOnn EZdmiVgGWFZatlheshyxvGdRLD63i9US1KrvIRLkTWCTwpipTvagCgQKmcrKNFcGYKgF0F3ZD/Q+ J0tEWgUOPLeOcDAjfi5+qmGyZkyfnsfnOdx57R0NW12Zlfn399dMtIjOrTW1DtE0e/PhI2+5RAeE Sl3/TZv4vXXN1z3Jf3L9spC4efPNc7fTt5EcjDzSXnxEfNq4Q/wrdGCRutV2fDuhvYhEdaGP2scw HjO0VPwr91fxtPSNcpW7pto4KsHMoJKgKkQWVCOReYMkx12jqDEw60uAFcY8pvCcMLeoQYb5RSQa UEeoK9Ut6kuqqPrMGhssE2MeLLWmrCFWhtwaJiTi2yViXz1g1uD9tOKnD8b0slAYKr3+H4ZH9gN6 PDb2PG1Ocz+MjaUnv4PNm8Wdj37HuaOZdce5SUwPpsjgI8JTOv3ujtwtIO1+tbBdOE1Py9/RizJ8 t4S3ilZpIbeQXymulFZxq/gt4hZpB7dLskDDT7XD3KRIVYOuLyMIDiud8pIoIlkIzBHqGBEVYFiX iEqDSA1QIsx71OVAkAOVxvt4xQdTzucB8/J5IUmBEzaWSxTvKpg/Umx0XGCmJTuIz3tItyvzqI3j Yq3PY8nBsPdiedzf+K7R9dz4uteirfW+zUPfBqFvKhkdcffkhnHjufs5AV5qGe2Gw1mWOESEqvaL QtyrFXGpBGsHOVmQihT4jiCuDA1stq+emHBOR1rgKnNDRwvQ1AZPNGtVXlvKPAw05JrHfR1tx++L Brmfdgsn4GBov1tvT4/6CqwjYN7lQMTKEyQPGpDaRRGk0IMjLLVLt2yRO4UH9RAKN7BgCIt9fy3c I0xB/maQnI384bjrvHxF5snjwi7fa+rpgGBWaSCSzKcprgRPsjHBj3nV7PaAHd5lonmSrcWesNEg O+yG5I68kTgS7Cl2x4SEgGadPc1O7b4Uf/Y0MAJvqN+COI3qmU665IJ0ZuSp+zaKCi6xYrzLyoPH GgO2cHcwRcfnTQL2pycJ/lbEq/ozSaKY3AoWvCezQeuHh6rX4LkReyBIuSBN7i0EOFdvCsUXrWVa J2EpULr6k8ZcIohC2hFZQYIWZJI7nM7bWHA8HjPj5w75aczyf6y59krbSVrwUObRBPPoIXvOPzhg 6Ac3l//xn1eP0lZ7Eaao+/7kgj8gh/EfvtjV8zt2wczhyIr6y8LvkWtpQ87rq5E+j4t73J+4L4qX 5OviDciifeoxlRPYePL+NMVhJ7zfZfQ4NOLvyCOfw4WBNHr04fIFbI6AlmN9xspZvcktG4auwcOo 6+wFl6C1FzUMEwu6slFK8LFRSlAxLD7B04q6ZVcm8Yr+Vk1GKTGJItTt7y0mcvbeJMn+76Ok5w9A x4FnNyUjPQMWsJey2GI8LEV73P3jmOVfrb32SpvJWrC2tmLIrm8XDBh6ih+lD1DsPTZAUr+69rGQ j6rfPL8To8P4wTbgWg/EDz1kU6TfGOMs4xrPbrLdeMgjHRCqlWrtgGO/8x3+HeUMf0ZRRQUmoslj cZmeNRotYVX2PEuIqyMHs38anuXz2bNzpCMSJ3m9LQfcjluM4ce99FF46RlW6aOTaHXyipCmpTl5 eyaxKtjAMM6EiWxpxKIGJLnloycNLnoWTrXDwd1e6HFo187YzSdon4sv/uWNp8fuH/Xqyc5ztgSL NlB1V4wO6LKvtOKT6U/GfrS1Y/gwA/2NAB/syIB+OdL1nHxV5iqFWvVt9fOkH1UxEEkEXTkdhE9I dDhtdkuxwUoSwgbZbkgEMVntAc3mC3qzH2IEFOjRFr2cw8ScR6chhg2MdvCvndO9kTAOGjHB7WeY 4Be8rYhb9WYSn5jYinjkhMaeNtJLUjLlkmlibyGJc/SmyY47MAFetibUwlwgXnobrSy+g1YO/SdC oT9fr6af3UEnD9d/JfwOeOACnbwS6V/iGuKqNfFLkrYJ25RdJhacedl2MuGMEVkfNB9ywuVI8Fgt AZM7oQcsLs6PIXKEOaPnWVfxNBM1+QLWZ3OkIoYKyW3vZDPnbsXOwVLZIDGGw8SAjhLNvUm83Ybg jZJu560YJSOIJlFNyCRJmugA6ZhAOkmyn41aFo3brrfjSDqL44CP2G2ukK7ltgeX1gO3QsE//vrk jyuXXln315/rYiM3V+w/HfVy2Y9Nm76998R11L3lKerbFDsX+6zZrNfL76fP+x9/bnucRp6HXFmK pFY3qYgkqRrVjJopaAya2mkl2hDtZeWYokoyNVmckC41kWQXZKGlgUJgoQs0kOAwOpycc4CXa+nR rmh16PE7zJRkUZ44PbCSnkXAGCISk9vmsbjzLVxPgpSBDNxy7dqYU3sefuxP00qX9qWHYsV8xYY2 X3601L83t+va6p4b6phDFDgOWyMC+ZGCLP7rkfQdzc7J3yT/IguPC6+q1e531M+zf1K/T/4+8H0Q 9jNYXwu+WHHU1N+I5HkSvHxiahgrPVoYU5tbi9OZIGkBxE8MJ1hTUgOOCVZfrre4eRz/c+7A/7jE jBMAzJJLOgHo+I/u6n3rAIbYOiMrKeR0CWowFAglh3hJSc8SmrciSa6UTOp0ZKjNM0mm2KIVCTkT M0kzOT1Tz5vV02azsjIX4RcXK9lwT7SkLXoL2Vy4N20ZvoNMmDe6CZ3k2TRkFN3KTGvXHv6n/w/d WG3NYmdPvv1+/28nD1mfk5Pyn8io7mLsmwcja/eMP9xuULu8vCXTYLr8JnuoHgssBK9xkzWR3GMy RlpyBBQ+wU2Jo6Mkuy0GRkFm8zTjKiNn9Hk5d4DmgI96PY3cs1G8QF7qrAXJCUXQSXRKSQBPMqqI QvOSLR1xzVbASwfECggjs2GMMM6iS3D0Fp1iQm/iShD420Sv7q5nOJbAEoHggUCkkOU32DbUDvif 6SM2Bbz22sCgVqO+7iX1i/oXPTGyuO19tdFV3JJnx3WtXR7V4xQc2Qz15k3Qhoz1JoURh+28EZpW usBLkpguE4NyHk7xn5EXckEMcBeI11lxQpcLfc9Fz12J3tKs9CUPuq2MSCBtyJyHnEunH8VO0su0 ffTy3ekZd9+dkX43f3RDXeEG8XJRYSH+Cxm+74m15PfraxGSyAMRl8FC37ReEC9YeC/co7z/vIsq MINqIgajQeLDmtV+Hsk/P+OrAcToC9Aa6jigZ34nHzlIhzYmLn/Doh99kdDfEOdBAvi/BXoyWaAH C2YYK4L/bLqD5fo0xnk0ptTc3pU9GyeVPdwrls6teey17ffRJUMyMoYwiPX+c8suTx/h79lQlxk7 92W5fPRW14ALbPXUDuCQgRyILJSlYdIckV8sPik+KT0vPi+dFi+K1yTlU+kjhXtLouvFpyTuU+lb CSKtUtwt71YOSa/Kb8N0rpORPmOQOZfolNZIcGoKshywK2BciBCJZ+0CL6g8ZLEoSBx4lgJ104Dv PBhMHK/yhgBlqoLJmPPO35GS4S6waSwm5IZSzJzz+TlvyogGaSo8Ndgp8Egg4kCmz0DO2fQZjUGh ELW9W8t5r0UvcOn1JPo1dBEDJ0ZvRndyw6I7dV1kLnDp7+irTLpFQnAXAI1IHI2APvwFIogB2h8r tf/BYlWIpnTc+0lcyWDEof2g/XALn6Cf62m1LLBM/xqr5hRaJlZvvNEXDLJxrch85HmcjUxj+e/+ FH+4Bd9CaJHSIjxGHqOMsY7RJvkm+SeFJ6XOkmcps6yztPm++f754fmpjyK35lHro9pqebWy2rpa 2y5vV/b49oSP+I6E3/V96fved8N3I5yV6jfwQlqoo+TpaLFAOkhpSUmJiQ4DUm1fjph62oJ2GrHT qdDHa+jp6sSeSey8uafqDybSSCKdmkgTWUVPLg0VL/cEU0jve5CWxtGThUgK5lwtmz69oGBOdA4w FUdzoh70X7cbsYN7HllMLIeJTYBO5klIPWepS7eROogemgNovsfWvou73zU6VDamS8+xW02prjb3 FW7s6M6b3VYoqydb5z80u2DsQ33mHajbz928pzh1S010LXdjTZvqZdEH4jISA4u13Ex/WNnI62xe hXe6bOB0yBc3GcymANKKpqmrsLrL5+ZcDbwu4b/zOtBcA6/TZE1Bvosmm1tRi2qLc7msBi5ndwii Q7D1Fu2iszdxOO/kcgT9hxNWz3q8rec6kxv9XJcGFieUXVn0xIQXrv8bfxsKfXFOQ37drsjQddzT wtPKOoNwnB7njgvHxRPyCeWE4YTxhPmE5YR2wnbcgWShhOPuS/SSHliqo3Xiv+R/GT2IF4Ul2RQm Rmv2NCw0QcgoexpPETXqN+52VbkhtVBn8fG4EbZUV4qtmSxulMniRpksbpTJ4kaQmgI2zIevb/Rl JWIKYTmIrZGMTTL0tHnMMmwpbtzl2Fc0ePknGox99dPaqqq166qqQFT19bRfrLq+PrZ3w4W3T164 cPLtC8x2Qrzl9+g705WPRe7ajzyPU9xHSWAtizx7PB94vhd/kL9x35QVWE+Jca05McHh9FqhNUNb lm0SNGejZvHGDaig3RrQtBzbMzbO5g38ZkHFHZrxsAfTnf+b6sy0Zsr0Z8q0Zl1/Ro915tuACY2q s8hUZ3Kn6qwn8+l0cMuEAjr8322oWD/JGmt2mxXF9K1+ur7FbMyaSPGT8nb3edgVQiX0LdgViYKR aVl+GBbMwHT5jTaPtZiZljKsTKPN4rBhXKy+gCeuViXfoVb95uuF7L9dq9IxpMG+ZKYlYUambloS ZmQ2GZpG+1Jg9iVWef3v6tL/2aq4/jNfeYf+cwM8IQL8sSETKgvKjxlLLI1mgyJxBgPhzGAMnEQg lANIVfA5OBvEjNd+JG44Nmg+DTklwAomZwD415XJuBJosQqiVTD3Fi2i1ptYtdtJv5Hu3dCm40zu Ru3QrysrKvbl+Me/NQIUX/l4IDalXtm2LXqfLn92gtbboL3N6bDIXi4lh+TQHC6neSe1k6FdcrvA mBSsXU+933q/NjM0M2VmeGbqasfTGbszau01jv3NP1I/MpxXsRpNvWJIZkKTLYhUk1SslqHWBKvb h4W1zRKauQuwLLY4WBz6PRkcHByaTCYYJ5gnWCZYKwIVwXlkrpGlu861zHXP9cwOzA5WYsnsHnIw eDB03PyJ6RNzem8lJWAxCF7BYjMEElNk9+YRCbO9YacMPSYxYhCIEG5mdL/cA363AwemYTWcLwuC 5EDEmGOjtgnEm9nyxbgCpqfmMxVnzjnIDZghyEVCNIYylxzzyd0yXNv4MkSHz5GYS8QMOZciPzqX JltR9Nu9uVRKF3KJkmrAitUU1ZCkBXJJcsBq0T08+qaRLbF4NlvGkwxWjFRaZDxy6RnxVZL6Ogiw J3dCgGJ9HlL/wyk7p90YumJ+UtLMyKL327X/+Kd9z9Q8N2dxx/xFC14sKfnHL590erNXp993zw4G c3x5dxV3H1VZ3WZX10GFBampOS2Levee+qdDcblUjjntIh6Ff2N+xFFJlohPk7XiC0REog/vUROQ yZH/skFT061I8XkyYkhA1ItMCMLGq6GPRaxme8AkXwiwdYHefo0eDZZ0dKWMLffU1/syJ9kt1dDl RA6QS7C3Ig4poVWjathgjCAxXE8Bimefxa1Tocsjc9rPPjqare6rpT/HrJFJvZaszW7vGl6F5OUN 9GiscEOsy5KpbYbE+7MS/WmNbwu5yBORNiflzx1cIGKTdElrAl1B2hpdHL5udgR6js9tMgeMBkOO +hAczrzqTWiY/LK4PcFU3AYCA98t+E3WslASk7WEydrGRCbdmdcoawUma2lTWYs4Zlum9rKONgSZ 2rW3Ca1rh39x76itEcja3FFf9xbKbm79pbJywu5r3LToXFgTB1dwy5hepseW0DeJbIs0X8iv4p/h L/I3eLEHN5QbT8eJO6EDfiNeI1dFVRFVOHPhcEbGTP3ySDMoikEoriSARBSOrVpkB7BC4KnGR10k sBnEeAVJrKURwtNIBAnhGtahV1EBqzcXPqm73/UA0qX/JXwERaQxGBnSne+I1sX879CH6JLamFso q1vOz7q5NT5XWCot1KA/DsRhNzWuyxdkgmxJq2r3Grxmvz1dbW5uZsk39zYjAovcgsnG8abZWPT6 ABjBYrKYrpfWWd+0Ytmd9A3C3tfF69Kvll+tKfgcm7WEK+E/MXxqPG2SBRsSFMwmuLqNJoQlHBYz 9HdNFTSbJKtmi0AcU00PYaXOOUvAPE0OSNNSTdQR6DEVHzziyDnqxOLoMiQW1UWjlzzRsjibZZzW m5PTOQfsAao+tH7dlaXHYfUYjB6CwaYhAnPywIsTE/3Vz58IuyetfPnPn6SIgVqhLDps82a2cI1t b27l3tu8KZrL5prlbG3C2BgRR1zBuC+vNBObS83lTCVfHos89nHCTH6msJ7bxe0SX5BekGvEQ9JB +YT4mfit8Vf5qtEXFtuK47ix4mPco+IO8VPugqL+t7BMAO5/FpYJ/BaWkeJhGSTQxcMyiMW8pMdi GrTshnAMW7n0v0djmG5xRzDG+il9JTb2R0QW/R/G5tN3f4rtwVejnLHH6X3RWHQ7fZX1mARjLYUX MQZ28nFk1eP4ANQL5FNewKcTSsnjpJJfLjwuPm5fT9bzT0pPyi/we4QXxBr+oHBQPCGcEM8IZ0SX CgVSJwI2gDxntwsmu6WBDoiGJCykSQSwdhereAlvbyAGuwGuW6sd/UaCPy0S+4sjxKniSlEUfU4T lpYj+6xvnCLOleXfikj1ZSyCcXQWomfJWBYk5DcmAMZzIOAIw1ouPbDK7L+ytEYCYcsBddO4PRJ7 6t5FOvKwQ7H+j/96bEi3viXDl8/yZAu5yP0tufnP2CufWbd5Sqq7sPFB7ARfhypDPGdExLGLe4tj Kw5gtv4Wy6lBLEdiMaYaFssxxGM5xSyWU4xYDvPOwjn7f4rlLOZejI7mV0f7cSd2swUqdd/psRzO VX+Kq2HhdD2W8yHexCehjV5h+Uf6Sxr5KBbXgPVxrq1YBX8dH5Zg/gn9V7+P+YP+ww+p8XiqAZRg avL1Dhfys+78akcQPr3//rWOVv/1Gx1d/+3LHL8jffF90f5kALkL3+UYhG+gsS+qDSXDgHzDye/J H/DNkRFoGQV2gq/iJ2FFLOlfPKR0aGlW36n3jhw9ldU2/GgBCj0BwwDjAfcDkD5I1wNg3dMawFuA zwAXANcwMArAA2gG6ADoCRgGGA+4H7AUsB6wE1ADeAvwGeAC4BoGTQF4AM0AHQA9AcMA4wH3A5YC 1gN2AmoAbwE+A1wAXANuKQAPoBmgA6AnYBhgPOB+wFLAesBOQA3gLcBngAuAa/j4igLwAJoBOgB6 AoYBxgPuBywFrAfsBNQA3gJ8BrgAuFbf8GMDeOsYPKFJWU+Rvq2+WZP65k3KWU3KLZqUs5uUWzYp s69e3N4eMOs7yuxLMLfXs8jr7eW8JmXEm++ob9ukjKDMHfXtm5Q7NCnnNyl3bFLu3KRc1KQMxnLH +7o2KXdrUu7epFzcpFzSpIwcijue37NJuVeTcu8m5T5Nyvr3c26bf8Ytbh/vfk3K/ZuUBzQp39Wk PLBJeVCTMhaj3fE+XQ29rT13N6kf2qQ8rEm5tEl5eJMy4zm3929kk/KoJuXRTcpjmpQrmpTHNimP a1Ie36Q8oUl5YpPypCblyU3KU5qU721SBhO9o7/TmpSnNynPaFKe2aQ8q0lZd9PfNl9zmtQzy/f2 8b6/SRk+2TvqkWNxR3k+K/8/TWdbMgplbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2JqCjE2NjMxCmVu ZG9iagozOSAwIG9iagooZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1hbGdzLWV4YW1wbGVzLXY0KQpl bmRvYmoKNDAgMCBvYmoKKE1hYyBPUyBYIDEwLjExLjYgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9i ago0MSAwIG9iagooVGV4dEVkaXQpCmVuZG9iago0MiAwIG9iagooRDoyMDE3MDIxNzIzNTUzMVow MCcwMCcpCmVuZG9iago0MyAwIG9iagooKQplbmRvYmoKNDQgMCBvYmoKWyBdCmVuZG9iagoxIDAg b2JqCjw8IC9UaXRsZSAzOSAwIFIgL1Byb2R1Y2VyIDQwIDAgUiAvQ3JlYXRvciA0MSAwIFIgL0Ny ZWF0aW9uRGF0ZSA0MiAwIFIgL01vZERhdGUKNDIgMCBSIC9LZXl3b3JkcyA0MyAwIFIgL0FBUEw6 S2V5d29yZHMgNDQgMCBSID4+CmVuZG9iagp4cmVmCjAgNDUKMDAwMDAwMDAwMCA2NTUzNSBmIAow MDAwMDMyMjU4IDAwMDAwIG4gCjAwMDAwMDE4NzggMDAwMDAgbiAKMDAwMDAxNDM3MCAwMDAwMCBu IAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDE4NTggMDAwMDAgbiAKMDAwMDAwMTk4MiAwMDAw MCBuIAowMDAwMDAzMzE5IDAwMDAwIG4gCjAwMDAwMTQ1NDUgMDAwMDAgbiAKMDAwMDAwMjA3OSAw MDAwMCBuIAowMDAwMDAzMjk4IDAwMDAwIG4gCjAwMDAwMDU0ODggMDAwMDAgbiAKMDAwMDAwMzM1 NCAwMDAwMCBuIAowMDAwMDA1NDY3IDAwMDAwIG4gCjAwMDAwMDU1OTUgMDAwMDAgbiAKMDAwMDAw Nzc0MSAwMDAwMCBuIAowMDAwMDA1NjkzIDAwMDAwIG4gCjAwMDAwMDc3MjAgMDAwMDAgbiAKMDAw MDAwNzg0OCAwMDAwMCBuIAowMDAwMDA5NzIwIDAwMDAwIG4gCjAwMDAwMDc5NDYgMDAwMDAgbiAK MDAwMDAwOTY5OSAwMDAwMCBuIAowMDAwMDA5ODI3IDAwMDAwIG4gCjAwMDAwMTE3MTYgMDAwMDAg biAKMDAwMDAwOTkyNSAwMDAwMCBuIAowMDAwMDExNjk1IDAwMDAwIG4gCjAwMDAwMTE4MjMgMDAw MDAgbiAKMDAwMDAxMzcyNSAwMDAwMCBuIAowMDAwMDExOTIxIDAwMDAwIG4gCjAwMDAwMTM3MDQg MDAwMDAgbiAKMDAwMDAxMzgzMiAwMDAwMCBuIAowMDAwMDE0MTY1IDAwMDAwIG4gCjAwMDAwMTM5 MzAgMDAwMDAgbiAKMDAwMDAxNDE0NSAwMDAwMCBuIAowMDAwMDE0MjcyIDAwMDAwIG4gCjAwMDAw MTQ0OTUgMDAwMDAgbiAKMDAwMDAxNTA1MSAwMDAwMCBuIAowMDAwMDE1Mjk1IDAwMDAwIG4gCjAw MDAwMzIwMTcgMDAwMDAgbiAKMDAwMDAzMjAzOSAwMDAwMCBuIAowMDAwMDMyMDk3IDAwMDAwIG4g CjAwMDAwMzIxNTAgMDAwMDAgbiAKMDAwMDAzMjE3NyAwMDAwMCBuIAowMDAwMDMyMjE5IDAwMDAw IG4gCjAwMDAwMzIyMzggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA0NSAvUm9vdCAzNSAwIFIg L0luZm8gMSAwIFIgL0lEIFsgPGIzNGNkZGUyOWMyOWFkYTBhNTg0ZmMxNmUxNjVhOThhPgo8YjM0 Y2RkZTI5YzI5YWRhMGE1ODRmYzE2ZTE2NWE5OGE+IF0gPj4Kc3RhcnR4cmVmCjMyNDAyCiUlRU9G Cg== --_003_845A415CD4694899B7B00DAF728D667Fnistgov_-- From nobody Wed Feb 22 01:01:07 2017 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 291BB1293DF for ; Wed, 22 Feb 2017 01:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 kGXuAoLVGoqu for ; Wed, 22 Feb 2017 01:00:59 -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 0954E129698 for ; Wed, 22 Feb 2017 01:00:56 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cgSn7-0000zk-Fy for sidr@ietf.org; Wed, 22 Feb 2017 10:00:54 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-215.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cgSn7-00040S-89; Wed, 22 Feb 2017 10:00:53 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_673E19B3-BC17-4611-844B-C014EE0F9659" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Tim Bruijnzeels In-Reply-To: <91A5C164-0684-45D2-A608-08AD2DFB1BA1@zdns.cn> Date: Wed, 22 Feb 2017 10:00:52 +0100 Message-Id: <53CB59D4-06B2-4FBA-9AA0-ED9AFA5F533D@ripe.net> References: <148686781128.10932.14298689350848508409.idtracker@ietfa.amsl.com> <91A5C164-0684-45D2-A608-08AD2DFB1BA1@zdns.cn> To: sidr wg list X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719968ee58f9c12831a98a75a7fecf58ee8 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-slurm-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 09:01:03 -0000 --Apple-Mail=_673E19B3-BC17-4611-844B-C014EE0F9659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi WG, Rob A. in particular :) Can you please have a look at this version? If we don't hear any = objections we plan to ask for WG LC one week from today. See below for some small things that I already shared with co-authors = and that are in our edit buffer. Just repeating here to save double = work. Cheers Tim --- @3.2: current: o One or more slurmTarget (Section 3.3) lines: * In this version of SLURM, there are two types of values for the target: ASN or FQDN. If more than one target line is present, all targets must be acceptable to the RP. I believe this is somewhat unclear and incorrect for json. I think we = should say instead: o A slurmTarget element (Section 3.3), consisting of: * Zero or more target elements. In this version of SLURM, there = are two types of values for the target: ASN or FQDN. If more than = one target line is present, all targets must be acceptable to the = RP. So there has to be a slurmTarget:" element in the file, but it can have = an empty list as its value. Which would mean "applies to all". @3.3: There is no 'header'. So I think we should say that "slurmTarget:" can = have zero or more elements. To be overly complete (if you want), we could give four examples: empty: "slurmTarget": [] asn only: "slurmTarget": [ { "asn": 65536 } ] hostname only: "slurmTarget": [ { "hostname": "rpki.example.com " } ] both: "slurmTarget": [ { "asn": 65536 }, { "hostname": "rpki.example.com " } ] @3.4.1: The grammar in the text that I provided for the numbered list seems in = need of a little love.. So, rather than: 1. A Prefix Filter contains an IPv4 or IPv6 Prefix only, a VRP is considered to match the filter if the VRP Prefix is equal to or subsumed by the Prefix Filter. maybe: 1. A Prefix Filter contains an IPv4 or IPv6 Prefix only and a VRP has a VRP Prefix that is equal to or subsumed by the Prefix = Filter. and similar in other places.. but we can also leave it to the RFC editor = to fix this. > On 13 Feb 2017, at 04:02, Declan Ma wrote: >=20 > Hi, all, >=20 > We authors just updated the SLURM by adding a new ingredient JSON, = offered by Tim, to describe the SLURM configuration file format.=20 >=20 > Looking forwards to seeing your reviews and comments. >=20 > Thanks very much indeed. >=20 > Di=20 >=20 > ZDNS >=20 >> =E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84=E9=82=AE= =E4=BB=B6=EF=BC=9A >>=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = >> =E4=B8=BB=E9=A2=98: [sidr] I-D Action: draft-ietf-sidr-slurm-03.txt >> =E6=97=A5=E6=9C=9F: 2017=E5=B9=B42=E6=9C=8812=E6=97=A5 GMT+8 10:50:11 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: > >> =E6=8A=84=E9=80=81: sidr@ietf.org >>=20 >>=20 >> 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 of the = IETF. >>=20 >> Title : Simplified Local internet nUmber Resource = Management with the RPKI >> Authors : David Mandelberg >> Di Ma >> Tim Bruijnzeels >> Filename : draft-ietf-sidr-slurm-03.txt >> Pages : 17 >> Date : 2017-02-11 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ = >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-slurm-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-slurm-03 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_673E19B3-BC17-4611-844B-C014EE0F9659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi WG, Rob A. in particular :)

Can you please have a look at this = version? If we don't hear any objections we plan to ask for WG LC one = week from today.

See below for some small things that I already shared with = co-authors and that are in our edit buffer. Just repeating here to save = double work.

Cheers
Tim


---

@3.2:

current:

  o  One or more slurmTarget (Section 3.3) = lines:

     * =  In this version of SLURM, there are two types of values for the
        target: ASN = or FQDN.  If more than one target line is present,
        all targets = must be acceptable to the RP.


I believe this is somewhat unclear and incorrect for json. I = think we should say instead:

  o =  A slurmTarget element (Section 3.3), consisting of:

     *  Zero or = more target elements. In this version of SLURM, there are
        two types of = values for the target: ASN or FQDN.  If more than one
        target line = is present, all targets must be acceptable to the RP.


So there has to be a slurmTarget:" element in = the file, but it can have an empty list as its value. Which would mean = "applies to all".



@3.3:

There is no 'header'. So I = think we should say that "slurmTarget:" can have zero or more = elements.

To be overly complete (if you = want), we could give four examples:

empty:
"slurmTarget": []

asn only:

 "slurmTarget": = [
      {
        "asn": = 65536
      }
    ]

hostname= only:

 "slurmTarget": [
      {
        "hostname": = "rpki.example.com"
      }
    ]

both:
 "slurmTarget": [
      {
        "asn": = 65536
      },
      {
        "hostname": = "rpki.example.com"
      }
    ]


@3.4.1:

The grammar in the text = that I provided for the numbered list seems in need of a little = love..

So, rather than:

  1.  A Prefix Filter contains an IPv4 or IPv6 = Prefix only, a VRP is
      considered to match the = filter if the VRP Prefix is equal to or
      subsumed by the Prefix = Filter.

maybe:

  1.  A Prefix Filter contains an IPv4 or IPv6 = Prefix only and a VRP
      has a VRP Prefix that is = equal to or subsumed by the Prefix Filter.

and similar in other places.. but we can also leave it to the = RFC editor to fix this.





On = 13 Feb 2017, at 04:02, Declan Ma <madi@zdns.cn> wrote:

Hi, all,

We authors just updated the SLURM by adding a = new ingredient JSON, offered by Tim,  to describe the SLURM = configuration file format. 

Looking forwards to seeing your reviews and = comments.

Thanks very much indeed.

Di 

ZDNS

=E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84= =E9=82=AE=E4=BB=B6=EF=BC=9A

=E5=8F=91=E4=BB=B6=E4=BA=BA: = internet-drafts@ietf.org
=E4=B8=BB=E9=A2=98: [sidr] I-D Action: = draft-ietf-sidr-slurm-03.txt
=E6=97=A5=E6=9C=9F: 2017=E5=B9=B42=E6=9C=8812=E6=97=A5 GMT+8 = 10:50:11
=E6=94=B6=E4=BB=B6=E4=BA=BA: = <i-d-announce@ietf.org>
=E6=8A=84=E9=80=81: sidr@ietf.org


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 of the IETF.

=        Title =           : Simplified = Local internet nUmber Resource Management with the RPKI
=        Authors =         : David Mandelberg
=             &n= bsp;           &nbs= p;Di Ma
=             &n= bsp;           &nbs= p;Tim Bruijnzeels
Filename =        : = draft-ietf-sidr-slurm-03.txt
Pages =           : 17
= Date =            : = 2017-02-11

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's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-sidr-slurm-03

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-slurm-03

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/

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail=_673E19B3-BC17-4611-844B-C014EE0F9659-- From nobody Wed Feb 22 11:22:38 2017 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 760DF129A82; Wed, 22 Feb 2017 11:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779135747.31127.6830646730119021109.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 11:22:37 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-publication-11: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 19:22:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-publication-11: 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-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Wed Feb 22 11:25:25 2017 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 A4A09129A9A; Wed, 22 Feb 2017 11:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=MyuHM2gp; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=OXqQ5m5E 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 KPmwWcNzto5t; Wed, 22 Feb 2017 11:25:14 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D39129531; Wed, 22 Feb 2017 11:25:14 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D2FD4225C1; Wed, 22 Feb 2017 14:25:13 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 22 Feb 2017 14:25:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=DFfx2NPiDb5vRUZ HcXLXD3qq+e0=; b=MyuHM2gpVcEae98DJM75XYW+/vsb9Dk83xNqPKMRfc/lFY3 aswpk5cMNVwVCspRvt9yfdxThat23wm7hIGxezKsEPmaOXYaz8mgMV5lP2hJ8+9h 1zJHubcAXElhxLfyVIdojtx3XopCwqB6QQzBJVrX5Wp2b9bWzPA836psMs1o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=DFfx2NPiDb5vRUZHcXLXD3qq+e0=; b=OXqQ5m5EvkvHVQvzZf3l zA5e2jq3g20wkXTzn+B0K+/KjouhrmrbBIJjkAXJOJin0EcUG5gGniucfnKjJJu/ +fUVOJAF2Bo/XzzhUD0kym8XP4irJJAMrTPwrCLTG0VLIRIBwKO+p36iNd8RX+NA kMnPFB+diATOrBA4C+sPRKo= X-ME-Sender: X-Sasl-enc: 9WcsziDkuyo/yAPRH4CQNLsnBBCJ7TM2Xc/hrBfJNqYw 1487791513 Received: from dhcp-10-150-9-191.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 64EAC7E0D1; Wed, 22 Feb 2017 14:25:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170209231225.802F2468503F@minas-ithil.hactrn.net> Date: Wed, 22 Feb 2017 14:25:12 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6B4349F8-F5CD-4E90-8706-831FB6BB5D72@cooperw.in> References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> <20170209231225.802F2468503F@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , IESG , "sidr@ietf.org" , "draft-ietf-sidr-rpki-oob-setup@ietf.org" Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 19:25:20 -0000 > On Feb 9, 2017, at 6:12 PM, Rob Austein wrote: > > Sorry, missed this part: > > At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> (2) If there is in fact supposed to be a protocol specified here, I have >>>> the same question as I had on draft-ietf-sidr-publication, which is how >>>> do the entities migrate from one version to another and do version >>>> negotiation? > > Essentially the same answer as for draft-ietf-sidr-publication, so > will include some variation of same text if that's acceptable. That would do the trick. Thanks. Alissa From nobody Wed Feb 22 12:50:18 2017 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 228AE129B13; Wed, 22 Feb 2017 12:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Vp9LnT9gl7xO; Wed, 22 Feb 2017 12:50:10 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C6A129A66; Wed, 22 Feb 2017 12:50:10 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-30-72-201.hsd1.pa.comcast.net [73.30.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id E34D0139A2; Wed, 22 Feb 2017 20:50:08 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 4885347B558D; Wed, 22 Feb 2017 15:50:12 -0500 (EST) Date: Wed, 22 Feb 2017 15:50:12 -0500 From: Rob Austein To: Alissa Cooper In-Reply-To: <6B4349F8-F5CD-4E90-8706-831FB6BB5D72@cooperw.in> References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> <20170209231225.802F2468503F@minas-ithil.hactrn.net> <6B4349F8-F5CD-4E90-8706-831FB6BB5D72@cooperw.in> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170222205012.4885347B558D@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , "sidr-chairs@ietf.org" , IESG , "sidr@ietf.org" , "draft-ietf-sidr-rpki-oob-setup@ietf.org" Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:50:14 -0000 At Wed, 22 Feb 2017 14:25:12 -0500, Alissa Cooper wrote: > > On Feb 9, 2017, at 6:12 PM, Rob Austein wrote: > > > > Sorry, missed this part: > > > > At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: > >>>> ---------------------------------------------------------------------- > >>>> DISCUSS: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> (2) If there is in fact supposed to be a protocol specified here, I have > >>>> the same question as I had on draft-ietf-sidr-publication, which is how > >>>> do the entities migrate from one version to another and do version > >>>> negotiation? > > > > Essentially the same answer as for draft-ietf-sidr-publication, so > > will include some variation of same text if that's acceptable. > > That would do the trick. Thanks. Whoops, then I went and lost having promised to fix this in -07 just like I missed the original issue the first time. Consistency is not always a good thing. Sigh. Sorry. Since this was a DISCUSS rather than just a COMMENT I'm assuming that there will be no objection to uploading a -08 now with the fix, so I will do that immediately after posting this. From nobody Wed Feb 22 12:52:56 2017 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 7167D129B24; Wed, 22 Feb 2017 12:52:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779677445.31075.4215977737600371897.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 12:52:54 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:52:54 -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 of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-08.txt Pages : 22 Date : 2017-02-22 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-08 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 Wed Feb 22 13:28:36 2017 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 6FE52129B7A; Wed, 22 Feb 2017 13:28:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779891245.31095.471497857432449461.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 13:28:32 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-rpki-oob-setup-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:28:32 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-08: 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-oob-setup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points, keeping COMMENTs below for posterity. 5.2.4: Per my comment on draft-ietf-sidr-publication, it would be good if service_uri accommodated either HTTPS or HTTP URLs, if HTTP URLs must be supported. 5.4: If it becomes obvious that a new reason code needs to be added to the element in the future, will that require a new version of the protocol? That seems like a bit of a heavy lift as compared to, say, creating a registry for these with an appropriate registration policy. From nobody Wed Feb 22 16:11:57 2017 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 8E5ED129445; Wed, 22 Feb 2017 16:11:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148780871657.31115.11311370013231718833.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 16:11:56 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-publication-11: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:11:56 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-publication-11: 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-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss about alg agility. From nobody Wed Feb 22 19:44:38 2017 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 C58FF12953F; Wed, 22 Feb 2017 19:44:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148782147780.31159.4968870466915501416.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 19:44:37 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 03:44:38 -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 of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-09.txt Pages : 22 Date : 2017-02-22 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-09 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 Thu Feb 23 12:25:11 2017 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 7CBAD12A2AD; Thu, 23 Feb 2017 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 z6U2D6Co4G3b; Thu, 23 Feb 2017 12:25:09 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F8712A1CF; Thu, 23 Feb 2017 12:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7186; q=dns/txt; s=iport; t=1487881509; x=1489091109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K2wbDrCjnv4w0Njgu261GzLXPZgOJnAgYUcSIj7BhLE=; b=h0bwwQJwOKeqqg4K5QMK8NDwp/khVgGbcsZ2/jCJkyIb3WK8vnvvQmZH 96HYlaw77iDr4Z2YH/SgOp9Hln6AvxtjjL/mrCFrU94QqARiO/VvNRDIC ybmYgrdy4AK1FhBKDlhj6kW/YVqHFAFXNkuKw/yLX4LEXr3k3r+MzQzRX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAQB4RK9Y/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYYEJB4NUigiRXJAIgx2CD4INhiICGoMJPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRxAQQBI1YFCwIBCD8DAgICMBQRAgQBDQWJbQiuHIImK4sYAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZMggWCaodaLoIxBZVphisBkiOBe4UciXqTJwEfOIEAVBU?= =?us-ascii?q?+EQGEb4FIdYo5gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208,217";a="388246150" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 20:25:08 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1NKP7Oa005364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 20:25:08 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 14:25:07 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 14:25:07 -0600 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels , "sidr-chairs@ietf.org" , "morrowc@ops-netman.net" , "sandy@tislabs.com" Thread-Topic: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) Thread-Index: AQHSh/jZg3PcEJPtD0S+zGbVhzl8aqFsJDuAgAE4rICACcnBAA== Date: Thu, 23 Feb 2017 20:25:07 +0000 Message-ID: References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> In-Reply-To: <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_A3DDD124EBE642ACB66F532AF0A5E175ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , "sidr@ietf.org" , The IESG Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:25:10 -0000 --_000_A3DDD124EBE642ACB66F532AF0A5E175ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltOg0KDQpIaSENCg0KR2l2ZW4gdGhlIGZlZWRiYWNrIHNvIGZhciBvbiB0aGUgbGlzdCwgSSB0 aGluayB3ZSBzaG91bGQgcm9sbCBiYWNrIHRoZSB1cGRhdGVzIGluIHByZXBhcmF0aW9uIGZvciBu ZXh0IHdlZWvigJlzIElFU0cgVGVsZWNoYXQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQpPbiAy LzE3LzE3LCA5OjU2IEFNLCAic2lkciBvbiBiZWhhbGYgb2YgQWx2YXJvIFJldGFuYSAoYXJldGFu YSkiIDxzaWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIGFyZXRhbmFAY2lzY28uY29tPG1haWx0bzphcmV0YW5hQGNpc2NvLmNvbT4+ IHdyb3RlOg0KDQo+ICoqQ2hhaXJzKio6ICBHaXZlbiB0aGF0IHRoaXMgaXMgYSBzaWduaWZpY2Fu dCBjaGFuZ2UsIGFuZCB0aGF0IHRoZSBXRyBtYXkgaGF2ZSBub3QgYmVlbg0KPiBmb2N1c2VkIG9u IHRoZSBkaXNjdXNzaW9uLCBhbmQgdGhhdCB3ZSBub3cgaGF2ZSBhIGxpdHRsZSBtb3JlIHRpbWUg Z2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUNCj4gSUVTRyByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB3 YXMgZGVmZXJyZWQgdW50aWwgTWFyLzLigKYgIFBsZWFzZSBleHBsaWNpdGx5IGFzayB0aGUgV0cg dG8NCj4gcmV2aWV3IHRoZSBVcGRhdGVzIHRvIFJGQzY0ODAsIFJGQzY0ODEgYW5kIFJGQzc3MzAu ICBJIHRoaW5rIHRoYXQgYSB3ZWVrIG9mIGRpc2N1c3Npb24NCj4gb24gdGhlIGxpc3Qgc2hvdWxk IGJlIGVub3VnaC4NCg0KDQo= --_000_A3DDD124EBE642ACB66F532AF0A5E175ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8B1192555224604EAD4E2EA53792AD57@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaW06 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ R2l2ZW4gdGhlIGZlZWRiYWNrIHNvIGZhciBvbiB0aGUgbGlzdCwgSSB0aGluayB3ZSBzaG91bGQg cm9sbCBiYWNrIHRoZSB1cGRhdGVzIGluIHByZXBhcmF0aW9uIGZvciBuZXh0IHdlZWvigJlzIElF U0cgVGVsZWNoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDIvMTcvMTcsIDk6NTYgQU0sICZxdW90O3NpZHIgb24gYmVoYWxmIG9m IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lkci1i b3VuY2VzQGlldGYub3JnIj5zaWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0K PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mZ3Q7ICoqQ2hhaXJzKio6Jm5ic3A7IEdpdmVu IHRoYXQgdGhpcyBpcyBhIHNpZ25pZmljYW50IGNoYW5nZSwgYW5kIHRoYXQgdGhlIFdHIG1heSBo YXZlIG5vdCBiZWVuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj4mZ3Q7IGZvY3VzZWQgb24gdGhlIGRpc2N1c3Npb24sIGFuZCB0aGF0IHdlIG5vdyBo YXZlIGEgbGl0dGxlIG1vcmUgdGltZSBnaXZlbiB0aGUgZmFjdCB0aGF0IHRoZQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jmd0OyBJRVNHIHJldmll dyBvZiB0aGlzIGRvY3VtZW50IHdhcyBkZWZlcnJlZCB1bnRpbCBNYXIvMuKApiZuYnNwOyBQbGVh c2UgZXhwbGljaXRseSBhc2sgdGhlIFdHIHRvDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mZ3Q7IHJldmlldyB0aGUgVXBkYXRlcyB0byBSRkM2NDgw LCBSRkM2NDgxIGFuZCBSRkM3NzMwLiZuYnNwOyBJIHRoaW5rIHRoYXQgYSB3ZWVrIG9mIGRpc2N1 c3Npb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si PiZndDsgb24gdGhlIGxpc3Qgc2hvdWxkIGJlIGVub3VnaC48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A3DDD124EBE642ACB66F532AF0A5E175ciscocom_-- From nobody Thu Feb 23 12:29:01 2017 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 3649B12A2C0; Thu, 23 Feb 2017 12:28:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148788172321.20288.3622684651748299791.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 12:28:43 -0800 Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1' to Proposed Standard (draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:28:43 -0000 The IESG has approved the following document: - 'The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1' (draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.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-rtr-rfc6810-bis/ Technical Summary In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the rpki-rtr protocol. RFC 6810 describes version 0. Working Group Summary This document adds support for a new PDU to carry router key information, new timing values, and a version negotiation. As it is an update to a protocol currently in use, the working group discussion was focused on the additional features. Document Quality There are three different implementations of the server side of this protocol. Three router vendors have implemented the client side. Four other implementations of the client side are also known. Personnel Document Shepherd: Chris Morrow Responsible Area Director: Alvaro Retana From nobody Thu Feb 23 13:05:34 2017 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 A0C6112A2F0; Thu, 23 Feb 2017 13:05:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148788392865.21154.13185582469519373299.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 13:05:28 -0800 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'An Out-Of-Band Setup Protocol For RPKI Production Services' to Proposed Standard (draft-ietf-sidr-rpki-oob-setup-09.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:05:28 -0000 The IESG has approved the following document: - 'An Out-Of-Band Setup Protocol For RPKI Production Services' (draft-ietf-sidr-rpki-oob-setup-09.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-oob-setup/ Technical Summary This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable secure means. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. Working Group Summary The protocol described in this document grew out of a series of workshops held starting in 2010, at which it became clear that manual configuration of keying material and service URLs was both error prone and unnecessarily confusing. The basic mechanism and semantics have been essentially unchanged since the earliest versions of the protocol, but there were several workshop-driven syntax changes and simplifications before the protocol made its way into the IETF, and a few more simplifications and minor extensions have occurred since that time. Document Quality There is a working implementation. Personnel Shepherd: morrowc@ops-netman.net (Chris Morrow) AD: aretana@cisco.com (Alvaro Retana) From nobody Thu Feb 23 13:26:51 2017 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 56901129984; Thu, 23 Feb 2017 13:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 kbYwHsIqCqR3; Thu, 23 Feb 2017 13:26:49 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3E61297F1; Thu, 23 Feb 2017 13:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2341; q=dns/txt; s=iport; t=1487885209; x=1489094809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sy14eOyoEpaW+aIFz2DP1COn2SLh9no8g/pxq/qQ5OA=; b=KtBSLF/LXl6Xi8Sq9PG8tB1MsG2/f5yR00/PvdNFX94YdPzoZPbEtZw1 FULd+p3XAplXfGN87kphfzQsCScGL5SGLayPYzdcd8gmo56k25qXV2QjH q8lNh1zLGBj/9qBwguwrLSVK8woyD8dWjKQFoqlFgzk3my3ZZOKKWBDWp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQACU69Y/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRXJU0gg0fDYV2AoMlPxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BBAEBODQLDAQCAQgRBAEBHwUEBycLFAkIAgQBDQUIDIlhDrBAi0QBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZMhG+KOQWcFAGGc4snkRqTJwEfOFUrVBU+hQGBSHW?= =?us-ascii?q?JCyuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="389705986" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 21:26:47 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1NLQlFS002161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 21:26:47 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 15:26:47 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 15:26:47 -0600 From: "Jakob Heitz (jheitz)" To: The IESG , IETF-Announce Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8w Date: Thu, 23 Feb 2017 21:26:47 +0000 Message-ID: <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> In-Reply-To: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.178.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "rfc-editor@rfc-editor.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:26:50 -0000 What happens if a BGP speaker validates a route in its own RPKI database and finds it to be either Valid or Invalid (not NotFound) and also receives the extended community that specifies a different validation state? I don't see that condition covered in the draft. I would say to ignore the extended community. Thanks, Jakob. > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, January 11, 2017 7:25 AM > To: IETF-Announce > Cc: draft-ietf-sidr-origin-validation-signaling@ietf.org; sidr@ietf.org; = sidr-chairs@ietf.org; The IESG > ; sandy@tislabs.com; rfc-editor@rfc-editor.org > Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Exte= nded Community' to Proposed Standard > (draft-ietf-sidr-origin-validation-signaling-11.txt) >=20 > The IESG has approved the following document: > - 'BGP Prefix Origin Validation State Extended Community' > (draft-ietf-sidr-origin-validation-signaling-11.txt) as Proposed > Standard >=20 > This document is the product of the Secure Inter-Domain Routing Working > Group. >=20 > The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah > Brungard. >=20 > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signal= ing/ >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document defines a new BGP opaque extended community to carry > the origination AS validation state inside an autonomous system. > IBGP speakers that receive this validation state can configure local > policies allowing it to influence their decision process. >=20 > Working Group Summary >=20 > This document has had consistent interest from the working group. > Because it defines a new BGP community, it was reviewed by the idr > working group as well. >=20 > Document Quality >=20 > The document has been implemented by major router vendors. > It is known to be in use in two large IXPs, AMS-IX and DE-CIX. >=20 > Personnel >=20 > Document Shepherd: Sandra Murphy > Responsible Area Director: Alvaro Retana >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Feb 23 13:55:37 2017 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 AF8341299E3; Thu, 23 Feb 2017 13:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 MjfMl0b14Aux; Thu, 23 Feb 2017 13:55:35 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4ACD1298BF; Thu, 23 Feb 2017 13:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4730; q=dns/txt; s=iport; t=1487886934; x=1489096534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kZ85v4Ws8dpGa7bPV+xQKWRlxhfhNTQscVuh5j7WMnM=; b=CWZqVo/6kumGoNRltC+2DQXGkzrNIbnO1S1XhqEhmk9ax96WZHhvhjKA iatGqVKZtYNIVko+Ewfg5M+QXZ3hz2c4EX/hgGvnRkjFf140HCbCYL7Eq Fmzs4KN/P5dNOgnwe6G7v7zKfWQObFnMIxCZpnPEvvLyW5jpfIstFN0Sd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgATWa9Y/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFclTSCDR8NhXYCGoMLPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQMCHwQDAgICJQsUAQgIAgQBDQUUiWEOriOCJ?= =?us-ascii?q?otEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggWCaodaLoIxBZVphisBhnO?= =?us-ascii?q?LMJERkycBHzhVK1QVPhEBhG+BSHWJCyuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="389625902" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 21:55:33 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1NLtXiO005685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 21:55:33 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 15:55:32 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 15:55:32 -0600 From: "Alvaro Retana (aretana)" To: "Jakob Heitz (jheitz)" , "draft-ietf-sidr-origin-validation-signaling@ietf.org" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQA= Date: Thu, 23 Feb 2017 21:55:32 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <6955BA08428BB74AAB6A725D3F12875E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sandy@tislabs.com" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:55:36 -0000 W1Rvb2sgdGhlIElFU0csIGlldGYtYW5ub3VuY2UgYW5kIHJmYy1lZGl0b3IgbGlzdHMgb2ZmLl0N Cg0KSmFrb2I6DQoNCkhpIQ0KDQpUaGlzIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gQVVUSDQ4LiAg SSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gbWFrZSBhbnkgY2hhbmdlcyB0byB0aGUgZG9jdW1l bnQsIGJ1dCBpZiB3ZSBkbywgd2UgbmVlZCB0byBkZWNpZGUgdmVyeSBzb29uLg0KDQpUaGUgZG9j dW1lbnQgZG9lc27igJl0IHNheSBhbnl0aGluZyBhYm91dCB3aGF0IHNob3VsZCBiZSBkb25lIHdp dGggdGhpcyBleHRlbmRlZCBjb21tdW5pdHksIGV4Y2VwdCB0byBzYXkgdGhhdCDigJxzcGVha2Vy cyB0aGF0IHJlY2VpdmUgdGhpcyB2YWxpZGF0aW9uIHN0YXRlIGNhbiBjb25maWd1cmUgbG9jYWwg cG9saWNpZXMgYWxsb3dpbmcgaXQgdG8gaW5mbHVlbmNlIHRoZWlyIGRlY2lzaW9uIHByb2Nlc3Mu 4oCdICBJT1csIHRoZXJlIGlzIG5vIGV4cGVjdGVkIGRlZmF1bHQgcHJvY2Vzc2luZyBvZiB0aGUg dmFsaWRhdGlvbiBzdGF0ZS4NCg0KSWYgdGhlIGNvbW11bml0eSBpcyByZWNlaXZlZCBhbmQgdGhl IHJvdXRlciBhbHNvIGhhcyB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCB0aGVuIEkgYWdyZWUgdGhh dCB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGlzIG5vdCBuZWVkZWTigKZidXQgSSB0aGluayB0aGF0 IGFjdGlvbiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpUaGFua3Mh DQoNCkFsdmFyby4NCg0KDQoNCg0KT24gMi8yMy8xNywgNDoyNiBQTSwgImllc2cgb24gYmVoYWxm IG9mIEpha29iIEhlaXR6IChqaGVpdHopIiA8aWVzZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBqaGVpdHpAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIFdoYXQgaGFwcGVucyBpZiBhIEJH UCBzcGVha2VyIHZhbGlkYXRlcyBhIHJvdXRlIGluIGl0cyBvd24gUlBLSSBkYXRhYmFzZQ0KICAg IGFuZCBmaW5kcyBpdCB0byBiZSBlaXRoZXIgVmFsaWQgb3IgSW52YWxpZCAobm90IE5vdEZvdW5k KSBhbmQgYWxzbyByZWNlaXZlcw0KICAgIHRoZSBleHRlbmRlZCBjb21tdW5pdHkgdGhhdCBzcGVj aWZpZXMgYSBkaWZmZXJlbnQgdmFsaWRhdGlvbiBzdGF0ZT8NCiAgICANCiAgICBJIGRvbid0IHNl ZSB0aGF0IGNvbmRpdGlvbiBjb3ZlcmVkIGluIHRoZSBkcmFmdC4NCiAgICBJIHdvdWxkIHNheSB0 byBpZ25vcmUgdGhlIGV4dGVuZGVkIGNvbW11bml0eS4NCiAgICANCiAgICBUaGFua3MsDQogICAg SmFrb2IuDQogICAgDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJv bTogc2lkciBbbWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJ RVNHDQogICAgPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTEsIDIwMTcgNzoyNSBBTQ0KICAg ID4gVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQogICAgPiBDYzog ZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsgc2lk ckBpZXRmLm9yZzsgc2lkci1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHDQogICAgPiA8aWVzZ0Bp ZXRmLm9yZz47IHNhbmR5QHRpc2xhYnMuY29tOyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQog ICAgPiBTdWJqZWN0OiBbc2lkcl0gUHJvdG9jb2wgQWN0aW9uOiAnQkdQIFByZWZpeCBPcmlnaW4g VmFsaWRhdGlvbiBTdGF0ZSBFeHRlbmRlZCBDb21tdW5pdHknIHRvIFByb3Bvc2VkIFN0YW5kYXJk DQogICAgPiAoZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0xMS50 eHQpDQogICAgPiANCiAgICA+IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRv Y3VtZW50Og0KICAgID4gLSAnQkdQIFByZWZpeCBPcmlnaW4gVmFsaWRhdGlvbiBTdGF0ZSBFeHRl bmRlZCBDb21tdW5pdHknDQogICAgPiAgIChkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRp b24tc2lnbmFsaW5nLTExLnR4dCkgYXMgUHJvcG9zZWQNCiAgICA+IFN0YW5kYXJkDQogICAgPiAN CiAgICA+IFRoaXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFNlY3VyZSBJbnRlci1E b21haW4gUm91dGluZyBXb3JraW5nDQogICAgPiBHcm91cC4NCiAgICA+IA0KICAgID4gVGhlIElF U0cgY29udGFjdCBwZXJzb25zIGFyZSBBbHZhcm8gUmV0YW5hLCBBbGlhIEF0bGFzIGFuZCBEZWJv cmFoDQogICAgPiBCcnVuZ2FyZC4NCiAgICA+IA0KICAgID4gQSBVUkwgb2YgdGhpcyBJbnRlcm5l dCBEcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmcvDQogICAgPiANCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gVGVjaG5pY2FsIFN1bW1hcnkNCiAgICA+IA0K ICAgID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJHUCBvcGFxdWUgZXh0ZW5kZWQg Y29tbXVuaXR5IHRvIGNhcnJ5DQogICAgPiAgICB0aGUgb3JpZ2luYXRpb24gQVMgdmFsaWRhdGlv biBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91cyBzeXN0ZW0uDQogICAgPiAgICBJQkdQIHNwZWFr ZXJzIHRoYXQgcmVjZWl2ZSB0aGlzIHZhbGlkYXRpb24gc3RhdGUgY2FuIGNvbmZpZ3VyZSBsb2Nh bA0KICAgID4gICAgcG9saWNpZXMgYWxsb3dpbmcgaXQgdG8gaW5mbHVlbmNlIHRoZWlyIGRlY2lz aW9uIHByb2Nlc3MuDQogICAgPiANCiAgICA+IFdvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KICAgID4g DQogICAgPiAgIFRoaXMgZG9jdW1lbnQgaGFzIGhhZCBjb25zaXN0ZW50IGludGVyZXN0IGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAuDQogICAgPiAgIEJlY2F1c2UgaXQgZGVmaW5lcyBhIG5ldyBCR1Ag Y29tbXVuaXR5LCBpdCB3YXMgcmV2aWV3ZWQgYnkgdGhlIGlkcg0KICAgID4gICB3b3JraW5nIGdy b3VwIGFzIHdlbGwuDQogICAgPiANCiAgICA+IERvY3VtZW50IFF1YWxpdHkNCiAgICA+IA0KICAg ID4gICBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgbWFqb3Igcm91dGVyIHZl bmRvcnMuDQogICAgPiAgIEl0IGlzIGtub3duIHRvIGJlIGluIHVzZSBpbiB0d28gbGFyZ2UgSVhQ cywgQU1TLUlYIGFuZCBERS1DSVguDQogICAgPiANCiAgICA+IFBlcnNvbm5lbA0KICAgID4gDQog ICAgPiAgIERvY3VtZW50IFNoZXBoZXJkOiBTYW5kcmEgTXVycGh5DQogICAgPiAgIFJlc3BvbnNp YmxlIEFyZWEgRGlyZWN0b3I6IEFsdmFybyBSZXRhbmENCiAgICA+IA0KICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNpZHIgbWFpbGlu ZyBsaXN0DQogICAgPiBzaWRyQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpZHINCiAgICANCiAgICANCg0K From nobody Sun Feb 26 06:43:56 2017 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 BD5311204D9; Sun, 26 Feb 2017 06:43:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148812023477.2888.8486186818190857881.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2017 06:43:54 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-publication-11: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:43:54 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-publication-11: 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-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS point. A couple of remaining issues: I still think lack of details about versionning and what requires (or not) to bump the version number is a mistake. RFC 2616 (HTTP) got obsoleted, please reference the latest version. In 2.5: is the list of error reasons extensible? If yes, should you have an IANA registry for them? In Section 5 you should reference this document (and not just section numbers), as IANA registrations cut & pasted to IANA website as separate files. From nobody Mon Feb 27 01:25:11 2017 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 72B3712950F; Mon, 27 Feb 2017 01:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 MjGdejhj5AGC; Mon, 27 Feb 2017 01:25:09 -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 A0EC01294CA; Mon, 27 Feb 2017 01:25:06 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1ciHYB-000BMh-CZ; Mon, 27 Feb 2017 10:25:00 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ciHYA-0004TO-41; Mon, 27 Feb 2017 10:24:58 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Oleg Muravskiy In-Reply-To: Date: Mon, 27 Feb 2017 09:24:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9DC16A6F-84C6-4E59-9086-3C4EB1A0C05E@ripe.net> References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -------- X-RIPE-Spam-Report: Spam Total Points: -8.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0395] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74c20a437c05f51bdb513b29587aba6745 Archived-At: Cc: "sidr@ietf.org" , "morrowc@ops-netman.net" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "draft-ietf-sidr-delta-protocol@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 09:25:10 -0000 Hi everybody, > On 23 Feb 2017, at 20:25, Alvaro Retana (aretana) = wrote: >=20 > Tim: > =20 > Hi! > =20 > Given the feedback so far on the list, I think we should roll back the = updates in preparation for next week=E2=80=99s IESG Telechat. Currently RFC7730 (TAL format) only allows rsync URIs in there. In order to allow RRDP in TAL, I think we have to keep the update to = RFC7730 in draft-ietf-sidr-delta-protocol, namely this part of the = draft: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 4.3. Updates to RFC7730 4.3.1. Update in Section 2.1, Trust Anchor Locator Format OLD: where the URI section is comprised of one of more of the ordered sequence of: 1.1) an rsync URI [RFC5781], 1.2) a or line break. NEW: where the URI section is comprised of one of more of the ordered sequence of: 1.1) a URI [RFC3986], 1.2) a or line break. 4.3.2. Update in Section 2.2, TAL and Trust Anchor Certificate Considerations OLD: Each rsync URI in the TAL MUST reference a single object. It MUST NOT reference a directory or any other form of collection of objects. ... Where the TAL contains two or more rsync URIs, then the same self- signed CA certificate MUST be found at each referenced location. NEW: Each URI in the TAL MUST reference a single object. It MUST NOT reference a directory or any other form of collection of objects. ... Where the TAL contains two or more URIs, then the same self-signed CA certificate MUST be found at each referenced location. 4.3.3. Update in Section 5.1, Normative References Remove the reference to RFC5781, "The rsync URI Scheme". Add a reference to RFC3986, "Uniform Resource Identifier (URI): Generic Syntax". = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D What do you think? Oleg > =20 > Thanks! > =20 > Alvaro. > =20 > On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)" = wrote: > =20 > > **Chairs**: Given that this is a significant change, and that the = WG may have not been > > focused on the discussion, and that we now have a little more time = given the fact that the > > IESG review of this document was deferred until Mar/2=E2=80=A6 = Please explicitly ask the WG to > > review the Updates to RFC6480, RFC6481 and RFC7730. I think that a = week of discussion > > on the list should be enough. >=20 >=20 From nobody Mon Feb 27 06:33:04 2017 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 9BE5712A039 for ; Mon, 27 Feb 2017 06:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=sn3rd.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 l2guqn3dQTnR for ; Mon, 27 Feb 2017 06:33:01 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 485E612A022 for ; Mon, 27 Feb 2017 06:33:01 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n127so99327741qkf.0 for ; Mon, 27 Feb 2017 06:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=oH+SCfYvBDI3VPGHkJfoX8BSVYSkh13odr1iO+AaM2k=; b=NL2o9BOHkaxGmpCH70X0o3wgzpUvOtiEL2YCwuVq9kVpkjatBjIrnxeeCLJCa0XzCf z9BL1Y26DAZr25eOzPpYhTVTn36w6Js5auan7N438obCZLltE8S9HykoX7dURnqf53yQ 4uNavdAacRgr3hfE93Pg61QttXaG7runi3kOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=oH+SCfYvBDI3VPGHkJfoX8BSVYSkh13odr1iO+AaM2k=; b=thHJgZ5O/QtD8czc4e+IfO4rqSgu94upCCjuOymYTT0/JMz0v09UiKx+XhZqQs+oz3 PEc+Jj6G9HnKvzWpRBoTZRoLTYZ5+QxPpK9uli4o0yNmJsZk114X6+wUn/6hjMCAa0sh V6kj6VmvHCsTVDhU7+X39R4+ADNHRsfcIT6U+YGL0HVXkFSK7OjbnCrSvylxtzaerlvW hfaYpsf4fEIfiVGVGbbfn3IC6O4nvwQIKeY43n/7ULV1FvtVW2dEA+gpjkI7ZrG23EBW gFAM6NMLgYcaUFEOYLdtax35zJTRZjXQEm75YVp541GPvKl1G5yFpndgQUKt5EyB9yvd sEZA== X-Gm-Message-State: AMke39mXZMVhMdK15sVQJwyYXOPEgNJV6Ve9/vDAdwbuoYUYRfMDBkpZ9hnwJt9X0kv37w== X-Received: by 10.200.3.74 with SMTP id w10mr16989840qtg.73.1488205979479; Mon, 27 Feb 2017 06:32:59 -0800 (PST) Received: from [172.16.0.18] ([96.231.229.68]) by smtp.gmail.com with ESMTPSA id f126sm10499922qkc.47.2017.02.27.06.32.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 06:32:58 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Feb 2017 09:32:57 -0500 References: <06FD4D79-FBDD-44E0-9CF2-4B7A039A06A9@nist.gov> <845A415C-D469-4899-B7B0-0DAF728D667F@nist.gov> To: sidr list In-Reply-To: <845A415C-D469-4899-B7B0-0DAF728D667F@nist.gov> Message-Id: <3AD0CCE2-930A-4A8A-90CD-F93F6275FA12@sn3rd.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:33:03 -0000 Unless there=E2=80=99s any comments, Wednesday I=E2=80=99ll cut these = into the draft-ietf-sidr-bgpsec-pki-algs draft. spt > On Feb 21, 2017, at 10:13 AM, Borchert, Oliver (Fed) = wrote: >=20 > Attached is the latest version of the examples. Here we added an IPv6 = BGP update to the existing example. >=20 > Again, for better reading I attached the example as text/pdf in case = the formatting within the email gets > Messed up. >=20 > Oliver >=20 > ----example----example----example---- > Topology: >=20 > AS(64496)----AS(65536)----AS(65537) >=20 > Prefix Announcements: AS(64496), 192.0.2.0/24, 2001:db8::/32 >=20 > For this example, the ECDSA algorithm was provided with a static k to=20= > make the result deterministic.=20 > The k used for all signature operations was taken from RFC 6979,=20 > chapter A.2.5 ?Signatures With SHA-256, message 'sample'?. >=20 > k =3D = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60 >=20 > Keys of AS64496: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 >=20 > private key: > x =3D = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9 >=20 > public key:=20 > Ux =3D = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A > Uy =3D = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5 >=20 > Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013 > -------------------------------------------------------------------- > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 38655612 (0x24dd67c) > Signature Algorithm: ecdsa-with-SHA256 > Issuer: CN=3DROUTER-0000FBF0 > Validity > Not Before: Jan 1 05:00:00 2017 GMT > Not After : Jul 1 05:00:00 2018 GMT > Subject: CN=3DROUTER-0000FBF0 > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (256 bit) > pub:=20 > 04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf: > fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f: > 77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55: > d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05: > a2:5b:d3:6f:f5 > ASN1 OID: prime256v1 > X509v3 extensions: > X509v3 Key Usage:=20 > Digital Signature > X509v3 Subject Key Identifier:=20 > = AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54 > X509v3 Extended Key Usage:=20 > 1.3.6.1.5.5.7.3.30 > sbgp-autonomousSysNum: critical > Autonomous System Numbers: > 64496 > Routing Domain Identifiers: > inherit >=20 > Signature Algorithm: ecdsa-with-SHA256 > 30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83: > ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1: > 02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1: > 1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29 > -----BEGIN CERTIFICATE----- > MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU > RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw > FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC > AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU > 9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN > kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF > BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k > 8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x > OCRdZCk1KI3uDDgp > -----END CERTIFICATE----- >=20 >=20 >=20 > Keys of AS(65636): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC >=20 > private key: > x =3D = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172 >=20 > public key:=20 > Ux =3D = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989 > Uy =3D = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F >=20 > Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013 > -------------------------------------------------------------------- > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 3168189942 (0xbcd6bdf6) > Signature Algorithm: ecdsa-with-SHA256 > Issuer: CN=3DROUTER-0000FFFF > Validity > Not Before: Jan 1 05:00:00 2017 GMT > Not After : Jul 1 05:00:00 2018 GMT > Subject: CN=3DROUTER-0000FFFF > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (256 bit) > pub:=20 > 04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21: > 2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a: > a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56: > 41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6: > b8:b5:88:f4:1f > ASN1 OID: prime256v1 > X509v3 extensions: > X509v3 Key Usage:=20 > Digital Signature > X509v3 Subject Key Identifier:=20 > = 47:F2:3B:F1:AB:2F:8A:9D:26:86:4E:BB:D8:DF:27:11:C7:44:06:EC > X509v3 Extended Key Usage:=20 > 1.3.6.1.5.5.7.3.30 > sbgp-autonomousSysNum: critical > Autonomous System Numbers: > 65535 > Routing Domain Identifiers: > inherit >=20 > Signature Algorithm: ecdsa-with-SHA256 > 30:45:02:21:00:df:04:c5:17:04:d0:f2:b9:fa:f3:d9:6e:3f: > 6f:a1:58:d8:fe:6c:18:e4:37:ca:19:7c:c8:75:40:57:6e:7e: > 9d:02:20:12:45:e8:a8:58:6b:00:7b:e6:a9:0e:f2:b6:62:50: > 4b:1c:01:6f:3b:41:11:69:88:30:73:9f:d7:02:9e:64:4f > -----BEGIN CERTIFICATE----- > MIIBijCCATCgAwIBAgIFALzWvfYwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V > VEVSLTAwMDBGRkZGMB4XDTE3MDEwMTA1MDAwMFoXDTE4MDcwMTA1MDAwMFowGjEY > MBYGA1UEAwwPUk9VVEVSLTAwMDBGRkZGMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD > QgAEKPxf6a/PX0yrP1+FyyEvwenQ4Nvq7kJb0vDTF1qg6Ynqm2A+OPNfsynfSVZB > 8roEDxw6xhODB/JXy6a4tYj0H6NjMGEwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBRH > 8jvxqy+KnSaGTrvY3ycRx0QG7DATBgNVHSUEDDAKBggrBgEFBQcDHjAeBggrBgEF > BQcBCAEB/wQPMA2gBzAFAgMA//+hAgUAMAoGCCqGSM49BAMCA0gAMEUCIQDfBMUX > BNDyufrz2W4/b6FY2P5sGOQ3yhl8yHVAV25+nQIgEkXoqFhrAHvmqQ7ytmJQSxwB > bztBEWmIMHOf1wKeZE8=3D > -----END CERTIFICATE----- >=20 >=20 >=20 > BGPSec IPv4 Update from AS(65536) to AS(65537): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Binary Form of BGPSec Update (TCP-DUMP): >=20 > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF=20 > 01 00 02 00 00 00 E9 40 01 01 02 80 04 04 00 00=20 > 00 00 80 0E 0D 00 01 01 04 C6 33 64 64 00 18 C0=20 > 00 02 90 21 00 CA 00 0E 01 00 00 01 00 00 01 00=20 > 00 00 FB F0 00 BC 01 47 F2 3B F1 AB 2F 8A 9D 26=20 > 86 4E BB D8 DF 27 11 C7 44 06 EC 00 46 30 44 02=20 > 20 72 14 BC 96 47 16 0B BD 39 FF 2F 80 53 3F 5D=20 > C6 DD D7 0D DF 86 BB 81 56 61 E8 05 D5 D4 E6 F2=20 > 7C 02 20 2D DC 00 3C 64 BE 7B 29 C9 EB DB C8 A4=20 > 97 ED 66 28 5E E9 22 76 83 E6 C1 78 CE 8D E6 D3=20 > 59 5F 41 AB 4D 91 0F 55 CA E7 1A 21 5E F3 CA FE=20 > 3A CC 45 B5 EE C1 54 00 47 30 45 02 20 72 14 BC=20 > 96 47 16 0B BD 39 FF 2F 80 53 3F 5D C6 DD D7 0D=20 > DF 86 BB 81 56 61 E8 05 D5 D4 E6 F2 7C 02 21 00=20 > C6 17 19 34 07 43 06 3B 8A 5C CD 54 16 39 0B 31=20 > 21 1D 3C 52 48 07 95 87 D0 13 13 7B 41 CD 23 E2=20 >=20 >=20 > Signature =46rom AS(64496) to AS(65536): > --------------------------------------- > Digest: 21 33 E5 CA A0 26 BE 07 3D 9C 1B 4E FE B9 B9 77=20 > 9F 20 F8 F5 DE 29 FA 98 40 00 9F 60=20 > Signature: 30 45 02 20 72 14 BC 96 47 16 0B BD 39 FF 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 05 D5=20 > D4 E6 F2 7C 02 21 00 C6 17 19 34 07 43 06 3B 8A=20 > 5C CD 54 16 39 0B 31 21 1D 3C 52 48 07 95 87 D0=20 > 13 13 7B 41 CD 23 E2=20 >=20 > Signature =46rom AS(65536) to AS(65537): > -------------------------------------- > Digest: 46 4B 57 CE B1 2D 18 B0 FD 1A 1A 35 94 17 3A 4A=20 > 09 88 E5 F4 ED ED 2F 3D 83 08 5A A8=20 > Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 05 D5=20 > D4 E6 F2 7C 02 20 2D DC 00 3C 64 BE 7B 29 C9 EB=20 > DB C8 A4 97 ED 66 28 5E E9 22 76 83 E6 C1 78 CE=20 > 8D E6 D3 59 5F 41=20 >=20 > The human readable output is produced using bgpsec-io, a bgpsec=20 > traffic generator that uses a wireshark like printout. >=20 > Send Update Message > +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > +--length: 256 > +--type: 2 (UPDATE) > +--withdrawn_routes_length: 0 > +--total_path_attr_length: 233 > +--ORIGIN: INCOMPLETE (4 bytes) > | +--Flags: 0x40 (Well-Known, Transitive, Complete) > | +--Type Code: ORIGIN (1) > | +--Length: 1 byte > | +--Origin: INCOMPLETE (1) > +--MULTI_EXIT_DISC (7 bytes) > | +--Flags: 0x80 (Optional, Complete) > | +--Type Code: MULTI_EXIT_DISC (4) > | +--Length: 4 bytes > | +--data: 00 00 00 00=20 > +--MP_REACH_NLRI (16 bytes) > | +--Flags: 0x80 (Optional, Complete) > | +--Type Code: MP_REACH_NLRI (14) > | +--Length: 13 bytes > | +--Address family: IPv4 (1) > | +--Subsequent address family identifier: Unicast (1) > | +--Next hop network address: (4 bytes) > | | +--Next hop: 198.51.100.100 > | +--Subnetwork points of attachment: 0 > | +--Network layer reachability information: (4 bytes) > | +--192.0.2.0/24 > | +--MP Reach NLRI prefix length: 24 > | +--MP Reach NLRI IPv4 prefix: 192.0.2.0 > +--BGPSEC Path Attribute (206 bytes) > +--Flags: 0x90 (Optional, Complete, Extended Length) > +--Type Code: BGPSEC Path Attribute (33) > +--Length: 202 bytes > +--Secure Path (14 bytes) > | +--Length: 14 bytes > | +--Secure Path Segment: (6 bytes) > | | +--pCount: 1 > | | +--Flags: 0 > | | +--AS number: 65536 (1.0) > | +--Secure Path Segment: (6 bytes) > | +--pCount: 1 > | +--Flags: 0 > | +--AS number: 64496 (0.64496) > +--Signature Block (188 bytes) > +--Length: 188 bytes > +--Algo ID: 1 > +--Signature Segment: (92 bytes) > | +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC > | +--Length: 70 bytes > | +--Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF = 2F 80=20 > | 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 = 05 D5=20 > | D4 E6 F2 7C 02 20 2D DC 00 3C 64 BE 7B 29 = C9 EB=20 > | DB C8 A4 97 ED 66 28 5E E9 22 76 83 E6 C1 = 78 CE=20 > | 8D E6 D3 59 5F 41=20 > +--Signature Segment: (93 bytes) > +--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 > +--Length: 71 bytes > +--Signature: 30 45 02 20 72 14 BC 96 47 16 0B BD 39 FF = 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 = 05 D5=20 > D4 E6 F2 7C 02 21 00 C6 17 19 34 07 43 06 = 3B 8A=20 > 5C CD 54 16 39 0B 31 21 1D 3C 52 48 07 95 = 87 D0=20 > 13 13 7B 41 CD 23 E2=20 >=20 >=20 > BGPSec IPv6 Update from AS(65536) to AS(65537): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Binary Form of BGPSec Update (TCP-DUMP): >=20 > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > 01 0C 02 00 00 00 F5 40 01 01 02 80 04 04 00 00 > 00 00 80 0E 1A 00 02 01 10 20 01 00 10 00 00 00 > 00 00 00 00 00 C6 33 64 64 00 20 20 01 0D B8 90 > 21 00 C9 00 0E 01 00 00 01 00 00 01 00 00 00 FB > F0 00 BB 01 47 F2 3B F1 AB 2F 8A 9D 26 86 4E BB > D8 DF 27 11 C7 44 06 EC 00 46 30 44 02 20 72 14 > BC 96 47 16 0B BD 39 FF 2F 80 53 3F 5D C6 DD D7 > 0D DF 86 BB 81 56 61 E8 05 D5 D4 E6 F2 7C 02 20 > 0A 9A E7 5F 56 CE 42 9C D2 D2 20 38 6B 8D 24 73 > E9 5C 8A 50 E5 58 DB 92 B7 88 3D 09 E8 42 4E E7 > AB 4D 91 0F 55 CA E7 1A 21 5E F3 CA FE 3A CC 45 > B5 EE C1 54 00 46 30 44 02 20 72 14 BC 96 47 16 > 0B BD 39 FF 2F 80 53 3F 5D C6 DD D7 0D DF 86 BB > 81 56 61 E8 05 D5 D4 E6 F2 7C 02 20 6E 26 52 40 > CF CA 0E F6 5C 8E A1 AF 6B 65 2A 19 13 D2 FC BD > B5 8E E9 53 60 9F 85 F0 D2 69 99 DF =20 >=20 >=20 > Signature =46rom AS(64496) to AS(65536): > --------------------------------------- > Digest: 8A 0C D3 E9 8E 55 10 45 82 1D 80 46 01 D6 55 FC=20 > 52 11 89 DF 4D B0 28 7D 84 AC FC 77=20 > Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 05 D5=20 > D4 E6 F2 7C 02 20 6E 26 52 40 CF CA 0E F6 5C 8E=20 > A1 AF 6B 65 2A 19 13 D2 FC BD B5 8E E9 53 60 9F=20 > 85 F0 D2 69 99 DF=20 >=20 > Signature =46rom AS(65536) to AS(65537): > -------------------------------------- > Digest: BA BF F7 95 BF 3C BE 81 79 1F A9 90 06 FC 30 1B=20 > 0D BC D5 49 39 5A 0A 71 C2 D5 B2 FA=20 > Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 05 D5=20 > D4 E6 F2 7C 02 20 0A 9A E7 5F 56 CE 42 9C D2 D2=20 > 20 38 6B 8D 24 73 E9 5C 8A 50 E5 58 DB 92 B7 88=20 > 3D 09 E8 42 4E E7=20 >=20 >=20 > The human readable output is produced using bgpsec-io, a bgpsec=20 > traffic generator that uses a wireshark like printout. >=20 > Send Update Message > +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > +--length: 268 > +--type: 2 (UPDATE) > +--withdrawn_routes_length: 0 > +--total_path_attr_length: 245 > +--ORIGIN: INCOMPLETE (4 bytes) > | +--Flags: 0x40 (Well-Known, Transitive, Complete) > | +--Type Code: ORIGIN (1) > | +--Length: 1 byte > | +--Origin: INCOMPLETE (1) > +--MULTI_EXIT_DISC (7 bytes) > | +--Flags: 0x80 (Optional, Complete) > | +--Type Code: MULTI_EXIT_DISC (4) > | +--Length: 4 bytes > | +--data: 00 00 00 00=20 > +--MP_REACH_NLRI (29 bytes) > | +--Flags: 0x80 (Optional, Complete) > | +--Type Code: MP_REACH_NLRI (14) > | +--Length: 26 bytes > | +--Address family: IPv6 (2) > | +--Subsequent address family identifier: Unicast (1) > | +--Next hop network address: (16 bytes) > | | +--Next hop: 2001:0010:0000:0000:0000:0000:c633:6464 > | +--Subnetwork points of attachment: 0 > | +--Network layer reachability information: (5 bytes) > | +--2001:db8::/32 > | +--MP Reach NLRI prefix length: 32 > | +--MP Reach NLRI IPv6 prefix: 2001:db8:: > +--BGPSEC Path Attribute (205 bytes) > +--Flags: 0x90 (Optional, Complete, Extended Length) > +--Type Code: BGPSEC Path Attribute (33) > +--Length: 201 bytes > +--Secure Path (14 bytes) > | +--Length: 14 bytes > | +--Secure Path Segment: (6 bytes) > | | +--pCount: 1 > | | +--Flags: 0 > | | +--AS number: 65536 (1.0) > | +--Secure Path Segment: (6 bytes) > | +--pCount: 1 > | +--Flags: 0 > | +--AS number: 64496 (0.64496) > +--Signature Block (187 bytes) > +--Length: 187 bytes > +--Algo ID: 1 > +--Signature Segment: (92 bytes) > | +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC > | +--Length: 70 bytes > | +--Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF = 2F 80=20 > | 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 = 05 D5=20 > | D4 E6 F2 7C 02 20 0A 9A E7 5F 56 CE 42 9C = D2 D2=20 > | 20 38 6B 8D 24 73 E9 5C 8A 50 E5 58 DB 92 = B7 88=20 > | 3D 09 E8 42 4E E7=20 > +--Signature Segment: (92 bytes) > +--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 > +--Length: 70 bytes > +--Signature: 30 44 02 20 72 14 BC 96 47 16 0B BD 39 FF = 2F 80=20 > 53 3F 5D C6 DD D7 0D DF 86 BB 81 56 61 E8 = 05 D5=20 > D4 E6 F2 7C 02 20 6E 26 52 40 CF CA 0E F6 = 5C 8E=20 > A1 AF 6B 65 2A 19 13 D2 FC BD B5 8E E9 53 = 60 9F=20 > 85 F0 D2 69 99 DF=20 >=20 > ----example----example----example---- >=20 > ------------------------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Phone) 301.975.4856 , (Fax) 301.975.6238 >=20 >=20 >=20 >=20 > = _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Feb 28 06:26:03 2017 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 21926129598; Tue, 28 Feb 2017 06:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 nHyqfMMIZ3lG; Tue, 28 Feb 2017 06:26:00 -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 97A27129563; Tue, 28 Feb 2017 06:26:00 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ciiiu-0006zw-BS; Tue, 28 Feb 2017 15:25:53 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-17.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ciiit-0005dz-3k; Tue, 28 Feb 2017 15:25:51 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: <9DC16A6F-84C6-4E59-9086-3C4EB1A0C05E@ripe.net> Date: Tue, 28 Feb 2017 15:25:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> <9DC16A6F-84C6-4E59-9086-3C4EB1A0C05E@ripe.net> To: Oleg Muravskiy X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0004] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190781c0797ab8371f0317c97a78f951ba Archived-At: Cc: "sidr@ietf.org" , "morrowc@ops-netman.net" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "draft-ietf-sidr-delta-protocol@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:26:02 -0000 Hi all, > On 27 Feb 2017, at 10:24, Oleg Muravskiy wrote: >=20 > Hi everybody, >=20 >> On 23 Feb 2017, at 20:25, Alvaro Retana (aretana) = wrote: >>=20 >> Tim: >>=20 >> Hi! >>=20 >> Given the feedback so far on the list, I think we should roll back = the updates in preparation for next week=E2=80=99s IESG Telechat. >=20 > Currently RFC7730 (TAL format) only allows rsync URIs in there. >=20 > In order to allow RRDP in TAL, I think we have to keep the update to = RFC7730 in draft-ietf-sidr-delta-protocol, namely this part of the = draft: While I share my co-author's enthusiasm to update the TAL document, I = propose to do this as a separate effort so that the delta protocol = doesn't depend on this. It's not needed by the protocol after all, but = would help scale access to Trust Anchor certificates. Also when we go here I believe we will have to allow HTTPS specifically = as an alternative scheme. And we may have discussions whether it should = be allowed in addition or even instead of rsync (which I believe may be = a lot simpler than phasing out rsync everywhere else). Tim >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > 4.3. Updates to RFC7730 >=20 > 4.3.1. Update in Section 2.1, Trust Anchor Locator Format >=20 > OLD: >=20 > where the URI section is comprised of one of more of the ordered > sequence of: >=20 > 1.1) an rsync URI [RFC5781], >=20 > 1.2) a or line break. >=20 > NEW: >=20 > where the URI section is comprised of one of more of the ordered > sequence of: >=20 > 1.1) a URI [RFC3986], >=20 > 1.2) a or line break. >=20 > 4.3.2. Update in Section 2.2, TAL and Trust Anchor Certificate > Considerations >=20 > OLD: >=20 > Each rsync URI in the TAL MUST reference a single object. It = MUST > NOT reference a directory or any other form of collection of > objects. >=20 > ... >=20 > Where the TAL contains two or more rsync URIs, then the same = self- > signed CA certificate MUST be found at each referenced location. >=20 > NEW: >=20 > Each URI in the TAL MUST reference a single object. It MUST NOT > reference a directory or any other form of collection of objects. >=20 > ... >=20 > Where the TAL contains two or more URIs, then the same = self-signed > CA certificate MUST be found at each referenced location. >=20 > 4.3.3. Update in Section 5.1, Normative References >=20 > Remove the reference to RFC5781, "The rsync URI Scheme". >=20 > Add a reference to RFC3986, "Uniform Resource Identifier (URI): > Generic Syntax". >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > What do you think? >=20 > Oleg >=20 >=20 >>=20 >> Thanks! >>=20 >> Alvaro. >>=20 >> On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)" = wrote: >>=20 >>> **Chairs**: Given that this is a significant change, and that the = WG may have not been >>> focused on the discussion, and that we now have a little more time = given the fact that the >>> IESG review of this document was deferred until Mar/2=E2=80=A6 = Please explicitly ask the WG to >>> review the Updates to RFC6480, RFC6481 and RFC7730. I think that a = week of discussion >>> on the list should be enough. >>=20 >>=20 >=20