*> This means drastically lowering the standards for what can be published *> as an RFC. (Note that this brings us closer to what RFCs used to be 15 *> years or so ago.) Another way to do it would be to simply archive all I do not believe that it means lowering the standards at all, in general. In general, the documents we should be publishing as RFCs, but are allowing to disappear into long-dead Internet Drafts, are every bit as good quality as the RFCs we are publishing today (if not better!). Example: The RFC Editor has been pushing to get the current plateau of the technical specification of HIP published as an RFC. It's like pulling teeth, for some reason, but hopefully we will make it. The current HIP architecture document is an important contribution that will be a valuable reference to future Internet techies, regardless of the future trajectory of the HIP protocol. BTW, when you said 15 years you really meant 25, back to the late ARPAnet and early Internet days. 15 years ago is relatively recent, really part of "modern times" for the Internet community. For example, the Host Requirements RFCs (1122, 1123) were published 15 years ago. I don't think you would be lowering current standards to reach that level. *> drafts. I agree this has the unpleasant side effect that all those *> drafts that become obsolete (or are so from inception) stay around *> forever. But it's still better than the current situation, where making *> something an RFC means an incredible amount of work for many people, It is true that writing quality documents, no matter what you call them, is always an "incredible amount of work." Work well spent, I believe. Bob Braden