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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf