Dave First, thanks for resurrecting this for us. I think splitting draft into two parts probably makes sense after that last round of comments.
However, we need to go find those App Area folks (hence cc'ing Murray here) and run this past them. If the group likes this split, we can progress attrleaf first and give you time to work on the second document. Tim On Tue, Mar 20, 2018 at 12:35 AM, Dave Crocker <d...@dcrocker.net> wrote: > Folks, > > I'll limit what should be an extensive and elaborate apology to just this: > I'm sorry for the year of inactivity. > > The -03 version should provide some useful substance of progress. > > I've gone over last summer's comments and the -03 version should reflect > what the wg agreed to. Basically, it has been significantly streamlined, > essentially to reflect a clean-sheet model of the world. That is, it > doesn't deal with the ugliness that SRV, et al, created. It merely > establishes the two registries we need, long term, and populates them. > This document should have continuing utility. > > -03 defines two registries, 'global' and 'second-level'. I'm suspicious > of how short the global one is, though it does make sense. > > As noted in the document, absent major concerns with the substance of the > document, please send me or the list s/old/new/ types of change > suggestions, and if the change is for a reference, I'd love the suggestion > to be <reference> xml... > > > A second document will attempt to fix up the uglinesses in some existing > documents, to get them to align with a world that has these registries. It > should be viewed as a transitional document, though we all know how glacial > 'transitions' are in the Internet... > > Deciding how to pursue that reasonably has been the effort. The changes > this 'fixes' document defines will be to documentation, but not to existing > operation. Existing uses in the field will be preserved. > > > Here's the approach I'm taking: > > > 1. Simple underscore usage > > For many/most specifications that use underscore naming, the text > merely says to use it. They are straightforward. > > These specifications need to be listed in this document, explicitly, so > that later updates to them will know to deal with the revisions called for > by this document. > > But this document doesn't really need s/old/new kinds of precise detail > for them. Rather than provide precise language for changing each of these, > I propose to provide some generic text, and generic IANA Considerations. > This will permit this Fixes document to be cited as Updating those RFCs. > > > 2. SRV and URI > > These need more detailed text, very much in the s/old/new style. > > The current text in them does a use-by-reference of existing tables > defined for other purposes. The Update text will, instead, specify a > requirement for adding entries in the Global or Common Second-Level > registries. > > > d/ > > > -------- Forwarded Message -------- > > Name: draft-ietf-dnsop-attrleaf > Revision: 03 > Title: DNS Scoped Data Through '_Underscore' Naming of Attribute > Leaves > Document date: 2018-03-19 > Group: dnsop > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-dnsop-attrleaf/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03 > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
