Christian, On Dec 1, 2013, at 10:22 AM, Christian Grothoff <[email protected]> wrote: > Aside from that, > if there are unrelated systems, they should probably write their own RFC, as > their requirements may differ.
Personally, I'd prefer each requester of a top-level pseudo-domain (to use the term from RFC 6761) submit their own draft. A possible implication of bundling is that the applications are sufficiently similar that they could fall under a single top-level pseudo-domain. > Finally, there isn't a "generic" method, as > different pTLDs have different requirements. ".local", ".test", ".arpa" and > ".onion" don't all fit under one umbrella. Just to be clear: .ARPA is not a pseudo-domain. > And who'll manage ".alt"? Why does it matter? Does it even need management? The issue here is that without the reservation of the top-level name, there is a chance that it will be delegated via ICANN's new gTLD process. Since the names in question (.onion, .gnu, etc) aren't DNS names, the applications that will be making use of these names will presumably have their own (software-based) mechanisms to do whatever management they'll need. Are you assuming that the allocation of these top-level pseudo-domains is somehow going to prevent others from using those names as they see fit? > I could equally > suggest that ICANN should just be given ".icann", and so it becomes > "www.google.com.icann". After all, who put them in charge? See RFC 2860. > Again, this is NOT a standardization > process, this is an _informational_ draft/RFC that documents what is > happening. It's a little more complicated than that. The use of the mechanisms in RFC 6761 explicitly preempt strings from use in the DNS. By my reading of the existing MoUs between the IETF and ICANN, ICANN, as the IANA functions operator, must abide by that preemption or risk termination of the MoU. > We'll continue to use ".onion", ".i2p", and ".gnu". Users > do not need someone's blessing to do so, but from a technical point of > view it makes a lot of sense to document these pTLDs and give guidance > to operators. That's what we're trying to do with the RFC, we're not > really asking for "permission". Understood. However, if the names aren't reserved, I suspect there is an increased likelihood that the names will be acquired under the ICANN new gTLD program at some point. > So please point me to your .onion inc http://www.onion.com > or .i2p inc http://impossible2possible.com/home > before making up some straw man argument. According to USPTO, there are 470 records that result from a search of the string "onion", 4 for "i2p", and 35 for "gnu", the latter including a clothing manufacturer whose trademark is the bare word "gnu". I am not a lawyer or even that well versed in ICANN's trademark clearinghouse, but I suspect it would be a mistake to blithely dismiss this particular issue. > The case is even stronger for GNS, where DNS queries can even be > intercepted at the network layer by a dedicated DNS2GNS gateway. Sorry, I'm confused. The point of the RFC 6761 reservation scheme is that the names are _NOT_ intended for use in DNS resolution. What do you mean by "DNS queries can be intercepted at the network layer"? > As for the technical side, I also don't quite buy your arguments, as > they excessively conflict with usability and seem to be purely based > on the idea that this would set a precedent that would then allow > anyone to "just" write a big system (Tor, GNUnet and I2P are all > projects with about 300,000 LOC) and an RFC and we'd end up with > ten billion special-use reserved pTLDs. Part of my concern is that RFC 6761 provides insufficient (IMHO) constraint on its use. It doesn't have any requirements for system size, lines of code, number of users, etc. It leaves the decision up to a subjective evaluation on the part of IESG (unless it is a standards action). > I find that's unlikely to happen, but even if it did, great, I'd call that > progress. An interesting view of progress. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
