--On Sunday, December 29, 2024 02:23 -0800 S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > Hi Ross, > At 03:23 PM 24-12-2024, Ross Finlayson wrote: >> Here's an off-the-wall idea that you can either mull over or laugh >> at over Christmas (whether or not you celebrate it): >> >> Instead of labeling RFCs with a single adjective (that may be >> ambiguous or easily misunderstood), why not instead label RFCs >> with a directive about what we want readers to actually do with >> its contents? E.g., - This protocol is insecure; do not implement >> it - Do not implement this version; refer to an updated >> RFC instead While I am not sure that is the right solution, I think the suggestion about labels helps to identify a more fundamental and broader problem. One view of the battle over "Historic" and similar labels is that it is a symptom of that broader problem. At least for me, Subramanian's comments below bring it into clearer focus. > This 2011 document is "Informational": > https://datatracker.ietf.org/doc/html/rfc6239 The status section > says that it represents the consensus of the community and it has > received public review. A reader [1] can see the current status on > the right (metadata sidebar). There would have been consensus for > the status change; the document is labelled as "Historic". The > status section does not reflect that. > > The IAB said that the statement in the status section which > describes the review of the document is an important component as: > > 1. It clarifies the breadth and depth of review, and > > 2. It gives the reader an understanding of how to consider > its content. > > One alternative is to update the status section to inform a reader > how to consider the contents today. That's not practical as the > section is part of the document. Another alternative is not to > include status information which could become outdated in future. I think this suggests two other options. One is what I think I've heard from several people, which is (more or less) that, since documents are available with integrated errata, handling these things as errata is more than sufficient. For reasons I'm given in other threads, particularly that I think it destroys the idea of an RFC as a stable and complete reference approved by community consensus (even if people check for the latest errata-updated version every time they consult the RFC), I don't believe that one but often seem to be in the minority. 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. That does not solve the problem for the 9000-odd existing documents but, once we got people used to the idea that "Category" at the top of an RFC was not the final word on the subject -- and where to look for that final word -- we could think better about ways to handle that backlog. best, john
