Hi all, First, thanks for running with this.
Top-posting a couple of process observations: First, the chairs are always open to discussion of what documents belong in the WG, interpretation/revision of our charter, etc. There’s a certain amount of process to be observed, especially if we want to revise our charter, but nothing unmanageable; it’s the chairs’ job to make process work for the WG rather than the other way around. The current DNSOP charter was deliberately written to be flexible in what we could work on. Normally an IETF WG is chartered to perform a fairly tightly constrained piece of work and then either re-charter to an equally specific next work item, or shut down. But part of the purpose of keeping DNSOP around in a slightly more open-ended fashion was that the community seemed to believe that major protocol work on DNS was done, but there would still be pressure to provide for small tweaks on the wire and review Informational documents on operational practice such as DNSSEC maintenance. Since then, a couple of pieces of work with significant protocol implications have gotten some initial review in DNSOP, and then moved to new WGs such as DPRIVE. Most of the documents DNSOP publishes are standards track only for procedural reasons— implementing them is strictly optional for interoperability on the public internet— or are informational. If the WG feels that the previous view of how DNSOP should work has been overtaken by events, we can certainly work with our Area Director (hi Warren!) on a revised charter. Given the deliberately loose boundaries on the current charter, we can adjust what we’re doing instead of (or during) the formal process of revising it. The charter we have doesn’t obligate us to adopt any particular work item, or to pursue one that’s been adopted but that the WG finds it doesn’t want to pursue after all. In my own strictly subjective impression, some of what we’re publishing is first written as an internet-draft….but some is implemented first in the field and then brought back to the IETF to be documented in an informational RFC so other implementers can write compatible behavior into their software, or so operators who want to use a particular feature can figure out how (*lots* of DNSSEC docs), or operators who don’t want to use a particular feature can (relatively) easily find ways around it. The pressure to standardize extensions to the DNS actually seems lower in the last few years, because both the RRtype registry and the EDNS opt registry policies are expert review rather than standards action. However, the tendency to desire DNS-over-new-transport is recent. So is DPRIVE. So are the assorted optimizations used by CDN operators such as serve-stale and client-subnet. It’s also worth noting that many WG participants (operators and implementers alike) have argued over the years that having the IETF refuse to publish an RFC does nothing to discourage people from inventing and fielding new features, it just makes it harder to find out what they’re doing— whether you want to interoperate with them or simply avoid them. So for novel uses of RRtypes or EDNS options, we’ve tended to encourage people who already had acquired code points in the registry to document what they’re doing with them (see RFC 7871 on client-subnet, which had a code point and was in widespread use and *then* was brought to DNSOP). Serious question: should we be encouraging people to document these optional extensions in RFCs? A couple more points inline: > On Mar 26, 2018, at 11:46 AM, bert hubert <bert.hub...@powerdns.com> wrote: > > I am optimistic that if we had a better 'hello, and welcome to DNS' document > we could point to, implementations would get better. Or if they didn't, we > could at least point at that document and blame them for not reading it. > This may prevent implementations that get confused if they get anything > other than an A query. > > So my first suggested action is: could we write a document that has a core > introduction of DNS and then provides a recommended (not) reading list. As discussed at the mic last Tuesday, I believe this is where DNSEXT got hung up, too: it’s likely to be hard work (given the effort that’s gone into just the terminology documents) and may not be considered the best use of people’s time by their assorted funding sources. Earnest question, for discussion: should this document be an RFC, produced in the IETF? (I can see arguments both ways). While we ponder this, there’s nothing to prevent anyone from posting a rudimentary internet-draft for consideration. > > Secondly, what we've been doing already, is grouping the various standards > in categories. Read this if you are doing X. This could go in the first > document. > > Thirdly, this may lead to a category of RFCs that you might be better off > not reading or implementing. I don't know if writing a draft that > specifically obsoletes record types or features that are never used is > helpful. In fact, adding MORE documents to the pile (even if meant to make > life easier) may be counterproductive. But simply noting that something > should not be implemented anymore would do rhe trick. There are process rules around obsoleting or updating an RFC with a new one. They’re not onerous. But for the older RFCs, this could be more complicated than it sounds; a patch is going to be much harder to write than new text in several cases. (I saw a plan once to update RFC 2181 that involved six new documents; each would update or obsolete one section.) > > Fourthly, on the currently active drafts aiming to become Internet Standards > (with page numbers): > > DNS Multiple QTYPEs 6 > Secret Key Transaction Authentication for DNS (TSIG) 21 > Address-specific DNS Name Redirection (ANAME) 11 > C-DNS: A DNS Packet Capture Format 58 > Extended DNS Errors 8 > A Root Key Trust Anchor Sentinel for DNSSEC 14 > Let 'localhost' be localhost. 9 > Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY 10 > Security Considerations for RFC5011 Publishers 18 > Serving Stale Data to Improve DNS Resiliency 9 > DNS Stateful Operations 49 > BULK DNS Resource Records 14 > A DNS Query including A Main Question with Accompanying Questions 10 > Returning extra answers in DNS responses. 8 > > These represent 245 pages of new reading material, or an increase of over > 10% on the already impressive list of DNS standards. > > I did a cursory read of the DNSOP charter, and I think at least some of > these drafts do no not fall under even a very broad interpretation of our > remit. Not all of these are WG documents (“candidate” just means someone has asked; bulk-rr for instance), and see above on the charter. The chairs don’t adopt documents we believe are off-charter, and would hope for pushback from the WG or our AD if we did. But in the context of the “Camel Problem,” arguing about the charter seems less useful than asking ourselves if we’re having second thoughts about the usefulness of documents the WG has adopted, or been asked to adopt. (This is long enough already, so further thoughts as the thread evolves. I do think it’s important to pursue the discussion.) Best, Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
