Hardly seems worth the effort. Of the 5092 RFCs published, just 67 are Full Standards. Of those, how many realistically need updates? Ad hoc may be a more efficient approach. Or, are you thinking about a "lessons learned from RFC 2821-bis"? On 12/6/07 8:20 AM, "John C Klensin" <john-ietf@xxxxxxx> wrote: > Hi. I had intended to bring this up at the plenary last night > but, since I had not raised it on the list and was tired, > decided not to. > > Our standards process (RFC2026 and updates) more or less assumes > that documents progress from idea -> I-D -> Proposed -> Draft -> > Full. Ignore, for now, the question of how much we use all of > that (and why we don't do so often enough). When the rules > associated with that progression are applied to an update to a > full standard -- a protocol that is widely deployed, tested by > much use and independent implementations-- things get a little > strange. For example: > > * The RFC Editor discovers that the community doesn't > quite know what to do with the STD number: It can't be > reassigned to the new document because it is at > Proposed. I shouldn't be left on the original document > because it really isn't our latest and best thinking on > the subject. And it shouldn't be withdrawn because that > leads to silly states in documents that have been > written to call on "STD 999" precisely because those > numbers were expected to refer to current specs. > > * It is not quite clear what implementation reports and > interoperability testing mean. Presuming that the > original spec doesn't count and the update is completely > new would be a major triumph of procedure over good > sense. But... > > There are other issues but, in the interest of keeping this note > short, I'll leave them for another time. > > So, three questions: > > (1) Does the community think this is a problem worth solving? > If the answer is "no", then trying to write up a proposal is > clearly a waste of time. > > (2) Assuming a draft and mailing list are created, are people > willing to review and contribute? Do we need to start thinking > in terms of a WG for this issue alone? (Experience with NEWTRK > suggests to me that a WG with a broader charter would be a bad > idea.) > > (3) Would the IESG be inclined to look on a proposal -- either a > request to Last Call a draft document or a WG request, depending > on (2)-- with favor? If the answer is, as it was with some > NEWTRK work (which, incidentally, would have eliminated this > problem), "we would rather you didn't pursue that", then I don't > believe this is a rock that we should start pushing uphill. > > john > > Disclaimer: rfc2821bis, now in last call, would clearly have > benefited from some changes along this line and thinking about > issues associated with it definitely got me motivated to think > about the problem. But it is already in Last Call, so any > changes that are made to the procedures will not affect its > processing in any way (although they might ultimately effect how > it, 821, 2821, and STD10 are identified). > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf