Subject: [DNSOP] Call for Adoption: draft-crocker-dns-attrleaf

From: Tim Wicinski <[email-masked]>
Date: Mon, 29 Feb 2016 10:40:31 -0500

There was some good discussion around this draft when it first appeared, 
and the initial idea by the author was to run this through the Apps area 
working group.  The chairs feel it make more sense to run this through 
DNSOP and we urged the author to allow us the chance to give the working 
group a try before giving up.

*Note: This draft will create an IANA registry for "underscored names". 
Now 10 years ago, even I would of blanched at such a thought.  But there 
seems to have come a time where it makes sense to document the
morass of these labels and offers some guidance.  The discussion seemed 
to bear this out.

This starts a Call for Adoption for "DNS Scoped Data Through 
'_Underscore' Attribute Leaves"

The draft is available here: 
https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/
Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 14 March 2016.

Thanks,
tim wicinski
DNSOP co-chair

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Feb 2016 10:54:42 -0500 (EST)

On Mon, 29 Feb 2016, Tim Wicinski wrote:

> There was some good discussion around this draft when it first appeared, and 
> the initial idea by the author was to run this through the Apps area working 
> group.  The chairs feel it make more sense to run this through DNSOP and we 
> urged the author to allow us the chance to give the working group a try 
> before giving up.
>
> *Note: This draft will create an IANA registry for "underscored names". Now 
> 10 years ago, even I would of blanched at such a thought.  But there seems to 
> have come a time where it makes sense to document the
> morass of these labels and offers some guidance.  The discussion seemed to 
> bear this out.

I don't like it but it seems we should have one.

> This starts a Call for Adoption for "DNS Scoped Data Through '_Underscore' 
> Attribute Leaves"
>

So I'm in favor of adopting this document.

Some comments so far:

Normally we try to leave "private use" ranges in registries for people
to experiment on. It would be good to have that here as well, or else we
won't be able to differentiate experimentation from standarization. I
suggest reserving the double underscore space (__*) for private use
(provided this isn't already in wide use)

The document should probably explain the RRtype listed in the registry
and interaction/allowance with CNAME/DNAME.

Are there any known already existing conflicts where two protocols use
the same underscore entry. If so, how do we resolve that issue?

What are the requirements for entry into this registry. I would not want
to see a rush of people registering vanity names for pet projects,
taking away all the sensible one word entries. I see _mail is available :)

Paul

---

From: "John Levine" <[email-masked]>
Date: 29 Feb 2016 18:07:56 -0000

>Please also indicate if you are willing to contribute text, review, etc.

This registry is long overdue (the -00 was written almost a decade
ago) but better late than never.  The draft is in OK shape but needs
some careful work to clarify how it relates to the service name and
number registry set up by RFC 6335.

Service names are, as far as I can tell, used extensively in the DNS,
but only as sub-names of protocol names for SRV, NAPRI, and URI
records, e.g., "sip" in:

   _sip._udp IN SRV 0 5060 host42

The service names in the current draft should come out, and it needs
language pointing to the service name registry for names used as
subnames of protocol names.

There is no registry of protocol names, and although it may be
somewhat painful to set one up at this late date, I think it would be
a good idea.  The names _tcp _udp _sctp are used as protocol names in
RFCs, maybe others.  IANA has a Protocol Numbers registry and it's not
clear to me whether we should add an optional name column to that
registry (optional because most of the protocols are dead and most of
the rest are not intended to carry multiple services) or a separate
registry of names of live protocols that are suitable for multiple
services.

None of this should be terribly hard.  I've discussed it with Dave and
believe that he generally agrees with the direction.  I'm happy to
rewrite, review, whatever.

R's,
John

PS: Speaking of rewriting, in the last paragraph of section 3, it
should say "right" where it says "left".

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Feb 2016 13:57:07 -0800

> subnames of protocol names.

I am currently updating the draft, where the interesting challenge is to 
specify text that modifies the SRV RFC so that it's use of underscore 
names is moved to the new registry.

The current model in the _Underscore draft is to focus only on the 
highest level of _underscore naming, and treat any _underscore naming 
below that as local to the specification registering the highest-level name.

Given the existing variety of SRV use, I think it's worth having an 
exception to the model.  That is, rather than only putting SRV's _Proto 
names into the registry, also register the _Service names.

My reasoning is that it appears that only _udp and _tcp seem to be in 
current use as instances of _Proto, and it would be better to fold the 
range of existing _Service instances into this global _Underscore 
registry than to create an SRV-specific _undrscore registry.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Feb 2016 14:07:08 -0800

> (provided this isn't already in wide use)

There is a real problem with private naming, and that is that any use of 
private names that becomes successful is then faced with having to 
change all existing behaviors to move to a publicly-registered name.

I think it makes more sense to have new uses choose a name that can 
eventually be registered and simply experiment with it 'raw' until then. 
  Given the size of the namespace, the likelihood of a collision during 
initial testing is quite small.  To make it even smaller, we can make 
the barrier to getting an entry in the _Underscore registry very low.

> and interaction/allowance with CNAME/DNAME.

1. What do you mean 'explain' and why should the registry contain this 
information?  Specifically, how is that information essential to simple 
and useful operation of the registry?

2. Entries of this type run the risk of either repeating text in the 
actual specification -- and therefore diverging from it if the spec 
changes -- or badly summarizing the spec.

> the same underscore entry. If so, how do we resolve that issue?

I don't recall seeing any, in spite of how many _underscore names there 
already are.

> taking away all the sensible one word entries. I see _mail is available :)

