Re: [DNSOP] [[e-mail]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

[Joe Abley <[e-mail]>]

On Monday 2 December 2013 at 13:13, Ted Lemon wrote:
> On Dec 2, 2013, at 12:58 PM, Joe Abley <[e-mail] (mailto:[e-mail])> wrote:
> > > This seems like a non-sequitur, since RFC 5855 refers to a function that RFC 3172 specifically mentions.
> >  
> > I was perhaps being a little opaque; RFC 5855 specifies names under .ARPA for hosts (A.IN-ADDR-SERVERS.ARPA, etc.) This seems to be in contradiction to the text you quoted.
>  
> Hm, okay, but that seems more like infrastructure than it does like a name. Every domain name is a name in that sense.

Perhaps I'm being over-pedantic, but the 3172 text refers to "naming hosts" and "host names" have specific meaning that do not apply to every domain name.

I suspect the answer is that 3172 is a little vague in its direction here, and arguably opaque about the motivations for that direction. This makes 3172 a poor choice for justification of use (or not) of names under ARPA, I think; better to reduce its impact to "IAB approval required" and not second-guess what the IAB might think.
> > > > I think you're sharing personal opinion rather than citing fact ("make sense"). The .local convention happened to be adopted by Apple for use in a DNS-like protocol, and was documented (and the IN-class top-level label reserved) later. They could equally well have adopted .local.arpa or .local.apple.com (http://local.apple.com).
> > >  
> > > So, in what sense is MDNS "internet infrastrucure?"
> >  
> > It's a protocol that is used on the Internet. It's a protocol that is used to locate and obtain addresses for hosts connected to the Internet. I appreciate that it has a restricted scope, but in practical terms so does everything.
>  
> Right, but a protocol is not infrastructure. The name servers that serve IN-ADDR.ARPA are infrastructure. IN-ADDR.ARPA is infrastructure. MDNS is a protocol for discovering hosts on the local wire. It isn't "internet" and it isn't "infrastructure"—it exists to deal with a lack of infrastructure.

... by providing infrastructure? :-)
  
I don't want to prolong what (it turns out) is a largely semantic disagreement, so I'll cut down to:
> > The reason my knee is jerking is that I think in general it's a mistake to assume that a unique top-level label is the only practical recourse for protocol designers looking for stable, dedicated namespaces. There are lots of other options, several of which mentioned in this thread, and one size does not fit all.
>  
> I think that's a valid point. However, the proposal has been made to register some existing uses of special-use TLDs, so it's not the case that we are dealing with a blank sheet of paper here. The number of special-use domains being discussed is fairly small, and they are names that likely would not see heavy conflict with proposed ICANN uses of TLDs.
>  
> So given that RFC 6761 does in fact represent IETF consensus at the moment, I think it's reasonable to consider allocating these names. If ICANN comes back and says "we really don't think you should do this because of X," I think we ought to take that seriously.
>  
> But we are not there now, and I don't know that we will get there. So I don't think it's a particularly useful point to raise in terms of _the IETF's_ consideration of this proposal.  
I think this approach seems sane and good.


Joe