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

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)

On Thu, Dec 10, 2020 at 9:12 AM Joel Jaeggli <joelja@bogus.com> wrote:
>
>
> On 12/9/20 05:24, Tim Bruijnzeels wrote:
>
>
> <snip>
>
> ...
>
> >> 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).
>
> I tend to agree, charters are meant to be amended when taking on new work.
>
> >
> > Tim
> >
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops