On Fri, Oct 04, 2019 at 12:11:30PM -0400, Michael StJohns wrote: > On 10/4/2019 3:51 AM, Christian Huitema wrote: > > At the same time, there is a tension between the tradition and the need > > to serve and recruit a wider community. Our document production time is > > counted in years, and that does not help convincing open source projects > > to work with us. > > To be clear, it's not (only?) the actual document production that takes > time, but the authoring, and then getting through WG, then various twiddles > by the IESG, and then finally IETF last call, all before it ever gets to the > RFC editor for publication. Indeed. Time spent by I-Ds on the RFC-Editor queue or in AUTH48 is not _the_ problem, though it can sometimes be _a_ problem. _The_ problem is that review by _volunteers_ is a time-consuming thing. To get others (volunteers!) to review _your_ work you have to... also volunteer to review _theirs_. Reviewing others' work who are not also employees of the same org is difficult to justify and/or account for correctly. As well, authors of I-Ds are almost never professional writers, and they're usually not paid to write those I-Ds except as a side aspect of a larger project. The cost and value, of review is unaccounted, thus treated as an intangible, thus difficult to arrange. Authoring I-Ds, finding homes for them (WGs, maybe having to spin one up), getting a volunteer community to step up and review your work, getting past all the process (WG & IETF LC, IESG review) requires a lot of energy. > > Our documents are cast for eternity, errors included, > > which does not help the part the part of the readership who wants to > > implement standards. 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 kinda sorta try to keep RFC numbers rhyming... but it doesn't always work. E.g., RFCs 2459 -> 3280 -> 5280. TLS is another example of the same thing. 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 ... Where <xx> or <xxx> is a document number in the series and <vv> is a version number. Each of these would resolve, ultimately, to an old-style RFC number for as long as we continue to assign RFC numbers from the flat RFC series number space. I'd really like something like this! It would greatly help solve a number of problems. > > Implementing our standards involves a treasure hunt > > to find how many RFC have to be read before understanding the whole > > picture. Yes. See above. Though one does get good at it eventually. > This is problematic, but inherent, not so much in the RFC series, but in the > way we've chosen to do our standards process. We extend, we rarely amend, > and we run into problems when we amend. DNS being the most egregious > example of this (amend -> DNSSEC, extend -> more RFCs than I care to think > about) that I can think of with possibly TLS a close second. I think > that's more of a standards discussion than an RFC series discussion. Also, > it is possible (and has been done) to write a "here's what you need to do to > implement" RFC. Perhaps we (the IETF - at some cost) might think of > paying someone to do that for a few of the more extensive cases? Yes. We should provide more links like the updated-by/obsoleted-by links. But even better, if we had a related series naming scheme (see above). > > And that's before we even consider the potential of confusion > > between standards, experiments, independent efforts, and drafts. > > I rarely have a problem differentiating between the relative values and > quality of each of these, although I'm getting a little concerned with the > Informational RFCs coming out of the CFRG that are actually cryptographic > standards of first publication. Each and every RFC (or at least in the > last 10-15 years or so) has the disclaimer to "go check XXX to find out what > the status of this document is and what 'informational' or 'experimental' > actually means". > > Note that this is NOT specific to the IETF. Every time I delve into the > worlds of ANSI, IEEE or ISO standards I have to refresh my memory on their > various varieties of document markings. +1 > > The > > IETF community will need to solve that over time. I assume that this > > will imply some sharing of the work between the RFC Editor and the > > "superstructure" of the IETF, and I wait to see the discussion happening > > in the ad hoc working group. And yes, of course the discussion process > > should be open and fair. > > Nothing I've seen above really has an impact on the RFC editor as an > separate institution. Perhaps I'm misreading this, but perhaps what you're > implying is that more attention to cleaning up (and speeding up) the > standards process pre-submission-to-the RFC Editor is warranted? What do > you see as the RFC Series Editor's role in that? A new series naming/numbering scheme would though. That would be my preference. Nico --
