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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
