From nobody Thu Oct 1 00:28:39 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD243A0D9D for ; Thu, 1 Oct 2020 00:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=nlnetlabs.nl 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 OjHR9WO-eIBa for ; Thu, 1 Oct 2020 00:28:36 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 9D6303A0D9C for ; Thu, 1 Oct 2020 00:28:36 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:9dab:1c57:857b:8a4b] (unknown [IPv6:2001:981:4b52:1:9dab:1c57:857b:8a4b]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A37D824DB7; Thu, 1 Oct 2020 09:28:34 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1601537314; bh=OBZlxuCMp2ijNjTPzGER05F3XjsbPjHvEA6kt3z+3YI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YLR+PayZ8HkRhlmqesJqpriEOlepWQZcDLpi1o3nt1cUMVZmhDjr6IS/rpAibtAAb nc49RI6vNe6vpvjg1na9aKKtxoBjJQ0r47uWTp7VqKWh8MNpVTMwqxRerN4pGGIMRl UgrTxDc11aRCMW7LCqI/0DuNdhqXf8oASncxO960= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 1 Oct 2020 09:28:34 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <4710A376-AC99-4363-9E51-50E256A9661A@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> To: Christopher Morrow X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 07:28:38 -0000 Hi Chris, all, I am happy to discuss all this later today, but I will respond here as = well. If you don't have time to read before the meeting, then you will = probably hear me say these things again there. > On 30 Sep 2020, at 08:55, Christopher Morrow = wrote: >=20 > First, thanks! having some tested results on an optional path (for > newly added types) seems cool. > it's at least informed some of the conversation, which seemed to go a > bit outside the original point of order (in my re-re-reading anyway) >=20 > I think the salient points in the discussion are really (happy to be > corrected, of course): > 1) the -bis is proposing a simpler handling of publication point = collection. > this simplicity is a bit at odds with some Internet principals > (robustness principal), but > trades this for very clear behaviors in the RP software. > operations folk (myself, job, mikael though I missed his mail... > others) > were a bit concerned with the different flavors of 'correct' > that can pop out the RP :( and see that being simpler about > the flavors/options may make all/MOST RP get the same set of > answers... predictability / consistency are nice. And I completely appreciate that. > 2) the CA software and operations have to be very clear now about > what is/not published, > keeping in mind that mistakes in the CA Publication Point will > have repercussions. > Perhaps these need to be clearly articulated in the -bis draft? > (more clearly?) > This will, I think, clearly have impact on both CA / PP software > and on operations of the CA / PP. > I think this is good, actually as we're (sidrops folks i mean) > attempting to push for: > o closer compliance to consistency > o more reliance upon the whole system > o better overall security for the routing system The points I have been raising should not be read as opposition to = change. But, I point out probably unintended repercussions of the = choices made. There may be tweaks that can be done to mitigate these, = and if not then at least they should be well understood. >=20 > 3) With the proposed simplicity/strictness comes some potential > problems, at least: > o problems in a CA / PP mean that CA / PP may not have their > most updated information (routing intent) available > o continual problems will lead to fallback to 'unknown' in the > routing system This is the case that worries me most. I completely agree with the = intention to have a soft landing to 'not found', but as written the bis = can actually *cause* invalid routes as well. Consider the scenario that a CA "alice" has resources and does an = announcement for a large prefix - covered by a ROA. She delegates some = more specific prefixes to "bob", and he makes more specific ROAs. Now = "alice" removes 1 prefix from "bob", but he still has the ROA published = (RFC6492 does not allow advance warning of withdrawal). Now "bob" has an = invalid ROA and his PP is rejected. Bob's remaining more specific routes = are now invalid. The same happens in a case where "alice" delegates a = new resource to "bob" and he uses it immediately after requesting the = certificate, but before "alice" had a chance to publish it. Of course there are also other failure scenarios for Bob's PP, but the = resource changes worry me the most because they are relatively frequent. One way to mitigate this is by adding all of Bob's resources - on the CA = certificate he received from Alice for this PP - to an ignore filter. = Then Alice's covering ROA would be filtered an all routes for affected = resources would go to unknown. This was discussed on a side thread, see = suggested text here: = https://mailarchive.ietf.org/arch/msg/sidrops/pi9v6RNA2kMvEOY9BfOD9VHGJtc/= The other case here is overclaims in resources held by NIRs under RIRs. = Typically these will not lead to invalid routes because the RIRs do not = (in practice) issue ROAs for those resources - nor delegate them to = other parties. But, in these cases the entire NIR resource set would end = up as "not found". This is why I suggested another mitigation strategy to the one discussed = above. If objects are found to be invalid due to overclaims, but they = are otherwise perfectly valid, then this is a recognisable state. And = RPs could then choose to ignore the intersection of resources on = overclaiming objects and the resource set issued to them instead. This = would leave things valid for resources which were not changed. The downside of mitigation is of course complexity, but without it we = should accept that invalidating children will happen. I am not convinced = that that that is a good idea, but I can accept it if operators = understand and accept the consequences. As an aside to this: I want to propose an update to RFC 6492 so that = child CAs can be informed when resources will be removed (in as much as = possible) and when new resource certificates can be expected to be = published. But this will take time and that is assuming that the working = group is open to this work. > o adding new object types seems difficult (just my reading so = far) > particularly there's a note about 'people won't upgrade their > RP software' >=20 > I think that the simplicity is a goal I would like to see achieved, > specifically because inconsistent results in the RP set is problematic > longer term. > If we can get to more consistency before we roll a bunch more out > we'll be able to course correct better/faster (I think). >=20 > I think the idea that people won't upgrade... sure? maybe? Also: "Do > you like killing kittens? because not managing your business critical > systems a great way to kill kittens." We've been able to push more > people into RPKI and better routing-intent hygiene, I don't see why we > can't keep doing that and get folk to treat part of the routing system > as critical to their business. >=20 > We should not shy away from a solution just because we may have to > convince people to upgrade. The following scenarios were discussed: 1. Accept as-is - don't specify types in the -bis This means that RPs should be updated to support new types. And that = once there is deployment, or operators have been given 'enough' time CAs = can publish the new types. Operators will then be forced to upgrade. = This implies that RP implementers should be committed to supporting new = types. If the RP tool of choice does not support new type, then = operators will need to switch to another. It's hard to quantify the delay for the deployability of new types = here.. 6-18 months? 2. Modify the -bis: let RPs check the hash and presence of types they = don't understand, but don't validate This assumes that new types are orthogonal to existing types. I.e. if = you don't understand ASPA this is no reason to reject ROAs. The RP would = verify the presence of all files and that they match the hashes. So they = know there was no error in transit between them and the CA. The presence = of an invalid object of a known type would still lead to invalidating = the PP. This would allow a more gradual roll-out of new types. If/when new object types are not orthogonal to existing types, then = those types could receive a version change to ensure that they would be = accepted only by RPs who understand the set of interconnected object = types. Under this strategy new types can be deployed on publication of RFCs, = without impacting the existing RPKI. 3. Introduce a new explicit SIA and new PPs when new object types are = introduced. As discussed, this is possible. But I believe that this is the most = difficult option by far. It requires a lot more thought, and then work = for CAs and RPs alike. This would essentially mean postponing ASPA for = years. If the WG and ASPA authors are okay with that, well then so be = it.. just be aware of the repercussion. 4? Your suggestion here... Tim >=20 > I look forward to the discussion tomorrow/thurs. >=20 > -chris >=20 >=20 >=20 > On Tue, Sep 29, 2020 at 10:55 AM Tim Bruijnzeels = wrote: >>=20 >> Hi, >>=20 >> On 7 Sep 2020, at 13:17, Tim Bruijnzeels wrote: >>>=20 >>>>>=20 >>>>> If we do go down this road then I think that we should also look = at the manifest object itself, and let it convey which object (types) = are critical (and while we are at it, we can specify types instead of = using filename extensions). That way future object types could = introduced more easily perhaps - this obviously needs more discussion = but it could even allow for semantics like: 1) new object please test, = don't use, 2) new objects, use if you can, 3) new objects, critical - = fail if you don't understand. >>>>=20 >>>> One could combine the new SIA URI and a revised manifest, in which = the manifest contains the per-object flag, rather than redefining the = basic object format to accommodate the flag. That would reduce the = number of RFCs that need to change. Good idea. >>>=20 >>> Upon reflection I realised that even the introduction of an SIA in = the issuing CA certificate will lead to issues. RPs would reject the CA = certificate, and as a result the whole PP of the parent CA. This means = that the SIA cannot be deployed without leaving a significant number of = RP installations behind. E.g. if I run a delegated CA under an RIR which = wants to adopt ASPA, and I get a new CA certificate with the additional = SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be = rejected. >>=20 >>=20 >> I have done some testing on this. >>=20 >> Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for = CA certificates can be expected and can be ignored. And indeed it seems = that all current RP software will accept (and ignore) additional SIAs. >>=20 >> At least that's the result from adding an extra SIA in a Krill branch = and running the end to end tests using the following validator versions: >>=20 >> fortvalidator 1.4.0 >> OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700) >> rcynic version believed to be buildbot-1.0.1544679302 >> routinator 0.7.1 >> rpkiclient 6.7p1 >> rpkivalidator3 3.1-2020.08.06.14.39 >>=20 >> I am still not very happy about the overhead that this approach = implies: >>=20 >> Additional publication points which need to be maintained, which may = be out of sync. What if MFT A has a certain ROA and MFT B doesn't? This = can lead to serious operational impact if an announcement would be valid = under one, but not the other. >>=20 >> It would also require much more fundamental code changes for = producing CAs - one cannot just support a new object type. One has to = support an additional publication model. Parent CAs have to be willing = to include the new SIAs as well affecting the ability to deploy for = delegated CAs. >>=20 >> But, at least it seems that it can be introduced without breaking = things immediately for existing deployed validators. >>=20 >> Tim >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Oct 1 08:05:03 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E703A10BC for ; Thu, 1 Oct 2020 08:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=ripe.net 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 LHElhsLB8__s for ; Thu, 1 Oct 2020 08:05:00 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D863E3A109D for ; Thu, 1 Oct 2020 08:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=Deq8MPv11WKG2P+j0tucRcNlfgVhA4HR7HiVtd8j+Dk=; b=gt+lqbmfBXet4MQflaug6Z Q4FWSSORkKzGRmzbJ9Ko7VpwHWB7wKqDuy092Ru5WCyT+/G54b2w7Dpf9oQ5vnCgTl+8qrAqNDCfy 7rJsd6L1uRe9+bELmJOv/rRVtwKsUU22j1MuRaGJAb16XHg5WsUWL8IUXXTdKllqy23+NbM1xTJyF POa0doYH1ZvmKSpTeI5pZv52XG3UECFDxZmntxxLYmgWdpI2ospAw0UHUzd0zSMUyCN2a39b87Qtg AKQtHpvTgJrV+Al7Qt9gtDf15Pa9NJNM92WombMHtEq4Kp+L3yNtpkYDna1azcaX5E1d9CiPCWif8 J3nvuzWoebdQ==; Received: from bufobufo.ripe.net ([193.0.23.13]:55306) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kO08g-0007ZR-D5 for sidrops@ietf.org; Thu, 01 Oct 2020 17:04:58 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f50]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kO08g-0006d0-AI for sidrops@ietf.org; Thu, 01 Oct 2020 17:04:58 +0200 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_04842A4E-58ED-40DF-9693-69882C014892" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Thu, 1 Oct 2020 17:04:57 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a0e0ba70efc99da36e7d9ea2917257b7c Archived-At: Subject: [Sidrops] Virtual Interim meeting recording X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:05:01 -0000 --Apple-Mail=_04842A4E-58ED-40DF-9693-69882C014892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Thank you for attending the virtual interim meeting today.=20 Because it was a short meeting, the recording is already available and = can be viewed at: = https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/3c9b= 868d338f4872adb790558ff2ce03 = Best, Nathalie Trenaman --Apple-Mail=_04842A4E-58ED-40DF-9693-69882C014892 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

Thank you for attending the virtual interim meeting today. 
Because it was a short meeting, the recording is already available and can be viewed at:  https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/3c9b868d338f4872adb790558ff2ce03

Best,
Nathalie Trenaman


--Apple-Mail=_04842A4E-58ED-40DF-9693-69882C014892-- From nobody Fri Oct 2 02:24:09 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7885B3A0F48 for ; Fri, 2 Oct 2020 02:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=nlnetlabs.nl 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 WhTAG7j77c5M for ; Fri, 2 Oct 2020 02:24:05 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 C75503A0F46 for ; Fri, 2 Oct 2020 02:24:05 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:6c37:42e1:6071:7ddf]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id BAA49261CA; Fri, 2 Oct 2020 11:24:03 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1601630643; bh=agBJGcfm27+vlA0lGeUidBsnmaESMKjI47lbg4x6o9w=; h=From:Date:Subject:To; b=dVn977R3MaxggwssEREMvXNf9ptoABpY9oMyuso1/L1Ebomin4cJdu01BOPpSZmE4 /tZOxLFLxK1i7poD46TdeEJp2NOd/LOR+KlzmOQxIOPnuu6oWhLn3EV0UiUufhYujp PLgs7X8/CIEloX9Qo2S8LneAmTxXFywC026cQZGc= From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 2 Oct 2020 11:24:03 +0200 Message-Id: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Sidrops] Example BGPSec Router certificate, and GBR for testing? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 09:24:08 -0000 Hi all, Does anyone have a real world BGPSec router certificate and Ghostbuster = object they could share for testing validation software? The router certificates use the same extension as delegated CA = certificates: ".cer". But, they are of course slightly different. = Relying parties should therefore be aware that when they loop over the = entries in a manifest, any file with the ".cer" extension might be = either. I am not aware of any BGPSec certificates in the wild, but they can = appear at any moment. Especially given the direction of the manifest = -bis document it's therefore important that RPs can deal with these = certificates properly. The same applies to Ghostbuster records. If there is an example that = could be shared, then this could help us and other RP implementers to = deal with these objects securely as well. Thanks, Tim= From nobody Thu Oct 8 23:41:49 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D630F3A09DE; Thu, 8 Oct 2020 23:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 YFYWYeZLCnLc; Thu, 8 Oct 2020 23:41:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D365C3A09D7; Thu, 8 Oct 2020 23:41:44 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7767942F8572B2F472E; Fri, 9 Oct 2020 07:41:42 +0100 (IST) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 07:41:42 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 9 Oct 2020 07:41:42 +0100 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.39]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Fri, 9 Oct 2020 14:41:38 +0800 From: Guyunan To: Melchior Aelmans , Chris Morrow CC: SIDROps Chairs , SIDR Operations WG , "sidrops-ads@ietf.org" Thread-Topic: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) Thread-Index: AQHWlVFKjypHpMvZl02QdAoy1p8G36mA4u+AgA38wyA= Date: Fri, 9 Oct 2020 06:41:39 +0000 Message-ID: References: <87imbybjne.wl-morrowc@ops-netman.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.195.233] Content-Type: multipart/alternative; boundary="_000_C01B0098369B2D4391851938DA6700B717C1D699DGGEML532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 06:41:47 -0000 --_000_C01B0098369B2D4391851938DA6700B717C1D699DGGEML532MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlbXMgcXVpdGUgdXNlZnVsIGZvciBsb2NhbCBtYW5hZ2VtZW50IG9mIHZhbGlkYXRlZCBjYWNo ZS4gQSBzbWFsbCBzdWdnZXN0aW9uLCBtYXliZSB0aGUgYXV0aG9ycyBjYW4gZnVydGhlciBjbGFy aWZ5IHRoZSB1c2Ugb2YgSFRUUCBhbmQgSFRUUHMsIHdoZXRoZXIgSFRUUHMgaXMgbWFuZGF0b3J5 LCBvciBpdOKAmXMgb3B0aW9uYWwgdXNpbmcgZWl0aGVyIEhUVFAgb25seSBvciBIVFRQcy4NCg0K U3VwcG9ydCBhZG9wdGlvbi4NCg0KQlIsDQoNCll1bmFuDQoNCkZyb206IFNpZHJvcHMgW21haWx0 bzpzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNZWxjaGlvciBBZWxtYW5z DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxLCAyMDIwIDEyOjUxIEFNDQpUbzogQ2hyaXMgTW9y cm93IDxtb3Jyb3djQG9wcy1uZXRtYW4ubmV0Pg0KQ2M6IFNJRFJPcHMgQ2hhaXJzIDxzaWRyb3Bz LWNoYWlyc0BpZXRmLm9yZz47IFNJRFIgT3BlcmF0aW9ucyBXRyA8c2lkcm9wc0BpZXRmLm9yZz47 IHNpZHJvcHMtYWRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIFdHIEFET1BUSU9O IC0gZHJhZnQtbWFkaS1zaWRyb3BzLXJ1c2ggLSBFTkRTIDEwLzEyLzIwMjAgKE9jdCAxMnRoKQ0K DQpBcyBhIGNvLWF1dGhvciBJIHN1cHBvcnQgYWRvcHRpb24gYnkgdGhlIFdHLg0KDQpUSGFua3Mh DQpNZWxjaGlvcg0KDQpPbiBNb24sIFNlcCAyOCwgMjAyMCBhdCA2OjM4IEFNIENocmlzIE1vcnJv dyA8bW9ycm93Y0BvcHMtbmV0bWFuLm5ldDxtYWlsdG86bW9ycm93Y0BvcHMtbmV0bWFuLm5ldD4+ IHdyb3RlOg0KDQpIb3dkeSwNCg0KUGxlYXNlIGNvbnNpZGVyIHRoaXMgdGhlIHN0YXJ0IG9mIGEg V0cgQWRvcHRpb24gY2FsbCBmb3IgdGhlIHN1YmplY3QNCmRyYWZ0LCB0aGUgYWJzdHJhY3Qgb2Yg d2hpY2ggaXM6DQoNCiAgIlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhvZCBmb3IgdHJhbnNm ZXJyaW5nIFJQS0kgdmFsaWRhdGVkIGNhY2hlDQogICB1cGRhdGUgaW5mb3JtYXRpb24gaW4gSlNP TiBvYmplY3QgZm9ybWF0IG92ZXIgSFRUUHMuIg0KDQpUaGUgVVJMIG9mIHdoaWNoIGlzOg0KICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hZGktc2lkcm9wcy1y dXNoLTAyDQoNClBsZWFzZSBnaXZlIHRoaXMgYSByZWFkLXRocm91Z2ggYW5kIGNvbnNpZGVyIGlm IHRoZSB3b3JrIGlzIGFwcHJvcHJpYXRlDQpmb3IgdGhlIFdHIHRvIHdvcmsgb24uDQoNCnRoYW5r cyENCi1jaHJpcw0KY28tY2hhaXItcGVyc29uYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNpZHJvcHNAaWV0 Zi5vcmc8bWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpZHJvcHMNCg== --_000_C01B0098369B2D4391851938DA6700B717C1D699DGGEML532MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNlZW1zIHF1aXRlIHVzZWZ1bCBmb3IgbG9jYWwgbWFuYWdlbWVudCBvZiB2YWxpZGF0 ZWQgY2FjaGUuIEEgc21hbGwgc3VnZ2VzdGlvbiwgbWF5YmUgdGhlIGF1dGhvcnMgY2FuIGZ1cnRo ZXIgY2xhcmlmeSB0aGUgdXNlIG9mIEhUVFAgYW5kIEhUVFBzLCB3aGV0aGVyIEhUVFBzDQogaXMg bWFuZGF0b3J5LCBvciBpdOKAmXMgb3B0aW9uYWwgdXNpbmcgZWl0aGVyIEhUVFAgb25seSBvciBI VFRQcy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5T dXBwb3J0IGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZdW5hbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTaWRyb3BzIFttYWlsdG86c2lk cm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NZWxjaGlvciBBZWxt YW5zPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDEsIDIwMjAgMTI6NTEgQU08 YnI+DQo8Yj5Ubzo8L2I+IENocmlzIE1vcnJvdyAmbHQ7bW9ycm93Y0BvcHMtbmV0bWFuLm5ldCZn dDs8YnI+DQo8Yj5DYzo8L2I+IFNJRFJPcHMgQ2hhaXJzICZsdDtzaWRyb3BzLWNoYWlyc0BpZXRm Lm9yZyZndDs7IFNJRFIgT3BlcmF0aW9ucyBXRyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs7IHNp ZHJvcHMtYWRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU2lkcm9wc10gV0cg QURPUFRJT04gLSBkcmFmdC1tYWRpLXNpZHJvcHMtcnVzaCAtIEVORFMgMTAvMTIvMjAyMCAoT2N0 IDEydGgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEg Y28tYXV0aG9yIEkgc3VwcG9ydCBhZG9wdGlvbiBieSB0aGUgV0cuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5USGFua3MhPGJyPg0KTWVsY2hpb3I8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBT ZXAgMjgsIDIwMjAgYXQgNjozOCBBTSBDaHJpcyBNb3Jyb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpt b3Jyb3djQG9wcy1uZXRtYW4ubmV0Ij5tb3Jyb3djQG9wcy1uZXRtYW4ubmV0PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpIb3dkeSw8YnI+DQo8YnI+DQpQbGVhc2UgY29uc2lkZXIgdGhpcyB0aGUgc3Rh cnQgb2YgYSBXRyBBZG9wdGlvbiBjYWxsIGZvciB0aGUgc3ViamVjdDxicj4NCmRyYWZ0LCB0aGUg YWJzdHJhY3Qgb2Ygd2hpY2ggaXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZxdW90O1RoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIG1ldGhvZCBmb3IgdHJhbnNmZXJyaW5nIFJQS0kgdmFsaWRhdGVkIGNhY2hl PGJyPg0KJm5ic3A7ICZuYnNwO3VwZGF0ZSBpbmZvcm1hdGlvbiBpbiBKU09OIG9iamVjdCBmb3Jt YXQgb3ZlciBIVFRQcy4mcXVvdDs8YnI+DQo8YnI+DQpUaGUgVVJMIG9mIHdoaWNoIGlzOjxicj4N CiZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LW1hZGktc2lkcm9wcy1ydXNoLTAyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hZGktc2lkcm9wcy1ydXNoLTAyPC9hPjxi cj4NCjxicj4NClBsZWFzZSBnaXZlIHRoaXMgYSByZWFkLXRocm91Z2ggYW5kIGNvbnNpZGVyIGlm IHRoZSB3b3JrIGlzIGFwcHJvcHJpYXRlPGJyPg0KZm9yIHRoZSBXRyB0byB3b3JrIG9uLjxicj4N Cjxicj4NCnRoYW5rcyE8YnI+DQotY2hyaXM8YnI+DQpjby1jaGFpci1wZXJzb25hPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpT aWRyb3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTaWRyb3BzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+U2lkcm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_C01B0098369B2D4391851938DA6700B717C1D699DGGEML532MBXchi_-- From nobody Fri Oct 9 03:51:04 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77273A0C36; Fri, 9 Oct 2020 03:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9PDgXn-dpdOH; Fri, 9 Oct 2020 03:50:59 -0700 (PDT) Received: from out20-37.mail.aliyun.com (out20-37.mail.aliyun.com [115.124.20.37]) (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 65EDD3A0C8F; Fri, 9 Oct 2020 03:50:56 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06848167|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.0117377-0.00352823-0.984734; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047204; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.Ih2HrVZ_1602240650; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.Ih2HrVZ_1602240650) by smtp.aliyun-inc.com(10.147.40.200); Fri, 09 Oct 2020 18:50:51 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Di Ma In-Reply-To: Date: Fri, 9 Oct 2020 18:50:49 +0800 Cc: Melchior Aelmans , Chris Morrow , SIDROps Chairs , SIDR Operations WG , "sidrops-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87imbybjne.wl-morrowc@ops-netman.net> To: Guyunan X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 10:51:03 -0000 Yunan, > 2020=E5=B9=B410=E6=9C=889=E6=97=A5 14:41=EF=BC=8CGuyunan = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Seems quite useful for local management of validated cache. A small = suggestion, maybe the authors can further clarify the use of HTTP and = HTTPs, whether HTTPs is mandatory, or it=E2=80=99s optional using either = HTTP only or HTTPs. =20 A very good catch. I think https is default at least as it is used in the name of this = draft literally. But I see a potential that http can work if IPsec has been established = between two cache servers. We can discuss it further if adopted as a WG item. Di > =20 > Support adoption. > =20 > BR, > =20 > Yunan > =20 > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Melchior = Aelmans > Sent: Thursday, October 1, 2020 12:51 AM > To: Chris Morrow > Cc: SIDROps Chairs ; SIDR Operations WG = ; sidrops-ads@ietf.org > Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS = 10/12/2020 (Oct 12th) > =20 > As a co-author I support adoption by the WG. > =20 > THanks! > Melchior > =20 > On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow = wrote: >=20 > Howdy, >=20 > Please consider this the start of a WG Adoption call for the subject > draft, the abstract of which is: >=20 > "This document defines a method for transferring RPKI validated = cache > update information in JSON object format over HTTPs." >=20 > The URL of which is: > https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 >=20 > Please give this a read-through and consider if the work is = appropriate > for the WG to work on. >=20 > thanks! > -chris > co-chair-persona >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Oct 13 00:30:31 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247E73A0EC6 for ; Tue, 13 Oct 2020 00:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=ripe.net 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 tYURr2y9GdBI for ; Tue, 13 Oct 2020 00:30:27 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6453A0EC0 for ; Tue, 13 Oct 2020 00:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Message-Id:To:Date:Subject:Mime-Version:Content-Type:From: CC; bh=dBXliJWV8SuL0c5uceIr9ZFupS2xHEbfn9/eAo1ee4U=; b=Ot6ZHsQkiSjG5zNiSCT+7/ wykHicMmgAfRqm93UpaeAZMuQFfKvRXTvlXaMLioX68qgy/AWPFm4pE8dZYdraEhRy+3ZqhOvnelf CAAdItznxxpIiqKde3bd1jkiDUrN7dAe2PlsLnKCZOCjzqrW9gop2qEnATZO8sXLS25JpXUj+6K6z Kmu8Q7xQ5O57zC6A6WY8MO208m/NW5Q6F6DjUpzzeXYoJqNH/b2kidu0MMrmCGHPFIliDbFpkqWUJ U9fTmZlkobbdkB6lUR/T5EdkdbdW/udt0pX95CyLAXtp0DFKnmBtv5KQ1O+EiGUjUbsylC/EVw1Yc orORwVcrzHGQ==; Received: from bufobufo.ripe.net ([193.0.23.13]:39022) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kSElN-0004MN-Rq for sidrops@ietf.org; Tue, 13 Oct 2020 09:30:25 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::dcc]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kSElN-00016J-Np for sidrops@ietf.org; Tue, 13 Oct 2020 09:30:25 +0200 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_D240D79B-68BE-4291-8748-512C80A60389" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 13 Oct 2020 09:30:24 +0200 References: To: SIDR Operations WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ae4bab1e1fd7c5762cee530d51b577399 Archived-At: Subject: Re: [Sidrops] Virtual Interim meeting recording X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 07:30:29 -0000 --Apple-Mail=_D240D79B-68BE-4291-8748-512C80A60389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Apologies, the recording has now been moved to: : = https://www.youtube.com/watch?v=3DRHLtv1QQrLY = Best, Nathalie > Op 1 okt. 2020, om 17:04 heeft Nathalie Trenaman = het volgende geschreven: >=20 > Hi all, >=20 > Thank you for attending the virtual interim meeting today.=20 > Because it was a short meeting, the recording is already available and = can be viewed at: = https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/3c9b= 868d338f4872adb790558ff2ce03 = >=20 > Best, > Nathalie Trenaman >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_D240D79B-68BE-4291-8748-512C80A60389 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

Apologies, the = recording has now been moved to: : https://www.youtube.com/watch?v=3DRHLtv1QQrLY

Best,
Nathalie

Op 1 okt. 2020, om 17:04 heeft = Nathalie Trenaman <nathalie@ripe.net> het volgende geschreven:

Hi all,

Thank you for attending = the virtual interim meeting today. 
Because it = was a short meeting, the recording is already available and can be = viewed at:  https://ietf.webex.com/recordingservice/sites/ietf/recording/pl= ayback/3c9b868d338f4872adb790558ff2ce03

Best,
Nathalie = Trenaman


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

