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

[Adam Roach <[e-mail]>]

On 8/2/17 7:42 PM, Dave Crocker wrote:
> On 8/2/2017 5:35 PM, John Levine wrote:
>> In article <[e-mail]> you 
>> write:
>>>     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-.
>>
>> It seems a bit late to change SRV.  Or would you only adjust the
>> documentation to match observed reality?
>
> The latter.  The change is to the registration process, not to SRV, 
> per se.  That is, take a snapshot of the existing SRV underscore usage 
> and re-specify it in terms of an underscore registry, rather than in 
> terms of an inheritance from another registry.

That would appear to call for a slightly more narrow scope than the 
current document, which claims to be registering underscore usage for 
SRV, TXT, and URI RRs as well as (and I don't quite get this) NAPTR RRs. 
The reason I don't get the NAPTR treatment is: my understanding of NAPTR 
records doesn't include any kind of underscore-prefixed name components 
at all. My knowledge of NAPTR is mostly informed by SIP's usage of 
NAPTR; but I'm pretty sure that, in a generic sense, the overall 
procedure here is to feed in an underscore-free name in as your query, 
and to get back a giant slew of records that indicate various available 
services in their respective "Service" fields, along with a string 
transform that should be applied to the original name, the result of 
which is then fed back into another query for the service of interest.

I have to concede that the situation around registration of NAPTR 
Service values has always baffled me, and section 9 of RFC 3403 makes 
essentially no sense as far as I can tell. SIP solved this problem in 
its little corner of the NAPTR world with the registry at 
<https://www.iana.org/assignments/sip-table/sip-table.xhtml>. I have no 
idea how other protocols are supposed to deal with this situation; or, 
indeed, how one might hope to avoid collisions if the "MPLS-TP Shared 
Ring Protection" mechanism and the "Message Session Relay Protocol" both 
decided to use a NAPTR Service value of "MSRP+D2T".

Practically, for this document, I would recommend having a unified table 
for SRV and URI records, initially containing:

 1. _tcp
 2. _udp
 3. _sctp (implict in rfc6733)

There's also the odd matter of _LDAP, _HTTP, and _OCSP, used by RFC4386 
in what I presume was a misunderstanding of what was meant by "Proto" in 
SRV's definition of that term -- I would think we want to put these in 
the table but mark them experimental and/or deprecated. In fact, I think 
we would want to stipulate that new entries in this registry cannot 
contain any value other than those registered at 
<https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>.


I would recommend documenting and registering the underscore leaf nodes 
used by TXT records as a completely separate concern and in a different 
IANA table (although still as part of this document), as they mean 
something rather different than what's defined for SRV and URI. I 
believe the initial tables looks something like this at the moment 
(although I may have overlooked one or two):

 1. _domainkey
 2. _dmarc (rfc7489)
 3. _spf
 4. _vouch
 5. _tcp (implicit in rfc6764, rfc7808)


If you want to fix the NAPTR Service registry issue I highlight above, I 
would recommend doing this in a different document. It feels like a 
rather different problem, and the presence of the SIP registry (which 
would need to be subsumed into any complete registry) would seem to make 
it much more complicated to deal with.

/a