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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf