Re: Services and top-level DNS names

[Karl Auerbach <[e-mail]>]

John C Klensin wrote:

> I'm going to try to respond to both your note and Mark's, using
> yours as a base because it better reflects my perspective.

I sense that many of your concerns are well grounded.  And I find it 
interesting that the concerns come not so much from DNS as a system and 
protocol in and of itself but rather from the practices that have 
developed in the ways that DNS is used.

I see that you consider this situation urgent.

But I think that even your sense of urgency may underestimate the 
exigency of the need to coming up with an answer that can be labeled as 
a standard or BCP.

It is my feeling that pretty much every company in the Fortune 1,000,000 
is going to want to go for their name as a TLD.  And the marketing 
people at those companies will exert strong internal pressures to have 
every service - from web to email to SIP to whatever - using only the 
single TLD/company name.

As for contracts - ICANN should, if it is not doing so aready, clearly 
articulate a requirement that TLD operators clearly agree to follow 
written and broadly practiced internet technical standards that pertain 
to DNS.  (I've gone further and suggest that this ought to be ICANN's 
sole criterion for accepting [which does not mean granting] an 
application for a new TLD, but that's another discussion for another day.)

But contracts only go so far.  First of all there is the issue of the 
ccTLDs - they tend to operate outside of the ICANN contractual hierarchy.

Then there is the issue of enforceability of contract provisions.  ICANN 
seems to have an institutional fear of something called "third party 
beneficiary" status.  This is a thing that a contract can grant to 
certain non-parties so that those parties can step in and demand that 
certain contract terms be enforced against one or both of the parties 
even if the parties themselves are not holding one another to account.

In other words, unless the contracts give these rights, the IETF and 
others might have to stand on the sidelines and able to do no more than 
gnash their teeth in frustration.

ICANN has not demonstrated that it is quick to take up its sword to 
enforce its contractual rights when users are being harmed - For 
instance it kinda took dynamite to get ICANN to notice, much less to 
react to the developing RegistryFly mess.

Also you mentioned that the Brooklyn Bridge park folks might want to sue 
ICANN rather than the people who register "brooklynbridgepark" as a TLD. 
  My sense is that this might be a poor strategy because ICANN might be 
able to excuse itself as merely acting as a bookeeper and recommending 
that you sue the people who registered the TLD once they show, through 
actual use, that you have suffered some concrete harm.  Also, ICANN 
operates with a somewhat uncertain shield that exists because ICANN is 
able to operate in that vague middle ground between being a private 
entity and an arm of the US government.  (It is this same uncertainty 
that may explain why ICANN has so far avoided squarely facing the 
restraint of trade question in the US or elsewhere.)

Also, you use the word "property".  That's a word so full of different 
meanings to different people in different places that it tends to cause 
more trouble than it is worth.  I might suggest that we look at this 
situation as one in which the various actors have various explicit 
rights (contractual or otherwise) and duties towards certain domain 
names.  That way we can deal with these things with clarity rather than 
getting buried under the emotional baggage that comes from the word 
"property".

With regard to that final point about requiring only delegation and glue 
records - what about things like LOC and some of the TXT and other 
records for things like DKIM, SPF, SIP, etc?  My point here is that this 
might not be as simple to define as we might initially think.

But the boiler in ICANN's locomotive is coming up to pressure and we can 
expect ICANN's new TLD train to start chugging fairly soon - so answers 
may be needed more at IETF 1988 speed rather than IETF 2008 speed.

		--karl--
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf