Note this discussion has started to split into (at least) two: cleaning up the DNS standard (protocol, documents, or both), possibly in a new WG; and whether/how the existing DNSOP WG needs to adjust its efforts.
> On Mar 27, 2018, at 3:49 AM, Ondřej Surý <ond...@isc.org> wrote: > > Hi Suzanne, > >> 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. > > > I strongly believe that any work on cleaning up DNS protocol and/or rewriting > RFC1034/RFC1035 and associated document would need a new WG with tightly > defined charter. > > Hence, I will not request or I won’t support adopting my > deprecating-obsolete-rr-types as a WG document - it might become one of the > first documents for new WG, or it might end up as individual submission. > While this work might be considered as “protocol maintenance”, I think it is > bigger then simple protocol maintenance. > > Again, from experience from dnsext, I would strongly suggest that any work in > this area is split into CHANGE documents and REWRITE documents, with strict > scope. Documents rewriting existing RFCs while adding more stuff at the same > time tend to not reach the finish line. This all makes sense to me. I have no opinion (yet) on what the desired output should be (some new RFCs? A reference implementation/RFC set? Something else?), but agree it doesn’t fit DNSOP. Personally I think it’s within charter for DNSOP to facilitate this discussion, permit it to stay on the WG mailing list, etc. while people work out how they want to approach it, in substance and process. For instance, DNSOP helped get DPRIVE going by having a session at an IETF meeting on the DPRIVE drafts and adopting one of them (QNAME minimization). The important thing should be whether there’s an identifiable work item and whether the will exists to get it done, not how to charter a WG or otherwise work the process machinery. There are quite a few DNSOP (and IETF) regulars who are current or past WG chairs, ADs, and document editors, with experience of making the IETF machinery turn, who would be happy to advise proponents. This includes the current DNSOP chairs and AD. I do have to say I support the warnings about getting bits committed to documents (and possibly code). As another anecdote to add to the stack, I remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and Roy Arends do) the effort it took to get the DNSSEC RFCs done: a series of interop workshops, a couple of open source companies sponsoring development in well-known code bases, and money to support production of both code and documents. Resources committed as an afterthought were not getting it done. This is a different project, and I think it’s doable, but it’s not a weekend undertaking. Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
