Re: Services and top-level DNS names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]