On Jun 9, 2011, at 12:17 PM, Joel Jaeggli wrote: >> I don't have a problem with the idea that an Informational document can >> describe the consequences of moving something to Historic. I have a serious >> problem with the idea that a standards-track document can be moved off of >> the standards track by less than an IETF Consensus process, or by ignoring >> the criteria for standards-track actions. I haven't seen any evidence that >> IESG is trying to do that - they are doing a Last Call after all. But I >> don't think we want to set a precedent that removing something from the >> standards track is easier or requires less scrutiny of the technical >> criteria than putting something on the standards track. > > The record will show that that the intended status of the document until it > reached the iegs was standards track. it has been understood from the outset > that advancement of the document was to obsolete 3056 and 3068. revision 4 at > the request of the iesg changed th e intented status to informational.
And Informational status *for the document*, if published, is entirely appropriate. But the *protocol action* is a standards-track protocol action. It used to not be considered necessary to publish an RFC every time the IESG approved a protocol action. Somewhere along the way, having a companion document started to be commonplace. I'm not sure why that got to be conventional - maybe it was because of increased use of tracking tools that were written with document processing in mind. And at least sometimes it's beneficial to the community to publish an RFC that explains why a particular document's status has changed, and how to interpret that change in document status. But RFC 2026 didn't anticipate the need for every protocol action to have an associated document, and sometimes - as in this case - it causes confusion when they are associated. Process-wise, I think that the protocol action and the document action should be separate items. Though of course it makes no sense for IESG to approve the document if it doesn't approve the protocol action. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
