> On 27 Mar 2018, at 03:36, Dick Franks <rwfra...@acm.org> wrote: > >> please see down-thread where deprecation turns out to be both undesirable >> for the reasons i've given, and additive to developmental complexity since >> there would be _more_ DNS RFC's to read, and suboptimal compared to >> declaring a core subset of DNS technology as "mandatory to implement" and >> simply leaving WKS (and its hypothetical friends) out of that core subset. > > I fail to see how this changes the number of RFCs to be read. > > Nobody has yet defined a core subset; all we have is a camel-load of DNS > technology most of which appears to be "mandatory to implement", > and a mountain of RFCs which are very unlikely to be 100% consistent with > each other. > > Expelling one or more items from the "mandatory" set necessarily involves > writing an RFC to add to this mountain, and sometimes obsoleting an old one. > > The result is a smaller set of "mandatory to implement" DNS technology. > > Repeat this process until nobody can make a good case for further expulsions; > what remains is the core subset.
I concur with Dick here. Unless we strip the “core” first, we would be either unable to finish the work because we would endlessly bicker about what to put and what to leave out; or we would end up with even worse superset of what we already have. Stripping down the existing RFCs one-by-one, then just documenting what we already have without changing the content and producing the one “core” document obsoleting 1034,1035 is reasonable approach that could lead to an actionable work plan. Ondrej -- Ondřej Surý ond...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
