Hi, No hats, except DNS/names geek who has spent a lot of time talking with policy people about why and how the root zone is (and isn’t) special.
> On Mar 20, 2017, at 3:38 PM, Russ Housley <hous...@vigilsec.com> wrote: > > Ted: > >> There are other processes for adding names to the root zone. In my opinion, >> using the special-use TLD registry as a means of putting a name, even one >> that has a different scope and use case, is an end run around that process. >> >> So it seems to me that your position is not that it's inappropriate for a >> name to both be registered in the root zone and in the special-use names >> registry, but rather that two processes would have to be followed in order >> for this to happen. Is that a reasonable interpretation of what you have >> said? > > No. In my opinion, the special-use TLD registry is not appropriate for the > assignment of any name that will appear in the root zone. As I said in my > first note, my view is that TLDs assigned through the special-use registry > MUST NOT be published in the root zone. > > If you have a domain names that is to appear in the root zone, then the > existing process ought to be used for that to happen. I’d probably state my version of this argument slightly differently: I think Russ is interpreting draft-ietf-homenet-dot-03 as unilaterally imposing a requirement on another body, possibly in violation of that body's own policies and processes, or at least creating a need for them to respond outside of established process. In this case, “the existing process” simply doesn’t cover what’s being asked for, and extending the existing process to cover what’s being asked for cannot unilaterally be done by the IETF as a body. This creates an external dependency and a need for the IETF to attempt to resolve it— an attempt that may well end in disappointment. A “special use name” is NOT necessarily a single label name. There is *no* necessary connection between “special use name” and “TLD,” any more than there’s a necessary connection between “special use name” and “the string has the letters of my pony’s name in it". One hypothetical string may be better for a specific use than another, but the characteristics of the string required are protocol-specific (including the significance of the dot), not intrinsic to the registry or to domain names generally. To add some color to the problem being created here, I’ll suggest looking at the question we’d be asking if the request were not for “.homenet,” but for “.homenet.arpa” or “.homenet.foo” (where “foo” is a TLD in the current DNS root zone). If the request were for “homenet.arpa,” we wouldn’t be having this conversation at all. The “.arpa” TLD is under the administrative control of the IAB, there’s existing process for asking the IAB to add a name to .arpa (signed or not, delegated or not), and there’s existing process within the IETF community for providing input to IAB decisions on the subject (see RFC 3172). Personally I’d be happy to advocate for the IAB to approve adding an unsigned delegation for .homenet.arpa to the .arpa zone; it seems to me it wouldn’t even require much change to the draft to satisfy RFC 3172, Sec. 3. If the request were for “homenet.foo,” we’d be having a different conversation about the implications, but we still wouldn’t be creating a new external process dependency. Operationally speaking, there are literally hundreds of TLDs whose existing policies would allow for the registration of “homenet” as a second level name. In my view it would be unwise to use one when the .arpa alternative is available, because future changes to the rules for such domains are outside of the control of the IETF and the standards process, but at least we wouldn’t be asking for an entirely new process from an external actor under no obligation to give us one. I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to users. I *strongly* suggest that if this document is to be used as justification to create an entirely new process for updating the root zone, coordinated between the IETF and the external body that controls the root zone, the justification should be *much* more explicit. Suzanne
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
