Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
On 10.8.2017 07:24, Andrew Sullivan wrote: > Hi, > > On Thu, Aug 03, 2017 at 03:36:24PM -0700, Dave Crocker wrote: > >> deal with that fully, in a single spec produced an especially confused >> draft, roughly 10 years ago. > > I _think_ I may be one of the people who complained at the time, and > if I recall correctly what Dave and I agreed about (maybe the only > thing) was that this was all a terrible mess that needed repair. At > the time, I was still too much in thrall to data-theoretic approaches > to give in on Dave's pragmatic answer. And I now see that Dave has > actually described better than I was ever able my objection: > >> I've come to the conclusion that "accommodating" the established >> registration practices is a fundamentally wrong path. The only way to solve >> a problem of multiple registration authorities is to create a single >> registration authority. > > Yes. > >>1. Have this document define the simple, sole, authoritative mechanism >> for registering "top-level" (global scope) underscore names. >> >>2. Create a separate document that specifies modifications to the SRV and >> URI documents, rationalizing the use of underscore names, through the >> mechanism defined in -attrleaf-. > > I like this approach. Definitelly! -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
Hi, On Thu, Aug 03, 2017 at 03:36:24PM -0700, Dave Crocker wrote: > deal with that fully, in a single spec produced an especially confused > draft, roughly 10 years ago. I _think_ I may be one of the people who complained at the time, and if I recall correctly what Dave and I agreed about (maybe the only thing) was that this was all a terrible mess that needed repair. At the time, I was still too much in thrall to data-theoretic approaches to give in on Dave's pragmatic answer. And I now see that Dave has actually described better than I was ever able my objection: > I've come to the conclusion that "accommodating" the established > registration practices is a fundamentally wrong path. The only way to solve > a problem of multiple registration authorities is to create a single > registration authority. Yes. >1. Have this document define the simple, sole, authoritative mechanism > for registering "top-level" (global scope) underscore names. > >2. Create a separate document that specifies modifications to the SRV and > URI documents, rationalizing the use of underscore names, through the > mechanism defined in -attrleaf-. I like this approach. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
On 04/08/2017 17:02, Matthew Pounsett wrote: > Do I understand correctly that the intent is to obsolete existing > underscore registries (whether they be actual IANA registries, or just > code points listed in a draft) and move their data to a new, central > registry? This seems sensible to me. I agree that it's sensible for those underscore labels that appear rightmost in a string of one or more such labels, e.g. the _udp label of an SRV record owner-name, but not the _proto that precedes it. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
On 8/4/2017 9:02 AM, Matthew Pounsett wrote: Do I understand correctly that the intent is to obsolete existing underscore registries (whether they be actual IANA registries, or just code points listed in a draft) and move their data to a new, central registry? This seems sensible to me. Arguably, there aren't any underscore registries. There are some specs that allocate underscore names, but a 'registery' per se is not specified anywhere. That's the motivation for the current draft. SRV does registration-by-inheritance, but that overloads one registry semantic with another. So I'll take the liberty of rephrasing what you describe as: Obsolete the existing inheritance registrations and create explicit registrations for the currently-inherited names in use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
On 3 August 2017 at 18:36, Dave Crocker wrote: > > > Therefore I propose to: > >1. Have this document define the simple, sole, authoritative mechanism > for registering "top-level" (global scope) underscore names. > >2. Create a separate document that specifies modifications to the SRV > and URI documents, rationalizing the use of underscore names, through the > mechanism defined in -attrleaf-. > > Do I understand correctly that the intent is to obsolete existing underscore registries (whether they be actual IANA registries, or just code points listed in a draft) and move their data to a new, central registry? This seems sensible to me. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
Howdy. (I posted this on the ART list, yesterday, because Tim started a query about attrleaf there, but the note should probably also be posted at the attleaf hosting wg list. /d) I've been mulling over the challenges of this registration topic for more than a decade, constantly being hoisted on the petard of established practice... First, underscores can be used for multiple levels of node name. Trying to deal with that fully, in a single spec produced an especially confused draft, roughly 10 years ago. More recently it became clear that this is best handled by the described simplification the spec now declares -- essentially distinguishing between 'top-level' underscore names and separately deal with those below. But, as you note, this is not fully or adequately implemented in the latest versions of the draft. But I'll leave details about further fixes for that, for the moment, because... Second, and much worse, is that the original documentation of underscore use created an inherently-problematic arrangement: Attempting to synthesize some of the registration by incorporating entries in independent registration tables documented in SRV and URI specifications. The semantics therefore would mean there would be more than one 'authority' for name registration. This is a registration model designed to produce collisions. Efforts have been to retrofit an administrative model that accommodated this, where the idea of real-time conflict detection and resolution -- by infinitely diligent and perfectly perceptive -- IANA staff is one of the more recent suggestions. Unfortunately, there is an essential and practical difference between 'excellent' and 'perfect', where the latter is an inappropriate goal for human performance. I've come to the conclusion that "accommodating" the established registration practices is a fundamentally wrong path. The only way to solve a problem of multiple registration authorities is to create a single registration authority. That is, the right path is to create a simple and obvious registration model, and, separately, go back and fix the problematic documents. Therefore I propose to: 1. Have this document define the simple, sole, authoritative mechanism for registering "top-level" (global scope) underscore names. 2. Create a separate document that specifies modifications to the SRV and URI documents, rationalizing the use of underscore names, through the mechanism defined in -attrleaf-. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
