Rob Wilton \(rwilton\) <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> A digression, but I don’t think that “proposed standard” and “standard”
> are really well understood, given that the IETF has published 1000’s of
> proposed standards, but IIRC, less then 100 have reached the elevated
> status of being actual “Internet Standards”. One perverse
> interpretation of this could be that the IETF has fundamentally failed
> in its mission of publishing mature standards … but given that I think
> that the IETF has actually been very successful, the much more
> plausible explanation is that reaching “Internet Standard” basically
> doesn’t matter to anyone who is consuming (i.e., reading or
> implementing) RFCs.
Yes/no.
We've raised the bar for proposed standard so much that it's basically way
above Internet Standard (Draft Standard/Full Standard of yore). So going to
IS does seem like busy work, because the work already occured.
> “standard” anyway. Instead, the sensible thing is to call a spade a
> spade and drop the “Proposed Standard” category altogether and just
> publish “Internet Standards”, but with an updated RFC 2026 definition.
I see your point, but I disagree strongly.
It will just further push the bar higher to the point where everyone just
implements "stable" I-Ds. Why do the work?
We need to go in the other direction.
Lower the bar for PS. (lower he workload on IESG!!!)
Also lower the bar for IS.
DHCPv6 RFC8415 will go to IS this year.
We obsoleted two significant things.
meanwhile there are still significant gaps in how DHCP relays and PD
interact, which is "solved" today by inspection by DHCP relays. (I would
like to fix this, but I no longer have a product with enough deployment to affect
running code at all)
> But my wider point is that in many cases, the consumers of RFCs are not
> intended to be the IETF audience, but the broader internet community.
For a bunch of process "BCPs", I think that we actually need a new category,
perhaps even a new stream.
> (iii) it is easy for the end consumer to understand (which I think is
> the most important one).
I have a few experiences with end users (not just network operations, but
actual users) digging into an RFC to argue that the vendor did it wrong.
(I've mostly been a cheerleader/guide in these efforts).
> I don’t think that creating new magic words that none of the wider
> community understand is going to help. What we need is the extra
> metadata associated with an RFC (such as its current status, and
> whether there are any errata to be applied, to be present in a clearly
> visible banner whenever someone tries to access the document).
Yes, so, it's not the choice of magic words that matters, but that we have
defined labels. The problem is that the labels escape without the definitions.
> Hence, I’m proposing that we define a few different categories (give
> them a separate label, or just put them under historic) and then we
> create half a dozen versions of the different boilerplate, and allow it
> is to be extended, or maybe even modified, to allow additional context
> information to be given).
We don't get to modify the boilerplate after publication (at least, not yet),
so really the boilerplate we need would say:
As of the publication date (YYYY-MM-DD) of this document it was lablelled FOO.
The status of documents and the protocols that they describe evolves regularly.
For an up-to-date status, please visit https://www.rfc-editor.org/info/rfcXXXX
We need the 2026-revision WG to do this, I think.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
