[DNSOP] End-to-end _underscore arguments (was: Re: [art] Another look - draft-ietf-dnsop-attrleaf-05.txt)

[Dave Crocker <[e-mail]>]

Folks,

(long note. couldn't make it shorter...)

This has been an unusually challenging journey.  None of the recent 
comments in support of a 'simplifying' view for this registry resonated. 
  Quite the opposite. In effect, it seemed to me as if RR type would be 
a lookup key, which frankly sounds a bit nuts.  OK in theoretical terms, 
perhaps, but problematic in practical terms, especially since -- given 
my understanding of what people were saying -- the use of the RR 
apparently would need to come into the lookup process just below the 
first underscore name...

On the other hand, when a variety of serious, knowledgeable folk support 
a view, there's an obligation to put serious effort into finding their 
f'ing pony...



It finally occurred to me that the current draft already has language 
that hints at the essential point that is probably what is actually 
being made, although it wasn't put there for that purpose or with that 
intended meaning:

     A given name defines a specific, constrained context for one or
     more RR records, in which use of such records MUST conform to the
     defined constraints.  Within this scope, other resource records that
     are not specified MAY be used.

The second sentence is the one with the larger meaning than I'd 
intended.  But the first one sets the larger point, though again, I 
wasn't seeing it.



One purpose of a registry to is prevent or resolve contention between 
publishers, for whatever is being listed.  The other is so that 
producers and consumers can rendezvous. The current draft's approach to 
doing the underscore work has focused on regulating domain name labels 
because, well, that's where the underscore is and it's been the obvious 
place where there has been no coordination.  The draft has been driven 
by a classic view of registration for a domain name.  Domain name 
registries concern possible contention between different organizations 
or people wanting a name.  So obviously that's what an underscore 
registry should worry about...



The essential point that I was missing was that the domain name is /not/ 
the contention to worry about, or at least, not much.  It's still 
essential that producers and consumers use the same rules for 
formulating the names, but that's about documentation and not 
contention.  The potential contention is in use of the RRs under a given 
name. (That is, after all, the point of the first sentence, quoted 
above.)  Having two different uses of the same RR in the same leaf is 
explicitly problematic.

So in end-to-end terms, the issue is the RR and not the path (name) to 
it.  As long as there is no contention in the production or use of a 
given RR appearing in a given leaf, then it doesn't matter if there are 
other actors using the same DNS node names (path) to get to their 
/other/ RRs.

Stated that way, this seems to me pretty obvious, but I really hadn't 
been seeing it.

The 'this' is:

      The DNS Global Underscore Registry MUST have entries that are 
unique with respect to the combination of the listed resource record and 
the listed, global underscore node name (RR, _Node Name).


Alas, seeing this doesn't resolve all the issues....

While (typeA, _label1) does not collide with (typeA, _label2), it 
obviously does collide with some other specification's use of (typeA, 
_label1).  Since permitting multiple services to use the same RR type is 
the explicit goal, we need procedures that ensure that these independent 
generators don't generate the same global underscore name.

The classic, boring approach to the underscore naming registry that I 
was taking fixes this problem, by ensuring there is only one controller 
of a given leaf, even with the simplest name registration FCFS approach.

The alternative being proposed does not accomplish this in an obvious 
way, since the requirement for uniqueness does not hinge on a single 
table entry value.

I think the best way to handle that issue is to make the global 
underscore registry subject to expert review, with very careful 
consensus language directing the expert on what to look for/ensure.



So...

1. Please comment on the above

2. I've submitted a new draft version based on this highly revised view

3. Besides changes to reflect the above, it also eliminates concern for 
any lower-level underscore usage:  uniqueness is only in terms of the RR 
and the global (first) underscore node name use. This is a simplifying 
point that could be argued, to have uniqueness depend on the full 
sequence of underscore lables, but I think it does not impose a 
significant burden.

3. The Expert Review is only for this registry entry.  Any other issues 
with the document specifying that entry would be outside of the scope of 
this review, but might be covered by some other process, such as the 
existing DNS RR review requirement.

4. I've punted on the details for the URI RR, given some complexities in 
RFC 6117.  If anyone wants to suggest specific text for this, it would 
be greatly appreciated.

5. There is still a second document needed, to fix the various documents 
that specify global underscore names, so that these documents are 
updated to cite the registry. Once things settle down for this main 
draft, I'll work on that one.



Thoughts?


d/

ps. Another round of hearty thanks to Ray Bellis for his offlist 
interactions with me on this, though of course he gets none of the blame 
for my getting any of this wrong...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net