--On Friday, January 21, 2022 13:22 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > Hi, > > In my opinion, the IETF, and therefore the IESG, has no right > to change the status of this RFC, which is dated 1984, two > years before the IETF existed. > I believe that the status of many early RFCs should be > reviewed, but by the RFC Editor function, not by the IETF. > Probably, Historic is the correct status for most of them. > However, it isn't an urgent matter as we have managed for the > last 35+ years with these RFCs unclassified, and we can > certainly wait until the new RFC Editor model is in place. > This will provide a proper mechanism to develop policies such > as "what to do about the 904 RFCs with status UNKNOWN". Brian, While I am skeptical about whether getting involved with the "rights" of the IETF is productive, I largely agree with the above. I found myself wondering why the effort described in RFC 4450 did not pick this one up. Having now looked that document, it reinforces your point of view: the IETF apparently decided at the point that cruft-cleaning should be focused on Standards Track (and hence IETF) documents (Eliot or Harald may be able to shed more light on that decision as my memory is very vague). It would certainly seem appropriate to turn the problem over to the new version of the RFC Editor model. Perhaps figuring out how to proceed might even be a good initial project for the RSWG -- interesting and complex, but not likely to stir up deep passions and conflicts. But I could be wrong about that. On the other hand, if the IESG is determined to go through with this, I think the community should insist that the status change notice be expanded to explain why it is important to make this particular change at this particular time... noting for example that 4.2 BSD isn't being used much any more but has not been for many years. It this is an effort to clean out documents with status "UNKNOWN", then why single out this one rather than mounting an organized cleanup effort (again, preferably in conjunction with the RFC Editor Function) along the same lines as the RFC 4450 review. john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
