On Tue, 21 Mar 2017, Suzanne Woolf wrote: [also speaking as individual only]
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.
That seems good enough for me. The problem of DNS being the only real name space for endusers is very well understood. And I still regularly have to refind my printer based on checking my dhcp server logs, something not available to regular endusers. The requirement is very real.
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.
This .home / .homenet issue has already been going on for a very long time. The longer we wait with resolving this issue, the worse the deployment situation will be of software mixing .home vs .homenet. Suggesting we postpone .homenet while figuring out a new IETF/ICANN process, something that can take years, would basically doom this rename and install .home as the defacto standard. Once this new process would be completed, it would lead to new breakage, and the new software would be forced to look into both domains, or if the install base is big enough for .home, would be better of ignoring a new .homenet altogether. As for requiring an insecure entry in the root, I'm still not convinced it buys us that much. Resolvers on the stub that bypass the local DHCP supplied DNS servers need to be modified anyway to use the local DNS servers to request .homenet entries, whether they support DNSSEC or not. So that leaves DNSSEC capable DNS resolvers that use the DHCP supplied servers as forwarder entries in need of such an unsigned entry only. I do think that such DNSSEC capable software tends to be maintained by the OS and could gain special handling of the .homenet domain. And if not, I seriously wonder if those enduser DNS stubs/servers implement RFC-5011 well enough to survive the upcoming KSK rollover. Or any other homenet protocol update in the future. So I would say an insecure delegation would be nice to have but not required. And if it would shave of a year of creating a new process between IETF, ICANN and the MoU, then I'd say for the deployment as a whole, it would be better to get the Special Use Domain ASAP without an entry in the root. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
