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

From: Job Snijders <[email-masked]>
Date: Tue, 8 Dec 2020 14:27:57 +0000

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.

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.
"""

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Dec 2020 14:49:02 +0000

>      implementations of a proposed specification, prior to publication as

given the difficulties that have been seen in the RPKI recently, all of 
which related to subtle spec interpretations, this does not seem to be a 
completely dumb idea.

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 8 Dec 2020 18:17:01 +0000

I support.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Nick Hilliard
Sent: Tuesday, December 8, 2020 6:49 AM
To: Job Snijders <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)

Nick

_______________________________________________
Sidrops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidrops

---

From: Lukas Tribus <[email-masked]>
Date: Tue, 8 Dec 2020 19:32:16 +0100

Hello,

>     implementations of a proposed specification, prior to publication as

I support this proposal.

Thanks,

Lukas

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 8 Dec 2020 20:06:47 -0800

> 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.

>     implementations of a proposed specification, prior to publication as

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.

joel

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 9 Dec 2020 14:24:12 +0100

Hi,

> On 9 Dec 2020, at 05:06, Joel Jaeggli <[email-masked]> wrote:
> 
> 
> 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.
> 
> 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.
> 
> 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. 
> 
> 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 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

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Dec 2020 15:11:45 -0800

On 12/9/20 05:24, Tim Bruijnzeels wrote:

<snip>

...

> 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…

I tend to agree, charters are meant to be amended when taking on new work.

---

From: George Michaelson <[email-masked]>
Date: Thu, 10 Dec 2020 09:22:38 +1000

I truly think RTA has a case to be here. It's aiming to provide B2B
pre-provisioning assurance, and other services to Operators who have
delegated Internet Number Resources. That is why I asked for adoption
here.

If there is a better fit in an OPS WG, I'm happy to take it there if
the AD or WG chairs prefer, but I think SIDROPS makes sense, not the
least because "here" is where it was previously discussed and
presented.

Given that we're heading to a registry for .3letter code assignments
for file types in Manifest and Repo, there is a meta-question lurking
here: What process do people want to adjudicate additional types into
the declared registry?

Personally, I think where they don't go to routing, It is low pain to
just admit an OID. If it has consequence in routing by intent, or
would alter validation models, VRP and ROV Then it demands more
discussion since it heads towards flag day consequences. If we made
that a conditional bar, then we could defer a process to IANA as "if
the submitter says its not routing, but is RPKI signed, then it should
be ok" and have an evil-bit model. (I know, but.. )

I also truly believe RTA doesn't do this (alter routing directly). We
did not expect it to alter validation outcomes for the issuing CA, we
intended the objects to lie outside of RPKI Repo space except for the
CA certificate chain issuing the RTA detached signature object. But,
it MAY appear in a repo., so it SHOULD be understood to have no
consequence for being unable to be parsed: it wasn't meant to alter
validation in routing like that.

cheers

-G

(sorry if this is deemed to be thread-hijacking)

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 10 Dec 2020 18:30:48 -0500

> implementations to exist prior to RFC publication will be beneficial to

I support.  I believe this change will help improve the quality of 
RFCs produced here by requiring thorough and detailed understanding by
implementers before the drafts become RFCs.

Thanks.

						Jay B.

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Dec 2020 21:45:43 +1000

>     implementations of a proposed specification, prior to publication as

I think this would be sensible. From a CA, producer-side point of
view, I think having confidence of interop demonstrated, and having
this in both producer and consumer (signer and validator)  would be
net beneficial.

cheers

-george