Paul, I’d like to make sure I understand your comment, as I’m not completely sure it addresses mine.
As I read your response, you’re willing to forgo a root zone entry, and the DNSSEC behavior the WG has reached consensus it wants, in order to have an entry in the special use name registry for “homenet”. Is that correct? If so….I see your point and I hope the IESG is listening, as I don’t think it’s the HOMENET WG consensus; as written, this draft asks for both a single-label name and certain behavior with respect to DNSSEC, which means asking for an entry in the root zone. A little more, below. > On Mar 21, 2017, at 9:54 AM, Paul Wouters <p...@nohats.ca> wrote: > > 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. The requirement for a name that will resolve in the DNS? Sure. The requirement for a single label/TLD that will resolve in the DNS root zone? Dramatically less clear to me, and nothing you say above is specific to the root. From the perspective of the DNS protocol, which string is used to fill a domain name slot is mostly immaterial as long as strings are generated and parsed according to the recognized rules; they’re interchangeable— what matters is that they’re unique within the relevant namespace. The root of a hierarchical namespace is mathematically special in a few ways, but I haven’t seen a case that the name used by HNCP requires any of them. At the same time, the root of the DNS namespace is quite clearly special in the administrative sense; I’m trying to separate the two sets of considerations. >> 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. For the purpose of the question I’m asking, I’m indifferent between the strings “.home" and “.homenet”. The policy problems with “.home" are significantly larger than with “.homenet”, but asking for a root zone entry at all is a significant problem for the current draft, no matter what string is involved. > 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. Again, I’d like to make sure the problem I was trying to address is clear. Asking for a delegation in the root zone, particularly an unsigned one, as this document currently does, *will* essentially require "figuring out a new IETF/ICANN process, something that can take years.” This is true no matter what string is being requested. It’s simple fact that a name elsewhere in the tree does not have the same obstacle. Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
