Rob Wilton (rwilton) <rwilton@xxxxxxxxx> wrote:
> 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
Yeah, I see your points.
If we can do this without raising the bar, then I would agree.
mcr> We need to go in the other direction. Lower the bar for PS. (lower
mcr> 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.
So, Experiemental is what PS used to be.
I'm not sure that a rename like this actually would help.
> 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.
I don't think you could deploy a web server, or a web browser (or CURL
library) that did not support HTTP 1.1. I'm not even sure one could remove
1.0 or 0.9 support from a web server at this point, but maybe.
But, we do need a way to say, "you do not need specification XYZ anymore in
new systems"
>>> 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.
I can go with this for process stuff.
>> 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 ....
I see this as step three.
>> We need the 2026-revision WG to do this, I think.
> Yes, probably.
"NEWERTRK"
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
