From nobody Wed Dec 9 05:24:23 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 F35FA3A1659 for ; Wed, 9 Dec 2020 05:24:21 -0800 (PST) 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 9QbOAX5bTcGy for ; Wed, 9 Dec 2020 05:24:18 -0800 (PST) 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 683433A1658 for ; Wed, 9 Dec 2020 05:24:18 -0800 (PST) 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 F3FC2600E6; Wed, 9 Dec 2020 13:24:15 +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=1607520255; bh=TVtZfcLAkI9nX2E5VxGRAtWQBsL2pXHIFVNV37TzLdc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=X8pbFUiNXIq7yk7+yVbsQyOb54U09SGVji1uEcCUr45sV9sB+xEkaXzMwNvZKEWc9 WzmGG23pGBTW5HZ1kkiezisogEe1KTg5ym/mybSKyzPwZR6hd6iLhDqCjXEchJw4Wn d/SP38e6V2+43JgDrwsDj0mMdGfVThHM/DLTNUWHdGSGr7ZSDRAvdGhEXKxkdF2nUv BrhSI7Y1e6VXbw8mIKmzqj8kTwEwoHX8o5wNrzMR/tPOUQgdwVzPOSeiLXi40jgWz8 dT5ljGUi6xhvlaUYdBtCLAAIbEE+gGtyAtzv4e3nKmz+ebyvztE47igWKWzHUGw109 k6axYPs065PGA== 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: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> Date: Wed, 9 Dec 2020 14:24:12 +0100 Cc: Job Snijders , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl> References: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> To: Joel Jaeggli Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 09 Dec 2020 13:24:22 -0000 Hi, > On 9 Dec 2020, at 05:06, Joel Jaeggli wrote: >=20 >=20 > On 12/8/20 06:27, Job Snijders wrote: >> Dear all, >>=20 >> I propose some following text detailing a requirement for multiple >> implementations to exist prior to RFC publication will be beneficial = to >> the working group. >>=20 >> Our neighbors at the IDR working group are known to have a similar >> requirement, which has dramatically improved the quality of that = working >> group's specifications and subsequently the deployability of IDR >> technologies. I hope the same can be achieved in SIDROPS. >>=20 > So, back when we proposed that the sidr work was mature enough to spin = up this working group to focus more on deploying it and less on what = should go into the base specification. we figured this would be an = involved and somewhat perilous transformation. >=20 > This deployment must be properly handled to avoid the division of > the Internet into separate networks. Sidrops is responsible for > encouraging deployment of theSIDR technologies while ensuring as = secure > of a global routing system, as possible, during the transition. >=20 > To my mind this includes addressing the question of how we = collectively use it and consensus on how the moving parts are expected = to work. If we don't have a consensus reality, then how am I to expect = that my network and yours will operate on the same information in = similar ways. Inter-domain routing really is one of those places where = the consensus reality had better be the market dominate one. >=20 >> IDR participants track implementation reports & interopability = testing >> through internet-drafts or their Wiki >>=20 >> = https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports >>=20 >>=20 >> Here are some examples of what reports can look like: >>=20 >> =20 >> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis >>=20 >> =20 >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementation= s >>=20 >> =20 >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20imple= mentations >>=20 >>=20 >> Proposed text to add to the SIDROPS charter: >>=20 >> """ >> Specifications produced by the SIDROPS working group are intended = to >> address a practical need where a standard specification can = assist >> both vendors and consumers of cryptographic PKIX products to be >> assured that a standards conformant implementation will undertake >> certain functions in a known manner, and that, as appropriate, >> implementations of the standard specification from different = vendors >> will indeed interoperate in intended ways. The SIDROPS working = group >> requires interopability reports from at least two different >> implementations of a proposed specification, prior to publication = as >> RFC. >> """ >>=20 > In the current charter sidrops does not intend to produce standards = track documents, with IETF and working group consensus being output as = BCPs when the weight of demonstrating consensus is required.=20 >=20 > That is a challenge in the case of for example >=20 > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ >=20 > And one that should probably be more explicitly included if we are = amending the charter. If we take on the protocol specification = maintenance here there absolutely we should require interoperable = implementation for standards advancement. >=20 > requirements text around interoperability testing is good, but it = needs be expanded a little to let us do the protocol maintenance, which = we generally would have ascribed to IDR under the original charter. >=20 > I hope the current AD will revist this. I believe that it would be good to extend the sidrops charter to allow = it to produce standard tracks documents *and* require two = implementations for that track. While in case of ASPA one could still argue that this could also be = discussed in IDR (or perhaps just be discussed there as well), I think = there is other work here that is not suitable for IDR. It may not be = routing related (see the RTA document for which adoption was requested), = or talk about the RPKI infrastructure itself (mft-bis / deprecate-rsync = / ..future work). Tim >=20 >=20 >=20 > joel >=20 >> Kind regards, >>=20 >> Job >>=20 >> _______________________________________________ >> Sidrops mailing list >>=20 >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >>=20 >>=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops