On Dec 2, 2013, at 11:29 AM, Joe Abley <jab...@hopcount.ca> wrote:
>> RFC 6761 has IETF consensus, and does not propose adding new namespaces
>> under .arpa, but rather at the top level. Here's what RFC3172 says on the
>> topic of .arpa:
>>
>> This domain is termed an "infrastructure domain", as its role is to
>> support the operating infrastructure of the Internet. In particular,
>> the "arpa" domain is not to be used in the same manner (e.g., for
>> naming hosts) as other generic Top Level Domains are commonly used.
>
> Perhaps 3172 needs to be updated to reflect current IAB practice, then. It's
> not hard to find examples of names under ARPA which contradict the text you
> quoted (e.g. see RFC 5855).
This seems like a non-sequitur, since RFC 5855 refers to a function that RFC
3172 specifically mentions.
>> Aside from the purely practical matter that having special domains live
>> under .arpa would be more complicated to implement,
>
> This feels like an over-general pronouncement that can't hope to be accurate
> in all cases. Why is it more complicated in the general case? More
> complicated than what?
If special-use names are at the top, then you can just look at the terminal
label to see that you need to use a different protocol to resolve names under
the special-use name. If special-use names are not at the top, then you have
to have special code that grovels through the labels doing pattern matches.
This is clearly more code; you can argue that it's not much more code, but I
think there's a reason why apple chose not to use local.apple.com, for example.
Aside from the additional implementation complexity, putting these domains
under some other TLD makes them longer to type. In the case of domains that
are not intended to be typed, this isn't a problem, of course.
>> it doesn't make sense. Consider .local—our main example of a special-use
>> domain. Would it make sense for .local to be under .arpa? I don't think so.
>> .local is specifically not "internet infrastructure." It isn't even DNS.
>> It's an escape from the DNS namespace, with different semantics than domain
>> names in the DNS.
>
> 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.
So, in what sense is MDNS "internet infrastrucure?"
> I'm not complaining about Apple's innovation here, or their decision to
> document it at the IETF. But I don't think it's sufficient to assert that
> alternatives would not have made sense without justifying why that is so.
No argument here, but I thought that's what I was doing.
>> The other proposed special uses are similar. Putting them under .arpa might
>> be _expedient_, because it avoids the whole change control question, but
>> that's pretty much the only way I can think of that it makes sense.
>
> It doesn't avoid the whole change control question -- it just reduces the
> change control to one with a single, uncontentious decision point (the IAB).
> By contrast, the business of identifying reserved strings (and enforcing
> their non-delegation for other purposes) in the root zone is fraught with
> administrative ambiguity.
It's not at all clear to me that this is an issue, and if it is, we should
figure that out. I would like to think that ICANN understands that there is a
change control conflict here, and is willing to work with us to make sure that
we don't step on each other's toes. Clearly it's incumbent upon the IETF not
to be frivolous in the use of RFC 6761. But I have not heard from anyone that
the IETF should not ever use RFC 6761, and that seems to be the position you
are advocating at the moment.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