= --Apple-Mail=_D240D79B-68BE-4291-8748-512C80A60389-- From nobody Thu Oct 15 12:14:48 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA13A13F7 for ; Thu, 15 Oct 2020 12:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.998, RCVD_IN_DNSWL_BLOCKED=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=nist.gov 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 YegyovjkxfZW for ; Thu, 15 Oct 2020 12:14:38 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2116.outbound.protection.outlook.com [40.107.89.116]) (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 5E8513A12FD for ; Thu, 15 Oct 2020 12:14:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g/1EIKHEQFb2V0sZDW5ZTqYkdlxf/fwIbAHQ4J+SDXCqYmZcv0enIHwK3ry58HVilyCQNX+vwuZ4opdqkZJ6yLyWuO53Z/AthDGhdvN9QRA/6e2ySVGJI5TVEqUjufKKXwj/YuY70J/okZtqGMwtsK+tOl7nZloVXDroZ0jA3f0OQ5Q77Kn2lFS6cH5RYoc2+gE5LbrpzSOZVdNQVCkMVLrk4Qm/7XhIUmwa7otbLjhsLCzo6fL6Kg/nJnnPMBCW1cZyZvgki5CkOKKQktLYyIXqnT4KXx9/bJo2kpXKyOEfq/JdCAESSXDFqf0N6On+/+TKLRvE1Ji0DtGVTT61KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MLROwjJ+bS4VCUjFSfTfujAgaQaZOL+J0vQrYmG4wdM=; b=XvUOWcHfRBbchB9pa7xO4rtQLEdUeuwqy4xY7vMccVmZnzGN8X3VH4GQf3FjGst6mjZ1B3tPammvgpyBE0PmhVGFgD+AvVbYmPgnH2gXOOI9Z4klIG+xEna3E+P1s0qX8JSGtCIM3lznw5pTiTLrgd2L6sLHxfqSWd3KGSuhTKY1szcI0lPVhzIDIS3ArArbCeWe+cnIhP1+MNtS0uzbbHr7PMAF7s6hPn4oQ1BHTkF4R8MQ1q8Ja7YolG2qq1/Pn3iwtBCCQVvLprc7w2CNvr5UL8Vo3zyUF1/q0gtF+oyNgrsnc0ajFi/i3+/Y6drUQMVZa655wVB/R8d9oDR1Bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MLROwjJ+bS4VCUjFSfTfujAgaQaZOL+J0vQrYmG4wdM=; b=RVQREDbg0WVOxFlIasFO392BPkSvZIO9fpOOp0q2C8R3JChVBb9nYkdFJl6v3tHYsIgReSDG5N1ZEBFLL7sWOQbYA1AczGVT1loe48SQAy+x1E1Z6Or8pkWE6podozqYlH5r2icbxiUj/qDzOuicuYGhY0rSE+LV7mjrdGKjzDA= Received: from SA0PR09MB6636.namprd09.prod.outlook.com (2603:10b6:806:ac::19) by SA9PR09MB5280.namprd09.prod.outlook.com (2603:10b6:806:45::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Thu, 15 Oct 2020 19:14:21 +0000 Received: from SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d]) by SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d%4]) with mapi id 15.20.3477.021; Thu, 15 Oct 2020 19:14:21 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" , "Montgomery, Douglas C. (Fed)" Thread-Topic: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt Thread-Index: AQHWk6uXSmv2SdqdjUWDbieQ3efDvqmBP5gAgBekxwA= Date: Thu, 15 Oct 2020 19:14:21 +0000 Message-ID: References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> <20200930141036.GD13264@bench.sobornost.net> In-Reply-To: <20200930141036.GD13264@bench.sobornost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:223::d8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0f3d5f83-9d34-4da1-7dd7-08d8713e855e x-ms-traffictypediagnostic: SA9PR09MB5280: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0FSNtOmeT9e5nDmN23NFo4Sgy0+zC6Y6sEpSifczvJQ4Z3QNRZ37X0l//dSGIsMqNIFEF5eENpc13ce29JQCfFWva3vt84hclwfkSM3aRBbLzLqIyAaoaLKXjMN9z4eNC717jVQlq+qNTyYmu3ibLi3crona21lqrmEcAQnB/Xhv60iTfrSACYdNG01q5a60jo64U9vUrVjQ+5VnLechplh2znv6bUkIww9X09C7x+UqXj1JtAhLUdovWO5w5+XeLKCnn/IOGo919YrojM9QN2A4GUZWjMGmyobxz0tpMnef9c/P5GyYMmix6O8p4Nz6Cdulc5iA8wY3atABU7uX4Xal86dhj7nxGKjdfRSOLV9HIYmsfvwDzj2fBBYk3ZPK4uf24NCjMhgyU5UBXxc7cg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6636.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(45080400002)(186003)(66946007)(8676002)(76116006)(91956017)(66556008)(6506007)(107886003)(66446008)(478600001)(64756008)(66476007)(4326008)(6512007)(966005)(71200400001)(2906002)(33656002)(86362001)(8936002)(83380400001)(30864003)(36756003)(54906003)(110136005)(316002)(66574015)(5660300002)(2616005)(6486002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6vlt4/ydhOe4ur5M4X2hCWgooBsDChcMRqkgjwGz4cIISnRQFzQsRI4/XmwswDsAvvKzOGsPivhwJRL0QkT+8IONEpx3sUDiDThyQ9GhRct9kCAd7hw0EGy8juB5gvcEqKiW/FqlrrFvzl/W/pAfOFgI6MJiU4bV+YjEoCwfc8Ec9cD+W6GqJvMrSsIHj8+g0XjUP9OLVtE/cgR2eRVUnjeTQXfSKzeMlwbjwwTMQ5c3l0cC8K3zu5Gzw8aDS10KucbpDhyljY9fmGQtIOJyBetZ+onEmskGjedE72EE4i96GQBEr7OqoJN0fMyWrX3i0Hn4HueOLNhbWfg3xDufFB71euAkqIEnoVKvj4gytgwyrFBxowsVU3/VltanH/+ahxD9znrzmlw32TnY0b1oM0fz4/b8TvAubaY0G5f6tcMPCMtrnA1L9x0FnMn1O+RAdmCj6mVEYvMdTjGleQrpEMnUTc5Yjax7k7hhgUhdtWBcgcOIUkyAe5Sqb0JtPJ/L39mn3BVIK6Ke8gEllvSfDbimdLjGUotCdrZBGd5JaHJCf8KeBshjgkr/vYxDrwS0KUdTFUEhLSf5My3B14ku6xbwx3GUFipH2IR6090yH9fchhMf3lWuv3QnxODbSL6DorKRP4OVD+pEkCHflj86VSQdqCWgHjlHDxwhj/D3FPQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6636.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f3d5f83-9d34-4da1-7dd7-08d8713e855e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 19:14:21.1104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tZVCtgWInEmSACQWEfUPF3/Xb+CVlH60l972I+f0WfPknBoVAHcbBu/ss0m3a03foWxxqxiNKDmvdo6B1E4FuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA9PR09MB5280 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:14:47 -0000 SGkgSm9iLA0KDQpJJ20gc29ycnkgZm9yIG15IGxhdGUgcmVwbHksIG15IGVtYWlsZXIgd2FzIGhp ZGluZyB0aGlzIGVtYWlsIGZyb20gbWUgYW5kIEkganVzdCBmb3VuZCBpdC4NCg0KSSBkbyBub3Qg YmVsaWV2ZSB0aGVyZSBpcyBhIG5lZWQgdG8gY2hhbmdlIHRoZSB0aXRsZSB0byBzcGVjaWZpY2Fs bHkgaW5jbHVkZSAiSW50ZXJuYWwgQkdQIi4NCldpdGhpbiB0aGUgbGF0ZXN0IGNoYW5nZXMsIHdl IHNwZWNpZmljYWxseSBhbGlnbmVkIHRoZSBkcmFmdCB0byBmb2xsb3cgdGhlIHNpZ25hbGluZyBh cyANCnNwZWNpZmllZCB3aXRoaW4gUkZDIDQzNjAuICBBcyB5b3Uga25vdywgUkZDIDQzNjAgZG9l cyBnb3Zlcm4gdGhlIGJvdW5kYXJpZXMgaW4gd2hpY2ggDQpub24tdHJhbnNpdGl2ZSBhdHRyaWJ1 dGVzIGNhbiBiZSB1c2VkIGFuZCB3ZSByZWZlcnJlZCB0byBSRkMgNDM2MCB3aGVyZSBldmVyIG5l Y2Vzc2FyeS4NCg0KSW4gZmFjdCwgdXBvbiB5b3VyIHJlcXVlc3QgZHVyaW5nIDEwOCwgd2UgbW9k aWZpZWQgdGhlIGRyYWZ0IGluIHN1Y2ggdGhhdCBpdCBnb2VzIG9uZSBzdGVwIA0KZnVydGhlciBi eSBsaW1pdGluZyB0aGUgc2lnbmFsaW5nIG9mIHZhbGlkYXRpb24gc3RhdGUgdG8gb25seSB2YWx1 ZXMgdGhhdCB3ZXJlIGxvY2FsbHkgY29tcHV0ZWQgDQpieSB0aGUgc2VuZGluZyBCR1Agcm91dGVy IGl0c2VsZi4gIFRoYXQgaXMsIGF0IHRoZSByb3V0ZXIgbGV2ZWwsIHRoZSBhdHRyaWJ1dGUgaXMg bm9uLXRyYW5zaXRpdmUsIGV2ZW4gaW4gdGhlIGNhc2Ugb2YgaUJHUC4NCg0KVGhlcmVmb3JlIEkg ZG8gbm90IHNlZSBhbnkgbmVlZCBmb3IgZnVydGhlciBtb2RpZmljYXRpb24uIA0KDQpUaGFua3Ms DQpPbGl2ZXINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1 dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQooT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYN Cg0KDQrvu79PbiA5LzMwLzIwLCAxMDoxMCBBTSwgIlNpZHJvcHMgb24gYmVoYWxmIG9mIEpvYiBT bmlqZGVycyIgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam9iQG50dC5u ZXQ+IHdyb3RlOg0KDQogICAgRGVhciBhbGwsDQoNCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRv Y3VtZW50IGFuZCB3b3VsZCBsaWtlIHRvIG9mZmVyIHNvbWUgZmVlZGJhY2suDQoNCiAgICBUaGUg dGl0bGUgcHJvYmFibHkgc2hvdWxkIHJlYWQgIkJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25h bGluZyB2aWEgSW50ZXJuYWwgQkdQIiANCg0KICAgIEZ1cnRoZXJtb3JlIHRoZSBkb2N1bWVudCBw cm9iYWJseSBiZW5lZml0cyByZXBsYWNpbmcgIkJHUCBuZWlnaGJvciIgd2l0aA0KICAgICJJQkdQ IG5laWdoYm9yIiwgc2ltaWxhcmx5ICJCR1AgcGVlciIgYW5kICJwZWVyIiBzaG91bGQgYmUgcmVw bGFjZWQgd2l0aA0KICAgICJJQkdQIG5laWdoYm9yIiBhbmQgIm5laWdoYm9yIiBmb3IgbW9yZSBj b25zaXN0ZW50IHJlYWRpbmcuIEVtcGhhc2lzIG9uDQogICAgSUJHUCBpcyBpbXBvcnRhbnQgYXMg dGhpcyBkb2N1bWVudCBvdXRsaW5lcyBub24tdHJhbnNpdGl2ZSBleHRlbmRlZA0KICAgIGNvbW11 bml0aWVzLiAoTGV0J3MgcGFyayBkaXNjdXNzaW9uIGFib3V0IEVCR1AgdnMgQ09ORkVEIHZzIElC R1AgZm9yIHRoZQ0KICAgIHNha2Ugb2YgcHJvZ3Jlc3NpbmcgY29udmVyc2F0aW9uIGFib3V0IHRo ZSBzdWJzdGFuY2Ugb2YgdGhpcyBkcmFmdCkNCg0KICAgIEludGVybmFsIGluY29uc2lzdGVuY3kg aW4gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmcNCiAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCiAgICBSRkMgODIwNSBzZWN0aW9uIDUuMSBzdGF0ZXMgIkJHUHNlYyB2YWxpZGF0aW9u IG5lZWQgb25seSBiZSBwZXJmb3JtZWQgYXQNCiAgICB0aGUgZUJHUCBlZGdlLiIsIGFuZCBhbHNv ICJhIEJHUHNlYyBzcGVha2VyIE1BWSB0ZW1wb3JhcmlseSBkZWZlcg0KICAgIHZhbGlkYXRpb24g b2YgaW5jb21pbmcgVVBEQVRFIG1lc3NhZ2VzLiIgDQoNCiAgICBXaXRoIHRoZSBhYm92ZSBpbiBt aW5kLCBpbiBzZWN0aW9uIDQgb2YgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWdu YWxpbmcNCiAgICB0aGUgZmlyc3QgcGFyYWdyYXBoIHJlZmVyZW5jZXMgYW4gRUJHUCBzcGVha2Vy IHRoYXQgcmVjZWl2ZWQgYSBCR1BzZWMNCiAgICBVUERBVEUgZnJvbSBhIG5laWdoYm9yIG91dHNp ZGUgdGhlIGFkbWluaXN0cmF0aXZlIGRvbWFpbi4gSWYgb25lIGZvbGxvd3MNCiAgICB0aGUgbG9n aWNhbCBvdXRjb21lcyBvZiB0ZW1wb3JhcmlseSBkZWZlcm1lbnQgb2YgdmFsaWRhdGlvbiwgdGhl IEVCR1ANCiAgICBub2RlIHdhcyB1bmFibGUgdG8gcGVyZm9ybSBCR1BzZWMgcGF0aCB2YWxpZGF0 aW9uLCB0aHVzIE1VU1Qgc2V0DQogICAgdmFsaWRhdGlvbiBzdGF0ZSAnVW52ZXJpZmllZCcuIENv bnNlcXVlbnRseSB0aGUgQkdQIFVQREFURSBpcw0KICAgIGRpc3RyaWJ1dGVkIHRvIElCR1Agc3Bl YWtlcnMsIHdoaWNoIGFsbCBoYXZlIHRvIHBlcmZvcm0gZnVsbCBCR1BzZWMgcGF0aA0KICAgIHZh bGlkYXRpb24gaW4gb3JkZXIgdG8gY29uZmlybSB0aGF0IHRoZSB2YWxpZGF0aW9uIHN0YXRlIGlz IGluZGVlZA0KICAgICJVbnZlcmlmaWVkIi4gT25lIG1pZ2h0IGFzIHdlbGwgbm90IGF0dGFjaCBh bnkgY29tbXVuaXR5IGF0IGFsbCBiZWNhdXNlDQogICAgc3BlYWtlciBBIGRvZXNuJ3Qgc2lnbmFs IG9mIG5vdGUgLSBiZWNhdXNlIGl0IGRvZXNuJ3Qga25vdy4NCg0KICAgIElmIHRoZSBFQkdQIGVk Z2UgZGV2aWNlIHRoYXQgKHRlbXBvcmFyaWx5IG9yIGZvcmV2ZXIpIGlzIHVuYWJsZSB0byBkbw0K ICAgIEJHUHNlYyB2YWxpZGF0aW9uLCBpdCB3aWxsIGZvciB0aGUgZHVyYXRpb24gb2YgdGhhdCBl dmVudCBiZSB1bmFibGUgdG8NCiAgICBzZXQgdGhlIGFwcHJvcHJpYXRlIGNvbW11bml0eSwgYXMg aXQgY2Fubm90IHZhbGlkYXRlLiBXaGF0ZXZlcg0KICAgIGNvbW11bml0aWVzIGl0IHNldHMsIG90 aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrIHN0aWxsIG5lZWQgdG8gdmVyaWZ5DQogICAgd2hldGhl ciBvciBub3QgdGhlIGNvbW11bml0eSBpcyB0cnVlLiBBcyBzdWNoLCB0aGUgY29tbXVuaXRpZXMg YXJlDQogICAgbWVyZWx5IG92ZXJoZWFkLg0KDQogICAgSW1hZ2luZSBhIHR3byBub2RlIG5ldHdv cmsgKGFzY2lpIGFydCwgbWluZCB5b3VyIE1VQSk6DQoNCiAgICAJCQkJICstLS0tLS0tLSsNCiAg ICAJCQkJIHxBUyA2NTEyM3wNCiAgICAJCQkJICstLS0tKy0tLSsNCiAgICAJCQkJCSAgfA0KICAg IAkJCSAgICstLS0tLS0rLS0tLSsNCiAgICAJKy0tRUJHUDEtLS0rIEFTIDY1MDAwMSArLS0tLS0t LS0tLS0tLS0tLUVCR1AyLS0tLS0tKw0KICAgIAl8ICAgICAgICAgICstLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgCXwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAJfCAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgfA0KICAgIAl8ICAgICAgICB8IEFTIDY1NjY2IHJ1 bm5pbmcgZHJhZnQtc2lnbmFsaW5nICB8ICAgICB8DQogICAgCXwgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAJfCAgICAgICAgfCArLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgfCAgICAgfA0KICAgIAkrLS0tLS0tLS0tLSsgQkdQ IHNwZWFrZXIgQSB8KioqKklCR1AgICAgICAgICB8ICAgICB8DQogICAgCQkJIHwgKy0tLS0tLS0t LS0tLS0tLSsgICAgICogICAgICAgICAgIHwgICAgIHwNCiAgICAJCQkgfCAgICAgICAgICAgICAg ICAgICAgICAgKiAgICAgICAgICAgfCAgICAgfA0KICAgIAkJCSB8ICAgICAgICAgICAgICAgKy0t LS0tLS0qLS0tLS0tLSsgICB8ICAgICB8DQogICAgCQkJIHwgICAgICAgICAgICAgICB8IEJHUCBT cGVha2VyIEIgKy0tLS0tLS0tLSsNCiAgICAJCQkgfCAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0rICAgfA0KICAgIAkJCSB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgCQkJICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgIElm IEJHUCBzcGVha2VyIEEgY2Fubm90IHBlcmZvcm0gQkdQc2VjIHZhbGlkYXRpb24gb24gRUJHUDEs IGl0IGNhbid0DQogICAgY29uZmlybSB3aGV0aGVyIF82NTAwMV82NTEyMyQgaXMgYSB2YWxpZCBC R1BTZWNfUEFUSCBvciBub3QuIEJ1dA0KICAgIHdoYXRldmVyIGNvbmNsdXNpb24gc3BlYWtlciBB IGRyYXdzLCBzcGVha2VyIEIgcmVjZWl2ZXMgdGhlDQogICAgXzY1MDAwMV82NTEyMyQgcGF0aCB2 aWEgaXRzIG93biBFQkdQMiBzZXNzaW9uIHdpdGggNjUwMDAxLiBXaGF0ZXZlcg0KICAgIHZhbGlk YXRpb24gKGFuZCBzaWduYWxpbmcpIGhhcHBlbnMgdmlhIHRoZSBJQkdQIHNlc3Npb24sIGl0IGRv ZXMgbm90IGluDQogICAgYW55IHdheSBwb3NpdGl2ZWx5IGltcGFjdCBzcGVha2VyIEIncyBkZWNp c2lvbnMsIGFzIHNwZWFrZXIgQiBjYW4ndCB1c2UNCiAgICBJQkdQIGluZm9ybWF0aW9uIGFzIGlu cHV0IGludG8gaXRzIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzIHJlZ2FyZGluZyB0aGUNCiAgICBC R1AgVVBEQVRFIHJlY2VpdmVkIHZpYSBFQkdQMi4gRHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRh dGlvbi1zaWduYWxpbmcNCiAgICBpcyBub3QgYSByZXBsYWNlbWVudCBvciBhbHRlcm5hdGl2ZSB0 byB0aGUgUlBLSS1Uby1Sb3V0ZXIgcHJvdG9jb2wuDQoNCiAgICBJZiB0aGUgbWVhbmluZyBvZiB0 aGUgJ3VudmVyaWZpZWQnIHN0YXRlIGlzICdtYXliZSBJIHdpbGwgZG8gdmFsaWRhdGlvbg0KICAg IGxhdGVyLCBtYXliZSBub3QnLCBJIGRvbid0IHNlZSBhbnkgcHJhY3RpY2FsIGFwcGxpY2F0aW9u Lg0KDQogICAgSWYgdGhlIG1lYW5pbmcgb2YgJ3ZhbGlkJyBpcyB0byBiZSB0YWtlbiBhdCBmYWNl IHZhbHVlLCBhZ2FpbiwgdGhlcmUgaXMNCiAgICBubyB2YWx1ZSBpbiBhIHN0YW5kYXJkaXplZCBj b21tdW5pdHksIHNlZSBSRkMgMzUxNC4NCg0KICAgIElmIHRoZSBtZWFuaW5nIG9mICdpbnZhbGlk JyBpcyB0aGF0IGZvbGxvd2luZyBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uIHRoZQ0KICAgIHJvdXRl IGlzIGRlZW1lZCBpbnZhbGlkLCB0aGVuIHdoeSB3YXMgaXQgcHJvcGFnYXRlZCBpbiB0aGUgZmly c3QgcGxhY2U/DQoNCiAgICBJZiBTcGVha2VyIEIgaXMgbm90IGFibGUgdG8gZG8gUGF0aCBWYWxp ZGF0aW9uLCB3aGF0ZXZlciAnaW52YWxpZCcNCiAgICBzaWduYWwgaXQgcmVjZWl2ZXMgb24gaXRz IElCR1Agc2Vzc2lvbiBkb2VzIG5vdCBhbmQgY2Fubm90IG92ZXJyaWRlIG9yDQogICAgaW5mbHVl bmNlIHdoYXQgd2FzIHJlY2VpdmVkIHZpYSBFQkdQMi4NCg0KICAgIFRoZSB0ZXh0IGluIHRoZSBh YnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGFib3V0ICd0ZW1wb3JhcmlseSBkZWZlcm1lbnQgb2YN CiAgICB2YWxpZGF0aW9uJyBzaG91bGQgcHJvYmFibHkgYmUgcmVtb3ZlZCBhcyBpdCBpcyBoYXJk IHRvIHNlZSBob3cgaW4gdGhlDQogICAgc2l0dWF0aW9uIG9mIHRlbXBvcmFyaWx5IGRlZmVybWVu dCB0aGUgZXhpc3RlbmNlIG9mIHRoZXNlIGNvbW11bml0aWVzDQogICAgbWFrZXMgc2Vuc2UuDQoN CiAgICBVbmRlcGxveWFiaWxpdHkNCiAgICAtLS0tLS0tLS0tLS0tLS0NCg0KICAgIEFuIGFyY2hp dGVjdHVyYWwgY2hvaWNlIHRvIHVzZSBCR1AgY29tbXVuaXRpZXMgZm9yIGFueSBwdXJwb3NlDQog ICAgb2Z0ZW50aW1lcyBzdGVtcyBmcm9tIGFuIG9wZXJhdG9yJ3MgYWJpbGl0eSB0byBkZXBsb3kg J2EgbmV3IHRoaW5nJyBpbiBhDQogICAgbmV0d29yayB3aGVyZSAocGFydCBvZikgdGhlIG5vZGVz IGhhdmUgbm90IHlldCBiZWVuIHVwZ3JhZGVkLiBHb29kDQogICAgdXNlZnVsIGV4YW1wbGVzIG9m IHRoaXMgbWVjaGFuaXNtIGFyZSBHUkFDRUZVTF9TSFVURE9XTiBhbmQgTk9fRVhQT1JULg0KDQog ICAgVGhlIGRvY3VtZW50IHN0YXRlcyBpbiBzZWN0aW9uIDMgIklmIHRoZSByb3V0ZXIgc3VwcG9y dHMgdGhlIGV4dGVuc2lvbg0KICAgIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCIgLi4uIHdo aWNoIGltcGxpZXMgdGhhdCBhbGwgbm9kZXMgaW4gYW4NCiAgICBhZG1pbmlzdHJhdGl2ZSBkb21h aW4gbXVzdCBiZSB1cGdyYWRlZCwgd2hpY2ggaW4gdHVybiBzb21ld2hhdCBudWxsaWZpZXMNCiAg ICB0aGUganVzdGlmaWNhdGlvbiB0byB1c2UgY29tbXVuaXRpZXMgaW4gdGhlIGZpcnN0IHBsYWNl LiBUaGlzIGRvZXNuJ3QNCiAgICBhbGxvdyBhIGJyb3duZmllbGQgdXBncmFkZSENCg0KICAgIFNl Y3Rpb24gMy4xICJFcnJvciBIYW5kbGluZyBhdCBQZWVycyIgcmVhZHMgYXMgYSBzaW1wbGUgcGFy YWdyYXBoLCBidXQNCiAgICBpcyBicml0dGxlIGFuZCBlcnJvci1wcm9uZSB0byBpbXBsZW1lbnQg aW4gcm91dGluZyBwb2xpY3kuIE1vc3QgbmV0d29yaw0KICAgIG9wZXJhdG9ycyBhcmUgYWNjdXN0 b21lZCB0byBpbXBsZW1lbnRpbmcgYSAndGVzdCAmIGJyYW5jaCcgcHJvY2VkdXJlIGJ5DQogICAg cG9zaXRpdmUgY29tbXVuaXR5IG1hdGNoaW5nIGFuZCB0aGVuIHRha2luZyBzb21lIGFjdGlvbi4g UkZDIDE5OTcNCiAgICBkZWZpbmVzIGNvbW11bml0aWVzIGFzICJBIGNvbW11bml0eSBpcyBhIGdy b3VwIG9mIGRlc3RpbmF0aW9ucyB3aGljaA0KICAgIHNoYXJlIHNvbWUgY29tbW9uIHByb3BlcnR5 LiIgVGhlIGltcGxpY2F0aW9uIGlzIHRoYXQgd2hlbiBtdWx0aXBsZQ0KICAgIGNvbW11bml0aWVz IGFyZSBhdHRhY2hlZCB0byBhIHJvdXRlLCB0aGUgcm91dGUgc2ltcGx5IGhhcyBtdWx0aXBsZQ0K ICAgIHByb3BlcnRpZXMuDQoNCiAgICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IG91dGxpbmVzIGEg bWVjaGFuaXNtIHdoZXJlIHNwZWNpZmljIGNvbWJpbmF0aW9ucw0KICAgIG9mIGNvbW11bml0aWVz IGFyZSBpbnZhbGlkIGlucHV0OiAiKDB4NDMsVEJELDApIOKIqSAoMHg0MyxUQkQsMSkiLCBvcg0K ICAgICIoMHg0MyxUQkQsMSkg4oipICgweDQzLFRCRCwyKSIsIG9yICIoMHg0MyxUQkQsMikg4oip ICgweDQzLFRCRCwwKSIuIEluDQogICAgY3VycmVudGx5IGF2YWlsYWJsZSBjb21tZXJjaWFsfGZy ZWUtb2YtdGhlLXNoZWxmIEJHUCBpbXBsZW1lbnRhdGlvbnMNCiAgICBpbXBsZW1lbnRpbmcgYWRl cXVhdGUgZXJyb3IgaGFuZGxpbmcgaXMgZXJyb3ItcHJvbmUuIFJGQyA4MDk3IHNoYXJlcw0KICAg IHRoaXMgd2Vha25lc3MuDQoNCiAgICBUaGUgSW50cm9kdWN0aW9uIHByb3Bvc2VzIHRoYXQgYSBy ZWR1Y3Rpb24gb2YgcGF0aCB2YWxpZGF0aW9uIHByb2Nlc3NpbmcNCiAgICBsb2FkIGNhbiBiZSBh Y2hpZXZlZCwgaG93ZXZlciBTZWN0aW9uIDQgc3RhdGVzIHRoYXQgaWYgdGhlcmUgaXMgYQ0KICAg IGRpc2NyZXBhbmN5IGJldHdlZW4gdGhlIGxvY2FsbHkgY29tcHV0ZWQgdmFsaWRhdGlvbiBzdGF0 ZSBhbmQgdGhlDQogICAgY29tbXVuaXR5LCB0aGUgbG9jYWxseSBjb21wdXRlZCBzdGF0ZSB0YWtl cyBwcmVjZWRlbmNlLiBUaHVzLCBubyBsb2FkDQogICAgcHJvY2Vzc2luZyByZWR1Y3Rpb24gY2Fu IGJlIGFjaGlldmVkIGJlY2F1c2UgYSBCR1BzZWMgY2FwYWJsZSBub2RlIG11c3QNCiAgICBjb21w dXRlIHRoZSB2YWxpZGF0aW9uIHN0YXRlIGJlZm9yZSBpdCBjYW4gY29tcGFyZSBpdCB0byB0aGUg Y29tbXVuaXR5Lg0KDQogICAgTm90IGFuYWxvZ291cyB0byBSRkMgODA5Nw0KICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIFRvIG1hbnkgdGhpcyBkcmFmdCBtYXkgYXBwZWFyIGFz ICdmb3Igc3VyZSwgd2UgbmVlZCBzb21ldGhpbmcgc2ltaWxhcg0KICAgIGZvciBiZ3BzZWMgYXMg d2UgaGF2ZSBmb3Igcm91dGUgb3JpZ2luIHZhbGlkYXRpb24nIC0gYnV0IEkgdGhpbmsgbm8gc3Vj aA0KICAgIGVxdWl2YWxlbmNlIGV4aXN0cywgb3IgbmVlZHMgdG8gZXhpc3QuDQoNCiAgICBSRkMg ODA5NyBkZWZpbmVzIGEgc2V0IG9mIEJHUCBjb21tdW5pdGllcyB3aGljaCBjYW4gb3B0aW9uYWxs eSBiZQ0KICAgIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCAqYWZ0ZXIqIHRoZSBPcmlnaW4gVmFs aWRhdGlvbiBwcm9jZWR1cmUgKFJGQw0KICAgIDY4MTEpICpzdWNjZXNzZnVsbHkqIGlzIGV4ZWN1 dGVkLiBUaGlzIGluIGNvbnRyYXN0IHRvDQogICAgZHJhZnQtYmdwc2VjLXZhbGlkYXRpb24tc2ln bmFsaW5nLCB3aGVyZSBhIG5vZGUgaXMgKnVuYWJsZSogdG8gcGF0aA0KICAgIHZhbGlkYXRpb24s IHRodXMgY2FuIG5ldmVyIHNldCB0aGUgYXBwcm9wcmlhdGUgY29tbXVuaXRpZXMuIFJGQyA4MDk3 DQogICAgZG9lcyBub3QgZGVzY3JpYmUgYSBzaXR1YXRpb24gd2hlcmUgT3JpZ2luIFZhbGlkYXRp b24gaXMgdGVtcG9yYXJpbHkNCiAgICBkZWZlcnJlZC4NCg0KICAgIFJlamVjdCBkb24ndCB0YWcg KGRvLCBkb24ndCB0YWxrIGFib3V0IGRvaW5nIGl0KQ0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgSWYgYSByb3V0ZSBpcyBjb25zaWRl cmVkIGludmFsaWQgKGZvciB3aGF0ZXZlciByZWFzb24sIGJlYXV0eSBpcyBpbiB0aGUNCiAgICBl eWUgb2YgdGhlIGJlaG9sZGVyKSwgdGhlIHJvdXRlIHNob3VsZCBiZSByZWplY3RlZC4gTWVyZWx5 IHRhZ2dpbmcgYW4NCiAgICBpbnZhbGlkIHJvdXRlIHdpdGggYSBzcGVjaWZpYyBjb21tdW5pdHkg YW5kIHByb3BhZ2F0aW5nIGl0IGZ1cnRoZXIsIGlzIGENCiAgICB1c2VsZXNzIGV4Y2VyY2lzZS4g U3VjaCBkZXNpZ25zIGhhbXBlcnMgZGVwbG95bWVudCBvZiBhY3R1YWwgc2VjdXJpdHkNCiAgICBt ZWFzdXJlcy4gSWYgYW4gb3BlcmF0b3Igd2FudHMgdG8gdGFnIGludmFsaWQgcm91dGVzIGZvciBh bmFseXRpY2FsDQogICAgcHVycG9zZXMsIHRoZXkgY2FuIGVhc2lseSBkbyBzbyBhbmQgY2FuIGNo b29zZSBmcm9tIG1pbGlvbnMgb2YgdmFsdWVzDQogICAgdXNpbmcgYW55IG9mIHRoZSBmbGF2b3Jz IG9mIGNvbW11bml0aWVzIHRoYXQgYXJlIGF2YWlsYWJsZS4gSWYgeW91ICphcmUqDQogICAgcHJv cGFnYXRpbmcgYW4gaW52YWxpZCByb3V0ZSwgeW91IGFyZSBwcm9wYWdhdGluZyBhbiBpbnZhbGlk IHJvdXRlIC0gaW4NCiAgICB3aGljaCBjYXNlIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0ZXZlciBj b21tdW5pdGllcyBhcmUgYXR0YWNoZWQgdG8gaXQuDQoNCiAgICBDb25jbHVzaW9uDQogICAgLS0t LS0tLS0tLQ0KDQogICAgQXQgdGhpcyBwb2ludCBpbiB0aW1lIEkgZG9uJ3QgdGhpbmsgdGhpcyBk cmFmdCBjYW4gcHJvY2VlZCB0bw0KICAgIHB1YmxpY2F0aW9uLCBmcm9tIHRoZSBkb2N1bWVudCBp dHNlbGYgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQNCiAgICBiZW5lZml0cyBjYW4gYmUgYWNo aWV2ZWQgYW5kIGhvdyB0aGlzIGJlbmVmaXRzIEludGVybmV0IG9wZXJhdGlvbnMuIFRoZQ0KICAg IGRyYWZ0IHJlcXVpcmVzIG5ldyBjb2RlIG9uIGRldmljZXMgaW4gYWRkaXRpb24gdG8gd2hhdCBh IEJHUHNlYyBjYXBhYmxlDQogICAgaW1wbGVtZW50YXRpb24gd291bGQgcmVxdWlyZS4gQW5kIGlu IHRvZGF5J3Mgd29ybGQgdGhlcmUgYXJlbid0DQogICAgb2ZmLXRoZS1zaGVsZiBCR1BzZWMgaW1w bGVtZW50YXRpb25zIHRvIHN0YXJ0IHdpdGgsIHNvIHBpbGluZyBvbg0KICAgIGFkZGl0aW9uYWwg Y29kZSByZXF1aXJlbWVudHMgaXMgdG9vIGVhcmx5IGluIHRoZSBpbm5vdmF0aW9uIGN5Y2xlDQog ICAgYW55aG93LiBVc2luZyBjb21tdW5pdGllcyBpcyBubyBzdWJzdGl0dXRlIGZvciBCR1BzZWMg dmFsaWRhdGlvbiBvciBmb3INCiAgICBSVFIsIHRoaXMgZG9jdW1lbnQgbWF5IHN1YnRseSBsZWFk IHBlb3BsZSB0byBiZWxpZXZlIG90aGVyd2lzZS4NCg0KICAgIEl0IGlzIHBvc3NpYmxlIEkgbWlz dW5kZXJzdG9vZCB0aGluZ3MsIEkgbG9vayBmb3J3YXJkIHRvIGZlZWRiYWNrIGZyb20NCiAgICB0 aGUgZ3JvdXAuDQoNCiAgICBLaW5kIHJlZ2FyZHMsDQoNCiAgICBKb2INCg0KICAgIHBzLiBuaXRw aWNrOiBvbmUgb2YgdGhlIGF1dGhvcidzIGNvbXBhbnkgbmFtZXMgc2VlbXMgbWlzc3BlbGxlZC4N Cg0KICAgIE9uIEZyaSwgU2VwIDI1LCAyMDIwIGF0IDA3OjE5OjEwUE0gLTA3MDAsIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCiAgICA+IA0KICAgID4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KICAgID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU0lEUiBPcGVyYXRp b25zIFdHIG9mIHRoZSBJRVRGLg0KICAgID4gDQogICAgPiAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25hbGluZw0KICAgID4gICAgICAgICBBdXRo b3JzICAgICAgICAgOiBPbGl2ZXIgQm9yY2hlcnQNCiAgICA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgRG91ZyBNb250Z29tZXJ5DQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIERh bmllbCBLb3BwDQogICAgPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtc2lkcm9wcy1iZ3BzZWMt dmFsaWRhdGlvbi1zaWduYWxpbmctMDUudHh0DQogICAgPiAJUGFnZXMgICAgICAgICAgIDogOA0K ICAgID4gCURhdGUgICAgICAgICAgICA6IDIwMjAtMDktMjUNCiAgICA+IA0KICAgID4gQWJzdHJh Y3Q6DQogICAgPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQkdQIG5vbi10cmFuc2l0 aXZlIGV4dGVuZGVkIGNvbW11bml0eSB0bw0KICAgID4gICAgY2FycnkgdGhlIEJHUHNlYyBwYXRo IHZhbGlkYXRpb24gc3RhdGUuICBCR1Agc3BlYWtlcnMgdGhhdCByZWNlaXZlDQogICAgPiAgICB0 aGlzIGNvbW11bml0eSBzdHJpbmcgY2FuIHVzZSB0aGUgZW1iZWRkZWQgQkdQc2VjIHZhbGlkYXRp b24gc3RhdGUgaW4NCiAgICA+ICAgIGNvbmp1bmN0aW9uIHdpdGggY29uZmlndXJlZCBsb2NhbCBw b2xpY2llcyB0byBpbmZsdWVuY2UgdGhlaXINCiAgICA+ICAgIGRlY2lzaW9uIHByb2Nlc3MuICBU aGUgYWJpbGl0eSB0byBhY2NlcHQgYW5kIGFjdCBvbiBCR1BzZWMgcGF0aA0KICAgID4gICAgdmFs aWRhdGlvbiBzdGF0ZSBmcm9tIGEgbmVpZ2hib3IgYWxsb3dzIGZvciBhIHJlZHVjdGlvbiBvZiBw YXRoDQogICAgPiAgICB2YWxpZGF0aW9uIHByb2Nlc3NpbmcgbG9hZCBhbmQvb3IgaW5jcmVhc2Vk IHJlc2lsaWVuY2UgaW4gdGhlIGV2ZW50DQogICAgPiAgICB0aGF0IGEgcm91dGVyIGlzIHRlbXBv cmFyaWx5IHVuYWJsZSB0byBwZXJmb3JtIGxvY2FsIHBhdGggdmFsaWRhdGlvbi4NCiAgICA+IA0K ICAgID4gDQogICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJh ZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmclMkYmYW1wO2RhdGE9MDIlN0Mw MSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDOTEyZTY2ZGM3Y2RjNGU0MDhmZDkwOGQ4 NjU0YWE1OGElN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3 MzcwNzE4NTY1MDEwMTM1JmFtcDtzZGF0YT1qJTJGb2g2amlabHdTbjFNY3Q2YUJaVWZYN0Y3SVdn ZmJMY3Y4OWM1Z3ZzSjAlM0QmYW1wO3Jlc2VydmVkPTANCiAgICA+IA0KICAgID4gVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgID4gaHR0cHM6Ly9nY2Mw Mi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWdu YWxpbmctMDUmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdD OTEyZTY2ZGM3Y2RjNGU0MDhmZDkwOGQ4NjU0YWE1OGElN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1 NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MzcwNzE4NTY1MDEwMTM1JmFtcDtzZGF0YT0zeElNeDNv SFExOW45ZXc3TUJnb1h2aFRVa1dtJTJCeEFHeHFWdHQlMkJZM3JSOCUzRCZhbXA7cmVzZXJ2ZWQ9 MA0KICAgID4gaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJh ZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUmYW1wO2RhdGE9MDIlN0Mw MSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDOTEyZTY2ZGM3Y2RjNGU0MDhmZDkwOGQ4 NjU0YWE1OGElN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3 MzcwNzE4NTY1MDIwMDkxJmFtcDtzZGF0YT1jNEpDOWw5bGpUMGsycE8lMkJYVkR0TnRjUlB4TGxq Ykg1WGU4ZE1zTzN3Y0UlM0QmYW1wO3Jlc2VydmVkPTANCiAgICA+IA0KICAgID4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgID4gaHR0cHM6Ly9n Y2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGcmZjZGlmZiUzRnVybDIlM0RkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxp ZGF0aW9uLXNpZ25hbGluZy0wNSZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQw bmlzdC5nb3YlN0M5MTJlNjZkYzdjZGM0ZTQwOGZkOTA4ZDg2NTRhYTU4YSU3QzJhYjVkODJmZDhm YTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzElN0M2MzczNzA3MTg1NjUwMjAwOTEmYW1wO3Nk YXRhPWQ0elV2USUyRnFJelQ1ckZKckdZUUE0MGxOZHczR0hmZVdYYlBHV1hVYUtFTSUzRCZhbXA7 cmVzZXJ2ZWQ9MA0KICAgID4gDQogICAgPiANCiAgICA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAg ICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICA+IGh0dHBzOi8vZ2NjMDIuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1mdHAlM0ElMkYlMkZmdHAuaWV0Zi5vcmcl MkZpbnRlcm5ldC1kcmFmdHMlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0 MG5pc3QuZ292JTdDOTEyZTY2ZGM3Y2RjNGU0MDhmZDkwOGQ4NjU0YWE1OGElN0MyYWI1ZDgyZmQ4 ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MzcwNzE4NTY1MDIwMDkxJmFtcDtz ZGF0YT1iSDBVMVFJcmx5V0ZzUTc2enolMkZOQk1sQ05LMThnZUtuckRJQUFJeUZVT1UlM0QmYW1w O3Jlc2VydmVkPTANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gU2lkcm9wcyBtYWlsaW5nIGxpc3QNCiAg ICA+IFNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVy dCU0MG5pc3QuZ292JTdDOTEyZTY2ZGM3Y2RjNGU0MDhmZDkwOGQ4NjU0YWE1OGElN0MyYWI1ZDgy ZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MzcwNzE4NTY1MDIwMDkxJmFt cDtzZGF0YT1ZVWpOQXpPUmk0TlRmZEkyYlZ2RDN3ekVxR1o3RiUyQnR6aG1mUnhSUEtFSTQlM0Qm YW1wO3Jlc2VydmVkPTANCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgU2lkcm9wcyBtYWlsaW5nIGxpc3QNCiAgICBTaWRyb3BzQGlldGYu b3JnDQogICAgaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lk cm9wcyZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M5MTJl NjZkYzdjZGM0ZTQwOGZkOTA4ZDg2NTRhYTU4YSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzElN0M2MzczNzA3MTg1NjUwMjAwOTEmYW1wO3NkYXRhPVlVak5Bek9SaTRO VGZkSTJiVnZEM3d6RXFHWjdGJTJCdHpobWZSeFJQS0VJNCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQo= From nobody Thu Oct 15 12:39:20 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BCC3A1330 for ; Thu, 15 Oct 2020 12:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zooveZ32uG-7 for ; Thu, 15 Oct 2020 12:39:17 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E403A0FC2 for ; Thu, 15 Oct 2020 12:39:17 -0700 (PDT) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id C54C4220188; Thu, 15 Oct 2020 19:39:15 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id de1791f3; Thu, 15 Oct 2020 19:39:13 +0000 (UTC) Date: Thu, 15 Oct 2020 19:39:13 +0000 From: Job Snijders To: "Borchert, Oliver (Fed)" Cc: "sidrops@ietf.org" , "Borchert, Oliver (Fed)" , "Montgomery, Douglas C. (Fed)" Message-ID: <20201015193913.GQ23031@bench.sobornost.net> References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> <20200930141036.GD13264@bench.sobornost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:39:19 -0000 Dear Oliver, On Thu, Oct 15, 2020 at 07:14:21PM +0000, Borchert, Oliver (Fed) wrote: > I do not believe there is a need to change the title to specifically > include "Internal BGP". OK, sure. The document title is just the document title. > Therefore I do not see any need for further modification. I am not sure I follow. On the third line of my review I made a suggestion about the title, to which you reacted, but then more text followed. The rest of the review details technical obstacles I perceive with the Internet-Draft in its current form. I attempted to organize the review by using '------' (markdown format) to separate the various conceptual issues I perceive. Kind regards, Job From nobody Thu Oct 15 13:53:43 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2313A03FC for ; Thu, 15 Oct 2020 13:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.998, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 s60WyYPRx_Nj for ; Thu, 15 Oct 2020 13:53:39 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2115.outbound.protection.outlook.com [40.107.91.115]) (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 9F1553A02C1 for ; Thu, 15 Oct 2020 13:53:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KPgYblkiU54cLEFdMnEwGvfRdxaBu38lj/8kwVkMB9RVDQAIGcTB2GMTvjIyZ3F7XzNjvyVVvykLq4swM0CQkZgw4LBCcnYOmovdvLdbGegomKPwZXVyhhRzyHtyQgSarUqHteXt4JxM9tcpJQXukwAg4zrWKZdFpRReMpAjBHJdCxppQ9/zFgoZNTVdSPq4bKmZm/ZRpEh9ToKQJOErDGjJzVLfEb5S7aiQHixPS6noVlJhMayIo2z5euICI7BmcgajZwI2fCRxsS0gncLTObLm+Lh57x9eHHcCVjcWI66S8cX6WqDSiT4nTKFghC07r5AeKqTtncXJTBSJWu+cYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+MumOMWsOybKmF0I8ERefd+E+kEmD3iYY4LquGBgzCk=; b=cqfkmQsV9A/xXP0SdwIQAUhxkLF0CVEzae2jgbtcJfZU8KaYsbwB26uwnRv6kTdPWXSMjKRkhEjnADqQnVm5zwBJkYdQRTci3wHvQBn1TGPxfuuWSOCeB+/1CZwlo7qX0PvZhEZjtVnjQEqf0rJXLgTYGGUa3su/d07xqXs+KtA+6ZmeRMIBo76hJyzmiH505p+3TRaAsF/8XjZKevq62aIa47lAQu3L3BcfTMHHnAffYt3IUAOfRyUKkg8Z86PyvBNBKxvSCflqUfOYheJzbB3HR0/9WT6GrnnU/6M4EriidHgvCDbinc+LeD0lFvlzLkuxlPtP9y9PVLRJjSpdCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+MumOMWsOybKmF0I8ERefd+E+kEmD3iYY4LquGBgzCk=; b=fF/zQDklAA1kHFm7p6m7UDcJTpIhOS4HLL8i4Pyps2YKKHvEf0PlM/rEXYMflb2ejQb4Q7qFOlZg9PTIKb3g50wELmp8mesbjp4mdYpvprsCJg0IEqjhL3NATKk2VWo1FtcIfTtoxHIKRdYINKSAwZ8U+x5qsSTbsHGU7I60xZQ= Received: from SA0PR09MB6636.namprd09.prod.outlook.com (2603:10b6:806:ac::19) by SA9PR09MB4992.namprd09.prod.outlook.com (2603:10b6:806:4c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Thu, 15 Oct 2020 20:53:36 +0000 Received: from SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d]) by SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d%4]) with mapi id 15.20.3477.021; Thu, 15 Oct 2020 20:53:35 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , "Borchert, Oliver (Fed)" CC: "sidrops@ietf.org" , "Montgomery, Douglas C. (Fed)" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt Thread-Index: AQHWk6uXSmv2SdqdjUWDbieQ3efDvqmBP5gAgBekxwCAAEoBgP//0bmA Date: Thu, 15 Oct 2020 20:53:35 +0000 Message-ID: References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> <20200930141036.GD13264@bench.sobornost.net> <20201015193913.GQ23031@bench.sobornost.net> In-Reply-To: <20201015193913.GQ23031@bench.sobornost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:223::d8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7c6b4bd4-4059-433e-802d-08d8714c6296 x-ms-traffictypediagnostic: SA9PR09MB4992: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4z33RevRedvccpOcA8uTltE865Xul/0kD2Xd9GUL4/XMrJVBwo7cIPGhtmNM7NA8Tj949cIDVgcC7T52JYZqpnU758XJvlmIP1Gdal2+cGKePTXtUzkfYu1KZWydkJ5Yq5CUMEDkQTTC1CuDNF1Y0Wooh4CT6nF9gDCRDpXdb8M/3j5l0226Z+GSUp/Zb+OI2Dh47QcvLF2x9g7kBlBDnnkQcl9Cmba5olc8OIG7yFepY5MBZssqo40N8lfGDcdxDP2yH7tZRPhKAbcwLgzGBunYNle1Xq8//TbIQbSsmAK91ofFGwX+siIWFyu4sDU++sMVfY/k2kAS8/1SAWtQsg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6636.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(8676002)(66556008)(6486002)(66476007)(5660300002)(316002)(110136005)(6512007)(6506007)(66574015)(54906003)(91956017)(36756003)(8936002)(4326008)(83380400001)(86362001)(71200400001)(66446008)(107886003)(76116006)(64756008)(2906002)(478600001)(66946007)(186003)(2616005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: blGgARQ6hU4QmLuyvK1w594kFU9/ATmBKlkmWH3GHQt2KwyNOoardVjDf3IEnwUMDY1cE1bSMzUwei0J3pE0LPIKwsOF4RWeocDAoMmgu9PRJ/DUcxmxpHJXCRiEp6aGZmf4HIu/8aQTSLyVXp9Pa8X5WRKEUXCYyczw8lPqIdrWfFHnueAFeABG29esM0r338l3A1cfkhoyWF3rM8PakhQ3eAjcj2COtUZwa4PmPwlKbJF04Us3RnNbls7Nu/ZDdr6QFqIxPiUnlGhDTwMCSeFL2QXSs/mSPydiDXodtdvD8DAWuOucyM6XfYS6Tq1mQWgZaUboTWGL2K2zkEyv2tq4FB/MYJ0CX0zXAs+rHGnnbLzam62Yu19YpLu9YmUEdsORdvoWPbGTY1riDi7BBSiz+zmYhvWi7iUZhTdXGEYQhMyD0sruPS8OhqifvXcx2pwspds/tyQYasGCSJQrAAgBK+NlajJHybXR4pMu8llzjdcZm3iIAgkujGPz/tO4LKlfwl8k0LPeSf7ZSwrYzhrFSIVZIhXQCY7DDgfBPhNFtWx97k3DItTXbKsBRw9jSpXq+iRf7U2LLyq+Kcm6zwSpS3f+AZKFzEHdyCi/uRR/HwJjYCU638E06TjuOwUs/4o81x0RXBDyAYyOcbTk54i6O0HFBc2VmZQnwlVWe2M= Content-Type: text/plain; charset="utf-8" Content-ID: <89FFC27904FECF44BF1A1052319C6804@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6636.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c6b4bd4-4059-433e-802d-08d8714c6296 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 20:53:35.6556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dFW5zOLiiG7YTLk8EOaB2jkNGmC4bXILE2j6SYA0ftPF//D4Q+VXJO2v91DqZTvl4MKGHD3zijLfZjVTVrYDrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA9PR09MB4992 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:53:42 -0000 SGkgSm9iLA0KDQpNeSBiYWQsIHNvbWVob3cgSSBtaXNzZWQgdGhlIHRlY2huaWNhbCBwb3J0aW9u IG9mIHlvdXIgcmV2aWV3LiBJIG5vdGljZWQgdGhlIC0tLS0tIGJ1dCBkaWQgbm90IHJlYWxpemUg dGhlcmUgaXMgbW9yZSB0byBjb21lLCBJIG1pcy1yZWFkIGl0IGFzIHBhcnQgb2YgYW4gZWFybGll ciBlbWFpbCAtIHNvcnJ5IQ0KDQpJIHdpbGwgZ28gb3ZlciBpdCBub3cgYW5kIGdldCBiYWNrIHRv IHlvdS4NCg0KVGhhbmtzLA0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdA0K TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KKE9mZmljZSkg KzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcNCiANCg0K77u/T24gMTAv MTUvMjAsIDM6MzkgUE0sICJKb2IgU25pamRlcnMiIDxqb2JAbnR0Lm5ldD4gd3JvdGU6DQoNCiAg ICBEZWFyIE9saXZlciwNCg0KICAgIE9uIFRodSwgT2N0IDE1LCAyMDIwIGF0IDA3OjE0OjIxUE0g KzAwMDAsIEJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCkgd3JvdGU6DQogICAgPiBJIGRvIG5vdCBiZWxp ZXZlIHRoZXJlIGlzIGEgbmVlZCB0byBjaGFuZ2UgdGhlIHRpdGxlIHRvIHNwZWNpZmljYWxseQ0K ICAgID4gaW5jbHVkZSAiSW50ZXJuYWwgQkdQIi4NCg0KICAgIE9LLCBzdXJlLiBUaGUgZG9jdW1l bnQgdGl0bGUgaXMganVzdCB0aGUgZG9jdW1lbnQgdGl0bGUuDQoNCiAgICA+IFRoZXJlZm9yZSBJ IGRvIG5vdCBzZWUgYW55IG5lZWQgZm9yIGZ1cnRoZXIgbW9kaWZpY2F0aW9uLiANCg0KICAgIEkg YW0gbm90IHN1cmUgSSBmb2xsb3cuIE9uIHRoZSB0aGlyZCBsaW5lIG9mIG15IHJldmlldyBJIG1h ZGUgYQ0KICAgIHN1Z2dlc3Rpb24gYWJvdXQgdGhlIHRpdGxlLCB0byB3aGljaCB5b3UgcmVhY3Rl ZCwgYnV0IHRoZW4gbW9yZSB0ZXh0DQogICAgZm9sbG93ZWQuIFRoZSByZXN0IG9mIHRoZSByZXZp ZXcgZGV0YWlscyB0ZWNobmljYWwgb2JzdGFjbGVzIEkgcGVyY2VpdmUNCiAgICB3aXRoIHRoZSBJ bnRlcm5ldC1EcmFmdCBpbiBpdHMgY3VycmVudCBmb3JtLg0KDQogICAgSSBhdHRlbXB0ZWQgdG8g b3JnYW5pemUgdGhlIHJldmlldyBieSB1c2luZyAnLS0tLS0tJyAobWFya2Rvd24gZm9ybWF0KQ0K ICAgIHRvIHNlcGFyYXRlIHRoZSB2YXJpb3VzIGNvbmNlcHR1YWwgaXNzdWVzIEkgcGVyY2VpdmUu DQoNCiAgICBLaW5kIHJlZ2FyZHMsDQoNCiAgICBKb2INCg0K From nobody Thu Oct 15 18:49:42 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCD43A0E55 for ; Thu, 15 Oct 2020 18:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.998, 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=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-QYWUJ_kiE4 for ; Thu, 15 Oct 2020 18:49:31 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2108.outbound.protection.outlook.com [40.107.91.108]) (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 614EC3A0E37 for ; Thu, 15 Oct 2020 18:49:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I+NJwOlW0Zluc+55lp3ljDnbaA03FigS46dBfIfBGAf6m+wDPZ6hzT2YUCGbBZ2uKNMmmvcLL6t8poDEma+mIm235L0QqrI4ehC8DzdPt5Bjc8RSEjkpQgVOoRFtjzvzg5FMnCbLmngJUfQ8Wc4kVs+YzlgRB/QcNyMhM5Nx+Etg8j0GkOiOl0mjHG244FHDpTqIobmHpqmGV7S3uc7pZjmMGD+0dGoc4Vu4CTJJCQXoVnZttz4tRCVTC2p/3hDl25tuJemnflFxoDw8t/2wTJiovAeS/6d1bE8y9TL3OrUFOKniITa2GfEz+XY1RXxoHg3OyI1xv1xtq4K1s7Amrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmzWoov3+PqxqvEqqwpYUeQENNbIrfZwF99MUufBr80=; b=X7qqu8cLNE8q33RQf5PPx7nqk8oVKPJm7kvBzeUSQvRva8fvmtlp28GEPp6VbfElfA2ZPVpigxyyfKAC6/3L30EzWcBhTc1f5nblQ6OtN2X2N8sWl1LF8a1KltLEy2rCPHi3Afq3vK/p/zfL4L3HNHhk5AToO3GLIXSnfTAvf+apGDNfKEpE+MC4xpH3oI74rqSBt9HC0sKbeAOaA0La9A8+EW97IffA3hL1jR3q1h8N3FvmX8TqK7zbSRLLFuwsx6ebCvK+8yHCLQJ0P9YqDm8fRG3QGQHyYXci7U1PEef5+oOaLijHFIl/BgUjFWMjt9H2dZPm7H99W3JcTPnVyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmzWoov3+PqxqvEqqwpYUeQENNbIrfZwF99MUufBr80=; b=D7uf/Hk+UdJqPdpr59QQlx+n55G8ZdRyBAAU3sN+9v9W14mYNSw3mHfTgxr8OIQhLuKj23JLOARzJOzKFsRJKxz4eEML1a8JEJrqNRYey7XSVjqFVcZLge+m0BcOESvrsvhV3aEh3cUv0A3d/m2riR7xYI2lFehXTr6ngIJ3pRk= Received: from SA0PR09MB6636.namprd09.prod.outlook.com (2603:10b6:806:ac::19) by SA0PR09MB7115.namprd09.prod.outlook.com (2603:10b6:806:7d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.23; Fri, 16 Oct 2020 01:49:28 +0000 Received: from SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d]) by SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d%4]) with mapi id 15.20.3477.021; Fri, 16 Oct 2020 01:49:28 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , "sidrops@ietf.org" CC: "Montgomery, Douglas C. (Fed)" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt Thread-Index: AQHWk6uXSmv2SdqdjUWDbieQ3efDvqmBP5gAgBekxwCAAG5CAA== Date: Fri, 16 Oct 2020 01:49:28 +0000 Message-ID: <3C7E14C8-9200-4991-8E8D-BE821F3A1D06@nist.gov> References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> <20200930141036.GD13264@bench.sobornost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:165::78] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a1eef5f5-10ef-4a3a-c775-08d87175b82e x-ms-traffictypediagnostic: SA0PR09MB7115: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hMq24J9XdEBSFUjdHp5VNpny2fhqSu54dOYJ3Syi1v1kuZcWAzsPktue0riKZCsPoll3uLwj9YSui7is3lUkT9B99wvmtqJAccKihmeRUt864h3h3tNUDU82sZkYmUHhzwCoJV9UTAaktTceV6Nx03I0AeHcZ5kUTOIpUbut+CSgP0ceSTlIZ8Xk0Aji7LxU/d2LRtYrQuxq3zQy86z466UPXYa8TcohScc+E7ZU3jb4Z9dE2M3ggGsgjKJvjA3KPuVhbzbaOQC3UYRfnIOhkDAGA349hb/UchE0bLprOwkuoiJ92kNnHw3h2Hsa++KIpyW+zVjz569G7l4nA4PWZQgsyYZiRbrQxc5KPwErJ6sn3aIoz44lkC9TQMA79qjtcNRaolgdQmDWTe0gSHqydg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6636.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(110136005)(54906003)(2616005)(6486002)(478600001)(30864003)(33656002)(966005)(5660300002)(186003)(66574015)(316002)(8676002)(64756008)(2906002)(71200400001)(107886003)(86362001)(6512007)(83380400001)(76116006)(66556008)(91956017)(66446008)(66476007)(66946007)(8936002)(6506007)(36756003)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rddGJmb74XpkQsst1CJxYuGZ4lPjIUniQpkys07e9Ki9n2Npk1AoqAvSZ9lZNbjJEyWMPBA3nupU8YE2tgvMNQrihWrrU9SbbEFF/koqyonLl5knzafx3y6Lv6TqvA/0p1mA+b2qJ7rlxv4rUvY4cC2dvxh+zKblvYDEhqtS/+8l3EJR7kuOuUl4/kpYz7YIpnnAfosNxf1rxG5OmnTR7dv+3gZ7UNjkXZ/UiGN1iOvnZAvaRCnu42CZDFV+tfeZzxvDzjFkKwjXJaQ4EdqTyc8COjfypAj0F39vyjU7bF9/vET/NNs3IvdeKsGXsu7C923tusoduyUUDiuDVkVuh5FU3yLeSE5mpLkE3zYWMD/jln4CPE122m7724mPgXz+C5MT16lY5SZQlErKJBRn8+PdK8fMM3XZNqmGKSADCSMLVV0zLxbIksNHXo8SYOuU/D8fOnHs4GZRnrvMN70AeZb/VUILY+Y2U/oHgYeyBWh//4oBMzQaX8nTbI8dmV550EfqUQnXT1yecj4tcwXO2phtmG7s5gCVVZ9R1noX+Py6dPw+tb5bHSLEE2kn+vLyN9YkEj9g7DTOP+pmeRaE2UdhCyPlkfd6VLaqAjlZ4Rq1ZubJw3fG5WDsGN/rkhiAHDWgN87WKUXDfEecueZK74OyvaRk9EMrx8njRcSrCFE= Content-Type: text/plain; charset="utf-8" Content-ID: <4EBEC770F0D3AA4B9D715C3C32B6D199@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6636.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a1eef5f5-10ef-4a3a-c775-08d87175b82e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 01:49:28.7135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nOO/y1PxBmnMxORBauI4V5dXRZxvrdEP2LnxDQdvXzFkRZP0k9K0NC/Og2zfvs8YKvcAUDZ2Wo4IaEYDSxVEeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7115 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 01:49:41 -0000 SGkgSm9iLCANCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBJIHJlbW92ZWQgc29tZSBvdmVy aGVhZCB0byBvbmx5IGZvY3VzIG9uIHlvdXIgDQp0ZWNobmljYWwgcmV2aWV3LiBJIGFkZGVkIFtv Yl0gaW4gZnJvbnQgb2YgYWxsIG15IGlubGluZSBjb21tZW50cy4NCg0KICAgICAgICBJbnRlcm5h bCBpbmNvbnNpc3RlbmN5IGluIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFs aW5nDQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAgICBSRkMgODIwNSBzZWN0aW9uIDUuMSBz dGF0ZXMgIkJHUHNlYyB2YWxpZGF0aW9uIG5lZWQgb25seSBiZSBwZXJmb3JtZWQgYXQNCiAgICAg ICAgdGhlIGVCR1AgZWRnZS4iLCBhbmQgYWxzbyAiYSBCR1BzZWMgc3BlYWtlciBNQVkgdGVtcG9y YXJpbHkgZGVmZXINCiAgICAgICAgdmFsaWRhdGlvbiBvZiBpbmNvbWluZyBVUERBVEUgbWVzc2Fn ZXMuIiANCg0KICAgICAgICBXaXRoIHRoZSBhYm92ZSBpbiBtaW5kLCBpbiBzZWN0aW9uIDQgb2Yg ZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmcNCiAgICAgICAgdGhlIGZp cnN0IHBhcmFncmFwaCByZWZlcmVuY2VzIGFuIEVCR1Agc3BlYWtlciB0aGF0IHJlY2VpdmVkIGEg QkdQc2VjDQogICAgICAgIFVQREFURSBmcm9tIGEgbmVpZ2hib3Igb3V0c2lkZSB0aGUgYWRtaW5p c3RyYXRpdmUgZG9tYWluLiBJZiBvbmUgZm9sbG93cw0KICAgICAgICB0aGUgbG9naWNhbCBvdXRj b21lcyBvZiB0ZW1wb3JhcmlseSBkZWZlcm1lbnQgb2YgdmFsaWRhdGlvbiwgdGhlIEVCR1ANCiAg ICAgICAgbm9kZSB3YXMgdW5hYmxlIHRvIHBlcmZvcm0gQkdQc2VjIHBhdGggdmFsaWRhdGlvbiwg dGh1cyBNVVNUIHNldA0KICAgICAgICB2YWxpZGF0aW9uIHN0YXRlICdVbnZlcmlmaWVkJy4gQ29u c2VxdWVudGx5IHRoZSBCR1AgVVBEQVRFIGlzDQogICAgICAgIGRpc3RyaWJ1dGVkIHRvIElCR1Ag c3BlYWtlcnMsIHdoaWNoIGFsbCBoYXZlIHRvIHBlcmZvcm0gZnVsbCBCR1BzZWMgcGF0aA0KICAg ICAgICB2YWxpZGF0aW9uIGluIG9yZGVyIHRvIGNvbmZpcm0gdGhhdCB0aGUgdmFsaWRhdGlvbiBz dGF0ZSBpcyBpbmRlZWQNCiAgICAgICAgIlVudmVyaWZpZWQiLiBPbmUgbWlnaHQgYXMgd2VsbCBu b3QgYXR0YWNoIGFueSBjb21tdW5pdHkgYXQgYWxsIGJlY2F1c2UNCiAgICAgICAgc3BlYWtlciBB IGRvZXNuJ3Qgc2lnbmFsIG9mIG5vdGUgLSBiZWNhdXNlIGl0IGRvZXNuJ3Qga25vdy4NCg0KICAg ICAgICBJZiB0aGUgRUJHUCBlZGdlIGRldmljZSB0aGF0ICh0ZW1wb3JhcmlseSBvciBmb3JldmVy KSBpcyB1bmFibGUgdG8gZG8NCiAgICAgICAgQkdQc2VjIHZhbGlkYXRpb24sIGl0IHdpbGwgZm9y IHRoZSBkdXJhdGlvbiBvZiB0aGF0IGV2ZW50IGJlIHVuYWJsZSB0bw0KICAgICAgICBzZXQgdGhl IGFwcHJvcHJpYXRlIGNvbW11bml0eSwgYXMgaXQgY2Fubm90IHZhbGlkYXRlLiBXaGF0ZXZlcg0K ICAgICAgICBjb21tdW5pdGllcyBpdCBzZXRzLCBvdGhlciBub2RlcyBpbiB0aGUgbmV0d29yayBz dGlsbCBuZWVkIHRvIHZlcmlmeQ0KICAgICAgICB3aGV0aGVyIG9yIG5vdCB0aGUgY29tbXVuaXR5 IGlzIHRydWUuIEFzIHN1Y2gsIHRoZSBjb21tdW5pdGllcyBhcmUNCiAgICAgICAgbWVyZWx5IG92 ZXJoZWFkLg0KDQogICAgICAgIEltYWdpbmUgYSB0d28gbm9kZSBuZXR3b3JrIChhc2NpaSBhcnQs IG1pbmQgeW91ciBNVUEpOg0KDQogICAgICAgIAkJCQkgKy0tLS0tLS0tKw0KICAgICAgICAJCQkJ IHxBUyA2NTEyM3wNCiAgICAgICAgCQkJCSArLS0tLSstLS0rDQogICAgICAgIAkJCQkJICB8DQog ICAgICAgIAkJCSAgICstLS0tLS0rLS0tLSsNCiAgICAgICAgCSstLUVCR1AxLS0tKyBBUyA2NTAw MDEgKy0tLS0tLS0tLS0tLS0tLS1FQkdQMi0tLS0tLSsNCiAgICAgICAgCXwgICAgICAgICAgKy0t LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgCXwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgCXwg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgIHwNCiAgICAg ICAgCXwgICAgICAgIHwgQVMgNjU2NjYgcnVubmluZyBkcmFmdC1zaWduYWxpbmcgIHwgICAgIHwN CiAgICAgICAgCXwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgIHwNCiAgICAgICAgCXwgICAgICAgIHwgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAg ICAgIHwgICAgIHwNCiAgICAgICAgCSstLS0tLS0tLS0tKyBCR1Agc3BlYWtlciBBIHwqKioqSUJH UCAgICAgICAgIHwgICAgIHwNCiAgICAgICAgCQkJIHwgKy0tLS0tLS0tLS0tLS0tLSsgICAgICog ICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgCQkJIHwgICAgICAgICAgICAgICAgICAgICAgICog ICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgCQkJIHwgICAgICAgICAgICAgICArLS0tLS0tLSot LS0tLS0tKyAgIHwgICAgIHwNCiAgICAgICAgCQkJIHwgICAgICAgICAgICAgICB8IEJHUCBTcGVh a2VyIEIgKy0tLS0tLS0tLSsNCiAgICAgICAgCQkJIHwgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKyAgIHwNCiAgICAgICAgCQkJIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgCQkJICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cg0KICAgICAgICBJZiBCR1Agc3BlYWtlciBBIGNhbm5vdCBwZXJmb3JtIEJHUHNlYyB2YWxpZGF0 aW9uIG9uIEVCR1AxLCBpdCBjYW4ndA0KICAgICAgICBjb25maXJtIHdoZXRoZXIgXzY1MDAxXzY1 MTIzJCBpcyBhIHZhbGlkIEJHUFNlY19QQVRIIG9yIG5vdC4gQnV0DQogICAgICAgIHdoYXRldmVy IGNvbmNsdXNpb24gc3BlYWtlciBBIGRyYXdzLCBzcGVha2VyIEIgcmVjZWl2ZXMgdGhlDQogICAg ICAgIF82NTAwMDFfNjUxMjMkIHBhdGggdmlhIGl0cyBvd24gRUJHUDIgc2Vzc2lvbiB3aXRoIDY1 MDAwMS4gV2hhdGV2ZXINCiAgICAgICAgdmFsaWRhdGlvbiAoYW5kIHNpZ25hbGluZykgaGFwcGVu cyB2aWEgdGhlIElCR1Agc2Vzc2lvbiwgaXQgZG9lcyBub3QgaW4NCiAgICAgICAgYW55IHdheSBw b3NpdGl2ZWx5IGltcGFjdCBzcGVha2VyIEIncyBkZWNpc2lvbnMsIGFzIHNwZWFrZXIgQiBjYW4n dCB1c2UNCiAgICAgICAgSUJHUCBpbmZvcm1hdGlvbiBhcyBpbnB1dCBpbnRvIGl0cyBkZWNpc2lv biBtYWtpbmcgcHJvY2VzcyByZWdhcmRpbmcgdGhlDQogICAgICAgIEJHUCBVUERBVEUgcmVjZWl2 ZWQgdmlhIEVCR1AyLiANCg0KW29iXSBZb3UgYXJlIGNvcnJlY3QgdGhhdCBpbiB0aGlzIGV4YW1w bGUsIEIgZG9lcyBub3QgZ2FpbiBhbnl0aGluZyBmcm9tIEEuICBTYWlkIA0KW29iXSB0aGF0LCBv bmNlIEIgdmFsaWRhdGVzIGFuZCBzZWxlY3RzIHRoZSByb3V0ZSBmb3IgaW5zdGFuY2UgdXNpbmcg dGhlIEVCR1AyIHBhdGgNCltvYl0gYW5kIG5vdCB0aGUgcm91dGUgaXQgbGVhcm5lZCBmcm9tIEEs IGl0IHRoZW4gd2lsbCBmb3J3YXJkIHRoZSByb3V0ZSB0byBBIA0KW29iXSBhbmQgQSBjYW4gcmVj ZWl2ZSBhbmQgdXNlIHRoZSB2YWxpZGF0aW9uIHN0YXRlIGl0IGxlYXJuZWQgZnJvbSBCLg0KW29i XSBIZXJlIHRoZSBvcGVyYXRvciBhbHNvIGhhcyBhIG1lYW5zIG9mIGFuYWx5emluZyB3aGF0IGhh cHBlbmVkLg0KDQogICAgICAgIERyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFs aW5nDQogICAgICAgIGlzIG5vdCBhIHJlcGxhY2VtZW50IG9yIGFsdGVybmF0aXZlIHRvIHRoZSBS UEtJLVRvLVJvdXRlciBwcm90b2NvbC4NCg0KW29iXSBXZSBuZXZlciBzYWlkIHRoYXQgZHJhZnQt c2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmcgaXMgYSANCltvYl0gcmVwbGFjZW1l bnQgZm9yIHJwa2ktdG8tcm91dGVyLiAgSW4gZmFjdCBib3RoIGhhdmUgYSBjb21wbGV0ZWx5IGRp ZmZlcmVudA0KW29iXSB0YXNrIHRvIHBlcmZvcm0uICBUaGlzIGRyYWZ0IG9ubHkgc2lnbmFscyB0 aGUgdmFsaWRhdGlvbiBzdGF0ZSBhIHJvdXRlciANCltvYl0gY2FsY3VsYXRlZCB0byBpdHMgcGVl ci4gIFJQS0ktdG8tcm91dGVyIHByb3ZpZGVzIFJPQSBpbmZvcm1hdGlvbiBhbmQgQkdQc2VjDQpb b2JdIHB1YmxpYyBrZXlzIHRvIHRoZSByb3V0ZXIuICBUd28gY29tcGxldGVseSBkaWZmZXJlbnQg dGFza3MuIA0KDQogICAgICAgIElmIHRoZSBtZWFuaW5nIG9mIHRoZSAndW52ZXJpZmllZCcgc3Rh dGUgaXMgJ21heWJlIEkgd2lsbCBkbyB2YWxpZGF0aW9uDQogICAgICAgIGxhdGVyLCBtYXliZSBu b3QnLCBJIGRvbid0IHNlZSBhbnkgcHJhY3RpY2FsIGFwcGxpY2F0aW9uLg0KDQpbb2JdIElmIHRo ZSByb3V0ZXIgaXMgb3ZlcmxvYWRlZCBpdCBtaWdodCBwZXJmb3JtIGxhenkgZXZhbHVhdGlvbiAi ZGVmZXIgdGhlIHZhbGlkYXRpb24iDQpbb2JdIFNlZSBSRkMgODIwNS4NCg0KICAgICAgICBJZiB0 aGUgbWVhbmluZyBvZiAndmFsaWQnIGlzIHRvIGJlIHRha2VuIGF0IGZhY2UgdmFsdWUsIGFnYWlu LCB0aGVyZSBpcw0KICAgICAgICBubyB2YWx1ZSBpbiBhIHN0YW5kYXJkaXplZCBjb21tdW5pdHks IHNlZSBSRkMgMzUxNC4NCg0KW29iXSBUaGUgbWVhbmluZyBvZiB0aGUgdmFsaWRhdGlvbiBzdGF0 ZSAndmFsaWQnIGlzIGRlZmluZWQgaW4gUkZDIDgyMDUgd2hpY2ggd2UNCltvYl0gZGVmZXIgdG9v IGluIHRoaXMgZHJhZnQuDQoNCiAgICAgICAgSWYgdGhlIG1lYW5pbmcgb2YgJ2ludmFsaWQnIGlz IHRoYXQgZm9sbG93aW5nIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24gdGhlDQogICAgICAgIHJvdXRl IGlzIGRlZW1lZCBpbnZhbGlkLCB0aGVuIHdoeSB3YXMgaXQgcHJvcGFnYXRlZCBpbiB0aGUgZmly c3QgcGxhY2U/DQoNCltvYl0gRHJvcHBpbmcgYW4gaW52YWxpZCByb3V0ZSBpcyBsb2NhbCBwb2xp Y3kgc28gb25lIG1pZ2h0IGRlY2lkZSB0byBub3QgZHJvcCBhbiANCltvYl0gaW52YWxpZCByb3V0 ZSBidXQgbG93LXByZWYgaXQgaW5zdGVhZCBhbmQgc2VsZWN0IGlmIG5vIG90aGVyIHBhdGggaXMg YXZhaWxhYmxlLg0KW29iXSBBbHNvLCB0aGVyZSBhcmUgc3RpbGwgdGhlIHR3byBvdGhlciBzaXR1 YXRpb25zIGxlZnQsICd1bnZlcmlmaWVkJyBhbmQgJ3ZhbGlkJy4NCg0KICAgICAgICBJZiBTcGVh a2VyIEIgaXMgbm90IGFibGUgdG8gZG8gUGF0aCBWYWxpZGF0aW9uLCB3aGF0ZXZlciAnaW52YWxp ZCcNCiAgICAgICAgc2lnbmFsIGl0IHJlY2VpdmVzIG9uIGl0cyBJQkdQIHNlc3Npb24gZG9lcyBu b3QgYW5kIGNhbm5vdCBvdmVycmlkZSBvcg0KICAgICAgICBpbmZsdWVuY2Ugd2hhdCB3YXMgcmVj ZWl2ZWQgdmlhIEVCR1AyLg0KDQpbb2JdIEluIHRoaXMgY2FzZSB5b3Ugd291bGQgaGF2ZSBhICdp bnZhbGlkJyBjb21wYXJlZCB0byBhbiAndW52ZXJpZmllZCcgcm91dGUuICANCltvYl0gSSBiZWxp ZXZlIHRoaXMgaXMgbG9jYWwgcG9saWN5LiAgT25lIGNvdWxkICdsb3ctcHJlZicgdGhlIHJvdXRl LiAgU2VlIGl0IA0KW29iXSBmcm9tIHRoZSBvdGhlciBzaWRlLiAgTGV0J3Mgc2F5IEEgcmVjZWl2 ZWQgdGhlIHJvdXRlLCB2YWxpZGF0ZWQgYW5kIHRoZSANCltvYl0gcmVzdWx0IGlzICdpbnZhbGlk Jywgbm93IGl0IHJlY2VpdmVzIHRoZSByb3V0ZSB2aWEgSUJHUCBmcm9tIEIsIHRoaXMgdGltZSAN CltvYl0gYXMgJ3VudmVyaWZpZWQnIGJlY2F1c2UgYXMgeW91IG1lbnRpb24gQiBkZWZlcnMgdmFs aWRhdGlvbi4gIE5vdyBBIGRvZXMgDQpbb2JdIHBlcmZvcm0gdmFsaWRhdGlvbiBhbmQgdmFsaWRh dGVzIGl0IGFzICd2YWxpZCcuICBJbiB0aGlzIGNhc2UgQSBzZW5kIGEgDQpbb2JdIHdpdGhkcmF3 YWwgdG8gQiBmb3IgdGhlIEEoRUJHUCkgcm91dGUgYW5kIGJvdGggQSBhbmQgQiB3aWxsIHVzZSBC J3Mgcm91dGUuDQpbb2JdIEV2ZW4gdGhvdWdoIG9ubHkgQSBrbm93cyBpdCBpcyB2YWxpZC4gIA0K DQogICAgICAgIFRoZSB0ZXh0IGluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGFib3V0 ICd0ZW1wb3JhcmlseSBkZWZlcm1lbnQgb2YNCiAgICAgICAgdmFsaWRhdGlvbicgc2hvdWxkIHBy b2JhYmx5IGJlIHJlbW92ZWQgYXMgaXQgaXMgaGFyZCB0byBzZWUgaG93IGluIHRoZQ0KICAgICAg ICBzaXR1YXRpb24gb2YgdGVtcG9yYXJpbHkgZGVmZXJtZW50IHRoZSBleGlzdGVuY2Ugb2YgdGhl c2UgY29tbXVuaXRpZXMNCiAgICAgICAgbWFrZXMgc2Vuc2UuDQoNCltvYl0gSSBrbm93LCB0aGUg cmVjZWl2ZXIgZG9lcyBub3Qga25vdyB3aHkgYSByb3V0ZSB3YXMgbm90IHZlcmlmaWVkLiAgQW5k IHRoZSANCltvYl0gcmVhc29uIGRvZXMgbm90IGNoYW5nZSBhbnl0aGluZyBvbiB0aGUgb3V0Y29t ZS4gIFNhaWQgdGhhdCwgJ3RlbXBvcmFyaWx5IGRlZmVybWVudCcNCltvYl0gd291bGQgYmUgYSBt b3N0IGxpa2VseSByZWFzb24gZm9yIG5vdCB2YWxpZGF0aW5nIGluIHRoZSBmaXJzdCBwbGFjZSBh cyANCltvYl0gbWVudGlvbmVkIGluIFJGQyA4MjA1LiAgVGhlIGltcG9ydGFudCBwYXJ0IGhlcmUg aXMgdG8gc2lnbmFsIHRoYXQgaXQgd2FzDQpbb2JdIG5vdCB2YWxpZGF0ZWQgYXQgYWxsLg0KDQog ICAgICAgIFVuZGVwbG95YWJpbGl0eQ0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0NCg0KICAgICAg ICBBbiBhcmNoaXRlY3R1cmFsIGNob2ljZSB0byB1c2UgQkdQIGNvbW11bml0aWVzIGZvciBhbnkg cHVycG9zZQ0KICAgICAgICBvZnRlbnRpbWVzIHN0ZW1zIGZyb20gYW4gb3BlcmF0b3IncyBhYmls aXR5IHRvIGRlcGxveSAnYSBuZXcgdGhpbmcnIGluIGENCiAgICAgICAgbmV0d29yayB3aGVyZSAo cGFydCBvZikgdGhlIG5vZGVzIGhhdmUgbm90IHlldCBiZWVuIHVwZ3JhZGVkLiBHb29kDQogICAg ICAgIHVzZWZ1bCBleGFtcGxlcyBvZiB0aGlzIG1lY2hhbmlzbSBhcmUgR1JBQ0VGVUxfU0hVVERP V04gYW5kIE5PX0VYUE9SVC4NCg0KICAgICAgICBUaGUgZG9jdW1lbnQgc3RhdGVzIGluIHNlY3Rp b24gMyAiSWYgdGhlIHJvdXRlciBzdXBwb3J0cyB0aGUgZXh0ZW5zaW9uDQogICAgICAgIGFzIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCIgLi4uIHdoaWNoIGltcGxpZXMgdGhhdCBhbGwgbm9kZXMg aW4gYW4NCiAgICAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG11c3QgYmUgdXBncmFkZWQsIHdo aWNoIGluIHR1cm4gc29tZXdoYXQgbnVsbGlmaWVzDQogICAgICAgIHRoZSBqdXN0aWZpY2F0aW9u IHRvIHVzZSBjb21tdW5pdGllcyBpbiB0aGUgZmlyc3QgcGxhY2UuIFRoaXMgZG9lc24ndA0KICAg ICAgICBhbGxvdyBhIGJyb3duZmllbGQgdXBncmFkZSENCg0KW29iXSBJIGRpc2FncmVlIHdpdGgg eW91ciAiaW1wbGljYXRpb24iIHN0YXRlbWVudC4gIE5vdCBldmVyeSByb3V0ZXIgaXMgcmVxdWly ZWQNCltvYl0gdG8gc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiBhbmQgYXMgc3RhdGVkIGluIHRoZSBk cmFmdCwgdGhlIHVzYWdlIG9mIHRoaXMgDQpbb2JdIGF0dHJpYnV0ZSBpcyBjb25maWd1cmFibGUg b24gYSBwZXIgcGVlciBiYXNpcy4NCg0KICAgICAgICBTZWN0aW9uIDMuMSAiRXJyb3IgSGFuZGxp bmcgYXQgUGVlcnMiIHJlYWRzIGFzIGEgc2ltcGxlIHBhcmFncmFwaCwgYnV0DQogICAgICAgIGlz IGJyaXR0bGUgYW5kIGVycm9yLXByb25lIHRvIGltcGxlbWVudCBpbiByb3V0aW5nIHBvbGljeS4g TW9zdCBuZXR3b3JrDQogICAgICAgIG9wZXJhdG9ycyBhcmUgYWNjdXN0b21lZCB0byBpbXBsZW1l bnRpbmcgYSAndGVzdCAmIGJyYW5jaCcgcHJvY2VkdXJlIGJ5DQogICAgICAgIHBvc2l0aXZlIGNv bW11bml0eSBtYXRjaGluZyBhbmQgdGhlbiB0YWtpbmcgc29tZSBhY3Rpb24uIFJGQyAxOTk3DQog ICAgICAgIGRlZmluZXMgY29tbXVuaXRpZXMgYXMgIkEgY29tbXVuaXR5IGlzIGEgZ3JvdXAgb2Yg ZGVzdGluYXRpb25zIHdoaWNoDQogICAgICAgIHNoYXJlIHNvbWUgY29tbW9uIHByb3BlcnR5LiIg VGhlIGltcGxpY2F0aW9uIGlzIHRoYXQgd2hlbiBtdWx0aXBsZQ0KICAgICAgICBjb21tdW5pdGll cyBhcmUgYXR0YWNoZWQgdG8gYSByb3V0ZSwgdGhlIHJvdXRlIHNpbXBseSBoYXMgbXVsdGlwbGUN CiAgICAgICAgcHJvcGVydGllcy4NCg0KICAgICAgICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IG91 dGxpbmVzIGEgbWVjaGFuaXNtIHdoZXJlIHNwZWNpZmljIGNvbWJpbmF0aW9ucw0KICAgICAgICBv ZiBjb21tdW5pdGllcyBhcmUgaW52YWxpZCBpbnB1dDogIigweDQzLFRCRCwwKSDiiKkgKDB4NDMs VEJELDEpIiwgb3INCiAgICAgICAgIigweDQzLFRCRCwxKSDiiKkgKDB4NDMsVEJELDIpIiwgb3Ig IigweDQzLFRCRCwyKSDiiKkgKDB4NDMsVEJELDApIi4gSW4NCiAgICAgICAgY3VycmVudGx5IGF2 YWlsYWJsZSBjb21tZXJjaWFsfGZyZWUtb2YtdGhlLXNoZWxmIEJHUCBpbXBsZW1lbnRhdGlvbnMN CiAgICAgICAgaW1wbGVtZW50aW5nIGFkZXF1YXRlIGVycm9yIGhhbmRsaW5nIGlzIGVycm9yLXBy b25lLiBSRkMgODA5NyBzaGFyZXMNCiAgICAgICAgdGhpcyB3ZWFrbmVzcy4NCg0KW29iXSBUaGUg ZHJhZnQgY2xlYXJseSBzdGF0ZXMgdG8gaGF2ZSBubyBjb21iaW5hdGlvbnMgb2YgdGhpcyBjb21t dW5pdHkgc3RyaW5nIA0KW29iXSBpbiB0aGUgc2FtZSBVUERBVEUsIHNvIEkgZG8gbm90IGZvbGxv dyB5b3VyIHBvaW50IGhlcmUuICBJZiBtb3JlIHRoYW4gb25lIA0KW29iXSBpbnN0YW5jZXMgb2Yg dGhlIGF0dHJpYnV0ZSBhcmUgZm91bmQgdGhlbiBhbGwgTVVTVCBiZSBkaXNjYXJkZWQuIFRoZSBh cmd1bWVudA0KW29iXSB0aGF0IGltcGxlbWVudGF0aW9ucyBoYXZlIGlzc3VlcyB3aXRoIGVycm9y IGhhbmRsaW5nIGRvZXMgbm90IGhvbGQuICBJJ20gc29ycnkNCltvYl0gYnV0IGFzIHNvbWVvbmUg d2hvIHdvcmtlZCBvbiBtYW55IHNvZnR3YXJlIGltcGxlbWVudGF0aW9ucyBvdmVyIHRoZSB5ZWFy cw0KW29iXSB0aGlzIGlzIG5vdCByZWFsbHkgYSB2ZXJ5IGNvbnZpbmNpbmcgYXJndW1lbnQuLi4u Li4NCg0KICAgICAgICBUaGUgSW50cm9kdWN0aW9uIHByb3Bvc2VzIHRoYXQgYSByZWR1Y3Rpb24g b2YgcGF0aCB2YWxpZGF0aW9uIHByb2Nlc3NpbmcNCiAgICAgICAgbG9hZCBjYW4gYmUgYWNoaWV2 ZWQsIGhvd2V2ZXIgU2VjdGlvbiA0IHN0YXRlcyB0aGF0IGlmIHRoZXJlIGlzIGENCiAgICAgICAg ZGlzY3JlcGFuY3kgYmV0d2VlbiB0aGUgbG9jYWxseSBjb21wdXRlZCB2YWxpZGF0aW9uIHN0YXRl IGFuZCB0aGUNCiAgICAgICAgY29tbXVuaXR5LCB0aGUgbG9jYWxseSBjb21wdXRlZCBzdGF0ZSB0 YWtlcyBwcmVjZWRlbmNlLiBUaHVzLCBubyBsb2FkDQogICAgICAgIHByb2Nlc3NpbmcgcmVkdWN0 aW9uIGNhbiBiZSBhY2hpZXZlZCBiZWNhdXNlIGEgQkdQc2VjIGNhcGFibGUgbm9kZSBtdXN0DQog ICAgICAgIGNvbXB1dGUgdGhlIHZhbGlkYXRpb24gc3RhdGUgYmVmb3JlIGl0IGNhbiBjb21wYXJl IGl0IHRvIHRoZSBjb21tdW5pdHkuDQoNCltvYl0gTm90IG5lY2Vzc2FyaWx5LCB1c2luZyB5b3Vy IHRvcG9sb2d5IGZyb20gYWJvdmUsIEIgcmVjZWl2ZXMgdGhlIHVwZGF0ZSBmcm9tIEEuICAgDQpb b2JdIExldCdzIGFzc3VtZSBmb3IgYSBtb21lbnQgQSBkaWQgdmFsaWRhdGUgYW5kIEIgaXMgbG93 IG9uIHJlc291cmNlcyBhbmQgZGVjaWRlcyANCltvYl0gdG8gZGVmZXIgdGhlIHZhbGlkYXRpb24u ICBIZXJlLCBpdCByZWNlaXZlcyBhIHZhbGlkYXRpb24gcmVzdWx0IGZyb20gQSBhbmQgdXNlcyAN CltvYlsgaXQgdW50aWwgQiBnYWlucyBiYWNrIHJlc291cmNlcyBhbmQgc3RhcnRzIHZhbGlkYXRp bmcgYWxsIHJlbWFpbmluZyByb3V0ZXMgaXQgDQpbb2JdIGRpZCBkZWZlciBlYXJsaWVyLiAgSXQg ZXZlbnR1YWxseSB3aWxsIHZhbGlkYXRlIHRoZSBVUERBVEUgaXQgbGVhcm5lZCBmcm9tIEEgYW5k DQpbb2JdIEIgd2lsbCB1c2UgaXRzIG93biB2YWxpZGF0aW9uIHN0YXRlLCBnb2luZyBmb3J3YXJk Lg0KDQpbb2JdIFJlZ2FyZGxlc3MgdGhhdCB0aGUgZW5kIGdvYWwgaXMgdGhhdCBldmVyeSBzaW5n bGUgcm91dGVyIHBlcmZvcm1zIGl0cyBvd24gDQpbb2JdIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24s IHRoZXJlIGFyZSBtb21lbnRzLCB3aGVyZSBhIHJvdXRlciB3aWxsIGRlZmVyIHRoaXMgdGFzay4N CltvYl0gVGhhdCBpcyB3aHkgYWxzbyBSRkMgODIwNSBhZGRlZCB0aGF0IHNlY3Rpb24uDQoNCltv Yl0gTmV4dCB0byBsb2FkIHByb2Nlc3NpbmcsIHRoaXMgYXR0cmlidXRlIGFsc28gYWxsb3dzIHZh bGlkYXRpb24gYW5hbHlzaXMuICBJdCANCltvYl0gbWFrZXMgaXQgZWFzaWVyIHdoZW4gYW5hbHl6 aW5nIHRoZSB0cmFmZmljIHRvIHNlZSB0aGUgdmFsaWRhdGlvbiByZXN1bHQgb2YgZWFjaCANCltv Yl0gcm91dGVyLiAgSGVyZSBhIHdlbGwtZGVmaW5lZCBhdHRyaWJ1dGUgYWxsb3dzIGVhcmx5IGlu dGVncmF0aW9uIGludG8gdGhpcmQgcGFydHkgDQpbb2JdIHRvb2xzIHN1Y2ggYXMgV2lyZXNoYXJr IG9yIG90aGVycy4gDQoNCiAgICAgICAgTm90IGFuYWxvZ291cyB0byBSRkMgODA5Nw0KICAgICAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgICAgVG8gbWFueSB0aGlzIGRyYWZ0 IG1heSBhcHBlYXIgYXMgJ2ZvciBzdXJlLCB3ZSBuZWVkIHNvbWV0aGluZyBzaW1pbGFyDQogICAg ICAgIGZvciBiZ3BzZWMgYXMgd2UgaGF2ZSBmb3Igcm91dGUgb3JpZ2luIHZhbGlkYXRpb24nIC0g YnV0IEkgdGhpbmsgbm8gc3VjaA0KICAgICAgICBlcXVpdmFsZW5jZSBleGlzdHMsIG9yIG5lZWRz IHRvIGV4aXN0Lg0KDQpbb2JdIEFzIGRldmVsb3BlciBvZiBvbmUgb2YgdGhlIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbnMgSSB0aGluayBkaWZmZXJlbnRseS4NCg0KICAgICAgICBSRkMgODA5NyBk ZWZpbmVzIGEgc2V0IG9mIEJHUCBjb21tdW5pdGllcyB3aGljaCBjYW4gb3B0aW9uYWxseSBiZQ0K ICAgICAgICBhc3NvY2lhdGVkIHdpdGggYSBwcmVmaXggKmFmdGVyKiB0aGUgT3JpZ2luIFZhbGlk YXRpb24gcHJvY2VkdXJlIChSRkMNCiAgICAgICAgNjgxMSkgKnN1Y2Nlc3NmdWxseSogaXMgZXhl Y3V0ZWQuIFRoaXMgaW4gY29udHJhc3QgdG8NCiAgICAgICAgZHJhZnQtYmdwc2VjLXZhbGlkYXRp b24tc2lnbmFsaW5nLCB3aGVyZSBhIG5vZGUgaXMgKnVuYWJsZSogdG8gcGF0aA0KICAgICAgICB2 YWxpZGF0aW9uLCB0aHVzIGNhbiBuZXZlciBzZXQgdGhlIGFwcHJvcHJpYXRlIGNvbW11bml0aWVz LiBSRkMgODA5Nw0KICAgICAgICBkb2VzIG5vdCBkZXNjcmliZSBhIHNpdHVhdGlvbiB3aGVyZSBP cmlnaW4gVmFsaWRhdGlvbiBpcyB0ZW1wb3JhcmlseQ0KICAgICAgICBkZWZlcnJlZC4NCg0KW29i XSBJIGRvbid0IHJlYWxseSB3YW50IHRvIHRhbGsgYWJvdXQgUkZDIDgwOTcgaGVyZSBidXQgd2hl cmUgeW91IGJyaW5nIHRoaXMgdXAsDQpbb2JdIGxldCBtZSBzYXkgdGhhdCB5b3VyIHN0YXRlbWVu dCBvZiAic3VjY2Vzc2Z1bCBleGVjdXRpb24iIHdoaWNoIEkgdGhpbmsgeW91IA0KW29iXSBtZWFu IGluIHJlZ2FyZHMgdG8gcGVyZm9ybWluZyB0aGUgdmFsaWRhdGlvbiBhbGdvcml0aG0gaXMgaW5j b3JyZWN0Lg0KDQpbb2JdIFJGQyA2ODExIGNsZWFybHkgc3RhdGVzIHRoYXQgaW4gY2FzZSBhIHJv dXRlciBjaG9vc2VzIG5vdCBwZXJmb3JtIG9yaWdpbiB2YWxpZGF0aW9uIA0KW29iXSB0aGUgcm91 dGVyIFNIT1VMRCBhc3NpZ24gIm5vdC1mb3VuZCIgdG8gdGhlIHJvdXRlLCB3aGljaCBpbiBteSBv cGluaW9uIA0KW29iXSBjb250cmFkaWN0cyB0aGUgZGVmaW5pdGlvbiBvZiAibm90LWZvdW5kIi4g T3V0IG9mIHRoYXQgcmVhc29uLCBJIHByb3Bvc2VkIGF0IA0KW29iXSBJRVRGIDEwMyBpbiBCYW5n a29rIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIHZhbGlkYXRpb24gc3RhdGUgInVudmVyaWZpZWQi IHRvIFJGQyA2ODExLg0KDQpbb2JdIEJ1dCB0aGlzIGRpc2N1c3Npb24gaXMgb3V0IG9mIHNjb3Bl IGZvciB0aGlzIGRyYWZ0LiANCltvYl0gTmV2ZXJ0aGVsZXNzLCBpbiBjYXNlIEkgY2FuIGludGVy ZXN0IHlvdTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMTAzL3NsaWRlcy9zbGlk ZXMtMTAzLXNpZHJvcHMtcHJvcG9zaW5nLXZhbGlkYXRpb24tc3RhdGUtdW52ZXJpZmllZC0wMA0K DQoNCiAgICAgICAgUmVqZWN0IGRvbid0IHRhZyAoZG8sIGRvbid0IHRhbGsgYWJvdXQgZG9pbmcg aXQpDQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogICAgICAgIElmIGEgcm91dGUgaXMgY29uc2lkZXJlZCBpbnZhbGlkIChmb3Igd2hh dGV2ZXIgcmVhc29uLCBiZWF1dHkgaXMgaW4gdGhlDQogICAgICAgIGV5ZSBvZiB0aGUgYmVob2xk ZXIpLCB0aGUgcm91dGUgc2hvdWxkIGJlIHJlamVjdGVkLiBNZXJlbHkgdGFnZ2luZyBhbg0KICAg ICAgICBpbnZhbGlkIHJvdXRlIHdpdGggYSBzcGVjaWZpYyBjb21tdW5pdHkgYW5kIHByb3BhZ2F0 aW5nIGl0IGZ1cnRoZXIsIGlzIGENCiAgICAgICAgdXNlbGVzcyBleGNlcmNpc2UuIFN1Y2ggZGVz aWducyBoYW1wZXJzIGRlcGxveW1lbnQgb2YgYWN0dWFsIHNlY3VyaXR5DQogICAgICAgIG1lYXN1 cmVzLiBJZiBhbiBvcGVyYXRvciB3YW50cyB0byB0YWcgaW52YWxpZCByb3V0ZXMgZm9yIGFuYWx5 dGljYWwNCiAgICAgICAgcHVycG9zZXMsIHRoZXkgY2FuIGVhc2lseSBkbyBzbyBhbmQgY2FuIGNo b29zZSBmcm9tIG1pbGlvbnMgb2YgdmFsdWVzDQogICAgICAgIHVzaW5nIGFueSBvZiB0aGUgZmxh dm9ycyBvZiBjb21tdW5pdGllcyB0aGF0IGFyZSBhdmFpbGFibGUuIElmIHlvdSAqYXJlKg0KICAg ICAgICBwcm9wYWdhdGluZyBhbiBpbnZhbGlkIHJvdXRlLCB5b3UgYXJlIHByb3BhZ2F0aW5nIGFu IGludmFsaWQgcm91dGUgLSBpbg0KICAgICAgICB3aGljaCBjYXNlIGl0IGRvZXMgbm90IG1hdHRl ciB3aGF0ZXZlciBjb21tdW5pdGllcyBhcmUgYXR0YWNoZWQgdG8gaXQuDQoNCltvYl0gQ29uc2lk ZXIgdGhlIGZvbGxvd2luZyB0d28gcmVjZWl2ZWQgcm91dGVzOiANCltvYl0gQm90aCByb3V0ZXJz IHBlZXIgd2l0aCAxICYgOA0KW29iXSBSMSB7MSwyLDMsNCw1LDYsNyxwMX0NCltvYl0gUjIgezgs OSxwMX0NCg0KW29iXSBCUFYoQSxSMSkgbWVhbnMgQkdQc2VjIFBhdGggVmFsaWRhdGlvbiBmb3Ig cm91dGUgUjEgYXQgcm91dGVyIEEuDQpbb2JdIFBvbGljeTogRHJvcCAnaW52YWxpZCcuDQoNCltv Yl0gVmFsaWRhdGlvbjoNCltvYl0gQlBWKEEsUjEpID0gZGVmZXJyZWQNCltvYl0gQlBWKEEsUjIp ID0gZGVmZXJyZWQNCltvYl0gQlBWKEIsUjEpID0gdmFsaWQNCltvYl0gQlBWKEIsUjIpID0gaW52 YWxpZA0KDQpbb2JdIEEgZGVmZXJzIEJQViBhbmQgc2VsZWN0cyBSMiAoc2hvcnRlc3QgcGF0aCku IA0KW29iXSBCIG9uIHRoZSBvdGhlciBoYW5kIGRvZXMgcGVyZm9ybSBwYXRoIHZhbGlkYXRpb24g YW5kIHNlbGVjdHMgdGhlDQpbb2JdIGxvbmdlciB2YWxpZCByb3V0ZSBSMSBvdmVyIHRoZSBzaG9y dGVyIGFuZCBpbnZhbGlkIHJvdXRlIFIyLiBJbiBmYWN0DQpbb2JdIEIgaWdub3JlcyBSMi4NCg0K W29iXSBOb3cgd2l0aG91dCB0aGUgdmFsaWRhdGlvbiBzdGF0ZSBjb21tdW5pY2F0ZWQgZnJvbSBC IHRvIEEsIEEgbmV2ZXINCltvYl0gd2lsbCBrbm93IHRoYXQgaXQgc2VsZWN0ZWQgYW4gaW52YWxp ZCByb3V0ZSAtIG9yIG1vcmUgaW1wb3J0YW50IHdpdGgNCltvYl0gUjIgYmVpbmcgdmFsaWQgYW5k IHRoZXJlZm9yZSBtb3JlIGRlc2lyYWJsZSwgaWYgQSBpbiBjYXNlIG9mIHRoZSB2YWxpZGF0aW9u IA0KW29iXSBzaWduYWxlZCB3b3VsZCBsZWFybiBvZiB0aGUgdmFsaWRhdGlvbiBzdGF0ZSBmb3Ig UjIgY291bGQgdXNlIHBvbGljaWVzIA0KW29iXSB0aGF0IHNlbGVjdHMgJ3ZhbGlkJyBvdmVyICd1 bnZlcmlmaWVkJy4NCg0KW29iXSBBbmQgeWVzLCB0aGVyZSBhcmUgcGxlbnR5IG9mIHZhbHVlcyBh dmFpbGFibGUgdG8gY3JhZnQgY3VzdG9tIGNvbW11bml0eQ0KW29iXSB2YWx1ZXMuIEFuZCBpZiB0 aGlzIGRyYWZ0IHdpbGwgbm90IHByb2NlZWQgdGhhdCBpcyB3aGF0IG1pZ2h0IGhhcHBlbi4NCltv Yl0gQnV0IHRoYXQgd291bGQgYmUgYSBiaWcgbG9zcywgd291bGRuJ3QgaXQuIFdoeSBkbyB3ZSBz dGFuZGFyZGl6ZSwgc28gdGhhdA0KW29iXSB3ZSBkbyBub3QgbmVlZCB0byBoYW5kIGNyYWZ0IGVh Y2ggYW5kIGV2ZXJ5IHRoaW5nLiAgSSBzdHJvbmdseSBiZWxpZXZlLCANCltvYl0gbWVjaGFuaXNt cyBsaWtlIEJHUHNlYywgc2FtZSBhcyBSUEtJIGRvIG5lZWQgc3RhbmRhcmRpemVkIGNvbW11bml0 aWVzLiANCltvYl0gVGhleSBub3Qgb25seSBhbGxvdyB0aGUgdmVuZG9yIHRvIHByb3ZpZGUgYW4g aW50ZXJvcGVyYWJsZSBvcGVyYXRvciANCltvYl0gZnJpZW5kbHkgZnVuY3Rpb25hbGl0eSwgdGhl eSBhbHNvIGFsbG93IHRoaXJkIHBhcnR5IHZlbmRvcnMgdG8gY3JlYXRlIA0KW29iXSBnZW5lcmFs aXplZCBmaWx0ZXJzIGluIG1vbml0b3Jpbmcgc29mdHdhcmUgd2l0aG91dCB0aGUgbmVlZCB0byBh bHdheXMgDQpbb2JdIGNyZWF0aW5nIGhhY2tzLiBBbmQgYXMgSSB1bmRlcnN0b29kIGZyb20geW91 ciBlYXJsaWVyIGNvbW1lbnRzLCBjb21tdW5pdGllcyANCltvYl0gYXJlIGEgZ29vZCB0b29sIGZv ciBlYXJseSBhZG9wdGVycyAtIEVzcGVjaWFsbHkgbGlrZSBCR1BzZWMuIEV2ZW4gbW9yZQ0KW29i XSBpZiBjb21tZXJjaWFsIGF2YWlsYWJsZSBtb25pdG9yaW5nIHNvZnR3YXJlIGNhbiBmaWx0ZXIg Zm9yIHRoZW0gYW5kIA0KW29iXSBwcm92aWRlIHVzZWZ1bCBmdW5jdGlvbmFsaXR5IHRvIG9wZXJh dG9ycy4gDQoNCltvYl0gRXZlbiB0aG91Z2gsIEJHUHNlYyBpdHNlbGYgb25seSBwcm92aWRlcyB0 aGUgdmFsaWRhdGlvbiByZXN1bHRzICd2YWxpZCcgYW5kDQpbb2JdICdpbnZhbGlkJyAtIGFjdHVh bGx5IGl0IGlzICJOb3QgVmFsaWQiIGJ1dCBsZXQncyBzdGF5IHdpdGggJ2ludmFsaWQnLCANCltv Yl0gd2hhdCBkb2VzIHRoaXMgbWVhbiBpbiBhIEJHUHNlYyB3b3JsZCB3aXRoIGRyb3AgaW52YWxp ZC4gIFdlIG9ubHkgc2VlIHZhbGlkIA0KW29iXSB1cGRhdGVzPyBPZiBjb3Vyc2Ugbm90IC0gZXNw ZWNpYWxseSBpZiB0aGUgcm91dGVyIG5lZWRzIHRvIGRlZmVyIHZhbGlkYXRpb24NCltvYl0gZHVl IHRvIGhlYXZ5IGxvYWQuIFRoZW4gd2hhdD8gVGhlcmUgaXMgbm8gYmluYXJ5ICd2YWxpZCcgb3Ig J2ludmFsaWQnLg0KW29iXSBFdmVyeSB0aW1lIGEgcm91dGVyIHJlY2VpdmVzIGEgcm91dGUgYW5k IGRlZmVyIHZhbGlkYXRpb24sIE5PIGFzc3VtcHRpb24NCltvYl0gYXNzdW1wdGlvbiBvbiB0aGUg dmFsaWRhdGlvbiBzdGF0ZSBtdXN0IGJlIG1hZGUuIFlvdSBzYWlkIHRoYXQgeW91cnNlbGYhICAN CltvYl0gU28gdGhlIG1vcmUga25vd2xlZGdlIGlzIGNvbW11bmljYXRlZCwgdGhlIGJldHRlci4g DQoNCltvYl0gU28sIEluIG15IG9waW5pb24sIEkgZG8gc2VlIGEgdmVyeSBiaWcgdmFsdWUgaW4g dGhpcyBjb21tdW5pdHkgYXR0cmlidXRlLg0KW29iXSBJdCBwcm92aWRlcyBhbiBhZGRpdGlvbmFs IGRhdGEgcG9pbnQgZm9yIHJvdXRlIHNlbGVjdGlvbiAtIGVzcGVjaWFsbHkgZHVyaW5nIA0KW29i XSBoZWF2eSBsb2Fkcy4gICANCg0KW29iXSBBZ2FpbiwgdGhpcyBjb21tdW5pdHkgYXR0cmlidXRl IG5vdCBvbmx5IGNvbW11bmljYXRlcyAidmFsaWQiIGFuZCAiaW52YWxpZCIsIA0KW29iXSBpdCBh bHNvIGNvbW11bmljYXRlcyAidW52ZXJpZmllZCIuIEFuZCB0aGF0IGluIGl0c2VsZiBpcyBhIHZl cnkgZ29vZCBtZWNoYW5pc20NCltvYl0gdG8gcHJldmVudCBpbmNvcnJlY3QgYXNzdW1wdGlvbnMg YWJvdXQgdGhlIHZhbGlkYXRpb24gc3RhdGUgb2YgYSByZWNlaXZlZCANCltvYl0gcm91dGUuDQoN Cg0KICAgICAgICBDb25jbHVzaW9uDQogICAgICAgIC0tLS0tLS0tLS0NCg0KICAgICAgICBBdCB0 aGlzIHBvaW50IGluIHRpbWUgSSBkb24ndCB0aGluayB0aGlzIGRyYWZ0IGNhbiBwcm9jZWVkIHRv DQogICAgICAgIHB1YmxpY2F0aW9uLCBmcm9tIHRoZSBkb2N1bWVudCBpdHNlbGYgaXQgaXMgbm90 IGNsZWFyIHRvIG1lIHdoYXQNCiAgICAgICAgYmVuZWZpdHMgY2FuIGJlIGFjaGlldmVkIGFuZCBo b3cgdGhpcyBiZW5lZml0cyBJbnRlcm5ldCBvcGVyYXRpb25zLiBUaGUNCg0KW29iXSBJIGhvcGUg bXkgZXhwbGFuYXRpb25zIGFib3ZlIGhlbHBlZCB0byBjbGFyaWZ5IHlvdXIgY29uY2VybnMgYW5k IGhlbHBlZCBjaGFuZ2luZw0KW29iXSB5b3VyIHZpZXcgb24gaXQuIE90aGVycyBkaWQgc2hvdyB2 YWx1ZSBhbmQgSSBob3BlIHlvdSBjYW4gam9pbi4NCg0KICAgICAgICBkcmFmdCByZXF1aXJlcyBu ZXcgY29kZSBvbiBkZXZpY2VzIGluIGFkZGl0aW9uIHRvIHdoYXQgYSBCR1BzZWMgY2FwYWJsZQ0K ICAgICAgICBpbXBsZW1lbnRhdGlvbiB3b3VsZCByZXF1aXJlLiBBbmQgaW4gdG9kYXkncyB3b3Js ZCB0aGVyZSBhcmVuJ3QNCiAgICAgICAgb2ZmLXRoZS1zaGVsZiBCR1BzZWMgaW1wbGVtZW50YXRp b25zIHRvIHN0YXJ0IHdpdGgsIHNvIHBpbGluZyBvbg0KICAgICAgICBhZGRpdGlvbmFsIGNvZGUg cmVxdWlyZW1lbnRzIGlzIHRvbyBlYXJseSBpbiB0aGUgaW5ub3ZhdGlvbiBjeWNsZQ0KDQpbb2Jd IFRoZSBhcmd1bWVudCB0aGF0IHRoaXMgYXR0cmlidXRlIGhhcyBubyBwbGFjZSBiZWNhdXNlIHRo ZXJlIGFyZSBub3QNCltvYl0gZW5vdWdoIGltcGxlbWVudGF0aW9ucyBvdXQgdGhlcmUgZG9lcyBu b3QgbWFrZSBzZW5zZSB0byBtZSBhdCBhbGwsIA0KW29iXSBlc3BlY2lhbGx5IGFzIGltcGxlbWVu dGVyIG9mIG9uZSBvZiB0aGUgb3BlbiBzb3VyY2UgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9ucyAN CltvYl0gb2YgQkdQc2VjLg0KDQogICAgICAgIGFueWhvdy4gVXNpbmcgY29tbXVuaXRpZXMgaXMg bm8gc3Vic3RpdHV0ZSBmb3IgQkdQc2VjIHZhbGlkYXRpb24gb3IgZm9yDQogICAgICAgIFJUUiwg dGhpcyBkb2N1bWVudCBtYXkgc3VidGx5IGxlYWQgcGVvcGxlIHRvIGJlbGlldmUgb3RoZXJ3aXNl Lg0KDQpbb2JdIFJUUj8gRG8geW91IG1lYW4gUlBLSS10by1yb3V0ZXIgYXMgbWVudGlvbmVkIGFi b3ZlPyBJbiB0aGF0IGNhc2UsIGl0IGhhcyANCltvYl0gbm90aGluZyB0byBkbyB3aXRoIHRoYXQu DQoNCltvYl0gVGhpcyBkb2N1bWVudCBpcyBpbiBubyBmb3JtIGEgcmVwbGFjZW1lbnQgb2YgQkdQ c2VjIHBhdGggdmFsaWRhdGlvbiAtIEkgDQpbb2JdIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3Ug b24gdGhhdC4gSXQgaXMgYSB2ZXJ5IGhlbHBmdWwgdG9vbCB0byBhbGxvdyANCltvYl0gcm91dGVy cyB0byBub3QgYnJlYWsgZG93biBkdXJpbmcgaGVhdnkgbG9hZHMsIG1ha2UgdXNhZ2Ugb2YgZGVm ZXJyaW5nIA0KW29iXSB2YWxpZGF0aW9uIHVudGlsIHRoZSBsb2FkIG9uIHRoZSByb3V0ZXIgZ29l cyBkb3duIGJ1dCBzdGlsbCBtYWtlIHVzYWdlDQpbb2JdIHZhbGlkYXRpb24gc3RhdGUgaXQgbGVh cm5lZCBmcm9tIGl0cyBwZWVyIHVudGlsIG93biB2YWxpZGF0aW9uIGNhbiBiZSANCltvYl0gcGVy Zm9ybWVkLiANCg0KICAgICAgICBJdCBpcyBwb3NzaWJsZSBJIG1pc3VuZGVyc3Rvb2QgdGhpbmdz LCBJIGxvb2sgZm9yd2FyZCB0byBmZWVkYmFjayBmcm9tDQogICAgICAgIHRoZSBncm91cC4NCg0K W29iXSBJIGhvcGUgSSBjb3VsZCBjbGFyaWZ5IHNvbWUgbWlzdW5kZXJzdGFuZGluZ3MgYW5kIGNv bmNlcm5zLA0KDQoNCiAgICAgICAgS2luZCByZWdhcmRzLA0KDQogICAgICAgIEpvYg0KDQoNCiAg ICAgICAgcHMuIG5pdHBpY2s6IG9uZSBvZiB0aGUgYXV0aG9yJ3MgY29tcGFueSBuYW1lcyBzZWVt cyBtaXNzcGVsbGVkLg0KDQpbb2JdIFRoYW5rcywgDQpbb2JdIEkgd2lsbCBmaXggdGhhdCwNCltv Yl0gT2xpdmVyDQoNCiAgICAgICAgT24gRnJpLCBTZXAgMjUsIDIwMjAgYXQgMDc6MTk6MTBQTSAt MDcwMCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgICAgICA+IA0KICAgICAg ICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICAgICAgPiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBTSURSIE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuDQogICAgICAgID4g DQogICAgICAgID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCR1BzZWMgVmFsaWRhdGlvbiBT dGF0ZSBTaWduYWxpbmcNCiAgICAgICAgPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE9saXZl ciBCb3JjaGVydA0KICAgICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRG91ZyBNb250 Z29tZXJ5DQogICAgICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5pZWwgS29wcA0K ICAgICAgICA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0 aW9uLXNpZ25hbGluZy0wNS50eHQNCiAgICAgICAgPiAJUGFnZXMgICAgICAgICAgIDogOA0KICAg ICAgICA+IAlEYXRlICAgICAgICAgICAgOiAyMDIwLTA5LTI1DQogICAgICAgID4gDQogICAgICAg ID4gQWJzdHJhY3Q6DQogICAgICAgID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJH UCBub24tdHJhbnNpdGl2ZSBleHRlbmRlZCBjb21tdW5pdHkgdG8NCiAgICAgICAgPiAgICBjYXJy eSB0aGUgQkdQc2VjIHBhdGggdmFsaWRhdGlvbiBzdGF0ZS4gIEJHUCBzcGVha2VycyB0aGF0IHJl Y2VpdmUNCiAgICAgICAgPiAgICB0aGlzIGNvbW11bml0eSBzdHJpbmcgY2FuIHVzZSB0aGUgZW1i ZWRkZWQgQkdQc2VjIHZhbGlkYXRpb24gc3RhdGUgaW4NCiAgICAgICAgPiAgICBjb25qdW5jdGlv biB3aXRoIGNvbmZpZ3VyZWQgbG9jYWwgcG9saWNpZXMgdG8gaW5mbHVlbmNlIHRoZWlyDQogICAg ICAgID4gICAgZGVjaXNpb24gcHJvY2Vzcy4gIFRoZSBhYmlsaXR5IHRvIGFjY2VwdCBhbmQgYWN0 IG9uIEJHUHNlYyBwYXRoDQogICAgICAgID4gICAgdmFsaWRhdGlvbiBzdGF0ZSBmcm9tIGEgbmVp Z2hib3IgYWxsb3dzIGZvciBhIHJlZHVjdGlvbiBvZiBwYXRoDQogICAgICAgID4gICAgdmFsaWRh dGlvbiBwcm9jZXNzaW5nIGxvYWQgYW5kL29yIGluY3JlYXNlZCByZXNpbGllbmNlIGluIHRoZSBl dmVudA0KICAgICAgICA+ICAgIHRoYXQgYSByb3V0ZXIgaXMgdGVtcG9yYXJpbHkgdW5hYmxlIHRv IHBlcmZvcm0gbG9jYWwgcGF0aCB2YWxpZGF0aW9uLg0KICAgICAgICA+IA0KICAgICAgICA+IA0K DQoNCg== From nobody Mon Oct 19 00:24:45 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6923A149E for ; Mon, 19 Oct 2020 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=ripe.net 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 CX40hwifP7Ii for ; Mon, 19 Oct 2020 00:24:41 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78563A149C for ; Mon, 19 Oct 2020 00:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=u72WswUKu6BCwa/hW5Otun5BbcQfoo3WRo+zArXW93E=; b=G9oNziAIWZmFOMYNWGFUvP kmZRDMDlIWUXjxr3WuGfmci7wvUs3ixogeRECPgLLj2+KFX+wNnKlk/iFQHL00zObKJ+Z7ySvEcdM 3u/r2oepxpUrE/iWwEI67/deuVqt8lGRJMNZIycc70+8yOAPjq/VwaXW0OOQBSJLfB3Nr7YAOPhhh OhnCtXQH0VSq0Tiu5UTPd1qsV1mEeksAdlzr9JwtmZOGK1FP77T0T7dpxWcHLVHJfdBoomx5sAlJK cC3EfPDw/Rlcvk4/rhv/AJXmgosBy9ryM283uT6qD8BdwDhkuqbKMY/byNbV5+O7RiBsbYG1/nReX syaTFRgHDzNA==; Received: from allealle.ripe.net ([193.0.23.12]:48904) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUPX6-0000WE-9M for sidrops@ietf.org; Mon, 19 Oct 2020 09:24:40 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::64f]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUPX6-0000d1-6r for sidrops@ietf.org; Mon, 19 Oct 2020 09:24:40 +0200 From: Nathalie Trenaman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <5481ACAA-439B-4F19-AD12-9DA433DFA240@ripe.net> Date: Mon, 19 Oct 2020 09:23:33 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a92045b665d48ccc11e71f6ed0625b913 Archived-At: Subject: [Sidrops] IETF109 -- Online -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:24:44 -0000 Hi all, SIDROPS will meet at IETF109 on Monday, 16 November from 09:00 =E2=80=93 = 11:00 UTC (!). Please forward any SIDROPS agenda items you may have to = Keyur, Chris and me. Please also make sure that your slides are = available to the chairs by Friday morning (13 November). Slides received = after the deadline may not be available for use during the meeting. =20 Regards, Chris, Keyur and Nathalie From nobody Mon Oct 19 00:25:40 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C953A14A1 for ; Mon, 19 Oct 2020 00:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=ripe.net 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 HujJduonPPqK for ; Mon, 19 Oct 2020 00:25:37 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E153A149E for ; Mon, 19 Oct 2020 00:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=vb0GS+7W1T74n36uQogi6++jv7VgjB702W9NlVbhFiM=; b=g7nRAyAl9ZnQHmIZt8nJr6 kmxZOfKbOATwI5RmJdhUiwfVdBpQzqm5O80iCbUKjVNIcylhK998ptAuCeoYhkRy1vIhGYZr7wwoB wrPX0A8sCzp2uE4S/P7KgP9bwL2GJOKu/p4VjldYYK5xq4MJ+CLsnRabTGgBNJKv+yZnb0iSPaDiP 5teHOy7oU8+CerIC9uSblrjM0EL+zufV5PdaEcYVxE61krSDjsbQiNugZYwok6UTtWkQxT+4SFHoz NdkGhLL3x3p+3xy9L+ASa9HmLLCFhJKt0NVCzmLOfwY4jakgNeFHqfucBDlSdrVkALxqOuEtrrvJE TCqvOV4ESdQQ==; Received: from allealle.ripe.net ([193.0.23.12]:55304) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUPY0-0003EX-Ch for sidrops@ietf.org; Mon, 19 Oct 2020 09:25:36 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::64f]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUPY0-0000d1-9n for sidrops@ietf.org; Mon, 19 Oct 2020 09:25:36 +0200 From: Nathalie Trenaman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Mon, 19 Oct 2020 09:25:36 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a8c1839a4c1edb870df7652573f9f034c Archived-At: Subject: [Sidrops] IETF109 -- Online -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:25:39 -0000 Hi all, SIDROPS will meet at IETF109 on Monday, 16 November from 09:00 =E2=80=93 = 11:00 UTC (!). Please forward any SIDROPS agenda items you may have to = Keyur, Chris and me. Please also make sure that your slides are = available to the chairs by Friday morning (13 November). Slides received = after the deadline may not be available for use during the meeting. Regards, Chris, Keyur and Nathalie From nobody Tue Oct 20 06:54:37 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7A3A0BE3 for ; Tue, 20 Oct 2020 06:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=ripe.net 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 N5HPqdbKFhDe for ; Tue, 20 Oct 2020 06:54:34 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4573A0BE9 for ; Tue, 20 Oct 2020 06:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=mBlwOEY75wHMDEM9DIA04ENuHZBhy7uFOp0DYgaTxHs=; b=DK2njSMwyJVwo+MbW/jiLw LduzEAtZ/zRBritMYjvJl+rbggsfMXMtPLnK37g+BSlf+3BHFrcF7wQOD3wsV24Ey4ssmBvLiJitX /EC9VqwVzhuNHuWjJ7LGYnkebtyTq1XAHfA1071fumWfih2yMzqcfrfrx/wv0xSsIPM/tbQRtNPrw R8qlrG6gVebyVI/T1A9oL4nXUqe7USHdD+nfH4gsNIQhvFxttbePK/HHp0NBjBbv6WIkChnVP5B5c Y+0cUjbbCuiu9hG7DGP+nYNd/KLn+Ee87FBlv/a9uAQ2ghIn9VpPHNYLpyNBaQmcBLxawBY5xSZa3 kCrzmHzB5YNw==; Received: from allealle.ripe.net ([193.0.23.12]:36770) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUs5w-000CYO-W0 for sidrops@ietf.org; Tue, 20 Oct 2020 15:54:33 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::806]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kUs5w-00059q-SO for sidrops@ietf.org; Tue, 20 Oct 2020 15:54:32 +0200 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_EA44DAD9-B2EA-4B7E-BE95-A263479E36F6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Tue, 20 Oct 2020 15:54:32 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92adb5fe1b4c3df55c570ed1dc086ac6dcc Archived-At: Subject: [Sidrops] New on RIPE Labs: Lifecycle of the RIPE NCC RPKI Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 13:54:36 -0000 --Apple-Mail=_EA44DAD9-B2EA-4B7E-BE95-A263479E36F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear colleagues, We made some important decisions with regards to the future of the RIPE = NCC RPKI Validator. In this RIPE Labs article, I provide an overview and = a time line.=20 = https://labs.ripe.net/Members/nathalie_nathalie/life-cycle-of-the-ripe-ncc= -rpki-validator-1 = Kind regards, Nathalie Trenaman RIPE NCC= --Apple-Mail=_EA44DAD9-B2EA-4B7E-BE95-A263479E36F6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear colleagues,

