Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Aug 2017 15:36:24 -0700

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

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 4 Aug 2017 12:02:39 -0400

On 3 August 2017 at 18:36, Dave Crocker <[email-masked]> 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.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Aug 2017 09:52:43 -0700

On 8/4/2017 9:02 AM, Matthew Pounsett wrote:
> 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/

---

From: Ray Bellis <[email-masked]>
Date: Fri, 4 Aug 2017 17:53:27 +0100

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Aug 2017 01:24:44 -0400

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:

> 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.

>    2. Create a separate document that specifies modifications to the SRV and
> URI documents, rationalizing the use of underscore names, through the

I like this approach.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Mon, 21 Aug 2017 08:24:02 +0200

>> mechanism defined in -attrleaf-.

Definitelly!

-- 
Petr Špaček  @  CZ.NIC