--On Friday, October 4, 2019 11:48 -0500 Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: >... > RFC numbers tend to become meaningless as we have more and > more of them. > > The ITU-T has a much better document naming scheme, and they > too have an immutability property. Thus ASN.1 is the x.680 > document series (x.680, x.681, x.682) and the encoding rules > for ASN.1 are the x.690 series, and each document gets a > "version number" in the form of publication year and month, > and old versions remain accessible and unchanged. >... > We would do much better to start having series identifiers for > related RFCs. All the LDAP ones, all the SSHv2 ones, all the > PKIX ones, ... - all related RFCs should be easy to find under > one prefix. > > We could design such a naming scheme and bolt it onto the > existing RFCs, much like STDs have distinct (and stable) > numbers from the RFCs that back them. > > E.g., we could have names like: > > STD-DNS-xx > RFC-DNS-xx-vv > > STD-PKIX-xxx > RFC-PKIX-xxx-vv >... Nico, I won't try to spend the time today to explain why that would cause a different set of problems other than to note that we often process documents that don't fall neatly into one category and that would just cause other arguments and uncertainties. At the risk of excessive kicking of dead horses, I note that there have been multiple proposals to assign STD numbers to standards track documents at Proposed. STF numbers have, as you more or less point out, never served their intended purpose because we advance so few documents past Proposed but they do perform the grouping function you are looking for. There were also pieces of the NEWTRK work that would have provided a clear structure for documents that would group others, explain what actually was "the standard" for a particular topic area, and even allow for incorporating comments on interoperability status and errata. There were similar, earlier proposals for grouping and status documents, as well as attempts to get more effort into Applicability Statements with the same intent. All of those efforts met the same fate: the IESG wasn't interested in them or willing to initiate IETF Last Calls. And no one in the community was willing to press that, e.g., by appealing the IESG's non-action of WG Last Call requests, at least in part because of concern that the appeal process would be damaging to the community and that the IESG would, even if they were told to rethink the decision, either reaffirm it or figure out other ways to kill an idea they didn't like. best, john
