Brian, I agree, but would add that this is another area where we have an anomaly or two left over from NEWTRK: The exact status of an Internet Standard obsoleted by a subsequent document is unclear. Consider, e.g., RFC 793. 9283 is an Internet Standard and obsoletes it, but 793 is still listed as an Internet Standard. Or consider RFC 821. RFC 2821, a Proposed Standard, obsoleted it and RFC 5321, a Draft Standard, obsoleted 2821. However, 821 retains the "Internet Standard" status and we've had an example or two of folks, in the last several years, being confused enough to believe they should be conforming to 821 because it is the full Internet Standard and that (ignoring the obsolete Draft Standard) Proposed means just what the word means and isn't. I don't believe Historic is the right fix for that but, if we are going to spend time on parts of this, it seems to me that the place to spend it is on that problem. The solution there might be a new category of "Obsolete", to join Proposed Standard, Internet Standard, and BCP. best, john --On Wednesday, 18 December, 2024 09:34 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > Hi, > > All of these RFCs have been obsoleted, most of them a long > time ago. There is no requirement to reclassify them in the > standards process. Anyone who checks them in the RFC index or > in the corresponding information pages such as > https://www.rfc-editor.org/info/rfc793 will immediately be > informed that they have been osboleted by, e.g., RFC 9293. > Anyone who just looks at the text of the RFCs will be none the > wiser. > > In my opinion there is no need to reclassify them, or any > other formally obsoleted standards track document, as > historic. If we reclassified these four documents, without > doing the same for every other obsoleted standards track > document, we would simply create four singularities, which > would lead to confusion. > > It would of course be quite easy to write a program to list > all obsoleted standards track documents and propose to > reclassify them all as Historic, but why bother? Well, since I > already had a program I could easily modify to do so, I can > tell you that there are 663 Standards Track RFCs that have > been obsoleted, and 51 BCP RFCs that have been obsoleted. > (Full list attached.) > > I note that the status-change document doesn't explain why > this is worth doing for these four documents in particular. I > think it is an unjustified waste of time and effort that will > cause confusion. > > Regards > Brian Carpenter > > On 18-Dec-24 05:22, The IESG wrote: >> >> The IESG has received a request from an individual >> participant to make the following status changes: >> >> - RFC793 from Internet Standard to Historic >> (Transmission Control Protocol) >> >> - RFC1065 from Internet Standard to Historic >> (Structure and identification of management information >> for TCP/IP-based internets) >> >> - RFC1723 from Internet Standard to Historic >> (RIP Version 2 - Carrying Additional Information) >> >> - RFC1725 from Internet Standard to Historic >> (Post Office Protocol - Version 3) >> >> The supporting document for this request can be found here: >> >> https://datatracker.ietf.org/doc/status-change-793-1065-1723- >> 1725-to-historic/ >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send >> substantive comments to the last-call@xxxxxxxx mailing lists >> by 2025-01-14. Exceptionally, comments may be sent to >> iesg@xxxxxxxx instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The affected documents can be obtained via >> https://datatracker.ietf.org/doc/rfc793/ >> https://datatracker.ietf.org/doc/rfc1065/ >> https://datatracker.ietf.org/doc/rfc1723/ >> https://datatracker.ietf.org/doc/rfc1725/ >> >> IESG discussion of this request can be tracked via >> https://datatracker.ietf.org/doc/status-change-793-1065-1723- >> 1725-to-historic/ballot/ >> >> >> >> _______________________________________________ >> IETF-Announce mailing list -- ietf-announce@xxxxxxxx >> To unsubscribe send an email to ietf-announce-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx