Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 09 December 2020 13:24 UTC

Return-Path: <tim@nlnetlabs.nl>
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 <sidrops@ietfa.amsl.com>; 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 <sidrops@ietfa.amsl.com>; 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 <sidrops@ietf.org>; 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 <tim@nlnetlabs.nl>
In-Reply-To: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com>
Date: Wed, 9 Dec 2020 14:24:12 +0100
Cc: Job Snijders <job@ntt.net>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl>
References: <X8+NbXjEfH7Balvq@bench.sobornost.net> <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com>
To: Joel Jaeggli <joelja@bogus.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/gJTKUgqpWrZdb3FtONp5RJytVtY>
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 <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 13:24:22 -0000

Hi,

> On 9 Dec 2020, at 05:06, Joel Jaeggli <joelja@bogus.com> wrote:
> 
> 
> On 12/8/20 06:27, Job Snijders wrote:
>> Dear all,
>> 
>> I propose some following text detailing a requirement for multiple
>> implementations to exist prior to RFC publication will be beneficial to
>> the working group.
>> 
>> 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.
>> 
> 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.
> 
> 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.
> 
> 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.
> 
>> IDR participants track implementation reports & interopability testing
>> through internet-drafts or their Wiki
>> 
>> https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports
>> 
>> 
>> Here are some examples of what reports can look like:
>> 
>>     
>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis
>> 
>>     
>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations
>> 
>>     
>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
>> 
>> 
>> Proposed text to add to the SIDROPS charter:
>> 
>> """
>>     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.
>> """
>> 
> 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. 
> 
>  That is a challenge in the case of for example
> 
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
> 
> 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.
> 
> 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.
> 
> 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


> 
> 
> 
> joel
> 
>> Kind regards,
>> 
>> Job
>> 
>> _______________________________________________
>> 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