Well, we know the concern about vanity use of DNS-related names is a 
long way from silly, so alas I guess we have to worry about that.  grrr...

 From the list of IANA choices for this:

      http://tools.ietf.org/html/rfc5226#section-4.2

I'm inclined to suggest 'Specification Required'.  In my own view, an 
internet draft ought to qualify, since they no longer disappear, but I 
believe the community view is that it would require an RFC or the like.

d/

---

From: "John R Levine" <[email-masked]>
Date: 29 Feb 2016 17:27:49 -0500

> The current model in the _Underscore draft is to focus only on the highest 
> level of _underscore naming, and treat any _underscore naming below that as 
> local to the specification registering the highest-level name.

So far so good.

> Given the existing variety of SRV use, I think it's worth having an exception 
> to the model.  That is, rather than only putting SRV's _Proto names into the 
> registry, also register the _Service names.

There's almost 7000 service names in the IANA port and service registry, 
all of which (as far as I can tell) are used only as subnames of _tcp _udp 
and maybe _sctp and _dccp.  They're mostly used for SRV but also for 
NAPTR.  RFC 6335 cleaned up the names with inconvenient characters (slash, 
dot, internal underscore) and set out the rules for adding new service 
names.  There are designated experts for SCTP and DCCP service names so 
they should be able to tell us how widely used the names are.

> My reasoning is that it appears that only _udp and _tcp seem to be in current 
> use as instances of _Proto, and it would be better to fold the range of 
> existing _Service instances into this global _Underscore registry than to 
> create an SRV-specific _underscore registry.

The existing port and service registry already has all of the _service 
names, and is updated as people invent new services.  What's the benefit 
of duplicating it rather than just pointing to it?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 29 Feb 2016 22:32:42 +0000

> of duplicating it rather than just pointing to it?

+1

[and this is pretty much the proposal I made to Dave back in Orlando...]

Ray

---

From: "John Levine" <[email-masked]>
Date: 29 Feb 2016 22:47:21 -0000

>long way from silly, so alas I guess we have to worry about that.  grrr...

I'm not too worried about it, since unlike domain names, these are not
ones that are likely to be visible to users, or to be typed into browser
address bars.

>believe the community view is that it would require an RFC or the like.

RFC 6335 says that the ports and services registry is FCFS for entries
that don't ask for a port number, and the registration request is
required to have a reference that either describes it or says it's
proprietary with some minimal interface info, so it's close to
specification required.  That de facto reserves an underscore name,
and we haven't seen an unseemly gold rush.  Given the size of that
registry, I'd want a compelling reason to make the rules different.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Feb 2016 17:58:45 -0500

+1

The use of the Service registry is pretty well established now and it
is the right model.

Creating additional registries is not something that should be
encouraged unless the registry is describing a new type of resource
that doesn't have a registry already.

The proliferation of cryptographic algorithm registries is not at all
helpful. I was rather peeved that the JOSE people were allowed to
create yet another registry for algorithm label names rather than
reuse the PEM registry. When you look at code that supports multiple
cryptographic applications, there are endless layers of code managing
tagging and bagging.

I would really like to see the .well-known registry killed off as well
and folded into the services registry. If you have a Web Service with
SRV prefix _mmm then the .well-known prefix should be .well-known/mmm/

If you have two registries for the same thing you are creating
unnecessary opportunities for ambiguity and inconsistency.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 23:12:05 +0000

> morass of these labels and offers some guidance.  The discussion seemed

Yeah. Support.

I hold it true, whate'er befall;
I feel it when I sorrow most;
'Tis better to have documented this
Than never to know at all.
 (apologies to L. AT)

> Please also indicate if you are willing to contribute text, review, etc.

Contribute, review.

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 29 Feb 2016 15:32:01 -0800

On 2/29/16 3:12 PM, Warren Kumari wrote:
> On Mon, Feb 29, 2016 at 10:40 AM Tim Wicinski <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

  Per [RFC2434], IANA is requested to establish a DNS Underscore Name
   Registry, for DNS node names that begin with the underscore character
   (_) and have been specified in any published RFC, or are documented
   by a specification published by another standards organization.  The
   contents of each entry are defined in Section 4

So the registry policy I read as specification required given the
inclusion of 3rd party documents rather than RFC required.  Is that how
you read it? Should those be subject to expert review?

anyway 5226 obsoleted 2434 so I'd probably cite that.

thanks
joel

>     [email-masked] <mailto:[email-masked]>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Feb 2016 20:49:21 -0500 (EST)

On Mon, 29 Feb 2016, Dave Crocker wrote:

> private names that becomes successful is then faced with having to change all 
> existing behaviors to move to a publicly-registered name.

It is still much preferred. If you have two competing proposals both
using _foo in experimentation, you're in even more trouble. Most regular
registries work with private use. Yes, there are examples of some that
are now tainted forever, but I do believe it prudent to ensure that we
can point to some text stating the implementors made the wrong choice.

> information?  Specifically, how is that information essential to simple and 
> useful operation of the registry?

The RRTYPE listed do not include CNAME. So are CNAME's disallowed? That is
the question I want to be clear for implementors. I am not saying to
dictate whether or not those are allowed, that is indeed for the
individual documents to say. I just want some generic advise to
implementors so they don't blindly reject CNAME/DNAME based on the list
of RRTYPE's in this registry.

> Well, we know the concern about vanity use of DNS-related names is a long way 
> from silly, so alas I guess we have to worry about that.  grrr...
>

I'd say so too.

Note that as others noted, this listing could also be added to an
existing registry. I haven't thought deeply about which of the two
options should be prefered, but a discussion of this draft will
hopefully make that clear.

Paul