On Fri, Oct 04, 2019 at 03:48:37PM -0400, John C Klensin wrote: > --On Friday, October 4, 2019 12:42 -0500 Nico Williams > <nico@xxxxxxxxxxxxxxxx> wrote: > > > On Fri, Oct 04, 2019 at 01:07:57PM -0400, John C Klensin wrote: > >> --On Friday, October 4, 2019 11:48 -0500 Nico Williams > >> <nico@xxxxxxxxxxxxxxxx> wrote: > >> > 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 > >> > ... > >> > >> 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 > > > > Maybe you can try tomorrow then? I don't see any obvious > > problems. > > Mike's examples of the ITU-T and IEEE 802.x problems should be > suff9icent to put your naming proposal to rest, but let me add > two examples of the sort of question I was thinking about. And yet they weren't. > (1) RFCs 5890-5894 and maybe 5895 and others are collectively > known as "IDNA2008". Do they become RFC-IDNA-nn or, given what > they do, RFC-DNS-nn? [...] Yes, possibly. I.e., both, if that's deemed to be useful. > [...]? And are other documents that specify > special characteristics or syntax for DNS labels become part of > RFC-DNS-nnn or are they separate? Similarly, are DNSSEC and the > various encrypted DNS query specs and proposals properly > RFC-DNS-nn or do they get their own subseries? Ditto. > (2) There are interesting dependencies among PRECIS work, IDNA, > specifications for language negotiation, language tag and media > type specifications, and the several interdependent > specifications for non-ASCII email addresses. If each > specification get a single number --regardless of which > sub-series it is associated with -- then the system breaks down > with regard to the other groups. In particular, are the latter > group part of email or part of some more or less generic I18n > category? Same answer. You could have one RFC in zero, one, or more series as appropriate. I'd expect an RFC that specifies a new DNS RR type for, say, TLS, to be in at least a series related to TLS. I could find the misc RR type in an IANA registry (since I know to look there), and such an RFC might not be said to modify core DNS in any way, but it might still be useful for it to *also* appear in the DNS series. > I think any way you would go with this would either require > drastic changes in how we do standards or would turn out to > create as much confusion as it solved. One could begin curating "series" like this right now without any change to anything, though without any authority or process to maintain it it wouldn't be so valuable. What process is needed to establish and maintain such series? For maintenance, sometime in between WG adoption and AUTH48, the authors, WG, IESG, or IETF, would get to pick zero, one, or more series to contain the new RFC. For establishment we might task WGs with proposing appropriate series. Or the RFC-Editor might have this as a responsibility. Since we're discussing the RFC-Editor SOW, and since organizing the series might be the sort of task that might fall in the RFC-Editor's purview, I think this is on-topic. Nico --
