Thanks for the quick followup, David... > On Mar 25, 2016, at 1:04 PM 3/25/16, David Conrad <[email protected]> > wrote: > > Ralph, > > On Mar 25, 2016, at 8:33 AM, Ralph Droms <[email protected]> wrote: >> I'm responding here with none of my various hats on... > > Me too. > >> RD>> I think it's more correct to write that RFC 7686 defines ".onion" >> as a Special-Use Domain Name, which takes it out of the Domain Name >> space. > > No. It is still a domain name in the sense that it is within the universe of > identifiers under a singly rooted namespace used on the public Internet (the > "domain name namespace"). What it is not is a part of the subset of that > namespace that is resolved using the DNS protocol/infrastructure.
Yes, you're right. I understand and actually meant to write what you wrote... >> RD>> Similarly, why are .uucp and .bitnet "bad precedents"? > > They are bad precedents because of the challenges they caused for network > operations. Specifically, the fact that they were local policy considerations > meant that references to a .bitnet or .uucp name within one administrative > domain would work but would fail when that reference escaped that > administrative domain (e.g., in a cc line of an email address). In my view, > this is essentially the same problem that led to the IAB publishing 2826. One > of my concerns with 6761 is that it can encourage recreating that > operationally challenging world without explaining the inherent risks. Thanks for that explanation. I think it would be helpful to include it in any future revs of the problem statement. > >> I think the common assumption is that everything >> not lised in the Special-Use Domain Names registry is in the DNS name >> space, which would make the Registry a complete catalog. > > I disagree. I believe the domain name namespace can be broken down into: > > 1. In the DNS (exists within the root zone) > 2. Not in the DNS (exists within the special use registry) > 3. Not defined (everything else) > > The primary issue I have with 6761 is that while it is relatively clear who > the authority is for (1) and (2), it does not provide a clear answer about > the authority for (3) or how a name gets put into (1) or (2) when taken in > the context of 2860, section 4.3. OK, I agree with your 3 categories. I think you elaborated on the observation about authority for (3) and process for moving a name to (1) or (2) below... > >> By design, RFC 6761 makes no >> statement about a specific WG or evaluation body or process. > > Which is, of course, one of the key problems. It results in an undefined > decision process dependent on the individual subjective evaluation of IESG > members. Given the economic, political, and social implications of the > naming hairball, this seems like a really bad idea to me. It is certainly a key issue and I hope we can get a focused discussion going about whether there is consensus that a more well-defined decision process is needed and, if so, what are the specifics of that process. - Ralph > > Regards, > -drc > (speaking only for myself) > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
