On Monday 2 December 2013 at 13:13, Ted Lemon wrote:
> On Dec 2, 2013, at 12:58 PM, Joe Abley <jab...@hopcount.ca
> (mailto:jab...@hopcount.ca)> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
