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

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