Re: [DNSOP] [[e-mail]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

[Christian Grothoff <[e-mail]>]

On 12/06/2013 09:50 PM, David Conrad wrote:
>> 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 meant 'management' in the sense of assigning names under .alt to
groups/organizations/software.  We'd effectively need another process to
decide who gets to implement a mechanism for ".com.alt".  Besides, as
was already pointed out, RFC 6761 rejected the idea of ".alt", and I
agree with Stephane that, as RFC 6761 has consensus, we should not
reopen that discussion just because we're trying to use it for the first
time.

>
> 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.  
Sure, but of course the point of having a mechanism in place is that it
should be used.  If you don't use it, even termination won't matter. 
Now, I'm hoping that this discussion will eventually turn away from the
"we shouldn't use that mechanism at all" to specific discussions about
the text of the draft.
>> 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. 
Sure, and that's of course one reason why we're trying to do this.
>> So please point me to your .onion inc
> http://www.onion.com

Actually, they are already proposing to use ".com2" and a few others
(which I wholeheartedly support), so I suspect ".onion" would be clearly
too boring for them:
http://www.theonion.com/articles/new-internet-destinations-created,28607/

> 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. 
I guess we can agree that we're both not trademark lawyers; regardless,
I suspect that IAB/IESG is going to check with ICANN lawyers on this in
due time, so maybe us engineers should focus on the engineering discussion?

>> 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"?
The GNS queries won't go to the DNS resolver hierarchy; however,
applications may use the DNS protocol initially (for legacy reasons),
and then at a 'personal' DNS resolver might decide to forward ".gnu" to
GNS and other queries to DNS.  So the question is what you consider "DNS
resolution" -- GNS resolution does not involve the DNS root zone, but
applications may talk to a GNS resolver using the DNS protocol (we have
a proxy that supports DNS-UDP with the standard query, response and
record formats).  I do not consider this using "DNS resolution", as the
distributed database that is DNS is not involved and anyone familiar
with DNS resolution would not say that the process is the same -- except
for the first UDP packet and (the format of the) final response that the
application generates/receives.

>> 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).  
Well, setting such constraints in an absolute fashion is hardly useful
anyway, I'm not sure a debate on metrics for this would be fruitful.  In
the end, yes, somebody will have to make a call on this, unless of
course nobody even is willing to say "yes" or "no" anymore (or even
hum...).  For now, we'll continue to try to integrate constructive
feedback into the draft.
>> I find that's unlikely to happen, but even if it did, great, I'd call that progress.
> An interesting view of progress.
>
Well, some people think ICANN selling thousands of gTLDs is progress;
I'm personally more interested in new technical developments.  But
business people are certainly free to disagree ;-).

Happy hacking!

Christian