This discussion is deeply flawed. RFC numbers are largely that --
DOCUMENT NUMBERS, assigned to the RFCs during publication.
They serve a vital function for cataloging RFC documents.
Over the years, the community has tended increasingly to use RFC numbers
as PROTOCOL LABELS. Originally life was simple;
protocols had labels. If you wanted to refer to the TCP spec you could
just ask for "TCP". But protocol engineers tend to be
numerically oriented, not particularly verbal (with some notable
exceptions you know ;-)), and they started to refer to
"793" when they meant TCP.
We have managed to get along with a half-ACKed solution to protocol
accession, typified by the sequence
RFC822 -> RFC2822. This was Jon Postel's and Joyce Reynolds' attempt to
force RFC *document numbers*
to serve as *protocol numbers*. As noted in this discussion, this led
to some apparent mysterious
randomness in RFC number assignment.
Now, a few years ago at a meeting of some sort of IETF reformation group
(I forget the name), I advocated
the development of *structured protocol names*. RFC (document) numbers
do NOT fill that bill. We need
both RFC document numbers and protocol names.
Possible properties of protocol names might be:
(1) names, not numbers!!
(2) Probably hierarchical; think domain names.
(3) Might incorporate the "Obsoletes" attribute by some sort of
generation number.
("TCP.1", "TCP.2," ...)
(4) Should be backwards compatible in general with our inherited
protocol names.
(5) Would be assigned by the IESG early in the standards process, e.g.,
in the WG charter from the beginning.
But of course YMMV.
If we had such a name space, it might give the IESG a handle for
organizing the currently highly random
standards development process. See for example TCP.ROADMAP/1 (i.e.,
RFC4614 vers 1) to see how chaotic
the process has become.
Conclusions:
Don't make small changes
Think carefully before making any process changes.
There are real and serious process problems in the IETF.