To me, this has a few extra benefits:
- it removes a class of pointless downref considerations since IS and PS become the same level.
- It makes it much clearer to implementors & deployers that the RFCs that IETF produces are real standards, rather than a idea of something that might one day (but probably won't) become a standard.
- It allows us to allocate relatively stable STD numbers to the protocol RFCs. I.e., when a protocol is updated with a new version then there is the option of keeping the same STD number even though it is obviously a new RFC. It further differentiates between IETF standards and Informational or ISE documents because all the IETF standards would have a STD number associated with them. (Yes ... there would need to be a path/plan to also allocate them to existing PS RFCs).
“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?
Same level of bar, just more intuitive and accurate name for the end reader, and one layer of complexity removed from the IETF standards process.
We need to go in the other direction.
Lower the bar for PS. (lower he workload on IESG!!!)
I sort of agree. But I think that this is what Experimental should become. Drop the idea that an experiment must be documented and time limited, and instead, experimental becomes a proposed protocol that may (or may not) have some serious deficiencies, and may be changed in ways that break existing implementations or deployments.
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)
I was pleased to see the HTTP 1.1 become a full standard relatively recently, because I'm a cautious fellow I had been holding off deploying or using anything based on HTTP because of my concerns that it wasn't really stable and might still significantly change ;-).
Of course, for similar reasons, I suspect that is much wiser/safer to stick with the full Internet Standard HTTP 1.1 rather then be very brazen and implement or deploy the updated H/2, or H/3, neither or which are real standards, just something proposed to be a standard in future.
My real point being that our existing naming/categorisation isn't clear and useful to readers, or consumers of RFCs since I really think that H/2 and H/3 are the "current" stable versions of HTTP, and HTTTP 1.1 is legacy/historic.
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.
Agree, although I would mostly like to not see these published as RFCs at all, and instead most of the IETF process should be documented in one place - i.e., webpages backed by source control. Still with consensus checks. But hopefully also in a way where is much easier/simpler to make small tweaks to the process without needing a new RFC to be published that updates the existing process RFCs. Brian has a great page that indicates how broken it all is today.
(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
This is good and we should try and do something like this, but as per my previous comment to John, I think that it would be even better to publish updated versions of the RFCs (e.g. RFC XXXX-2) that can include the updated status and any verified errata. Maybe that a bridge too far at this time ....
We need the 2026-revision WG to do this, I think.
Yes, probably.
Kind regards,
Rob
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