We made some important decisions with regards to the future of the RIPE NCC RPKI Validator. In this RIPE Labs article, I provide an overview and a time line. 


Kind regards,

Nathalie Trenaman
RIPE NCC
--Apple-Mail=_EA44DAD9-B2EA-4B7E-BE95-A263479E36F6-- From nobody Tue Oct 20 09:27:54 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 325C33A09F2; Tue, 20 Oct 2020 07:16:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160320341819.24851.1095876182831900457@ietfa.amsl.com> Date: Tue, 20 Oct 2020 07:16:58 -0700 Archived-At: X-Mailman-Approved-At: Tue, 20 Oct 2020 09:27:53 -0700 Subject: [Sidrops] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 8893 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 14:16:58 -0000 Dear Randy Bush, Rüdiger Volk, Jakob Heitz: An IPR disclosure that pertains to your RFC entitled "Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export" (RFC8893) was submitted to the IETF Secretariat on 2020-10-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4356/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 8893" Thank you IETF Secretariat From nobody Thu Oct 22 07:42:46 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7093A0BE5; Thu, 22 Oct 2020 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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 7TG5EaVd7vIA; Thu, 22 Oct 2020 07:42:41 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 5B49B3A0EFF; Thu, 22 Oct 2020 07:42:41 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id q199so1626462qke.10; Thu, 22 Oct 2020 07:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Or5RsOHQdogXBOT1gb8mXvjS7uTLW4VwEFzAGFqDJsI=; b=mOXzMrtstB4NefRBX85itUklDmGU5mOfGE3Gy3si5EWGVtHC2lgBg9vxrfl+of0unZ mcD398rmRv/77XQ2LqBbIFUh1h+do3Y2MkkxsgLSiJoNeCMLctwuNY4VDxBJ5kN5rjPn fBB5BiOOc1vFFvIVTccIWX4NCGW2QvnJmDsSmwQn21zR4VoK6PQgStTtc8JzD+ysrinn 2xr/3uFYDAVA5h5LL23kJt7X2b3+/9Lv3eVeGa+VZzlFwul0JYy7h6esfQf7r4vb797i izciII8hcekp5Gs5JJjnuyWbSx6pEo5WjILUv8P7WfdWvnz0GL76tyHJqOrPjnBU9G6y cxRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Or5RsOHQdogXBOT1gb8mXvjS7uTLW4VwEFzAGFqDJsI=; b=jmO48CLRvrOZVIafnQDaqg1lLocWJ5eXt5chzcA3L/jJp/heOeqbqKzK3dIyVbMiAt S1+6Vaoxkc3yiWiS3cNhY0+piJaAwUl814JbQ/BRXmVJx5pGkMmDoypkihc3kcEdswgK gzuNuQgWzWIH4U6dnsXpw6h59QF5nBPrteFtnCikZj8GX/TkhhDWnNkSET9LGzxJrBgm oagDMEpaaUGl4VgVnErJc2biAZOX84DZ0F7EWowqHGOpQpzj5ZbldU+BdoUXHo/lt7OT AwVRIhzCVuNrveuSHr2r444KZTME8f4INf88UBw4JzmhZQuJ3wREYsbkWimseLXrtkbO rPzg== X-Gm-Message-State: AOAM532jC4mdC4t/WkoOJJFJ+Z/p6w0VrpkXXhxxTeB9G7FezJHQ2fM7 bLV9B4zzfs3ME3Ghn8ZRHzWUqoIxSQmLYHTzzY8Hka8xxq4= X-Google-Smtp-Source: ABdhPJxKBb1r9dVW8vlJTz9ATy0FoXeMSB3gCE1MbmR9bJBdR7HQgcWmebE5gHoT8roLU9Vi/yZIllyFZPxPdhMw3N4= X-Received: by 2002:a05:620a:13d4:: with SMTP id g20mr2710726qkl.376.1603377760331; Thu, 22 Oct 2020 07:42:40 -0700 (PDT) MIME-Version: 1.0 References: <87imbybjne.wl-morrowc@ops-netman.net> In-Reply-To: From: Christopher Morrow Date: Thu, 22 Oct 2020 10:42:29 -0400 Message-ID: To: Di Ma Cc: Guyunan , Chris Morrow , Melchior Aelmans , SIDR Operations WG , SIDROps Chairs , "sidrops-ads@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 14:42:44 -0000 Howdy folks, We had 2 authors and 1 not-author reply here... Are there other folks interested in moving this forward? or working on this in the WG over the next few meeting slots/periods? -chris On Fri, Oct 9, 2020 at 6:51 AM Di Ma wrote: > > Yunan, > > > 2020=E5=B9=B410=E6=9C=889=E6=97=A5 14:41=EF=BC=8CGuyunan =E5=86=99=E9=81=93=EF=BC=9A > > > > Seems quite useful for local management of validated cache. A small sug= gestion, maybe the authors can further clarify the use of HTTP and HTTPs, w= hether HTTPs is mandatory, or it=E2=80=99s optional using either HTTP only = or HTTPs. > > > A very good catch. > > I think https is default at least as it is used in the name of this draft= literally. > > But I see a potential that http can work if IPsec has been established be= tween two cache servers. > > We can discuss it further if adopted as a WG item. > > Di > > > > > Support adoption. > > > > BR, > > > > Yunan > > > > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Melchior A= elmans > > Sent: Thursday, October 1, 2020 12:51 AM > > To: Chris Morrow > > Cc: SIDROps Chairs ; SIDR Operations WG ; sidrops-ads@ietf.org > > Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/= 12/2020 (Oct 12th) > > > > As a co-author I support adoption by the WG. > > > > THanks! > > Melchior > > > > On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow w= rote: > > > > Howdy, > > > > Please consider this the start of a WG Adoption call for the subject > > draft, the abstract of which is: > > > > "This document defines a method for transferring RPKI validated cache > > update information in JSON object format over HTTPs." > > > > The URL of which is: > > https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 > > > > Please give this a read-through and consider if the work is appropriate > > for the WG to work on. > > > > thanks! > > -chris > > co-chair-persona > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Oct 22 08:38:07 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495703A0EA5 for ; Thu, 22 Oct 2020 08:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 CriASEt9g59x for ; Thu, 22 Oct 2020 08:38:03 -0700 (PDT) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (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 A37A63A0B9C for ; Thu, 22 Oct 2020 08:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603381082; bh=UCrRYbSbBXvjBqIw2m31Uk1zdaq7dfJvVpI31WK65k0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=pPlotNczOya9JzjOkGpzpjpfgdAOZ+NXFLQkZh6UuULLt32IxmssP6tIl44/3u4MZIdG8hMc9Fj+QKSKv0bCJyIm/tiuZvo4GVjjvExOFJTEHtP9PSLASqu2YJrL6M4i4wJbKEpL/B3AUz5icb1C6Tfg2U5hV38c6S9icdH8JkLMTSkQBsNmNtW/3ripAlSH8mF/trMjYEOpRTWFeT7msHoJXubsyURdbPT6fznZmucapnHGff22xizIwBvqPdxFrQOeLxJfDMC+rU5hKM8vaO57KUEx3RdcpM7BM0sxu2hB9tfAbzX1lUhDV4e7v40Z4M7fNIffiTd4Jw/xBWG5cQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603381082; bh=BWmCyJhxMB3h/c0Uvg9k+qPOA04KN2QmYI8Vd9Z3O0U=; h=Subject:From:Date:To; b=ZqZHNZlQK8txr5sUwWTFmXhXs9uLMkyfTOFEYcbKK9ws+/wA7/5LqsOxcmrOhcbhdwc6K/bZQNhCfORtpL7iM7enmuzx6ZgbYZo3617rYgE97BQnInCaJ6WJ23HnDyYNqrRQ/RpXzM2QZFX0ugbcVo/14DVziDOahAhK3rF3oSGua1SBa9RJ+hnfzfbf5zmMW4dIb5j88ypeC0sCOyWqVypiqk75bPPolS+p40qRrrLyIF9+lz5W8txt0TAB6KZUQ8j3QJTTbUngeOCT6v2+R+fdudpvEEPTaBq2eCvs3dorCjBIYBgrlOtQQUIvdG/095S5jAvwL8g0F3L/q9ozJA== X-YMail-OSG: Ezf_o7AVM1npDZAvrmooot4yWWAeKyjgVibR5yZ.WI4pqzYIXmEjzBdPLzfhsbU _l977I2FMqEI9TDBzq2Pni3Tp9cgxjEZTTGgGiPyonfEnJKFGy07UiX_7PtlYXdRVHB9huHt3XYw QwwOGyjveuN8Pue2xw6mSdmZbTEaXdBqNrvB2qVU._1TE26N3SOH_wNldTxV1Hk_T3c3.5Fks2Vq LiRFl2WTJixmFIYTraQV0Vb93ewcqYnr5l_vgoi7tR2c9KNMkMpooC1YyneJOa7_jns7RVKar1hq pNhylZ0czfkWrm.jGsiookEJIbC.DZta3bEMO5aV5MPOfhUDMObuzaAWZ1_55wWOfZ_9SACqtJQd R79Ps8AIxCjQuu9tXVZwhY9OCGX647pycTEoxH8ItcZzdXCMgtvFOR3tG4O3mX5HezLKMHVDwWRf OJUQdg73bd4yEE7M9JedBBXDFWQ1FHh_lfcJ2wqBg2BvO4mwwXaCbA.1te4NUEB62qMTVd_UsN0S g_xWiqR56Hc2Epwyf7xu78h_7KJmxUSzAOO_ZuqjE1H676PO16_TQZA1.ZGFPmFzSt7Z9gbw.ZIK yqErylHlAwfCYG8YdGSjw6.AvlIBX5CewxFMHczRBB02IHJJPxu2pmIEzeWaDC_QW60DVnSDxuoL UN4j4WafPguu3k8WCLPs4p5g63MTkpz_3kgzatE998xSNbXpYwyafonITsHtbiALCO2eerZMug3V 30sQmLVNmSC1I2dPenEMlq6_IFJJHtohur2PfQlLADayhuyLrqFaLzdsAema6vC.vwQRzxdvHU0s foF_89R_ABaKgPqIx.7NLL4nQNrG9TBHzSL2ZkRn_BxU4Qj_VhTtOJA.505uAta3p66WLoItp3bf UtUu42WkgL1a5.gWa29u_ub7rNT9B5LbLVk3CMVDiq9jBvbBSP2tNZh.BMsKgAGJ1Zvc8XHzSuMa .UXr6LWGf.a20n6al3tzND5WMe1WltcEKZsQiJbMZqDDZkEeLNlc07p.4IMQwhYbKkhzSwcDYwmD ebWuI8xKI8D3WaHscg5pux8HWxPfEaeBqkXX2i4W7pY4lqUgEBmTKa7l_SlMtlWTGRkt1odRW9FP EN3HUs5nLiUyhs5xSuX73TA2uY0sD8_DaZArerB97_oWsXvYf1GClNtn8FopJvxcrvkhhhkvPdaN 6XiZQVkVbTY9oA313CrYKVwPiM3VBS16n.DydqOi7PtM0tGKI1euQYTrF7oFY3gc23PzgSBERKbV G_t.4Y9UhZWvqVF4ohtuMEY1v9xFvOWMcQLMYySV7K9YAEHV9306h9Qoj3B.qweP.DXel59QjjiV mXPQVIIF8QENd6TvSf7EXOTrelHsV8qnkKEP4kvfbdETaxFMxbWCgoGTJm4vRgtM0_0epwVSUGe9 qbVOU2v8Xp7C6eyL9gkLo0wpAu8R46W2hAyidMPAcLJE2NUU.uwwGvBAf10R3GqWoxFwK6YO4nG6 j9kWnkoxDBFKPK.nmREeDWZ1UB341WDyYPeHyCjdqnezhzzKzso.1PzHaQUwkunlAiz7X3ytCM3H jH9h9dTVXyvHkKghnab_fPifwQlMHfstGWdC3Xcl43jbUHEcjCf4wzYK4MGeDnJY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 22 Oct 2020 15:38:02 +0000 Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 56c14896d53184cd41327b063b3323fd; Thu, 22 Oct 2020 15:37:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Stephen Kent In-Reply-To: Date: Thu, 22 Oct 2020 11:37:58 -0400 Cc: Di Ma , SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans Message-Id: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> References: To: Christopher Morrow X-Mailer: iPhone Mail (17H35) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:38:06 -0000 I support adoption. SLURM seems to be a potentially very useful mechanism a= nd this proposal is a natural companion to SLURM, Steve=20 Sent from my iPhone > On Oct 22, 2020, at 10:42, Christopher Morrow wrote: >=20 > =EF=BB=BFHowdy folks, > We had 2 authors and 1 not-author reply here... Are there other folks > interested in moving this forward? or working on this in the WG over > the next few meeting slots/periods? >=20 > -chris >=20 >> On Fri, Oct 9, 2020 at 6:51 AM Di Ma wrote: >>=20 >> Yunan, >>=20 >>> 2020=E5=B9=B410=E6=9C=889=E6=97=A5 14:41=EF=BC=8CGuyunan =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> Seems quite useful for local management of validated cache. A small sugg= estion, maybe the authors can further clarify the use of HTTP and HTTPs, whe= ther HTTPs is mandatory, or it=E2=80=99s optional using either HTTP only or H= TTPs. >>=20 >>=20 >> A very good catch. >>=20 >> I think https is default at least as it is used in the name of this draft= literally. >>=20 >> But I see a potential that http can work if IPsec has been established be= tween two cache servers. >>=20 >> We can discuss it further if adopted as a WG item. >>=20 >> Di >>=20 >>>=20 >>> Support adoption. >>>=20 >>> BR, >>>=20 >>> Yunan >>>=20 >>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Melchior Ae= lmans >>> Sent: Thursday, October 1, 2020 12:51 AM >>> To: Chris Morrow >>> Cc: SIDROps Chairs ; SIDR Operations WG ; sidrops-ads@ietf.org >>> Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/1= 2/2020 (Oct 12th) >>>=20 >>> As a co-author I support adoption by the WG. >>>=20 >>> THanks! >>> Melchior >>>=20 >>>> On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow w= rote: >>>=20 >>> Howdy, >>>=20 >>> Please consider this the start of a WG Adoption call for the subject >>> draft, the abstract of which is: >>>=20 >>> "This document defines a method for transferring RPKI validated cache >>> update information in JSON object format over HTTPs." >>>=20 >>> The URL of which is: >>> https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 >>>=20 >>> Please give this a read-through and consider if the work is appropriate >>> for the WG to work on. >>>=20 >>> thanks! >>> -chris >>> co-chair-persona >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Oct 22 09:17:49 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DD73A07E6; Thu, 22 Oct 2020 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qydYiLdk8l5f; Thu, 22 Oct 2020 09:17:44 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935673A07BD; Thu, 22 Oct 2020 09:17:44 -0700 (PDT) Received: from bench.sobornost.net (153-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.153]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 2D0F9220171; Thu, 22 Oct 2020 16:17:42 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 185158b3; Thu, 22 Oct 2020 16:17:40 +0000 (UTC) Date: Thu, 22 Oct 2020 16:17:40 +0000 From: Job Snijders To: Stephen Kent Cc: Christopher Morrow , Chris Morrow , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Di Ma Message-ID: <20201022161740.GT58295@bench.sobornost.net> References: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:17:49 -0000 Hi all, I am hesitant to support adoption as I feel this opens yet another not-at-all-validated channel into pandora's box. I don't think this draft in its current form is ready for adoption. If this work is to proceed, I'd like RUSH to *strictly* limit itself to transportation of VRPs within a *single* trust domain. If you are not willing to give the operator of the RUSH endpoint absolute unrestricted 'enable' access on your BGP routers, they are outside your trust domain and one should not talk RUSH with them. The offending paragraph is this one: "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs) need to publish assertions with origin AS0 ([RFC6491]) for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator. RUSH is able to deliver those assertions to RPKI relying parties if so called AS0 SLURM file are generated by the RIR." Here is an *explicit* example of the detrimental effects of so-called RIR 'AS 0' policies https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html Do we really want to create big red buttons that can be pressed to nuke *countries* off the global Internet Routing system? Surely that is not our intention. I'm a pacifist, I do believe that if we don't develop machine guns, machine guns can't be used against other human beings. If RUSH is positioned akin to IBGP, RTR or IGP (OSPF/ISIS) - something that in the general Internet routing use case is *not* something you'd set up with a third party (like an RIR), the specification can perhaps be morphed into something that is useful. However, if we zoom in on the contents of the draft, it really is just "SLURM over HTTP" ... and I am not sure whether it is worth standardizing that a RFC 8416 file can be put on a HTTP server. Will the next Internet-Draft be that a SLURM file can also be transported over SSH? This Internet-Draft (to me) doesn't read as a novel specification, and given the use cases that it includes (which I find problematic) I am lacking convinction this is the right path forward. RUSH is not an alternative to signed object security. Object security based on X.509 (which some painstakingly worked on for a decade!) is a corner stone of the routing system, we have to be very careful when specifying things that water it down. However... there *might* be some work to be done in this area (forgive me for linking to non-IETF resources, this is not to promote or NIH) https://github.com/job/draft-sidrops-rpki-vrp-lorri HTMLized version here https://htmlpreview.github.io/?https://raw.githubusercontent.com/job/draft-sidrops-rpki-vrp-lorri/master/draft-spaghetti-sidrops-rpki-vrp-lorri-00.html As it currently stands all RPKI validators are able to emit the VRPs in a JSON format. This JSON format has become the defacto standard because each validator blindly copied the other validators. However, the 'commonly used JSON format for VRPs' is not optimal from a data structure perspective, and it is not standardized (unlike SLURM). There is no schema, and thus no validation. In summary: * RUSH specifically targets a (IMHO) terrible use case * RUSH appears to be "SLURM over HTTP" (doh?) * One can argue there is a need to standardize a VRP exchange format perhaps based on JSON for archival / intra-domain applications Kind regards, Job From nobody Thu Oct 22 09:25:03 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5FF3A082C for ; Thu, 22 Oct 2020 09:25:01 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=netorgft1331857.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 oH6uaocWjDr9 for ; Thu, 22 Oct 2020 09:25:00 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770040.outbound.protection.outlook.com [40.107.77.40]) (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 1BCCB3A0822 for ; Thu, 22 Oct 2020 09:24:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=norBDSCWm180uAgM/ub0EZ3N4Dphumhda7uajGMOC6u2rljyjnsDHBzI6AbpD/9+QKkyLQ4xYUK3Ve9zKwIbv7gJ4NmZVFxHHnzon5zuHBwFs75mcbntOqsZCINdNJ2qNkZI6EVYl9RrB6kPc0xdXw+rD2DbLNJvhDfvpiE79Ho2ha3C/0gJrEM+svkFXDv7IXb2W2TnD33xIh62/X0AldBl6mVkbpL8+GIXR3SMkvT6VLJ1uwPe2MS2csxTzgyeSwgmBhP7J2adSRxEvd0GfyWTMz7jezusgZw9wRzG/JIIoTBkwbX1rmR8iydVcYv6k1imtSMC7OZuNrORblo0pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xImEod+GN4lXnnEoqg/hJm3vm1EccDuN8qWRDmOFSV4=; b=ecZi80jIpQnR/MWkZVoyfXDxiDWNXx2WqtLW+XLOZef38TU4cH9CmotWxecbWu1s2HJxXJuLWa0lToY+nModNfJIB4VifeMq/cya7FaWWSVUVZPTDkBeV2guQjxb4S9uROVZ3yJzNLZIHCZfE3vsBqyhilE0jP0YoegNrYyGA6tfiu1p7CDTpArfLTDGXKmq1Tw77jd5jl95GXDNyl4nKFC/CmghRGQvwdBTDTlhfPzqxz4xlLWW68BDf3fw6wyFSnYczlzTs7nrbsYzdmKab3q7YctmQFRfp0nuzl00/SuMpT4qsg7qz/t4MXNgzl1sz8X1GvtUuMLG4HdezQUQlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xImEod+GN4lXnnEoqg/hJm3vm1EccDuN8qWRDmOFSV4=; b=CdWgCpXRrM8jYgcoPoNfQeYVcayuPW67VTKu9F4uLgGpg/oI02EQXDNjyzIWDhyBKzI1AjlZLwxKPfQJN6+z76ZH8+84WcF50R8REvk1a8s2rpiZFIHnPZ2O1W7PsGN7SviTnn1eLFjKDl/jiXnoktzePXUOQYIlHT5C8GHJAzY= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3266.namprd18.prod.outlook.com (2603:10b6:a03:1a1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Thu, 22 Oct 2020 16:24:57 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d%7]) with mapi id 15.20.3477.029; Thu, 22 Oct 2020 16:24:57 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: IETF109 -- Online -- Call for Agenda Items Thread-Index: AQHWqI/h1hLCqY+28kaE01GZFD5OoQ== Date: Thu, 22 Oct 2020 16:24:56 +0000 Message-ID: <27CEB8B1-D1CF-400C-9FFE-A2CC2FA0CB1B@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d371ad9d-2a61-4181-e137-08d876a703f0 x-ms-traffictypediagnostic: BY5PR18MB3266: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ssSZW4+Z4ZVUoZaHvrKT0sfiutEQcvioE206H3MFfZhWnab9G3BpgF8B+/1QoWaqJLivZrMImqgMZnEUFB6xZxaon/9mNynONR0iqjE7ksvEiMBhSDkbfyANaEkd3BP3P07qoOs+bYCpX87HUu4gztPp+XnPyKotqBaNENl33//ZEGIs9pj1VBpiZE6+b1BqNWvou2xPadZ+g4YzxRgng03Tk2c+MnIiFGR/EhFbCXWtVhNKnVhwMymEWqN3c5HDEJZm7xMhxXePM0xdCKh8VVkQHOMpHrXIlzZPd6DVgv9uAPNCHjQQ2ND/Sx5XkIhuyKrEsakBYy0bxztAViDyTw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39830400003)(136003)(396003)(66556008)(64756008)(6512007)(66446008)(66476007)(76116006)(26005)(83380400001)(478600001)(6506007)(71200400001)(316002)(4744005)(66946007)(5660300002)(8936002)(2906002)(2616005)(6486002)(6916009)(36756003)(86362001)(33656002)(186003)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: u1y4fyiZPN32T0FHeCfvmPXUeqYOF2hqiMjF7uL0kcO2PLDVZH9DUSatZrdJk2HGCMW+ZB0zcfaVsMtuOh5JpXyNzOtWVBquRbeNwfY5EEjgG+NuiOk6NyUxyTGZz4i9TDsZnE8VhWOXlT6LhzvxagoGXudK4F6DSO6gkikSqeUDuaD1fq8BghZdlzNxlRxE7qHWt41ZkmGjg9A8cTY3C4nfCneF5/kEwUq5QnGZ351xXgqekl+iGxEz/Bwprke7G7vsUlbDJaa+tP/u+9WjpH+QaMRzOO5oKHDIkjm0rhmMqVtbW8E19B6XldiDCEae+MQaFwnVIM2vMw69sYUvRV6YvHfUKXAEVo0r/rN6rFM1IPgYSaHs67J8ccsmIMJBylc+v+N7MbsCv2Tgd+YYK3gotykkmz05Sbq//aQ1dSKULCcfxe5LenNcLtoplQXWlg3DYY1BD7KLKvFANydEOc9kdPQhn+EobBPNWshTOVNLUDHPpmy2rTdTEFJ1RJXU4TuXwrP5LGBHyoqTQ8x7FukAV0DpavFKTGP9AvvcHnMBIdefno8OHHEsEU9FgE3VB4rbBHoPuYF07fleKon9YiOxZa9I/B0r6Kb+UCHFsLMWlyqtmVZDEv89xi4+xbI5lzkYjzneBPlONtEHhtL22Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_27CEB8B1D1CF400C9FFEA2CC2FA0CB1Barrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d371ad9d-2a61-4181-e137-08d876a703f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2020 16:24:56.8870 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m9ffTauqfwW0Mh+yzPjScbPUizmHE4DdsUTtDmJBXeJ9iZ2AI5N9RgrZBSc02oe5e057mVrpQ/oUW+WKyUA0wA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3266 Archived-At: Subject: [Sidrops] IETF109 -- Online -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:25:02 -0000 --_000_27CEB8B1D1CF400C9FFEA2CC2FA0CB1Barrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IG9ubGluZSBhdCBJRVRGLTEwOSBvbiBNb25k YXksIE5vdmVtYmVyIDE2dGggZnJvbSA5OjAwIGFtIC0gMTE6MDAgYW0gKFVUQykuIFBsZWFzZSBm b3J3YXJkIGFueSBTSURST1BTIGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gTmF0aGFsaWUs IENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28gbWFrZSBzdXJlIHRoYXQgeW91ciBzbGlkZXMgYXJl IGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5IEZyaWRheSAoMTEvMTMvMjAyMCkuIFNsaWRlcyBy ZWNlaXZlZCBhZnRlciB0aGUgZGVhZGxpbmUgbWF5IG5vdCBiZSBhdmFpbGFibGUgZm9yIHVzZSBk dXJpbmcgdGhlIG1lZXRpbmcuDQoNClJlZ2FyZHMsDQpOYXRoYWxpZSwgQ2hyaXMgYW5kIEtleXVy DQoNCg0K --_000_27CEB8B1D1CF400C9FFEA2CC2FA0CB1Barrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <0251E85B79426A4889F9B814C6E9D85A@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPkhpIGZvbGtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+U0lEUk9QUyZuYnNwO3dpbGwgbWVl dCBvbmxpbmUgYXQgSUVURi0xMDkgb24gTW9uZGF5LCBOb3ZlbWJlciAxNjxzdXA+dGg8L3N1cD4m bmJzcDtmcm9tIDk6MDAgYW0gLSAxMTowMCBhbSAoVVRDKS4gUGxlYXNlIGZvcndhcmQgYW55Jm5i c3A7U0lEUk9QUyZuYnNwO2FnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gTmF0aGFsaWUsIENo cmlzIGFuZCBtZS4gUGxlYXNlIGFsc28NCiBtYWtlIHN1cmUgdGhhdCB5b3VyIHNsaWRlcyBhcmUg YXZhaWxhYmxlIHRvIHRoZSBjaGFpcnMgYnkgRnJpZGF5ICgxMS8xMy8yMDIwKS4gU2xpZGVzIHJl Y2VpdmVkIGFmdGVyIHRoZSBkZWFkbGluZSBtYXkgbm90IGJlIGF2YWlsYWJsZSBmb3IgdXNlIGR1 cmluZyB0aGUgbWVldGluZy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPk5hdGhh bGllLCBDaHJpcyBhbmQgS2V5dXI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_27CEB8B1D1CF400C9FFEA2CC2FA0CB1Barrcuscom_-- From nobody Thu Oct 22 10:32:16 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E783A09C6; Thu, 22 Oct 2020 10:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwudjdItuSwM; Thu, 22 Oct 2020 10:32:12 -0700 (PDT) Received: from relay.ops-netman.net (unknown [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E753A09C1; Thu, 22 Oct 2020 10:32:11 -0700 (PDT) Received: from mail.ops-netman.net (mail.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id A56693C2302; Thu, 22 Oct 2020 17:32:10 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 7EFC223D; Thu, 22 Oct 2020 17:32:10 +0000 (UTC) Date: Thu, 22 Oct 2020 17:32:10 +0000 Message-ID: <87zh4ekvz9.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org,sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:32:14 -0000 First, apologies for this being so tardy :( Second, thanks for attending the interim on 10/01/2020 (Oct 1st) and bearing with me/us in the conversation. Now, at the end of the meeting (which I thought was 1hr in, but was really 2hr in) I said I'd send out a mail to discuss two items: 1) Being clear about impacts/repercussions related to the decision process being put forth for 6486bis: a) There will be repositories that disappear when they can't get their content straight at publication time. b) Repeated failures at a CA/PublicationPoint(PP) will eventually lead to that CA/PP's routing intent falling back to 'not found'. c) In some circumstances (tim pointed these out I believe) if the CA/PP is a leaf below another CA/PP which publishes ROA for covering routes, the leaf CA/PP's routing intent may change to INVALID. ie: RIR -> LIR -> end-user if the LIR publises 8.0.0.0/8 - AS64600 if the end-user publishes 8.8.0.0/16 AS64601 if the end-user CA/PP expires (for any reason, but specifically collection problems) the end-user prefixes will become invalid. d) There are some ordering/rollout/planning concerns related to new object types in the repository which either need to be worked out in the bis OR noted and pushed to the next new object proposal. I think the authors are clear that: "for next proposal" I think the meeting participants seemed split, but that at least: "Hey, note that adding new objects will be different... pay attention!" should end up in the bis document. 2) Closing up the -bis conversation/document prior to december The current author set has an expiry timer, we can either finish up 'now' or hand-over reins at/after the F2F meeting + edit time. I'd like to get some closure on these, ideally, before the f2f in ~3wks time. -chris co-chair-persona From nobody Thu Oct 22 15:42:39 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9C53A08B6; Thu, 22 Oct 2020 15:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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 SS7LbnQxuzhO; Thu, 22 Oct 2020 15:42:37 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 F1FA53A08B2; Thu, 22 Oct 2020 15:42:33 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id t20so1879345qvv.8; Thu, 22 Oct 2020 15:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MzMXndztpwbj68Ct9KQzxaovmT3WoOme72uj6jvLS3A=; b=VfJ1dJN/pZSA0MSArSejeEZql4I3/7vXSbJQjnlADFj7W9ZRRl2cAgKKonQJrJhl3F NZuYG9iVPXq6gbuZlmEi42WgB8CtwURlCU+tK38fSoOtNYocefE8yhVa+Io7F+VXQTC1 n3C+Tmz/0Yybd/O9ZMjtVYDJ3sD8aakycnW1jXMu5eg9q43BB1LA1dmIVn+XnFHNKWxX Z9ZHV7q349tUk7RTiWTKhU67gIdiNYxog4oAbCc/0Nz7JhWGkarh3AMRdu3DMZxJIiNF HimQJld55Og9L05ReF1rlXpxHVbgBAu31AVD68XJNURMNC7G/J2WyW7yNPpj887AnDwH fDyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MzMXndztpwbj68Ct9KQzxaovmT3WoOme72uj6jvLS3A=; b=GodFjN2lCPHrmbiqIdJvrKn0VIgDbQjli9QHEE1kBa7j7ml3kUW+NKgV9bm7+y+FzN ytH8XZ5odYCTHPv46nGMFavWGAX/sg7r2eNQ9d2owrnyfKvB+Q8uvE88Y6ow3XZhc9yE snoEJYOUQDj1uz3MVi0vyEhnMubEcpeWFla2ma5TuduMfiW0E4/n2A/DLJpnn+t7AYkl 8Zzt4OT7WGN8GWlKsPy5ycw9Jwk1DcJTL48X4ZQGMF6snoTRBbcLLWvGqWoKF1ZHGRWb 51BkKgzt6iwnr9l85S/4L81zNNiid/Izg0PZ6CS2AEjHj0bIRF2a04DBNO28/m0pnmbB SuOA== X-Gm-Message-State: AOAM5311Gwvg36OYdv3LqYTn49lhhhQ6mOQkHierOztA7WaZl/+Hw8wn 7wQdX3qMrAZYjqNWTLzzp5BHtjJsiebG2GYx1TVmAkcR0Mc= X-Google-Smtp-Source: ABdhPJx4aY3Nf7JazaEK07krB3z/OsZ+Qqdx2fruUSXm3c1zCj5A+t5uWPJRRQsbFgyMQD9qrkCoJkU+ERnXvFx2pzQ= X-Received: by 2002:ad4:5901:: with SMTP id ez1mr4846509qvb.56.1603406552783; Thu, 22 Oct 2020 15:42:32 -0700 (PDT) MIME-Version: 1.0 References: <160320341819.24851.1095876182831900457@ietfa.amsl.com> In-Reply-To: <160320341819.24851.1095876182831900457@ietfa.amsl.com> From: Christopher Morrow Date: Thu, 22 Oct 2020 18:42:22 -0400 Message-ID: To: IETF Secretariat Cc: draft-ietf-sidrops-ov-egress@ietf.org, SIDR Operations WG , ipr-announce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 8893 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 22:42:38 -0000 Howdy SIDROps folks, Just making sure you all noted this came through this week... We did ask the authors if they knew of any pending IPR claims, they all replied: "Nope!" of course, none of them work(ed) for the claimant :( oops. fyi, forewarned is four armed and all that... -chris co-chair-persona. On Tue, Oct 20, 2020 at 12:27 PM IETF Secretariat wrote= : > > Dear Randy Bush, R=C3=BCdiger Volk, Jakob Heitz: > > > An IPR disclosure that pertains to your RFC entitled "Resource Public Key > Infrastructure (RPKI) Origin Validation for BGP Export" (RFC8893) was > submitted to the IETF Secretariat on 2020-10-19 and has been posted on th= e > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/4356/). The title of the IPR disclosure= is > "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 8893" > > > Thank you > > IETF Secretariat > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 23 06:18:58 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C609F3A0B40; Fri, 23 Oct 2020 06:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CmeLfgETev68; Fri, 23 Oct 2020 06:18:54 -0700 (PDT) Received: from out20-62.mail.aliyun.com (out20-62.mail.aliyun.com [115.124.20.62]) (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 0C2693A0A90; Fri, 23 Oct 2020 06:18:47 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1339426|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.405801-0.0126901-0.581509; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047188; MF=madi@rpstir.net; NM=1; PH=DS; RN=9; RT=9; SR=0; TI=SMTPD_---.InSiyG7_1603459115; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.InSiyG7_1603459115) by smtp.aliyun-inc.com(10.147.41.158); Fri, 23 Oct 2020 21:18:37 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Di Ma In-Reply-To: <20201022161740.GT58295@bench.sobornost.net> Date: Fri, 23 Oct 2020 21:18:21 +0800 Cc: Stephen Kent , SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans , Christopher Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> <20201022161740.GT58295@bench.sobornost.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 13:18:57 -0000 Job, > 2020=E5=B9=B410=E6=9C=8823=E6=97=A5 00:17=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi all, >=20 > I am hesitant to support adoption as I feel this opens yet another > not-at-all-validated channel into pandora's box. I don't think this > draft in its current form is ready for adoption. >=20 > If this work is to proceed, I'd like RUSH to *strictly* limit itself = to > transportation of VRPs within a *single* trust domain. If you are not > willing to give the operator of the RUSH endpoint absolute = unrestricted > 'enable' access on your BGP routers, they are outside your trust = domain > and one should not talk RUSH with them. You have got the essence of RUSH: TRUST. But, trust is not necessarily limited into the *single* trust domain. = If I am allowed to exaggerate, RUSH even can used between two tier 1 = ISPs as long as one trusts the other.=20 I think we authors have articulated the essential usecase. >=20 > The offending paragraph is this one: >=20 > "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs) > need to publish assertions with origin AS0 ([RFC6491]) for all the > unallocated and unassigned address space (IPv4 and IPv6) for which > it is the current administrator. RUSH is able to deliver those > assertions to RPKI relying parties if so called AS0 SLURM file are > generated by the RIR." >=20 > Here is an *explicit* example of the detrimental effects of so-called > RIR 'AS 0' policies = https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html > Do we really want to create big red buttons that can be pressed to = nuke > *countries* off the global Internet Routing system? Surely that is not > our intention. I'm a pacifist, I do believe that if we don't develop > machine guns, machine guns can't be used against other human beings. AS0 is only a potential usecase and it is a policy issue whether the = community decide to use RUSH to implement AS0.=20 But we just want to offer the tool.=20 >=20 > If RUSH is positioned akin to IBGP, RTR or IGP (OSPF/ISIS) - something > that in the general Internet routing use case is *not* something you'd > set up with a third party (like an RIR), the specification can perhaps > be morphed into something that is useful. As I mentioned, trust is not necessarily limited into a *single* trust = domain. =20 >=20 > However, if we zoom in on the contents of the draft, it really is just > "SLURM over HTTP" ... and I am not sure whether it is worth > standardizing that a RFC 8416 file can be put on a HTTP server. Will = the > next Internet-Draft be that a SLURM file can also be transported over > SSH? This Internet-Draft (to me) doesn't read as a novel = specification, > and given the use cases that it includes (which I find problematic) I = am > lacking convinction this is the right path forward. I don=E2=80=99t see the reason we would come up with SLURM over SSH.=20 If you find it, I am okay with that. >=20 > RUSH is not an alternative to signed object security. Object security > based on X.509 (which some painstakingly worked on for a decade!) is a > corner stone of the routing system, we have to be very careful when > specifying things that water it down. We indeed realize that RUSH is not an alternative to signed object = security as we state in Security Consideration. That=E2=80=99s why we iterate RUSH is intended to for TRUST. >=20 > However... there *might* be some work to be done in this area (forgive > me for linking to non-IETF resources, this is not to promote or NIH) > https://github.com/job/draft-sidrops-rpki-vrp-lorri HTMLized version > here > = https://htmlpreview.github.io/?https://raw.githubusercontent.com/job/draft= -sidrops-rpki-vrp-lorri/master/draft-spaghetti-sidrops-rpki-vrp-lorri-00.h= tml >=20 > As it currently stands all RPKI validators are able to emit the VRPs = in > a JSON format. This JSON format has become the defacto standard = because > each validator blindly copied the other validators. However, the > 'commonly used JSON format for VRPs' is not optimal from a data > structure perspective, and it is not standardized (unlike SLURM). = There > is no schema, and thus no validation. I go with a standard RFC8416 (SLURM). Why bother to find an = unstandardized tool? I am confused. Di and Melchior From nobody Fri Oct 23 06:45:09 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3C73A0AD5; Fri, 23 Oct 2020 06:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GJLBMhc6cocE; Fri, 23 Oct 2020 06:45:04 -0700 (PDT) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4902F3A0CC4; Fri, 23 Oct 2020 06:45:04 -0700 (PDT) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id CBEE4EE012F; Fri, 23 Oct 2020 13:45:01 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 0c7f0e2c; Fri, 23 Oct 2020 13:45:00 +0000 (UTC) Date: Fri, 23 Oct 2020 13:44:59 +0000 From: Job Snijders To: Di Ma Cc: Chris Morrow , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Christopher Morrow , SIDROps Chairs , Melchior Aelmans , Stephen Kent Message-ID: <20201023134459.GE32039@bench.sobornost.net> References: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> <20201022161740.GT58295@bench.sobornost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 13:45:08 -0000 Hi Di, On Fri, Oct 23, 2020 at 09:18:21PM +0800, Di Ma wrote: > > 2020年10月23日 00:17，Job Snijders 写道： > > I am hesitant to support adoption as I feel this opens yet another > > not-at-all-validated channel into pandora's box. I don't think this > > draft in its current form is ready for adoption. > > > > If this work is to proceed, I'd like RUSH to *strictly* limit itself to > > transportation of VRPs within a *single* trust domain. If you are not > > willing to give the operator of the RUSH endpoint absolute unrestricted > > 'enable' access on your BGP routers, they are outside your trust domain > > and one should not talk RUSH with them. > > You have got the essence of RUSH: TRUST. RUSH seems the opposite of TRUST. All validation steps from which we can derive a degree of trust have been removed? > But, trust is not necessarily limited into the *single* trust domain. > If I am allowed to exaggerate, RUSH even can used between two tier 1 > ISPs as long as one trusts the other. Interesting point, indeed we could iterate over all permutations of possibilities, but what you mention is simply not how things are done in practise between tier 1s (or other networks). I fail to see how the exaggregation supports the Internet-Draft. > I think we authors have articulated the essential usecase. Please see below. > > The offending paragraph is this one: > > > > "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs) > > need to publish assertions with origin AS0 ([RFC6491]) for all the > > unallocated and unassigned address space (IPv4 and IPv6) for which > > it is the current administrator. RUSH is able to deliver those > > assertions to RPKI relying parties if so called AS0 SLURM file are > > generated by the RIR." > > > > Here is an *explicit* example of the detrimental effects of so-called > > RIR 'AS 0' policies https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html > > Do we really want to create big red buttons that can be pressed to nuke > > *countries* off the global Internet Routing system? Surely that is not > > our intention. I'm a pacifist, I do believe that if we don't develop > > machine guns, machine guns can't be used against other human beings. > > AS0 is only a potential usecase and it is a policy issue whether the > community decide to use RUSH to implement AS0. > > But we just want to offer the tool. Yes, you want to offer a tool, but as I mentioned the existence of some tools is not without consequences to the global routing system. When a big red dangerous button is created, at some point someone somewhere will want to push it. I'll note for full transparency to this group that one of the co-authors of the RUSH Internet-Draft is also the co-author of a "RIR AS0" policy, which was rejected by the RIR community in which it was submitted. >From my perspective the many discussions all over the globe (which so far have taken place in APNIC, AFRINIC, RIPE, and LACNIC), is now just spilling over to SIDROPS. Just like in all those RIR policy forums, it should come as no surprise it will meet some resistance in this forum too. As one of the use cases explicitly references 'AS 0' policies, it no longer can be positioned as a neutral tool but has become part of a wider (contentious) discussion. > As I mentioned, trust is not necessarily limited into a *single* > trust domain. Interesting, I am not sure I understand your definition of trust domains. I am not even sure what my definition is, but I will point out that the RIRs generally are *not* considered something to blindly trust. The channel from RIR to Network Operator for RPKI related data is - right now - one that strictly flows through a X.509 verifyable chain, and RUSH is a novel way which sidesteps an existing more secure mechanism. Why water that channel down? > > However... there *might* be some work to be done in this area (forgive > > me for linking to non-IETF resources, this is not to promote or NIH) > > https://github.com/job/draft-sidrops-rpki-vrp-lorri HTMLized version > > here > > https://htmlpreview.github.io/?https://raw.githubusercontent.com/job/draft-sidrops-rpki-vrp-lorri/master/draft-spaghetti-sidrops-rpki-vrp-lorri-00.html > > > > As it currently stands all RPKI validators are able to emit the VRPs in > > a JSON format. This JSON format has become the defacto standard because > > each validator blindly copied the other validators. However, the > > 'commonly used JSON format for VRPs' is not optimal from a data > > structure perspective, and it is not standardized (unlike SLURM). There > > is no schema, and thus no validation. > > I go with a standard RFC8416 (SLURM). Why bother to find an > unstandardized tool? I am confused. The OpenBSD rpki-client, NLNet Labs Routinator, RIPE NCC RPKI Validator, Cloudflare OctoRPKI, NIC.MX FORT, and possibly other validators are all capable of emitting a specific (quite similar) JSON format. This (non-standardized) format that is *widely* deployed & used by operators, and has been for many years. I've uploaded an example JSON file here: http://sobornost.net/~job/example-rpki-client-json-output.txt Many network operators use this JSON format -today-. So on the one hand we have RUSH (SLURM over HTTP), on the other hand we have a JSON format that is widely used but not standardized. I brought up the topic of the not-standardized-json because it appears to cover a similar solution space to what RUSH addresses, and perhaps this working group has thoughts or ideas on whether this is work suitable for the working group. It is also fair to consider my reference to this non-standard JSON as 'thread hijacking', but to me it seems somewhat related. Kind regards, Job From nobody Fri Oct 23 07:33:42 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4463A0C10; Fri, 23 Oct 2020 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 7GSxsj-69Yg2; Fri, 23 Oct 2020 07:33:38 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD3D3A0BF7; Fri, 23 Oct 2020 07:33:37 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 649B360975; Fri, 23 Oct 2020 14:33:35 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1603463614; bh=m3YgP80vWPORJltXs8sfSnOE1BOaTjPaz7Xgp0Gd1tc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=uI8Xvrt7YRuaL1BUHYqaSVEtyDRnoXCi2exZ2hDxcgr09CtKNMArmeoBsKg+WBoQk 2bt0Vl/e8630QCd5LEZL9l/GV7Uu/9pbGyJ0jsaRaPcEHH18+vBQb81qnR+33Lp3pC v/PNv5/31IEJ3paBBQDxLbioFJBuOlbasOqCnrYk8iuDlRMxinWJQyPCCJNqKbIpW4 Fj1ytbPAR6PNh//slsYQBLPIjOiFiehO05ti5ok0IST6RqLpz0QxmKTKQk2ANnkssl M7ee0H5uczdJNLYVIEI0RemZLctwIqNZxhjpTKoRlUmOnWctdbOFsLnQF/tnplyDOg /FaZzKGOWi3Hw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <87zh4ekvz9.wl-morrowc@ops-netman.net> Date: Fri, 23 Oct 2020 16:33:32 +0200 Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> References: <87zh4ekvz9.wl-morrowc@ops-netman.net> To: Chris Morrow Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 14:33:41 -0000 Hi, > On 22 Oct 2020, at 19:32, Chris Morrow wrote: >=20 > First, apologies for this being so tardy :( > Second, thanks for attending the interim on 10/01/2020 (Oct 1st) and > bearing with me/us in the conversation. >=20 > Now, at the end of the meeting (which I thought was 1hr in, but was > really 2hr in) I said I'd send out a mail to discuss two items: Thank you. >=20 > 1) Being clear about impacts/repercussions related to the > decision process being put forth for 6486bis: > a) There will be repositories that disappear when they can't > get their content straight at publication time. I pointed out there is a failure scenario that cannot be avoided, where = a child CA produces delegated CA certificates or ROAs containing = over-claims, i.e. referencing resources not on its own CA certificate as = currently published by its parent. As a child CA using RFC 6492 (provisioning) I learn entitlements from my = parent (section 3.3.2), but the response lacks the context to know: - when a current resource will disappear - when a new resource will be safe to use, ie. when my *parent* = published my certificate, and it's picked up by RPs I am happy to try discuss preventing over-claims as a separate issue, = but in the context of this document I believe we should assume that they = will happen. This means that CAs will be temporarily rejected at times. This includes = the case where an RIR (eg Lacnic), issues a certificate with extra = resources to an NIR (eg nic.br), and the NIR issues and publishes a = delegated certificate to one of its members, before the extended = certificate is published by the RIR. FWIW, for the time being I can build a safeguard into the next version = of Krill to refrain from using new resources for some time, but any time = chosen is of course arbitrary. I think there are two options here: 1) accept that CAs will be temporarily rejected, even NIR level CAs 2) make an exception for overclaiming, but otherwise valid, objects I can see how #2 would be hard to swallow for some, but then at least = consciously accept and acknowledge that #1 will happen, and it's not the = rejected CA's fault. > =20 > b) Repeated failures at a CA/PublicationPoint(PP) will > eventually lead to that CA/PP's routing intent falling back > to 'not found'. > =20 > c) In some circumstances (tim pointed these out I believe) > if the CA/PP is a leaf below another CA/PP which publishes > ROA for covering routes, the leaf CA/PP's routing intent > may change to INVALID. > =20 > ie: RIR -> LIR -> end-user > if the LIR publises 8.0.0.0/8 - AS64600 > if the end-user publishes 8.8.0.0/16 AS64601 > if the end-user CA/PP expires > (for any reason, but specifically collection problems) > the end-user prefixes will become invalid. Indeed, so the landing is not always soft. There was a beginning of a discussion here: = https://mailarchive.ietf.org/arch/msg/sidrops/pi9v6RNA2kMvEOY9BfOD9VHGJtc/= The bottom line is that one might want to filter out VRPs for the = resources on the CA certificate for the child CA. Except in cases where = the child has *all* resources (e.g. it is the online CA under a TA), = because then this could invalidate all objects in the RPKI. Two options wrt VRP filtering: 1) Doing this adds complexity, and possibly brittleness in software as a = result. 2) Not doing this means the WG must accept that the landing is not = always soft, and may result in brittleness in routing. A child CA can = end up with invalid routes. To me the most important question is how routing security is best = served, by #1 or #2. I can live with either choice, as long as it's = consciously accepted and acknowledged. > d) There are some ordering/rollout/planning concerns related > to new object types in the repository which either need > to be worked out in the bis OR noted and pushed to the next > new object proposal. > I think the authors are clear that: "for next proposal" > I think the meeting participants seemed split, but that at = least: > "Hey, note that adding new objects will be different... pay = attention!" > should end up in the bis document. Observe the word 'valid' in this sentence in section 6.7 (Failed = Fetches): "or does not acquire current valid instances of all of the objects = enumerated" As written this implies that unknown object types are not considered = valid, and therefore RPs MUST reject *all* objects for a CA if they are = encountered. This means that new object types can only be published safely when, some = arbitrary value of, enough RPs have been upgraded to support it. And = even then those operators who did not upgrade will be left behind. By = this (arbitrary) time the burden may be on them, rather than the = publishing CA. I, and some others I believe, suggested that unknown objects could be = considered 'valid' in this context if they are present and match the = hash in the manifest (i.e. the PP is complete and unaltered). One could = even go further, and as long as the new object is a form of RPKI signed = object (RFC6488) one could validate the outer object, but not its = content. Or to make it more tangible in text: CURRENT: If an RP does not acquire a current valid manifest, or does not acquire current valid instances of all of the objects enumerated in a current valid manifest as a result of a fetch, then processing of the signed objects associated with the CA instance has failed for this fetch cycle. PROPOSED: Processing of the signed objects associated with the CA instance MUST be considered as failed for this etch cycle, if: o current instances of objects matching the names and hashes in a current valid manifest could not be retreived o any current object for a supported object type is considered invalid o any current object, of an unknown object type, which is found to be a form of an RPKI Signed Object, fails the validation outlined in section 3 of RFC 6488, with the exception that further = validation of the eContent (section 2.1.3.2) is not performed. This would allow for new objects to be introduced, without causing = existing - not updated - RPs to reject the publication point altogether. = I believe that this is safe as long as a new type is orthogonal in its = semantics to existing types - and it does not change their meaning. For = example: ASPA objects do not change how ROAs work or should be = validated. If new objects are not safe in this way, eg imagine that ASPA objects = would change the meaning of ROAs, then we could just introduce two new = object types instead: ASPA and ROAv2. CAs which would choose to do ASPA = then, could just publish ASPA and ROAv2 objects and stop doing ROAs(v1). Steve Kent suggested a different approach where new SIA entries are used = instead, so that new objects can introduced in a new -presumably = parallel - PP context. Theoretically this is indeed possible, and it = could be specified in a "next proposal". However, this approach = introduces a lot of new complexity for all parties involved. It will = take significant time to be specified, and it will then take more time = to be implemented. Until such time new object types could not be safely = introduced. So, I am not convinced about this approach at all. Then I = would prefer that we expect people to 'just upgrade their RPs', and = clearly document this in a considerations section. >=20 > 2) Closing up the -bis conversation/document prior to december > The current author set has an expiry timer, we can either finish = up 'now' > or hand-over reins at/after the F2F meeting + edit time. >=20 >=20 > I'd like to get some closure on these, ideally, before the f2f in = ~3wks time. I am all for resolving this timely if we can. I would also really like = to hear from other WG participants besides myself and Steve Kent. Tim >=20 > -chris > co-chair-persona >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 23 08:33:36 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851BC3A0EF8 for ; Fri, 23 Oct 2020 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 B0U1pDNm2oxg for ; Fri, 23 Oct 2020 08:33:34 -0700 (PDT) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (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 D5BD23A0EF9 for ; Fri, 23 Oct 2020 08:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603467213; bh=KqXy/Qtu38FJawN0WI3nhqAZ4unyy99Ugk58cRU14gg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=MIwShpkXMGRTRqBKkNc0BNS4wMKUid752fqIUha47nxjBdfPtxNRr64epRdUXyRA8Cn66OWPM5let7CVypLu/0UjMOQttyVRH5NkqlQiijudbuKBIt92O/jB/rBRnYlqd9ZdrELsqvRghDK9cDf7qUZK6fLKGoU576/mgMjlfiQP28s/SqhRaXM1Og2oEW9Ps4FpHZWQA4SA6YRzKG0CuofwEXxlYgPiiY92CK3Xz3Q4njInxnFb8hmeBhuQohQBC5sOzpI0Erh+OxXneCA3ltlr5Ltcd2Vr0G+pwsHxs5XvHWf8smWwA59R7Lqs2huSyyjkxNxRIyy0TNPfDzVs8Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603467213; bh=6JdkLGbSvCwpk/Jg3sxzPnzsFpLEC8zbW+NwnkCxFtO=; h=Subject:To:From:Date; b=CU4Ht70n5C12was+4dh/TM64HlJy82d7Uqj7fcuXgrbUklCZtjAoaESxAFLfZDfZe/iQ4FQhNaC9gMjl6u1M8JDfUYobhBgqXVMimGvbKj+PAm8jU5GrKl2eiGc+ymc2sqSo+Dc6hlJLW3NuodtXuc+oPFQ6CeEv4oKDZ4qLJUsz+5LeK8hMRiYfcb94wRxF2cSu8pEmEdfnaBuZMXSTIBGiL29PySLybJol9FhatMdGK9Ms7UCOdj11GBS/QhU29fFsCnTo9M2yuRfu5/kBGu7WIcRG75IkTHtCL/DnvgqbpivyFQ6e5sfotEkDziCRzYRRKlSsP43ZWLXCChlapw== X-YMail-OSG: Rbq2HwkVM1kqRRuQvzZFRxwZM9OP14x6avTWrVz0wFtlQZiiqWWwB4ooxI8lFhE JDQL.KmSORHaW2El_7NfHhJqQASq.8eVOOKzc_pCvRZmV8ZHdaceW3AOOXYoMN0KuY6Z5UvRLjPS SeXIm8BK98E_cE3iRjBQzBtL0MVJK47wmQq3X1PiuLxidLLnyu.iElflVOJwozE3nG88XBO_pE0C nIP5fKmvfqeI6zXPX4AQoX.Q80XFZDuvGyoywIZIsgsPQh8rDpiGEqLKihnq4g7uE1YL8SK_7buG 4ERHI0kmiCb19_ZCKOvjtEQNgAQ9ZvLOHRD8LJacZrCLwiQakHKGx0r59zDBuLw8mC5t4qCkGZ82 1lkcM7.8uzf0_oKE6QHEFptAjqbbZsxSErz6ekC7BK6B0PQTAK_2fBtRQ0PuBUb8EO0VydrW03pY IFJ57DTehAEBk5t1AAh6B7iICDA6xlQbNg3WjoIjV53Rox.__jyZeatd8ZERXuHqgZdPnFz2vPsE oc.ZF_Us1RdG28FSxc12kga9acxYeX669EdkUxQsnHGo.DADdzo1gYZblPgXm_OaCLzyY1T31LtM cVZu_q0gsJJmi_goP1KX89HDS3mBeCSiccvlFCeIjnusLdQjog1I167_AzaB.AP_2Hp.XGJoHBj. zY6sQ1ueXMlUmGlorgLb9MjuCFEwItVBzOGXiFt7yyuiNkVENEmRx08AugwirBj5Pg8AjDnqhZir 6An2x6yQm81d8D3ji4hhJlQl9MHZELYwdivVEMUJbnrCt76R8Vsge5JQkPJlFIyr4lvtimsE5ZT_ Xkd56GqIX2Ojc7eAMwcQ5mDFDbXtW4LwdsTsMN23590XzAVzp0ZImTmDoooXWeZPB2Gm.JZ8GLsK b2JlR0.u1JZqSw_h5B7C0Ry22pwb.spmM_TZAS_9fjG6dwtmJ..5iIemy_ZvSZ6CS3ploz_vUTfo FMaBo9_Q5RYEtc5k30lVX0jfNnvM0iqXsMWofpuZCWF8SOZbmSsZD3ILwQ9ISCy5BzGsL029HqYt FeNry2OUmR5HbXjfqYFpZsIh0a9TSPgqftWX.pgiW2c1eqGCr7XxUcepVdM5b.A.6sr0Ve1qsuDI lFIvuWIi4LTE6n8KM8vWop5.E576qg4JvlbO_5ZPxiw_Vrha7HVVO8Pm8J.E0LScE0DbcK9xRbHS wWoz_bd.FkJNwEUagj9UKCuYIGa0wzEk4n.HVXe9PFSSiwOnof1aIQja4eJCBQ6KskYwJQINKZsn waMLWhOdiFpF2GJkVns2L4ThGEEncEtHvVjAO8XVkODFBhE5B.etpYsuVlF6vUiaARM0bRvwqk5y uGpQzUKHHIDxiFX5H_qn13BniGuNUR62MKDMc3x.pQiSFstH3xWfZKcuUJ4CgpXcEET.Sm6mkxTM Oimh91CYZJARyzMYfcAcbzSBiXC01W0k1s768j.R2PbB9Nmu_Gf_XdVyurjby7ZRIE.TTgPjhLyP iFTeRo5Tu8cqyzNC3HWhoOF26KDPKLSw2MX0lDV94_iaZYl0iV1gEzE3cb1J1qFMokpNG8R7.MAA tQrlZqNbEtInGo74ZUsBjwhbqsVZAZAQTWFGJbriAbagYRxZLDz.7LaDIyOLdlKz7EyepjUixfc9 7oSeFPNzY8ZBmu8KpQocZVgyhFNXJWmZ54seYxhM6E9cX1d46Ebt7JF27IwSAzWA.VqxNTt2Cu1. bW9n4RJiX4tIMhEaoptPUX6cDfalg6NvoRyRgHf7qak9gSXlY6bopidGYQcOlaCc9eDjJZatoyit Bry0QLoxLq3ZRDcz_yP3Ucsi8kY6eXfzpAMqcphCiBWhuGp9efLsJi.zrD6YNnbCQgPl72GTG2N0 46eEtTVZ7JylPTbHxc2FEMpt_LfNeAqMQRfXSxaKmAJ3NLvyG1X3kDlKpa_kUMKGEDfqcQiBcxRB l3KMUUEtetZOzfb3rDKMdXfq49ElPp12mewjs3KS7qdlBan3eMpSXa.8JZwZub7Q7WPXxSTcrqSG MkjEhRqiDef9ArUeFyboQJ1BKVAvX0arXEOSihNjTxHRMWKGEsahY_Wp.Wpj8e7hb5JjvaB0zxxy 2Z.Bdo.30rE2rOzj74fbJaqkKj0_Ut6NtT1tOPBro7gPdhmCWPDj5atDxDUgYLXDtA6YcBkAd0gl UnfaRhIeG7efaEzLEYKPYyx9.U3GjiWMjj6WZ5SwHQxt.eRHBTI7WrHF3ii2er7fXL2igDpcr8Cl hl4SScrxq7b54oqszc1VlPHNfCMMHnt74D3gDniKU5SQuVpQVst8fxJ20IigXMnMN2zD51ALKhq2 VP53Ail1PdzzHbiexDRxDfTja9PqzcxtJPZ6ZLDKGfEln8iCnNzcuWudarGx1qI5KqNtvnKXWiQS R2ZohveaWj0ag.CN_L27DG3233jixj63j0fhxLbm_ZnamKmFD0e3kxu0PBgmtRDMA2hMU8CLM4cL 6ePX8fKCJqucjsKAMW7wCUKI9fA1FzbzCgzq8Pnmzq2GRlSS8hTKkcQlX9x1k5wGQ_dMwfiusQk6 zo816Xss3dNA9CxPT_Br7gJUtDu83_uFC8J8PRLhhfyRmyVeWQS7PUvdPbWmKaf4P2nwQuKD9Fq0 ngbI39TxXPPOt.2_Vp614wimtPoIIkJzAy5AcQvPCpT4SIK7xO7wMCZAifzrZDaa75QqTf2A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 23 Oct 2020 15:33:33 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b966781a900a0b896fc38d4090b4095f; Fri, 23 Oct 2020 15:33:30 +0000 (UTC) To: sidrops@ietf.org References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> From: Stephen Kent Message-ID: <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> Date: Fri, 23 Oct 2020 11:33:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16868 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 15:33:36 -0000 Tim, > ... > I pointed out there is a failure scenario that cannot be avoided, where a child CA produces delegated CA certificates or ROAs containing over-claims, i.e. referencing resources not on its own CA certificate as currently published by its parent. > > As a child CA using RFC 6492 (provisioning) I learn entitlements from my parent (section 3.3.2), but the response lacks the context to know: > - when a current resource will disappear > - when a new resource will be safe to use, ie. when my *parent* published my certificate, and it's picked up by RPs > > I am happy to try discuss preventing over-claims as a separate issue, but in the context of this document I believe we should assume that they will happen. > > This means that CAs will be temporarily rejected at times. This includes the case where an RIR (eg Lacnic), issues a certificate with extra resources to an NIR (eg nic.br), and the NIR issues and publishes a delegated certificate to one of its members, before the extended certificate is published by the RIR. > > FWIW, for the time being I can build a safeguard into the next version of Krill to refrain from using new resources for some time, but any time chosen is of course arbitrary. > > I think there are two options here: > > 1) accept that CAs will be temporarily rejected, even NIR level CAs > 2) make an exception for overclaiming, but otherwise valid, objects > > I can see how #2 would be hard to swallow for some, but then at least consciously accept and acknowledge that #1 will happen, and it's not the rejected CA's fault. > Why should a parent push a new cert to a child without waiting a suitable interval to allow RPs to learn of changes? Such behavior seems a bit careless by the parent. > ... > The bottom line is that one might want to filter out VRPs for the resources on the CA certificate for the child CA. Except in cases where the child has *all* resources (e.g. it is the online CA under a TA), because then this could invalidate all objects in the RPKI. > > Two options wrt VRP filtering: > 1) Doing this adds complexity, and possibly brittleness in software as a result. > 2) Not doing this means the WG must accept that the landing is not always soft, and may result in brittleness in routing. A child CA can end up with invalid routes. > > To me the most important question is how routing security is best served, by #1 or #2. I can live with either choice, as long as it's consciously accepted and acknowledged. VRP filtering seems to add considerable complexity. If CAs can't manage to do a better job when changing resource allocations, why should we expect the RP side of  a child CA to do the right thing re filtering? > > Observe the word 'valid' in this sentence in section 6.7 (Failed Fetches): > > "or does not acquire current valid instances of all of the objects enumerated" > > As written this implies that unknown object types are not considered valid, and therefore RPs MUST reject *all* objects for a CA if they are encountered. > > This means that new object types can only be published safely when, some arbitrary value of, enough RPs have been upgraded to support it. And even then those operators who did not upgrade will be left behind. By this (arbitrary) time the burden may be on them, rather than the publishing CA. > > I, and some others I believe, suggested that unknown objects could be considered 'valid' in this context if they are present and match the hash in the manifest (i.e. the PP is complete and unaltered). One could even go further, and as long as the new object is a form of RPKI signed object (RFC6488) one could validate the outer object, but not its content. Your suggestion would avoid the problem you describe, but it also means that publishers of such objects have no idea whether any RPs know what to do with them. Is the plan to allow publication of arbitrary new objects (so long as the outer wrapping meets the 6488 syntax), and to address the transition to use of new objects in the RFCs that define the semantics of those objects? > ... > > PROPOSED: > Processing of the signed objects associated with the CA instance MUST > be considered as failed for this etch cycle, if: > > o current instances of objects matching the names and hashes in a > current valid manifest could not be retreived > o any current object for a supported object type is considered > invalid > o any current object, of an unknown object type, which is found to > be a form of an RPKI Signed Object, fails the validation outlined > in section 3 of RFC 6488, with the exception that further validation > of the eContent (section 2.1.3.2) is not performed. I find the wording above very confusing; the term "supported" is not defined, and  the last bullet is very, very convoluted, ... How about: Processing of the signed objects associated with the CA instance MUST be considered as failed for this etch cycle, if o current instances of all the objects matching the names and hashes in a current valid manifest could not be retrieved o any of the retrieved objects fails the Signed Object validation process described in Section 3 of RFC 6488 o any retrieved object, of a type that the RP is prepared to process, fails validation of the eContent as described in Section 2.1.3.2 above > This would allow for new objects to be introduced, without causing existing - not updated - RPs to reject the publication point altogether. I believe that this is safe as long as a new type is orthogonal in its semantics to existing types - and it does not change their meaning. For example: ASPA objects do not change how ROAs work or should be validated. I agree that new objects that are independent of semantics of existing object types could be tolerated under these revised processing rules. > If new objects are not safe in this way, eg imagine that ASPA objects would change the meaning of ROAs, then we could just introduce two new object types instead: ASPA and ROAv2. CAs which would choose to do ASPA then, could just publish ASPA and ROAv2 objects and stop doing ROAs(v1). Easily said, in a casual fashion, but if one examines the transition processes already defined for alg transition etc., this will entail a complex description. Still, I suspect your principal goal is allowing near-term publication of ASPA objects, without having to deal with description of a transition process, so for that concern the revised Manifest processing changes would suffice. Steve From nobody Fri Oct 23 12:15:08 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361563A13A4 for ; Fri, 23 Oct 2020 12:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 LnJJIebS8Pd4 for ; Fri, 23 Oct 2020 12:15:03 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C61D3A139E for ; Fri, 23 Oct 2020 12:15:03 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 6650460290; Fri, 23 Oct 2020 19:15:01 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1603480500; bh=nG22xBG98J/mxJcISwwPMCQVSVA6dJul9Vg7/xIA6wM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=aA60DM6etioVdsHs6STEM5j6YFR2YJHUXUSzCwzzdNN7NAZkm5wDOfk5q8C1PfB7F KXoBIwfXBywfK7gRQJGDcqJ8km/f+6OlKjbpCMBFu/H2psl+R450d1Ou1iyMHIxjmY sZ29U/tsrt5MXq1b5NUzWQXwSmcuMLljdgQ+L38oH0r44/Dq/sZUgZeg67eonzSbhn CaDGNTwal+MCj3OwpuETwkI9T4jiAm0x36JquCdfpTsBDAapFb//3V5IN+u8OrecSb nefsA5amgaOnwRqkvFbNHTCSoND50DtdatACLl3LWkjvr1lnfA1vylOHd2rrf8uIHI YtDaLPkAyaPVA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> Date: Fri, 23 Oct 2020 21:14:59 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 19:15:06 -0000 Steve, Thank you for your quick reply. > On 23 Oct 2020, at 17:33, Stephen Kent = wrote: >=20 > Tim, >> ... >> I pointed out there is a failure scenario that cannot be avoided, = where a child CA produces delegated CA certificates or ROAs containing = over-claims, i.e. referencing resources not on its own CA certificate as = currently published by its parent. >>=20 >> As a child CA using RFC 6492 (provisioning) I learn entitlements from = my parent (section 3.3.2), but the response lacks the context to know: >> - when a current resource will disappear >> - when a new resource will be safe to use, ie. when my *parent* = published my certificate, and it's picked up by RPs >>=20 >> I am happy to try discuss preventing over-claims as a separate issue, = but in the context of this document I believe we should assume that they = will happen. >>=20 >> This means that CAs will be temporarily rejected at times. This = includes the case where an RIR (eg Lacnic), issues a certificate with = extra resources to an NIR (eg nic.br), and the NIR issues and publishes = a delegated certificate to one of its members, before the extended = certificate is published by the RIR. >>=20 >> FWIW, for the time being I can build a safeguard into the next = version of Krill to refrain from using new resources for some time, but = any time chosen is of course arbitrary. >>=20 >> I think there are two options here: >>=20 >> 1) accept that CAs will be temporarily rejected, even NIR level CAs >> 2) make an exception for overclaiming, but otherwise valid, objects >>=20 >> I can see how #2 would be hard to swallow for some, but then at least = consciously accept and acknowledge that #1 will happen, and it's not the = rejected CA's fault. >>=20 > Why should a parent push a new cert to a child without waiting a = suitable interval to allow RPs to learn of changes? Such behavior seems = a bit careless by the parent. Part of the issue - I believe - is that the parent can pro-actively = issue a shrunk certificate to the child *before* they learn about the = shrunk resource set, and send a new CSR for the reduced set. This may = seem careless, but the parent may not have a choice if their own = certificate is shrunk. But, I think I should start a separate thread on this and explore the = problem statement before suggesting solutions. I don't think this can be = solved as part of the bis work. >> ... >> The bottom line is that one might want to filter out VRPs for the = resources on the CA certificate for the child CA. Except in cases where = the child has *all* resources (e.g. it is the online CA under a TA), = because then this could invalidate all objects in the RPKI. >>=20 >> Two options wrt VRP filtering: >> 1) Doing this adds complexity, and possibly brittleness in software = as a result. >> 2) Not doing this means the WG must accept that the landing is not = always soft, and may result in brittleness in routing. A child CA can = end up with invalid routes. >>=20 >> To me the most important question is how routing security is best = served, by #1 or #2. I can live with either choice, as long as it's = consciously accepted and acknowledged. > VRP filtering seems to add considerable complexity. If CAs can't = manage to do a better job when changing resource allocations, why should = we expect the RP side of a child CA to do the right thing re filtering? Note that this VRP filtering is very similar to the SLURM prefix based = filtering already implemented by many RPs (Section 3.3.1 of RFC 8416). = The key difference would be that in this case covering VRPs would need = to be filtered as well (I am not sure now why this was not done in = SLURM). I don't deny that it adds complexity, and I can understand if the WG = prefers the simpler validation model, but there is some prior art. >> Observe the word 'valid' in this sentence in section 6.7 (Failed = Fetches): >>=20 >> "or does not acquire current valid instances of all of the objects = enumerated" >>=20 >> As written this implies that unknown object types are not considered = valid, and therefore RPs MUST reject *all* objects for a CA if they are = encountered. >>=20 >> This means that new object types can only be published safely when, = some arbitrary value of, enough RPs have been upgraded to support it. = And even then those operators who did not upgrade will be left behind. = By this (arbitrary) time the burden may be on them, rather than the = publishing CA. >>=20 >> I, and some others I believe, suggested that unknown objects could be = considered 'valid' in this context if they are present and match the = hash in the manifest (i.e. the PP is complete and unaltered). One could = even go further, and as long as the new object is a form of RPKI signed = object (RFC6488) one could validate the outer object, but not its = content. > Your suggestion would avoid the problem you describe, but it also = means that publishers of such objects have no idea whether any RPs know = what to do with them. Is the plan to allow publication of arbitrary new = objects (so long as the outer wrapping meets the 6488 syntax), and to = address the transition to use of new objects in the RFCs that define the = semantics of those objects? >> ... >>=20 >> PROPOSED: >> Processing of the signed objects associated with the CA instance = MUST >> be considered as failed for this etch cycle, if: >>=20 >> o current instances of objects matching the names and hashes in a >> current valid manifest could not be retreived >> o any current object for a supported object type is considered >> invalid >> o any current object, of an unknown object type, which is found to >> be a form of an RPKI Signed Object, fails the validation = outlined >> in section 3 of RFC 6488, with the exception that further = validation >> of the eContent (section 2.1.3.2) is not performed. >=20 > I find the wording above very confusing; the term "supported" is not = defined, and the last bullet is very, very convoluted, ... >=20 > How about: >=20 > Processing of the signed objects associated with the CA instance = MUST > be considered as failed for this etch cycle, if >=20 > o current instances of all the objects matching the names and hashes = in a > current valid manifest could not be retrieved > o any of the retrieved objects fails the Signed Object validation = process > described in Section 3 of RFC 6488 > o any retrieved object, of a type that the RP is prepared to = process, > fails validation of the eContent as described in Section 2.1.3.2 = above I like your text better! >=20 >> This would allow for new objects to be introduced, without causing = existing - not updated - RPs to reject the publication point altogether. = I believe that this is safe as long as a new type is orthogonal in its = semantics to existing types - and it does not change their meaning. For = example: ASPA objects do not change how ROAs work or should be = validated. > I agree that new objects that are independent of semantics of existing = object types could be tolerated under these revised processing rules. >> If new objects are not safe in this way, eg imagine that ASPA objects = would change the meaning of ROAs, then we could just introduce two new = object types instead: ASPA and ROAv2. CAs which would choose to do ASPA = then, could just publish ASPA and ROAv2 objects and stop doing ROAs(v1). >=20 > Easily said, in a casual fashion, but if one examines the transition = processes already defined for alg transition etc., this will entail a = complex description. Still, I suspect your principal goal is allowing = near-term publication of ASPA objects, without having to deal with = description of a transition process, so for that concern the revised = Manifest processing changes would suffice. Indeed that is my principal goal and this works for me. I can also see how for the class of new object types which are not = orthogonal to existing types the transition process needs to be clearly = defined as part of their definition. Tim >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 23 14:17:34 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56E3A098D; Fri, 23 Oct 2020 14:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: warren@kumari.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774775.5087.1935183035370698711@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:47 -0700 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 109 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:51 -0000 Dear Chris Morrow, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (2:00 requested) Monday, 16 November 2020, Session III 1600-1800 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: idr rtgwg grow Technology Overlap: opsec rtgarea Key Participant Conflict: dnsop People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 27 23:33:24 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214923A0FD4; Tue, 27 Oct 2020 23:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FOy8b86Xx_Wy; Tue, 27 Oct 2020 23:33:21 -0700 (PDT) Received: from out20-111.mail.aliyun.com (out20-111.mail.aliyun.com [115.124.20.111]) (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 757C93A0FCE; Tue, 27 Oct 2020 23:33:15 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06485461|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.108991-0.127076-0.763933; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047212; MF=madi@rpstir.net; NM=1; PH=DS; RN=9; RT=9; SR=0; TI=SMTPD_---.IpQuYpL_1603866786; Received: from 172.20.10.2(mailfrom:madi@rpstir.net fp:SMTPD_---.IpQuYpL_1603866786) by smtp.aliyun-inc.com(10.147.42.198); Wed, 28 Oct 2020 14:33:08 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Di Ma In-Reply-To: <20201023134459.GE32039@bench.sobornost.net> Date: Wed, 28 Oct 2020 14:32:48 +0800 Cc: Chris Morrow , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Christopher Morrow , SIDROps Chairs , Melchior Aelmans , Stephen Kent Content-Transfer-Encoding: quoted-printable Message-Id: <132DD2FB-C6D7-4F41-B532-3786C129CDA6@rpstir.net> References: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> <20201022161740.GT58295@bench.sobornost.net> <20201023134459.GE32039@bench.sobornost.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 06:33:23 -0000 Job, Sorry for my late response. > 2020=E5=B9=B410=E6=9C=8823=E6=97=A5 21:44=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi Di, >=20 > On Fri, Oct 23, 2020 at 09:18:21PM +0800, Di Ma wrote: >>> 2020=E5=B9=B410=E6=9C=8823=E6=97=A5 00:17=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >>> I am hesitant to support adoption as I feel this opens yet another >>> not-at-all-validated channel into pandora's box. I don't think this >>> draft in its current form is ready for adoption. >>>=20 >>> If this work is to proceed, I'd like RUSH to *strictly* limit itself = to >>> transportation of VRPs within a *single* trust domain. If you are = not >>> willing to give the operator of the RUSH endpoint absolute = unrestricted >>> 'enable' access on your BGP routers, they are outside your trust = domain >>> and one should not talk RUSH with them. >>=20 >> You have got the essence of RUSH: TRUST. >=20 > RUSH seems the opposite of TRUST. All validation steps from which we = can > derive a degree of trust have been removed? The trust in the RPKI roots in the public key that an RP uses to = validate a X.509 certificate or a signed object.=20 The trust in RUSH basically is the key bound to the cache server to do = authentication which by the way is out of band of the RPKI. Or the = trust can also be the shared-key pre-configured between cache server and = cache client of a RUSH connection in question. >=20 >> But, trust is not necessarily limited into the *single* trust domain. >> If I am allowed to exaggerate, RUSH even can used between two tier 1 >> ISPs as long as one trusts the other.=20 >=20 > Interesting point, indeed we could iterate over all permutations of > possibilities, but what you mention is simply not how things are done = in > practise between tier 1s (or other networks). I fail to see how the > exaggregation supports the Internet-Draft. >=20 An exaggerated example might not implemented in practice but helps make = the statement more straightforward. >> I think we authors have articulated the essential usecase. >=20 > Please see below. >=20 >>> The offending paragraph is this one: >>>=20 >>> "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs) >>> need to publish assertions with origin AS0 ([RFC6491]) for all the >>> unallocated and unassigned address space (IPv4 and IPv6) for which >>> it is the current administrator. RUSH is able to deliver those >>> assertions to RPKI relying parties if so called AS0 SLURM file are >>> generated by the RIR." >>>=20 >>> Here is an *explicit* example of the detrimental effects of = so-called >>> RIR 'AS 0' policies = https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html >>> Do we really want to create big red buttons that can be pressed to = nuke >>> *countries* off the global Internet Routing system? Surely that is = not >>> our intention. I'm a pacifist, I do believe that if we don't develop >>> machine guns, machine guns can't be used against other human beings. >>=20 >> AS0 is only a potential usecase and it is a policy issue whether the >> community decide to use RUSH to implement AS0.=20 >>=20 >> But we just want to offer the tool.=20 >=20 > Yes, you want to offer a tool, but as I mentioned the existence of = some > tools is not without consequences to the global routing system. When a > big red dangerous button is created, at some point someone somewhere > will want to push it. >=20 > I'll note for full transparency to this group that one of the = co-authors > of the RUSH Internet-Draft is also the co-author of a "RIR AS0" = policy, > which was rejected by the RIR community in which it was submitted. >=20 > =46rom my perspective the many discussions all over the globe (which = so > far have taken place in APNIC, AFRINIC, RIPE, and LACNIC), is now just > spilling over to SIDROPS. Just like in all those RIR policy forums, it > should come as no surprise it will meet some resistance in this forum > too. As one of the use cases explicitly references 'AS 0' policies, it > no longer can be positioned as a neutral tool but has become part of a > wider (contentious) discussion. I did note the discussions in RIPE Routing WG where AS0-slurm proposal = did not reach consensus. But I have not got the similar observation in APNIC, LACNIC, ARIN and = AfriNIC community. I would like to hear from them. Anyway, AS0-slurm is just one of the usecases. Should it not be proper = to be a RUSH usecase, RUSH should not be denied on the whole. >=20 >> As I mentioned, trust is not necessarily limited into a *single* >> trust domain. >=20 > Interesting, I am not sure I understand your definition of trust > domains. I am not even sure what my definition is, but I will point = out > that the RIRs generally are *not* considered something to blindly = trust. > The channel from RIR to Network Operator for RPKI related data is - > right now - one that strictly flows through a X.509 verifyable chain, > and RUSH is a novel way which sidesteps an existing more secure > mechanism. Why water that channel down? I think the first two usecases described in the draft are easy to be = implemented in a commonsense trust domain. o Cache Distribution RUSH can be used to distribute a RPKI validated cache within a single ASN or network, for example a confederation composed of a number of ASes. A small site or enterprise network MAY also use RUSH by synchronizing with a third-party RPKI cache provider over external networks. o Local Control over Networks Network operators MAY want to inject SLURM Assertions/Filters via an API offered by RPKI validator/cache. RUSH is therefore able to carry out such local control signals inside an administrative bailiwick in a secure manner. Di From nobody Wed Oct 28 05:50:30 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C4A3A0A42; Wed, 28 Oct 2020 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 RpTiPs0YEPuj; Wed, 28 Oct 2020 05:50:26 -0700 (PDT) Received: from out20-50.mail.aliyun.com (out20-50.mail.aliyun.com [115.124.20.50]) (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 4A3903A0A47; Wed, 28 Oct 2020 05:50:23 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06483812|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.326121-0.154525-0.519354; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047192; MF=madi@rpstir.net; NM=1; PH=DS; RN=9; RT=9; SR=0; TI=SMTPD_---.Ipao-Mx_1603889411; Received: from 192.168.8.2(mailfrom:madi@rpstir.net fp:SMTPD_---.Ipao-Mx_1603889411) by smtp.aliyun-inc.com(10.147.40.200); Wed, 28 Oct 2020 20:50:11 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Di Ma In-Reply-To: <132DD2FB-C6D7-4F41-B532-3786C129CDA6@rpstir.net> Date: Wed, 28 Oct 2020 20:49:51 +0800 Cc: SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Stephen Kent , Chris Morrow , Melchior Aelmans , Christopher Morrow Content-Transfer-Encoding: quoted-printable Message-Id: <12B9F3F2-13AD-48DF-8773-BBE498DDE5FE@rpstir.net> References: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net> <20201022161740.GT58295@bench.sobornost.net> <20201023134459.GE32039@bench.sobornost.net> <132DD2FB-C6D7-4F41-B532-3786C129CDA6@rpstir.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 12:50:29 -0000 Job, We authors are fine with removing AS0 usecase in RUSH after some = discussions. Di > 2020=E5=B9=B410=E6=9C=8828=E6=97=A5 14:32=EF=BC=8CDi Ma = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Job, >=20 > Sorry for my late response. >=20 >=20 >> 2020=E5=B9=B410=E6=9C=8823=E6=97=A5 21:44=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Hi Di, >>=20 >> On Fri, Oct 23, 2020 at 09:18:21PM +0800, Di Ma wrote: >>>> 2020=E5=B9=B410=E6=9C=8823=E6=97=A5 00:17=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >>>> I am hesitant to support adoption as I feel this opens yet another >>>> not-at-all-validated channel into pandora's box. I don't think this >>>> draft in its current form is ready for adoption. >>>>=20 >>>> If this work is to proceed, I'd like RUSH to *strictly* limit = itself to >>>> transportation of VRPs within a *single* trust domain. If you are = not >>>> willing to give the operator of the RUSH endpoint absolute = unrestricted >>>> 'enable' access on your BGP routers, they are outside your trust = domain >>>> and one should not talk RUSH with them. >>>=20 >>> You have got the essence of RUSH: TRUST. >>=20 >> RUSH seems the opposite of TRUST. All validation steps from which we = can >> derive a degree of trust have been removed? >=20 > The trust in the RPKI roots in the public key that an RP uses to = validate a X.509 certificate or a signed object.=20 >=20 > The trust in RUSH basically is the key bound to the cache server to do = authentication which by the way is out of band of the RPKI. Or the = trust can also be the shared-key pre-configured between cache server and = cache client of a RUSH connection in question. >=20 >=20 >>=20 >>> But, trust is not necessarily limited into the *single* trust = domain. >>> If I am allowed to exaggerate, RUSH even can used between two tier 1 >>> ISPs as long as one trusts the other.=20 >>=20 >> Interesting point, indeed we could iterate over all permutations of >> possibilities, but what you mention is simply not how things are done = in >> practise between tier 1s (or other networks). I fail to see how the >> exaggregation supports the Internet-Draft. >>=20 >=20 > An exaggerated example might not implemented in practice but helps = make the statement more straightforward. >=20 >=20 >>> I think we authors have articulated the essential usecase. >>=20 >> Please see below. >>=20 >>>> The offending paragraph is this one: >>>>=20 >>>> "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs) >>>> need to publish assertions with origin AS0 ([RFC6491]) for all the >>>> unallocated and unassigned address space (IPv4 and IPv6) for which >>>> it is the current administrator. RUSH is able to deliver those >>>> assertions to RPKI relying parties if so called AS0 SLURM file are >>>> generated by the RIR." >>>>=20 >>>> Here is an *explicit* example of the detrimental effects of = so-called >>>> RIR 'AS 0' policies = https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html >>>> Do we really want to create big red buttons that can be pressed to = nuke >>>> *countries* off the global Internet Routing system? Surely that is = not >>>> our intention. I'm a pacifist, I do believe that if we don't = develop >>>> machine guns, machine guns can't be used against other human = beings. >>>=20 >>> AS0 is only a potential usecase and it is a policy issue whether the >>> community decide to use RUSH to implement AS0.=20 >>>=20 >>> But we just want to offer the tool.=20 >>=20 >> Yes, you want to offer a tool, but as I mentioned the existence of = some >> tools is not without consequences to the global routing system. When = a >> big red dangerous button is created, at some point someone somewhere >> will want to push it. >>=20 >> I'll note for full transparency to this group that one of the = co-authors >> of the RUSH Internet-Draft is also the co-author of a "RIR AS0" = policy, >> which was rejected by the RIR community in which it was submitted. >>=20 >> =46rom my perspective the many discussions all over the globe (which = so >> far have taken place in APNIC, AFRINIC, RIPE, and LACNIC), is now = just >> spilling over to SIDROPS. Just like in all those RIR policy forums, = it >> should come as no surprise it will meet some resistance in this forum >> too. As one of the use cases explicitly references 'AS 0' policies, = it >> no longer can be positioned as a neutral tool but has become part of = a >> wider (contentious) discussion. >=20 > I did note the discussions in RIPE Routing WG where AS0-slurm proposal = did not reach consensus. >=20 > But I have not got the similar observation in APNIC, LACNIC, ARIN and = AfriNIC community. I would like to hear from them. >=20 > Anyway, AS0-slurm is just one of the usecases. Should it not be = proper to be a RUSH usecase, RUSH should not be denied on the whole. >=20 >>=20 >>> As I mentioned, trust is not necessarily limited into a *single* >>> trust domain. >>=20 >> Interesting, I am not sure I understand your definition of trust >> domains. I am not even sure what my definition is, but I will point = out >> that the RIRs generally are *not* considered something to blindly = trust. >> The channel from RIR to Network Operator for RPKI related data is - >> right now - one that strictly flows through a X.509 verifyable chain, >> and RUSH is a novel way which sidesteps an existing more secure >> mechanism. Why water that channel down? >=20 > I think the first two usecases described in the draft are easy to be = implemented in a commonsense trust domain. >=20 >=20 > o Cache Distribution > RUSH can be used to distribute a RPKI validated cache within a = single > ASN or network, for example a confederation composed of a number of > ASes. A small site or enterprise network MAY also use RUSH by > synchronizing with a third-party RPKI cache provider over external > networks. >=20 > o Local Control over Networks > Network operators MAY want to inject SLURM Assertions/Filters via an > API offered by RPKI validator/cache. RUSH is therefore able to = carry > out such local control signals inside an administrative bailiwick in > a secure manner. >=20 >=20 > Di >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 28 09:03:03 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60ED3A064A for ; Wed, 28 Oct 2020 09:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 eFsYLJtJRUIs for ; Wed, 28 Oct 2020 09:03:00 -0700 (PDT) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 08DDE3A05A6 for ; Wed, 28 Oct 2020 09:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603900978; bh=RphbzF7ielY2b2UP/QAJGrdakeyOhIY2/KACtBzye9Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=NHfOx1NRltbvKTYXDlVn8NArkNqXQe68Hv8IrWkNnGbIQGvDmGgMhv8tD9V7kJ3OFrT7LN/CviWCRl8vn5Ixn8anbH/e9XFyYYSHkzZI9yD3wP4hXWNi6lXivP4LLLKp1HNEvknhJ4iLuHtzkzu6uQh5FWfn+PsKPUp2iYDplvFJ8CF+bVmv6SG6yDeSnmdYBVR4okUEwr+CJUGBM3Fy6tB3/GsdcoXM8WTWmg+bXUq89nW+wIs4B6LK3oOow20sl3SoStyFK3VNIqtHlTUT19qd4b9VJloUB0sPIFTgW+I3sHB+tZD5Ro1HiVoQGbSSyM9aAWDusCqzsgJ28pmqnQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603900978; bh=K+VZ+3+DyeTs8yUF140k00xOha+ydRi4a9Mt5oVUg2o=; h=Subject:To:From:Date; b=cEtSgIn6PKGZwY/88HrNtG0WZrxOQLpgTQ5B9/xxmBR110roKbYGf+8hbmshLO1htLk3a5tzrG1UlCxb5u6Aa5kX1J9rh7Q7Esxga0x2lk26jcrIG9lmwqz1RAqYwXc/7ICknF677EHi2aJqpfeWb8LbPDBk2eu249vqnWhXRdJ42XkwfQDD1ibUBvmYJOUytXCkcu5ag0FI1c9uv+nPkRg2VK1bR56Cmt/Oy0nQBhjj853dt57Kii5Iqs3pumDt8888SM+4InQC6zSHu1/R9eTE0YSdkBc9nDzSnhIhVkp6S0bDm6A7V6GGf9eS0B5/Atmh+fNxMTe1Pl5qdXw9DA== X-YMail-OSG: RWuJD0YVM1k70gWurUF5OwS5AVROvCmw4tlQHyx43zomKVfCrqtNs2iJxfGFtYP zIkT0.Xn_IOpj6ZRaIdRy1ajRPUA4KbdUixEGnWioEilHBPm2s1eHlrVimGZ7OCpdgg.onIKWMB_ tD2gLQX8yGqaImznR2UHjosv1wA_QHO.9iCjdVe48f6QmdevjvZRBWqqbXxs76PAI.6BqImDMm7m n6G2Z4IRl0sUFYpVhDT8kiaBN8q3Y0EomkvvQ7sw9a9KFTvz1qZWV_AGZWT2RCxkoy4DFYZZM_vI n6UwWbRcgIHfK19vCR7JN5ESnVn2dpU8VFD.K6RHe.e0j_lq6SrFsFM83anx5_2HsAL8imCjEs7X v.XabxUwuXB_.x2.hiGVzyiWLcFw811L4UPEEczigIWrALiDzWYRJ.djlwExRuVZ98NnhGzifl7I dSoMC49lcQtenKaxlEDA0hOcg_6PVLpbAgUPctR.HqA5GNxvJ1EGndehdVTJPubYA9ONRnJToj1m QO1OS33SSfdX.KKm36nG4WVEux_wt5Zb_tB3VQ.iO2tOsgJf2lHXiyacVExI.I8O8EmdrIQ9lx6C I0LL9NLIYd3_g_st_HocwkIkJn8RFWvdd3FI6BktaNHQynjEOjjpSupbYyTt5o2bTFssUtHOo19R Q1eYHl5SRoaCRw7bKRDPR51.P6R02liTcU_Gk0PCnwyAj6i8x2SmSq9sG9n2Upn8b8zq9BBOKiAD mRFgqKCOUivzJjglIEEVf1YxxkyqEqBEkGK8PxMaSzutHVbgptW7X8CmEGFGFuFJ2TeJhShYUBpm 4Q6yjNj7UBr7z9VR2YXyWkKb0_7F0aAZVyro.DWrdS4_FkbbkWHmF.LtM2JUCCxOECakEi7pWKbW wPzu_b2NUy3457SKsEy9PSuZbjy2xg1LxbWtkW7KDsHJifoGQ49uZsGfjZWRHUj4.UDuORRVM77Z 26Z9f5TqmLQtZml5djP4hpd7xD0_81kvu5TEMDs6cdJxHj534dVD8A4qxNBHYRPBrI6oa2y3Gjpa vcSkCaV4BvGqY7SzzF.dc4COwAOGmfiUxEp1b3LriIERCXf3fAOpKwnpSaXhouaNbbCCn0F3x_CB 9je75VaD6F6Hdi7Sg1k70GTnZS0J3RkEVK5kEo5S.PhGKtOKroRMnBrLqPOMVs6GjwIweYgo6qB6 PC_PHTGZcaeraaUXEkd4c2OWO.2E1StnZOfNGOhviER84G2h2TZ0bWXK_04_z0Rtt5k0Hytkm1vw glKA4I6ryzhYo4gDHNrHfBJTnuZsR.ZzZ1gLh.RSzp1NcvqMQrWAJKSAix.lMTTIBiKhaN1PmkyB FuT97nErJtyZqyLHztCszev.3FPAKexc86JKrLbbKFzt3PlW4kkyajblSnjfYBNrZX5jICQgedJA RQERqyJZnhweEKQRmwbk1OSc27ty2oHxXPEDgPBMRkYJ9se5sfdwwqiK4bX7o6qDOTKLihd1TA3y G5gg.auu7vY5Y4HQYp94Em.524V9_FyluVSI0eNpLQW9G7PDJ5rLZIwdU73kK7o0M0x5HOAv9mTD RAfjZQ8U.uBj8raefr0gvVQkGn6GMucAsYVMLKw.GlEsJg74.65654r1wbO9n._tdWaRtqC0OuSZ V5OsB65hcJuOjLemT621bkrCQi8TxZJrfEbouynBifB8ylsr5grtbUrehfD6YUthNeBIGK6T_.JV Z3pQcxCR4nD3fKZdV7fmtR0maTWEkBedQkgDCmno8zSYZ5ydDfYmt4nHYbR19Lg5I3U3E06oUGN4 Bh48_sE7mkoel8j5Juj.zMbgehS3cntAsVRz0blS_TvqxdItKc3tiQwtx7TXs1uuPqhGAbyazjek zZ7UdOlfFZMZ.6hfd_cZwbn0ee1.8RUYktsCfR1AxWW4WBP4WsmZU8bBM7BqKabRYnMev3I0.pQc NSy2_XbCB1SMZ2r_F8A50dHBdyhCRDKMrVccC9Qt2DF6lV9Ouwlj0_BD0g6TCiIR2KRR2V_l2gd6 Xl.bgBfPqkZzuU5Aye_e_ElXbPKaxpw23.HBgaU3OxCq8LzVW1SRBdHPFuvvMsP0uWTQD3nmbD9P zJggyMDLdCX5.c4XHFF0wrqi5dFQIZaD5Qf9sJ8Ij3l12HX5l.JUtM1JuuR3lvcIKTraYiY3VWOP Sg4xBZekQmLrWkj_B4opPYgOeymlGpoopWpt4m0F4sDuW_MMzT6dp1Oy6SonL2oZ4JiJ6AclMOmY NffrponSyyWPA8clsYJ4jWU6rxA7bVq77HbSjctTtAPbajc._hVZyXArpRFppVAlGmwuG3Zc45fn PnMrA3U0DV4gfi6D_zSaTYYYlTMb8Lg140Jfc.x6G4yeMPczF3nDq6AcjM04Uub.N7ZDuOM2sjfo arFszeQQLnF29SPkcFXpVe8hRazVjLqHaHbtmOQiuAD381XIFrXMriESo90MRxyM_Cq3yKyW7NVN ly8QPiU8omQkA_kgoofbQnb2AEheE465_.ZC7pBDjCvuLnhN6JPPV6_lk_8.Hv.WFXRTusicJ9Ok w22pjc36Bm22CwE6QEjVeRitqx26JdxH0GKtbDRVo5Dm3eH26YnE69W5.h.f2IRn6bT.GkU.G4o9 P.ZSKQe9iZS5jleN5uP2AqTZSvWdyefAIKOcliPVW6LuWyBfIZ0q2mkD8k5uVctJ13qSdSnO2Nmr bOgbEVNnzmRAp2oGX3piq9VO4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Oct 2020 16:02:58 +0000 Received: by smtp409.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b598cd964b5e6965b85158ad154842e7; Wed, 28 Oct 2020 16:02:57 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Wed, 28 Oct 2020 12:02:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------21A5E498D42D4ED7CE1288AE" Content-Language: en-US X-Mailer: WebService/1.1.16868 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:03:02 -0000 This is a multi-part message in MIME format. --------------21A5E498D42D4ED7CE1288AE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tim, I looked at the revised bullet points we agreed upon and crafted a new Section 6.4 to reflect the last point. (The first three were already covered in this or other sub-sections of Section 6.) The proposed, revised text is below. If you concur, I'll ask that 6486-bis be revised accordingly. 6.4.Acquiring Files Referenced by a Manifest The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point.If there are files listed in the manifest that cannot be retrieved from the publication point, or if they fail the validity tests specified in [RFC6488], the fetch has failed and the RP MUST proceed to Section 6.7; otherwise, proceed to Section 6.5. Note that the set of retrieved objects may include types that    the PR is not prepared to process, e.g., objects other than CRLs, certificates,    and Ghostbuster records (all of which MUST be processed by an RP, if present).    When such objects are encountered by an RP, the RP MUST NOT attempt to validate    the eContent (as described in Section 2.1.3.2 above) of such objects;    encountering such objects does not, per se, result in a failed fetch. --------------21A5E498D42D4ED7CE1288AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tim,

I looked at the revised bullet points we agreed upon and crafted a new Section 6.4 to reflect the last point. (The first three were already covered in this or other sub-sections of Section 6.) The proposed, revised text is below. If you concur, I'll ask that 6486-bis be revised accordingly.


6.4.  Acquiring Files Referenced by a Manifest

   The RP MUST acquire all of the files enumerated in the manifest
   (fileList) from the publication point. If there are files listed in the
   manifest that cannot be retrieved from the publication point, or if
   they fail the validity tests specified in [RFC6488], the fetch has
   failed and the RP MUST proceed to Section 6.7; otherwise, proceed to
   Section 6.5. Note that the set of retrieved objects may include types that

   the PR is not prepared to process, e.g., objects other than CRLs, certificates,

   and Ghostbuster records (all of which MUST be processed by an RP, if present).

   When such objects are encountered by an RP, the RP MUST NOT attempt to validate

   the eContent (as described in Section 2.1.3.2 above) of such objects;

   encountering such objects does not, per se, result in a failed fetch.

--------------21A5E498D42D4ED7CE1288AE-- From nobody Wed Oct 28 09:16:12 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB43A07D3 for ; Wed, 28 Oct 2020 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xZtyGmeOf9OE for ; Wed, 28 Oct 2020 09:16:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB783A07DB for ; Wed, 28 Oct 2020 09:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 340C5300B5C for ; Wed, 28 Oct 2020 12:16:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oyN4ExYk-hiH for ; Wed, 28 Oct 2020 12:16:03 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 12E81300A48; Wed, 28 Oct 2020 12:16:03 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FCF7983B-9A49-44BF-9C71-3CBD820BDC45" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 28 Oct 2020 12:16:04 -0400 In-Reply-To: Cc: Tim Bruijnzeels , sidrops@ietf.org To: Stephen Kent References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:16:11 -0000 --Apple-Mail=_FCF7983B-9A49-44BF-9C71-3CBD820BDC45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In one place "PR" should be "RP" Russ > On Oct 28, 2020, at 12:02 PM, Stephen Kent = wrote: >=20 > Tim, >=20 > I looked at the revised bullet points we agreed upon and crafted a new = Section 6.4 to reflect the last point. (The first three were already = covered in this or other sub-sections of Section 6.) The proposed, = revised text is below. If you concur, I'll ask that 6486-bis be revised = accordingly. >=20 >=20 >=20 >=20 > 6.4. Acquiring Files Referenced by a Manifest >=20 > The RP MUST acquire all of the files enumerated in the manifest > (fileList) from the publication point. If there are files listed in = the > manifest that cannot be retrieved from the publication point, or if > they fail the validity tests specified in [RFC6488], the fetch has > failed and the RP MUST proceed to Section 6.7; otherwise, proceed = to > Section 6.5. Note that the set of retrieved objects may include = types that > the PR is not prepared to process, e.g., objects other than CRLs, = certificates,=20 > and Ghostbuster records (all of which MUST be processed by an RP, = if present).=20 > When such objects are encountered by an RP, the RP MUST NOT attempt = to validate=20 > the eContent (as described in Section 2.1.3.2 above) of such = objects;=20 > encountering such objects does not, per se, result in a failed = fetch. > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_FCF7983B-9A49-44BF-9C71-3CBD820BDC45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = one place "PR" should be "RP"

Russ

On Oct 28, 2020, at 12:02 PM, = Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:

Tim,

I looked at the revised bullet points we = agreed upon and crafted a new Section 6.4 to reflect the last point. = (The first three were already covered in this or other sub-sections of = Section 6.) The proposed, revised text is below. If you concur, I'll ask = that 6486-bis be revised accordingly.



6.4.  Acquiring Files = Referenced by a Manifest

   The RP MUST acquire = all of the files enumerated in the manifest
   (fileList) from the = publication point. If there are files listed = in the
   manifest that cannot = be retrieved from the publication point, or if
   they fail the = validity tests specified in [RFC6488], the fetch has
   failed and the RP = MUST proceed to Section 6.7; otherwise, proceed to
   Section 6.5. Note = that the set of retrieved objects may include types = that
   the PR = is not prepared to process, e.g., objects other than CRLs, = certificates, 
   and = Ghostbuster records (all of which MUST be processed by an RP, if = present). 
   When = such objects are encountered by an RP, the RP MUST NOT attempt to = validate 
   the = eContent (as described in Section 2.1.3.2 above) of such objects; 
   = encountering such objects does not, per se, result in a failed fetch.

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


= --Apple-Mail=_FCF7983B-9A49-44BF-9C71-3CBD820BDC45-- From nobody Wed Oct 28 10:10:31 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284853A03F2 for ; Wed, 28 Oct 2020 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 narzEob7NUct for ; Wed, 28 Oct 2020 10:10:29 -0700 (PDT) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 4CDF53A0140 for ; Wed, 28 Oct 2020 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603905028; bh=1YEy11c107KB0qHx536hbbaOWmxH+kW4jEoB94H+sCY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=TzSRXlRZi8q/6Eskxq0LKbgzjX1Gie+PsKUgq9jj/dMCkUqBRxzVQeEHf1RpDNl2L8g+7B45rgypkKnIKxU6QBQ0xy8qbmXTAl4f/AmWBNn7Ogu01mRV30EQLcGqpfeKtXSFdFH4seMq/VRsdCjQ1TRzWiUtPDLDjPJsHNslyXOevv9PkTj3Kvx8+FDA2xOW0FIRie5eLF2t2gfEeCS9+wmCWSkqdQfNOplJyjgehJ6K+iKu9O0f2vJyQXmKw0vpMZgZojEza+kEt/ScxCeGf9J6rhoRV4WRjO0giQ6ZkeZZZk68PBE0+QKklGAELOyOLugFSRCNnO9OLwKp3cDeJA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603905028; bh=HJgFhJkcf2UgdCHrRyLC/r8o6SYUdFjh50FCFgAu/9K=; h=Subject:To:From:Date; b=LjHp9yNBCSj75UNpYpAlPXafN30Pn3xXxJ+Wi1PRHdnyC1xkNaeYiks3bFMzHXicidXX7tj+tS9lT1WdOJzARhQ6ctlXvoEyzM1sDCvtrTbASLtZat2b8axXXXgfqvy9WLWV9Uxn+m1zjNdpGPaYy7tMTofMN0AsCBlcvMsFFLBpB23IoW1rE/16FtlIV6IoG5SczA/6DeiusIXSKgzO7KT6HUEmztzJwRrVOOOFbJWypl9dD/IXfigZ334MU7sOvxowkBdwfvdkbK1DUQeXZ/CY86u2u1WJeKu4ewecndT60b/9+eim1Yd1zOd2p2nkCrRwq3OGkdaqU1xL+U38xg== X-YMail-OSG: 4S4pzVUVM1ksR4TAUNbiSr7534g9Op4I3e2PeRwBv_LrMuXXVlf_8szxLAA4.Ve wAacFEwl_pRkQH_zPUzumPBWE.2_j3nspNcgum6o7Ulk6zJIxN6mCHnaP3FVUFMiQHKDog_ReVDz NpeordFTd9NQxNfrEDe6frmUMqYlWNJlCpz4uTIKZDZU5HQtvtBgl9e1P9ad64Tn5VCjytaenoYO VRKsJNU7PPuQeg2qFjD2zbISQ.2yDwGyeoCQ__32FYGDR00KxGqlPQcXD3i2zzwcwwENMmhYcy6B Jrf01Q24rrRPsKQfWbvxztCLimHjT847huhiSBveCR7eWw55f7e834._MW0F41t5TeLzO_SESi9C cXWuLNX.31x351yopEbIJdSjfYvNwlhMkSjOl.FVNVB2_0_gv18Qtmpa6IrhaliSI.aiSpetu.eG sjoVxWeYVMttkkWKLBpfvL2EpOubDhXZGR5eI9Tsf5uBIUzYZGEg0Xh1FTt348hCiIjJ38E4E1lo WA9wyGEuHyrCD0xTy9zCFXzFylwr38QSDg9pqu5R54.42KcKYNW53gBwT277T_C80JYyEh4W3d3e Rrb1xlvw8fL8PJVD0UOJTcrSw.GnZU1kT0yrpWfcMDp0Kd7ZBDWX8M1b_ZofM2WyTcxLXe3b4dwr ftyy7r97DH.ouw4EuRd5CDAkMpKc7oZLEZEGQiXNPFyLc1AiCCE4bfjMbLXPQJE.V7NSiAhlKhpx k6MZHWrLp5Ju29Ogs1Hf5GPMVdOCavD2WikxMmbyUAS5x.q0ZMQiC40jW3jgC7Kr2O20DSWQZTgg LeVRxrK4T3xjTR.xW..x6TLHFQF2z.H_sqzjQ3ZUZ1GtIoArH1zRhJtcroO29X95v1eITNcxhbKC ZPCk51hMgUgR6cZ9uGONM3Poy.CD5jUmby257X8tb9NY2g3_7j6heZohbo26v7NeN6teg22DGvic wCqZ0XBiwo7ysws7qWcrj__JNXqxGcN7lY.DRHxXBpbKx9mABgtpiYrZxT0fJck.v1UiJY23sTRK uL0NRuMm6Taemd6SiL5qKpOuYUDgZyuqyRiLcFc1mEpVQbBpxz.0i6IQEuoFTF_zgsUnl8CN.Etd RduToBnH3hui3EchF9xCPrtv1p_d3Fx5tw0i3_Q95VQbZ1uYffI0GjyvGTBNOuH0SCFRHKWVneV_ F46tzzklXzWux3aGTNs6w68Z_U35DncCO7m3qxDVREgSfhA40Yf2a39KMLA6zf3ehMkX1Hlcl0GE ugYqPxdiE06_B05ttFe_L6D8eMJgWgUU..J84yRZvuzt2TCp0HU3UUoV6G7QnRc8Siuwb.4hKCX0 yC7jr33WcXoEqU._BRcxttQsRMWFi5k0N0Q9FwFTnURFRvZhTmLE5poEkHYpCoKG5FHhUfRb_XCw 30u1H3Zqa3Z.zecbzOkL2DrzUJrmhMRHTnSn8nru23HDl4nWT2kV9cDPUHnGaBGU2Uaw.MAPblqW k7NRH0YnmcW.Tw7_nGroXLzLSBZlcPK4db0dItEwS65debnPiBEAxrM.lUqm0kWwaQZAyeh8tkHU hM4cB5l2w04KrFec2m9HIdMoqchl7icNRK723VIBlZw9gN0yZ4K8j5neEoPcBKgXFYfUUWZ5m0z0 ua9dbyIibO_SXXHjK0WsHyr5.tCdFtQFQSt4kEiEQrntsIN8QEhlmvx47ja3J8Lqq0rxPdLKRXrt KGoBRy3_I07Ndeuc.2kBy70wIoTJFtLupS0fw8R9O5R2VK8qtFUyyjvvjT6iIqMbipseZj2bsuAY veUnuJceoee4crKEbt.BE2rtA4sFromYmnNovZRKkjGWPgGycFDjLFABz.pykzeei9v25cPHSn7X 9a6GrrTBrVxlukaMT0CB6Y9e8UPyPxcVC2.c5fiCkUOrJo9vlni_dAAUJ3JmKBvOs1G6tmGBsZdC loj_E6H2GXyBo5VJ.hKesCJkd0JSHh1JQQ3gFtneaM5Z7u_EYGEkOiXTwOU27Mf140Bkrcb7c7Yt .UrHm7.DbpztXVFNgQEzwHnZZ_3iH6eKSFqPRBnwEejPa0rMkL7dhSBAYo0zGRNN1Vlv3UYbFboS T.3VzQkmoG5T1mH98CGmfrVKw0OWpmoipCevrSRtI18xfIf6zgtFK50610inBOIS43ogx9bq1mdA UrvtFsNHo3uPPK0Lrc6YTCxNY6kGYk8tBNsuKAU4w34gCSkJoI5aPwz_7Vy00NhQSXephZgEfBbe .W0qtxj3jFNfXS6ULwjwU2rIokeeJm0iDm2zEZD.zYdQW1tXehrUhx2eo52A65IzT_vrhbpCx6O8 MsfSiAakEfBfa2jMqJPngDKetdcrdpGAeTnGjgMeNNRmFoGvwp9GqvlngA8eWObuKiIkk_bXuP4z gWEns5960qjzI.WbW.QOrS4Ktgb16ySNuVfMPg4Yf8xejbNm69rmSSl8tc3wy3TX2o8_FHlxHg_E 2KwdGa56wcbd5dRZmeS3DFicdy7_ZY2p.atiyeI6u1ockLualCqdPIhm5uSzVA7YV0hfP6jMHBRd iQEFLUufgOb90x83ZfqMAwSMrJLrxiDvp.D7Qw7ionohAPpmW.puj7la6KqUS9qFVf_mugRgnYnh ZKhZnrztdR0wZ7Lk..yJo.5F5PhwVF_PdsMNBpX0dYxHHVLWKSlXHdBobwNXI6C7uTUAO5Vl2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Oct 2020 17:10:28 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f5a952c45cbd86f3afc49e764ec4dcfa; Wed, 28 Oct 2020 17:10:27 +0000 (UTC) To: sidrops@ietf.org References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> From: Stephen Kent Message-ID: <9dc3ee70-7138-dfe6-f810-02f19fd77a69@verizon.net> Date: Wed, 28 Oct 2020 13:10:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16868 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 17:10:30 -0000 Russ, > In one place "PR" should be "RP" > > Russ thanks, fixed. Steve From nobody Thu Oct 29 05:56:36 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB713A03FC for ; Thu, 29 Oct 2020 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 xpT696B5TitZ for ; Thu, 29 Oct 2020 05:56:32 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CEF3A0A16 for ; Thu, 29 Oct 2020 05:56:31 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 1003460B19; Thu, 29 Oct 2020 12:56:28 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1603976187; bh=ZJGjXkOxb2Kt1yLoXqlI0939Za2Rwpq8k8P+AHmOt44=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gsjs3JRJjKjcCmspSwMoZnp7NBg4fp1a7GCDWtfAEs0wtwv68MVU25jYfVi/JhUs7 qCSiILSDGusW/qcuFefuyI5aEEHFfX4fcwUag9viiEZXQUg87PAAgIEk/2gkVsSGTK W5Me530DskVdq/4uN6OusvOc8DMKCXkPSwnV4kjXEFyL/GVztwpZOAIX5Fik+geuZp sg25h5rJgWulyc9usXf2FzOVqxZVqDwlKhHLmZiIheOB/YV7jDDfqfPmmQ83NDebzC L4hxNndp4HO/VJ+uDvfvtuJJURxbv8utuJQubCO1m+JOiqlv1ObV2O/d535LapNYYL 5+Q2peW4evGjA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 29 Oct 2020 13:56:25 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <72E7C44B-7478-402B-A0F3-2376A2818657@nlnetlabs.nl> References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 12:56:34 -0000 Hi Steve, > On 28 Oct 2020, at 17:02, Stephen Kent = wrote: >=20 > Tim, >=20 > I looked at the revised bullet points we agreed upon and crafted a new = Section 6.4 to reflect the last point. (The first three were already = covered in this or other sub-sections of Section 6.) The proposed, = revised text is below. If you concur, I'll ask that 6486-bis be revised = accordingly. >=20 >=20 >=20 >=20 > 6.4. Acquiring Files Referenced by a Manifest Right, indeed it's section 6.4 that needs the update. I was a bit = confused by the repeated text in 6.7 (Failed Fetches). Maybe this first = sentence could be dropped? If an RP does not acquire a current valid manifest, or does not acquire current valid instances of all of the objects enumerated in a current valid manifest as a result of a fetch, then processing of the signed objects associated with the CA instance has failed for this fetch cycle. To me this reads like these checks are done as part of 6.7, whereas = actually these checks to determine that a fetch failed were all done in = earlier sections and that is why implementers were directed to proceed = to 6.7, right? > The RP MUST acquire all of the files enumerated in the manifest > (fileList) from the publication point. If there are files listed in = the > manifest that cannot be retrieved from the publication point, or if > they fail the validity tests specified in [RFC6488], the fetch has > failed and the RP MUST proceed to Section 6.7; otherwise, proceed = to > Section 6.5. Note that the set of retrieved objects may include = types that > the PR is not prepared to process, e.g., objects other than CRLs, = certificates,=20 > and Ghostbuster records (all of which MUST be processed by an RP, = if present).=20 > When such objects are encountered by an RP, the RP MUST NOT attempt = to validate=20 > the eContent (as described in Section 2.1.3.2 above) of such = objects;=20 > encountering such objects does not, per se, result in a failed = fetch. I see you use "e.g." when enumerating types which MUST be processed. But = I think it would be better to either enumerate all object types = explicitly, or have no enumeration and leave the choice which types MUST = be supported out of this context. If you go for explicit enumeration, then it will most likely need = updating by future RFCs. E.g. the ASPA RFC when it comes out could = update the list. How about something like this: Note that the following objects MUST all be fully validated if = present: * Manifests (this document) * CRLs [RFC6487] * Resource Certificates [RFC6487] * BGPsec Router Certificates [RFC8209] * Ghostbuster Records [RFC6493] * Route Origin Authorizations [RFC6482] However, the publication point MAY include other object types that the RP is not prepared to process. When such objects are = encountered by an RP, the RP MUST NOT attempt to validate the eContent (as = described in Section 2.1.3.2 above) of such objects; encountering such objects does not, per se, result in a failed fetch. =20 As a note to implementers: there is little (inter-)operational = experience in producing and validating BGPsec Router Certificates and = Ghostbuster Records. I am okay with including them in a list, but I = would advise that CAs test with known RP software and collaborate, = before deploying these objects in production environments. Tim > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Thu Oct 29 08:37:40 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C993A0A62 for ; Thu, 29 Oct 2020 08:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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=verizon.net 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 QIPKgCD4GWkM for ; Thu, 29 Oct 2020 08:37:37 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 A83DD3A0A5E for ; Thu, 29 Oct 2020 08:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603985856; bh=8RwtLGnJ9CQi6LHzg2NIYrDy5q662y8c/XvfDEVrWCc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hwHCFKwggfo4Kin1w6P4BwaLDxO3U51l4RQJOxkSA6rFDbo63xrVawQixmZy4oII+gA2GDWHZeDqkoBg63mrZw2gyGTiLKGM3yMZIH60faPFBYcff904czQvTwccfLJauWzjLEyPtpxqOxPR60+huReBb6/jIxivbd5Ol/eYFyprCTltOwXJ33yqzja2XZDzRJ4g+rACqZSZN2nUaASt1zJn+w3wBKkX4sc16062oBav9YPhXR1KntnxjiA2c/9BFvkSw2xYPD9C7dGKAGeWYcG28BldoCaOWSS1/lNl5zvEas3dnNzLyUxQ5fjLeX/cg1LJIgcYfr17bkYHlYYdwA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603985856; bh=NPvlHGbErcMxN+qGc1BZB3XE1a+IeYa9J/OxY551k25=; h=Subject:To:From:Date; b=JtdQJihcJ8HtHps9HsFo+SYM7t7WgEZpjBiwDL3PZIYQKMxBNqCwnfDMhTgKZmkobKR+lz5Si/BDTLzoRDCtjrXubmBUp0B7IdpKIPs2ZMqcEYdm5WVpD7eVou2X6/qjcOPFPku2+WzYG3ABGaoB5KjKzW88Yn/jXVMdnc8N+cr9JD9vNnKKB9JGB02jOf64LxFfn7Xp/kuRzva4fluFxFzhcffVBsG38xz8mFsZ38JheB5KCY48RMfeYoxM4zJ8co152a9rS6nUBFYTlxgHi9GYnkhpkrXUrzyK/HV1837fKi/vuOx62dmtMB+oMo7ivHS+iDXjv+lhkdP8dBxTTQ== X-YMail-OSG: xB_gpT0VM1mA_7C1OOwetC06B3iSoqFY0qTg0rf.Jt.eOklGnEz4nrAzXHuwlEz .dSYhPdweX4yoo4QVPCGhyuIoi5bxpR_zSxNXpQro4oDo5s6YrV_v4Nci0V1qjtd4l93.XEZmTmn Xj1LhDde5YGs7OhkYP7xezuKfazy4phmWKltn4gVsvsgMQtv5ktmp_ZT.QFP3J7DEpGo8XXyXYYg jdB5VU1xwQV8d6gQNPjwgEdzqWNDbPVCtZ1fvJvEc_F1a16Q1yXpxoZ5WNU56TpB.qk53WbT.Oe2 Dqrk3P6ZfO4EATyFCPd00OfaqpEyvlu5jHRJAmwrWESla_kchNWPPX_Hg4nokwF1zlBlgZzTrzm1 GUOpBNEd6Zoeem5wwHw5o_g7CAcwph6Est8tHBovhGy87gR4lM.cXfuHFaA5TEQTSIJbfpu9wlMN nNaBBFEMATra2nM5PauIpVn1i.xFjWJ_nGVaJfI.TVAoHXVCrRi8n7RlGn5qj3LgvJFEGCLh1ndC ECrAPmjsk0QVqt2dAb.91eipIz68uzpEkxfSFEtMkqw3MpjbhY5DPruFyFX4NyI6gdKUMEo8r_fy FuPH1D_JIaJBJPtz9t8nzQjMsiUQXlYqp0vdkGqS5_8lDyDGnWt2rKTXZlU4z9FVWyp70ByLkWP2 IrmDa.W0drscFw23tu7unj.B51_Gl3Qrk4czBrZYNKA79STxTUGewEorS_oX_9n4e6a2WbX51eAI vL467AOU7AgGdh6N8oH2gogZK.Xj4eJ62Plsuj22Gz3feckJlIogcCXrCi0RnvtXTi9.fmcOs6TO d2_KdHmmY6FqQZdYhNfFnY4V4ZEgkGxq8bVz0X256h1MxgXb4jmbr4A7gyuyB1F7VfesjVuUshtj MqQHK3m7ybiqc50EEjNhJB2JSJSURmQOuaMXwH9keg3DWA_HebI3.cmFFNM9F9kVH3b2IMPXzRdL z2jR4TMbNLuM.owNhCSaS_ejntx98zGUCOxn1EItBmoOH9m4uTiqOIg6ba3wHZFPdRiaxZRYGmUb iye2futov0K_ME71P7kZI6Laa7mWaVPfFzvcA7h87xZppO8XQZDgT0z1sFfDJAp5RFwnpUCwSZWh hH2RxWA2yNxRmHAUsjME5gyNHzpNzDV9.8c0ijcbvVBPGB42bYR_.X0nY97hdeNaP2zWFNSp.UtI FQkgHIZPz58TN3Pf7Zvgvyxn7XmOM3AV9YfWZgkNWhSUwgJYkkwo_zl52XRyRJR8uj40SUIRC3Ns .hl2_7SheDU4th5FGzgSr2kup1mV.CuxRM.pX3GQ.ir6I0DNrnSxqOLYNWA4DxpCyRd1Aywsatwm fgeHXaPrwgJm1UzWVQsrOF08eh.mW0uzRYrayvawKXW7clkMCX4ITQXV0r6tJQAZ3Nn.1_rRFnxJ _XgUQQVku732ayxdtbLoZYkKr9Z1FFCnQtWuinOSAAVRvHrXNByyuCjXExLWe7NcxtTKhq3ru09b nk8mIV9YG3Io7e1ozWKDoLF5zLca6_CbzkAheNq7C79lV0cl9uuzvAra7qDlBMlbJAmytgUKPZYL 8q30koe.eR2z3oiGK82_xNiaGtojj9XlCTNTithMcfsdvA6tl1jtSyP9UiYVRP4tPhIIKAwlGezX wAt1a.oU3NKL5Aa3qLzMoJqx74Z1hZunQPOEAbeD1J0LNT0ggL2w2puogRu_TM8k6CBY4iG_FmTY wwYJvc8ag4tBdKsaon1U019u9mF6eZ2hXGWSPzC6eVLwLqc09PYTWNGHRcrRGMLGQvL.RdN7AHGm nh2VlJKu2F0qLlC8PiixkJyIrtvNyOSd04YCbFpNtk0IR5yE0v7TKPqeYHPsxe1nJPLMh2.wFwWu 5ryPyZp.sB2vVThMe40f9HPuMiLUP7jMrqxRLzVjF9Td93PwwNNcvsk_7AbXtAbcMjcdqZVDODdL m69ccUYo7dC1ojP5QYbsP1._MvMab8vfi11fhQihc9gB0yUWuzXx7emzM46rphR8x7MYz7L5Jjwk 535I5NRJvwFYikVG3mQxDfyX2lNWCbJ6mMKV_RNjYMGHagzWa8lRQKz6cG1nLB6oFQRtvTlCmeGv rCuIYdZRLB.5gahLT5PjCDjkGohG6ctRBLieiECHPMh2GHj5mpLFwnpvzfvr3svGk9cjNKfwtXmg 6MlbTxLF6V8pmbKgl.NbjbtE7baLvNRO6GVJhBZyy.51sGa5X7XSH7NMtGqsALBYiD9Y5V.QudqE l3__fTOKAE3rIpbvzEACdtxq4n9NIuIlOjH7Mv14jvXlmwt45JtPwGPpe1as6wOt2kFKBHGn7qMJ p.Se8Lpedyk7NYoHEFGR39TW1XbkweOLintXglPTdwToaU2KyCaSGRQYJMnJDhn9xEE5U1fWZTfR junHORYRwIA3Br2_j_j6ygrtxArMkTm9ZIAiQvT5OXzpmprDuVlylljWgTSsGAYuZns5CuPEBIz1 _aS9oZXjOYuI920K2JmlrMpQp Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Thu, 29 Oct 2020 15:37:36 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f813460ffa04013cceff134e3fae3cff; Thu, 29 Oct 2020 15:37:31 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> <72E7C44B-7478-402B-A0F3-2376A2818657@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Thu, 29 Oct 2020 11:37:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <72E7C44B-7478-402B-A0F3-2376A2818657@nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------56617377AEE6C8D430101935" Content-Language: en-US X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 15:37:39 -0000 This is a multi-part message in MIME format. --------------56617377AEE6C8D430101935 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tim, I revised the text of 6.4 and 6.7 to address the issues you cited. See below: 6.4.Acquiring Files Referenced by a Manifest The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point, or if they fail the validity tests specified in [RFC6488], the fetch has failed and the RP MUST proceed to Section 6.7; otherwise, proceed to Section 6.5. Note that all RPs MUST be able to process Manifests, CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates {RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The set of retrieved objects may include other RPKI object types that the    RPis not prepared to process. When such objects are encountered by an RP, the RP MUST NOT attempt to validate the eContent (as described in Section 2.1.3.2 above) of such objects; encountering such objects does not, per se, result in a failed fetch. 6.7.Failed Fetches If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST issue a warning indicating the reason(s)for termination of processing with regard to this CA instance.It is RECOMMENDED that a human operator be notified of this warning. Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch.This implies that the RP MUST not try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. --------------56617377AEE6C8D430101935 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tim,

I revised the text of 6.4 and 6.7 to address the issues you cited. See below:

6.4.  Acquiring Files Referenced by a Manifest

 

   The RP MUST acquire all of the files enumerated in the manifest

   (fileList) from the publication point. If there are files listed in

   the manifest that cannot be retrieved from the publication point, or

   if they fail the validity tests specified in [RFC6488], the fetch has

   failed and the RP MUST proceed to Section 6.7; otherwise, proceed to

   Section 6.5. Note that all RPs MUST be able to process Manifests,

   CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates

   {RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The

   set of retrieved objects may include other RPKI object types that the

   RP is not prepared to process. When such objects are encountered by an

   RP, the RP MUST NOT attempt to validate the eContent (as described in

   Section 2.1.3.2 above) of such objects; encountering such objects does

   not, per se, result in a failed fetch.



6.7.  Failed Fetches

 

   If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST

   issue a warning indicating the reason(s)for termination of processing

   with regard to this CA instance.  It is RECOMMENDED that a human

   operator be notified of this warning.

 

   Termination of processing means that the RP SHOULD continue to use

   cached versions of the objects associated with this CA instance,

   until such time as they become stale or they can be replaced by

   objects from a successful fetch.  This implies that the RP MUST not

   try to acquire and validate subordinate signed objects, e.g.,

   subordinate CA certificates, until the next interval when the RP is

   scheduled to fetch and process data for this CA instance.

--------------56617377AEE6C8D430101935-- From nobody Fri Oct 30 05:52:56 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78E23A0E6F for ; Fri, 30 Oct 2020 05:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 saLQzcGUG5QK for ; Fri, 30 Oct 2020 05:52:53 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78C93A0E6D for ; Fri, 30 Oct 2020 05:52:52 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 404F2607C6; Fri, 30 Oct 2020 12:52:50 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1604062369; bh=/esGLPUQ1V3uBv/rLGDqjDleNHFfuAtizZ2FPG5n/Dk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=X756cceE5bayCZQQpjR6znycnQKclVwwrrTGcb2mHtiSnj40i55i2puuEey4Z4okP FThwfVUS6iRY2piau5u73JwD4xzmDckk/SXkB2vuY2TDWLcuKn8teZ9b4gEQWLufsG GOB/AZb4ICDMnj6eIbyXLVkIjit7nd9GQ1ztXs/2J9wf9GD3Lejds9g0Sp6dl5B6ys xZUwCYVbAU8Cy2Z/2hPWckxVqW/vxE+ZAddr95izefXzupbFIwWPJcLN4P2otArGz9 pAjh0lNMzWAPKWJoPP4ajEOmM7tsO2k4fgJfpcBkqvM+H3WcIzs2MXjVl+SvYEQ4nF wV9rPE10L38Nw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 30 Oct 2020 13:52:48 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <92BBA00D-0BE1-4161-AB93-0E82EFF2E999@nlnetlabs.nl> References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> <72E7C44B-7478-402B-A0F3-2376A2818657@nlnetlabs.nl> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] Interim Meeting Follow-up Mail X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 12:52:55 -0000 Hi Steve, Thank you. That text works for me. Tim > On 29 Oct 2020, at 16:37, Stephen Kent = wrote: >=20 > Tim, >=20 > I revised the text of 6.4 and 6.7 to address the issues you cited. See = below: >=20 > 6.4. Acquiring Files Referenced by a Manifest > =20 > The RP MUST acquire all of the files enumerated in the manifest > (fileList) from the publication point. If there are files listed in > the manifest that cannot be retrieved from the publication point, = or > if they fail the validity tests specified in [RFC6488], the fetch = has > failed and the RP MUST proceed to Section 6.7; otherwise, proceed = to > Section 6.5. Note that all RPs MUST be able to process Manifests,=20= > CRLs and Resource Certificates [RFC6487], BGPsec Router = Certificates > {RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The > set of retrieved objects may include other RPKI object types that = the=20 > RP is not prepared to process. When such objects are encountered by = an > RP, the RP MUST NOT attempt to validate the eContent (as described = in > Section 2.1.3.2 above) of such objects; encountering such objects = does > not, per se, result in a failed fetch. >=20 >=20 > 6.7. Failed Fetches > =20 > If a fetch fails for any of the reasons cited in 6.2-6.6, the RP = MUST=20 > issue a warning indicating the reason(s)for termination of = processing > with regard to this CA instance. It is RECOMMENDED that a human=20 > operator be notified of this warning. > =20 > Termination of processing means that the RP SHOULD continue to use > cached versions of the objects associated with this CA instance, > until such time as they become stale or they can be replaced by > objects from a successful fetch. This implies that the RP MUST not > try to acquire and validate subordinate signed objects, e.g., > subordinate CA certificates, until the next interval when the RP is > scheduled to fetch and process data for this CA instance. > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 30 09:38:33 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36CB3A03EC for ; Fri, 30 Oct 2020 09:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fS4WmP9Q772P for ; Fri, 30 Oct 2020 09:38:30 -0700 (PDT) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [128.241.192.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCF63A08B1 for ; Fri, 30 Oct 2020 09:38:29 -0700 (PDT) Received: from bench.sobornost.net (162-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.162]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id CB25CEE0123; Fri, 30 Oct 2020 16:38:28 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id a94f60c0; Fri, 30 Oct 2020 16:38:27 +0000 (UTC) Date: Fri, 30 Oct 2020 16:38:27 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20201030163827.GE34637@bench.sobornost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] notes on rsync --delete (rrdp withdraw), and garbage collection X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:38:32 -0000 Hello SIDROPS, I noticed that most validator implementations accept what are essentially unauthenticated instructions via an untrusted network input channel on what files to delete in the local cache. The below suggestions are *on top of* this year's manifest handling improvements, so in most implementations I think the below suggestions will leverage existing code. In order words: any coding efforts hopefully are modest. A quick survey on how common implementations are doing things: Routinator: 'rsync -rltz --delete $source $dest' [1] ^^^^^^^^ OctoRPKI: 'rsync -var $source $dest' [2], and then takes rsync's verbose output for a file listing of what exists on the server side, then proceeds to delete what is not on that list. (basically the same as running 'rsync --delete') RIPE NCC Validator: 'rsync -u -rt --delete $source $dest' ^^^^^^^^ FORT: 'rsync -r --delete -t $source $dest' [4] ^^^^^^^^ rpki-client: 'rsync -rt $source $dest' [5] <-- THE ODD ONE OUT! I imagine implementers came to rely on '--delete' as a quick and easy way to do garbage collection. This is operating under the assumption that if a server says a file is not present, it probably is safe to delete from local disk as well! However one has to realize that such 'delete' instructions are entirely unauthenticated: there is no cryptographic proof a file actually was deleted from the publication point. This conceptual issue is present in BOTH rsync and RRDP. In the RRDP protocol the 'withdraw' elements are not authenticated against anything in the X.509 RPKI data. In RRDP the 'withdraw' elements are channeled through a TLS transport (which is deemed secure), but the validator can't know if the TLS endpoint is the same entity as the issueing CA. Unauthenticated instructions are - even when transported through a secure channel - still unauthenticated. Rpki-client does the garbage collection is to make a list of all files that appear on valid current manifests and match the associated sha256 hash. Any files which do *not* appear on valid current manifests are then deleted from the local cache on disk. This is a strategy I would advise others to consider as well. 'Deletion after validation' leads to the curious situation that the *coldest* files (aka files that are not referenced anywhere) become the most transferred files. It is incumbent upon the CA operator to not leave unreferenced files laying around to avoid frequent transfers. I believe a filename's absence from any valid current manifest is superior information about whether to delete a file compared to trusting a rsync server's file listing or 'withdraw' elements in RRDP. Deleting what's not present on any manifest makes the garbage collection dependent on a cryptographically verifiable chain all the way up to the Trust Anchor, whereas executing 'rsync --delete' (or similar) is akin to taking orders which are *not* backed by the RPKI data itself. draft-ymbk-sidrops-6486bis-00 section 8 states: """However, a manifest enables an RP to determine if a locally maintained copy of a repository is a complete and up-to-date copy, even when the repository retrieval operation is conducted over an insecure channel.""" The insecure channel should be as narrow as possible. The fewer facilities exist through the channel, the better! The locally maintained copy can only exist if the validator software does *not* perform garbage collection based on unauthenticated instructions from the insecure channel (aka 'rsync --delete'). My recommendation: implement the RP without rsync's '--delete' option, and ignore withdraws in RRDP. Ignoring 'withdraws' in RRDP will need to be backed by updates to the RRDP RFC, but that can happen later. OpenBSD is not implementing the 'withdraw' element in its RRDP implementation. If garbage collection is done *after* validating the tree, the removal of files is anchored in the cryptographically signed reality, which I think is safer. Note: this is not a firedrill like 8 months ago related to incomplete manifest handling, this is merely a small suggestion to optimise a bit. Consider this an attempt to translate the Internet-Draft's prose about maintaining a local cache into simpler English with concrete suggestions for coding. Keep in mind: falling back to locally cached files is an *optional* feature. If an implementation doesn't fall back it is akin to booting with an empty file cache, which is a valid behavior and common case too! The draft wording is """Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance""", I believe a SHOULD indeed is appropriate here. Is this real? I think so. There already are several large production networks where the validators run without '--delete', instead manipulating the local file cache based on delisting via validated RPKI manifests. It appears to have no negative effects. :-) On the contrary! leveraging the local cache to supplement what was fetched via the network appears to increase robustness. Incomplete fetches can be 'repaired' in some situations. Object security truely is fascinating. Kind regards, Job [1]: https://github.com/NLnetLabs/routinator/blob/404e84f7f13fd12789f4f951e8d638799cd6ab28/src/rsync.rs#L423-L426 [2]: https://github.com/cloudflare/cfrpki/blob/051e8d99151e55a8efc5516fd2b26fae7f7a064b/sync/lib/rsync.go#L44 [3]: https://github.com/RIPE-NCC/rpki-validator-3/blob/6d53f8c6adc0f5340cfbeb76af848c1b1925e416/rpki-validator/src/main/java/net/ripe/rpki/validator3/util/RsyncFactory.java#L46 [4]: https://github.com/NICMx/FORT-validator/blob/940e79057dd27895a65917eb5febe9cc23c90fbd/src/config.c#L851-L859 [5]: Line 322 at http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/rpki-client/rsync.c?annotate=1.9