Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

[John C Klensin <[e-mail]>]

--On Monday, March 26, 2018 09:44 +0100 "John R. Levine"
<[e-mail]> wrote:

>...
>>> i have reproduced your entire second suggestion here,
>>> because i think  it's solid. rrset atomicity means you're
>>> right, and that underbar'ed  labels need only be unique
>>> within an RRTYPE, and any registry of such  labels can and
>>> therefore should be per-RRTYPE.
> 
> Technically, you are completely correct.  But since the
> namespace is in effect infinite I would just as soon not have
> to explain to anyone why _foo for SRV means the same thing as
> _foo for URI but different from _foo for TXT.  As we've seen
> it's hard enough to understand the separate second level
> underscore namespaces and we're stuck with them.

Ah, but pulling them together into one registry is our old
problem, in disguise, of trying to control behavior by what we
allow to be registered.   If, for example, I'm stupid enough to
use "_tcp" as the label of a TXT RR, a single registration tree
won't stop me or cause any DNS problems, it will just help me
add to the confusion.   If they are separated, I'm at least
marginally encouraged to document what I'd doing. 

At least as I see it, the purpose of a registry like this is to
help non-stupid people avoid conflicts and to provide
documentation pointers for information about the keywords.
Especially if the registry is not expected to grow to a huge
number of entries, asking IANA to create an alphabetical index
of all label keywords (I'm resisting "_Node Name" because I
don't believe this is really a namespace) that could link names
to particular subregistries (possibly more than one) would not
be a big deal.  

By contrast, Table 1 of the I-D is 

                    +-------------+-----+------------+
                    | _NODE NAME  | RR  | REFERENCE  |
                    +-------------+-----+------------+
                    | _tcp        | SRV | [RFC2782]  |
                    | _udp        | SRV | [RFC2782]  |
                    | _sctp       | SRV | [RFC2782]  |
                    | _dccp       | SRV | [RFC2782]  |
                    | _domainkey  | TXT | [RFC6376]  |
                    | _spf        | TXT | [RFC7208]  |
                    | _dmarc      | TXT | [RFC7489]  |
                    | _vouch      | TXT | [RFC5518]  |
                    +-------------+-----+------------+ 

While not very large, it is sorted by RRTYPE and then not sorted
in any obvious way.  Were it to grow significantly, one would
either want the same sort of index or would want to sort it by
label string ("_Node name") and then create an index by RRTYPE. 

If we are going to separate "SRV" out, as you and several other
have argued is necessary, we've got two separate registries
already -- SRV and "everything else", with the latter consisting
exclusively of TXT.  So, again, going to two subregistries and
provision for expansion from a table that is halfway there
anyway does not seem to me to be a big deal while being closer
to the reality of the DNS (as Paul explained better than I
could).

best,
   john