*> 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