Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07

From: "John Levine" <[email-masked]>
Date: 14 Nov 2015 20:28:44 -0000

>Done.
>
>This will be the third or fourth try for the document.  Perhaps there is
>now enough community interest to make it happen?

The more I look at this, the more of a mess I find.  It's not like it
would have been all up to you.  RFC 6335 came out five years after the
first version of your draft and would have been a fine opportunity to
de-mess.

Assuming the places in the draft where you refer to the left-most name
you mean the right-most name for what gets registered, it needs to
make clear what names enable what sub-names.

For example, if a name is _tcp or _udp, all of the names in the RFC
6335 service name registry are eligible.  This includes _soap-beep and
_xmlrpc-beep which are in that registry, and _certificates and _crls
which should be but aren't.  But RFC 2782 is pretty casual about what
protocols other than _tcp and _udp correspond to SRV names.  IANA has
a protocol registry at
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
but a lot of the entries are not obvious candidates for SRV.  On the
other hand, RFC 5509 makes _sip a SRV protocol name even though it's
also a service.

DKIM currently allows _adsp as a subtag, probably not worth making a
registry, since there don't seem to be any other likely DKIM subtags.
Similarly there's _report._dmarc which seems to be a one-off.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Nov 2015 15:26:04 -0800

On 11/14/2015 12:28 PM, John Levine wrote:
> RFC 6335 came out five years after the

Given what it was trying to do, I don't think they could reasonably have
tackled this topic.  However I suppose it's nice that they sought to
enfoce a "no underscores" rule for their table, since it facilitates the
re-use of the names under SRV.

The more serious problem, IMO, is that the SRV spec has such a fuzzy
spec for the alternative names that might be used besides _udp and _tcp.

I tried to accommodate this actively in the earliest versions of the
draft -- even to the point of having the registry be hierarchical -- but
seem to have fallen back to something as fuzzy as the SRV spec itself.
I finally decided flat organization suffices but didn't care the
requirement for explicit registration forward. Yuck.

At this point, after looking at the relevant SRV spec text again, I
believe the only respectable solution is to change that part of the SRV
spec and dictate that the service names must be registered in this IANA
table.  I do not see a "inherited from the IANA service names table"
model as being viable, since it almost encourages name collisions.

> make clear what names enable what sub-names.

oh my.  ummm.  yes.  i only wish i could attribute this to alcohol or
dyslexia.

> Similarly there's _report._dmarc which seems to be a one-off.

For got that.  Thought it was indepedent. ADSP is now removed from the
draft.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net