What is the point of having a MoU that names may need to be assigned in the root namespace if there cannot be a entry added to the root namespace if there is a technical need to it?
.onion names were never supposed to be looked up using the DNS protocol so there is no need to the entries to exist. Any DNS lookups should return NXDOMAIN to the client. .homenet on the other had uses DNS as the resolution protocol. Existing tools should just work. Part of making them work is to provide a break in the DNSSEC chain of trust. There is only one way to do that. As for the name it needs to be in *stable* place in the namespace. We have exactly two of these today. The root and arpa. The homenet working group decided that the root was a more appropriae place than arpa. Mark In message <b1f8c6d6-7160-4bb0-b8a4-39d0027a5...@gmail.com>, Suzanne Woolf write s: > Paul, > > Id like to make sure I understand your comment, as Im not completely sure > it addresses mine. > > As I read your response, youre 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 dont think > its 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; theyre interchangeable what > matters is that theyre unique within the relevant namespace. The root of > a hierarchical namespace is mathematically special in a few ways, but I > havent 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; Im 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 Im asking, Im 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, Id 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. > > Its 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
