For all on the list who may not know all those "status upgrade" aspects, some
details:
The status of an IETF standards track document is NOT in the document itself.
The document itself just says "Standards Track".
But you can see it on the datatracker page:
https://datatracker.ietf.org/doc/rfc8366/
Document Type: RFC - Proposed Standard (May 2018) Errata
^
One can change the status of a specification "inline" without new RFC, but
typically
this can only be done, when there is no errata (i remember rfc8279 from
experimental
to proposed).
When there is errata, it needs to be fixed. Which requires a -bis document. AND
in both cases
you need to produce evidence of implementation (which is a WG process) and that
it works as
expected. Which we should be able to produce for rfc8366 after all the ongoing
implementations.
And example recent and adjacent advancement of status from proposed to internet
standard is CBOR:
https://datatracker.ietf.org/doc/rfc7049/
https://datatracker.ietf.org/doc/rfc8949/
http://www.ietf.org//rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc7049.txt=https://www.rfc-editor.org/rfc/rfc8949.txt
As you can see, there is a good amount of freedom to editorially improve
on the text of the original RFC to help implementers as much as possible to
avoid misunderstanding, BUT you do not want to introduce any incompatibilites
or additional functionality - that additional functionality would not have
been tested/validated as much as the original RFCs content/goals. That is the
root cause for Michaels (and BRSKI design team) opinion to just do bug fixes
(and editorial improvements as seen fit).
In result of becoming internet standard, datatracker would show:
DocumentTypeRFC - Internet Standard (...Data...)
Obsoletes RFC 8366
Also known as STD xx
Aka: The document also gets a STD number, and not only an RFC number.
Which of course is so much more prestigious given how there are only about 100:
as opposed to about 10,000 RFC! (turns your RFC into a 1 percenter ;-).
https://www.rfc-editor.org/standards
(i will take any bets that STD100 is already reserved for some -bis in the
making ;-)
RFC8366 is probably also the only of our RFCs we could easily get to internet
standard, because RFC8995 for example might have the issue that rfc7030 was
never brought to internet standard (real work). That might be considered
a problematic downrev for RFC8995. But of course, we could try, once we
have worked through the easier rfc8366 process.
Thats all i know ;-)
Cheers
Toerless
On Tue, Aug 02, 2022 at 11:27:03AM -0400, Michael Richardson wrote:
>
> Hi, we did not discuss RFC8366bis at the last IETF, because there aren't
> really any changes since IETF113.
>
> We have discussed a few times whether rfc8366bis should be just a bug-fix (on
> enumeration of assertion), or whether we should roll up all other extensions
> to 8366 into this document.
>
> The BRSKI Design team thinks we should just do bug-fix and in the process we
> should advance it to Internet Standard.
>
> https://www.ietf.org/rfcdiff?url1=rfc8366=draft-ietf-anima-rfc8366bis-00=--html
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
t...@cs.fau.de
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
