--On Tuesday, December 31, 2024 08:13 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
> On 31-Dec-24 06:54, Michael Richardson wrote:
>>
>> John C Klensin <john-ietf@xxxxxxx> wrote:
>> > The other, which may be more practical and useful, suggests
>> > that we should include a statement in every new RFC that
>> > says something like "for up-to-date information about the
>> > status of this document, see..." and give a URL. If we
>> > needed to drive that point home (given recent debates, we
>> > probably do), we might also change "Category" at the top of
>> > every RFC to "Category at the time of publication" or even
>> > "Status at the time of publication" and include relevant
>> > STD or BCP numbers with that label. That would make it
>> > extremely clear that Category/Status information was _not_
>> > a permanent property of that particular RFC.
>>
>> +1.
>>
>> I still think we need a richer lexicon than just Historic.
At the risk of wading a bit deeper into this pond, I had two main
points in mind. One was to move away from rigid categories in a
document with which we are stuck forever unless we start believing
that RFCs are living documents that can, in principle, change any (or
every day). The other was to try to approach this incrementally
rather than moving into areas that involve our getting bogged down
and ending up doing nothing.
So, in particular, once we have established the model that, while
category and status information might have initial values in an RFC,
the "real" information isn't in the RFC but in someplace that is
referenced and can be dynamic. The latter could easily be "Historic"
plus some explanatory wording that could evolve into multiple
categories but we don't need that rich lexicon at the outset.
Similarly,...
>> Can bike shedding this be added to the 2026 update group?
>
> Only as far as the IETF stream goes. It would be better for
> the changes to be applicable to all streams (along with the
> question of who "owns" the virtual Legacy stream, which is
> closely related to the UNKNOWN question.
That is another opportunity for an incremental, low-disruption,
approach: BCP and the two Standards Track categories are unique to
the IETF stream and the historical (lower case) versus active status
is more likely to be important there. On the other hand, we have a
WG and Area structure and a broad community approval process that
might come in hand. Perhaps we can agree that the confluence of
"hard", "important", and "large quantity" tends to lie with the IETF
Stream, do that one first, and then let the other streams, at their
leisure, learn from the experience and adapt as needed. We have
precedent for that too, of course.
And...
When I suggested using "UNKNOWN" as a precedent, it was more about
"don't worry about the exact status of this until there is a reason
to do so". My guess is that, although a few tweaks might be in order
(I'm personally more concerned about thoroughly obsolete documents
identified as "Internet Standard" or "BCP" than I am about, e.g.,
Informational documents) it is safe, although uncomfortable, to do
what we have been doing since around 2006 (and RFC 4450) which is to
ignore all of them unless an issue pops up with a particular one.
But, if we have to assign a label for some reason, "UNKNOWN" probably
isn't automatically it because, like "HISTORIC", there are multiple
flavors starting with a recent specification, perhaps even an
explicitly Experimental one, that has been wanting and possibly
harmful, being very different from "approved before 1990 and no one
wanted to advocate keeping it in an active status".
Borrowing from Subramanian again, if the goal is to make some
progress and make it sooner rather than (much) later (or not at all),
some aggressive sidestepping is probably our friend.
Going down any of the paths that have sorting out more details, more
labels, more conditions, or more streams before we can do anything
just invites our getting bogged down in interminable discussions,
interfering with moving more substantive IETF work forward, and
raising the risk of doing nothing for an extended period.
john
