[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Simon Josefsson <[e-mail]>]

Peter Gutmann <[e-mail]> writes:

> Eliot Lear writes:
>
>>Perhaps one of the best kept secrets we have is the independent submissions
>>stream, which provides exactly this path.  See
>>https://www.rfc-editor.org/about/independent/.
>
> I think that definitely needs to be publicised more, or perhaps people
> encouraged to use it more rather than creating de facto standards.  The last
> part of my comment was a subtle dig at someone elsewhere in the thread who
> said that we can't allow publication of stuff like the OpenSSH extensions
> because it implies endorsement by the IETF.  The point I was trying to make
> was that they're called Request for Comments for a reason, so when it's
> clearly marked as "Informational" hopefully no-one will mistake that as an
> IETF-endorsed standard of any kind.
>
> One question about the independent-submissions track, pretty much everything
> you can do in the IETF is already the domain of some standards group or other,
> so if someone submitted an independent submission would it end up being
> blocked with the justification being that it's an attempt to bypass the
> standards group?  For example if GPG published their private extensions to
> OpenPGP (to avoid picking on OpenSSH for a change :-) would it end up being
> blocked because it's not being done via the OpenPGP WG?

That is my impression -- the independent submission track has not been a
relevant venue because it is possible to block publications by setting
up a WG, or bring up a topic in some existing WG, to fillibuster things.

The argument seems to be that independent submissions are inappropriate
while ongoing discussions occur in the IETF, and as we know "ongoing
discussions" are easy to prolong indefinitely if you so desire.
Alternatively, invoke the rough consensus argument.  I recall that we
explored independent submission for PEAP, EdDSA and some CURVES-related
documents, with different outcomes.

https://www.rfc-editor.org/rfc/rfc5742.html#section-3

Perhaps we should try with LibrePGP?  There is an I-D on it, so here we
can't blame the authors for not bringing this work to the IETF.

https://datatracker.ietf.org/doc/html/draft-koch-librepgp-02
https://librepgp.org/updates.html

/Simon