That last message from me was of the inadvertent "pocket" variety/apologies and please ignore. Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/cell "Luck is the residue of design" -- Branch Rickey ________________________________________ From: accountability-cross-community-bounces@icann.org [accountability-cross-community-bounces@icann.org] on behalf of Phil Corwin [psc@vlaw-dc.com] Sent: Friday, November 20, 2015 12:59 PM To: Andrew Sullivan; accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] what ICANN can't regulate (was Re: Board comments on the Mission statement) Sent from my BlackBerry 10 smartphone. Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW. Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/Cell Twitter: @VLawDC "Luck is the residue of design" -- Branch Rickey Original Message From: Andrew Sullivan Sent: Friday, November 20, 2015 12:58 PM To: accountability-cross-community@icann.org Subject: [CCWG-ACCT] what ICANN can't regulate (was Re: Board comments on the Mission statement) On Fri, Nov 20, 2015 at 11:08:58AM -0500, David Post wrote:
I had proposed a revised "sevices clause" : ICANN should not be allowed to impose -- directly or indirectly, via its contracts -- obligations on persons or entities whose only connection to the DNS is that they use a domain name for Internet communication.
A couple of people raised a problem: What about the obligation that ICANN already imposes, through the RAA, on domain holders to provide accurate WHOIS data? Am I suggesting they can't do that?
I'm sure you're not suggesting that, but that's indeed the apparent effect. And of course, in some registries, ICANN is the enforcer of other terms (because those are the terms under which the top-level domain is delegated from the root, and if the operator refuses to impose those terms then it's possible to appeal to ICANN's compliance department. Note I'm not observing this with approval, but it is a fact.) I'm also a little worried about this "use a domain name for Internet communication". There are two ways to do that. One is to connect to a service, such as a web page. That's what most people on the Internet do, and in that sense more or less everything that connects to the Internet has this connection to the DNS. Another is to register a domain name and offer a service there. I _think_ this is what we're trying to prevent ICANN regulating, but strictly speaking such operators have more than just the "use a domain name for communication" relationship, because they're all operators of DNS zones. Moreover, some such operators we certainly don't want to regulate, but they're clearly registries in some sense as well. For instance, my employer (Dyn) operates dyndns.org and other such services, where people can register they're dynamicly-assigned addresses as hostnames in a public zone. That way you can reach services in your house on your cable modem (for instance). Dyn clearly has a greater connection to the DNS than a simple user of the DNS does, here, but I don't think we want ICANN to be able to regulate such services. Dyn is also a registrar, mostly for convenience, and there's the additional problem of whether we want ICANN to be able to regulate otherwise-unregulable things just because the company or individual happens to fall under an RAA in some other part of its business. The previous concentration on services is therefore better because it specifies the thing ICANN can't regulate, rather than the person or organization. (Of course, the old formulation is bad because it catches too any such things.)
do this - but why? Where does ICANN's authority to impose these obligations on name holders (but not others) come from? It comes, n my opinion, from its ability to implement consensus policies reasonably necessary to insure the security/stability of the DNS, developed by consensus.
I am not sure, but I think I disagree. I think it comes from ICANN's ability to set terms on the names it will delegate from the zone it controls -- in this case, the root zone. In this respect, ICANN is just like any other zone operator. It just so happens that they control a zone in which, ultimately, _everyone_ has dealings with. So their policies need to be very broad. I have policies about what I'll delegate from anvilwalrusden.com, too; they turn out to be very restrictive ("things I operate"), but they're the same kind of thing. And that's ultimately where the problem comes: people have realised that the root is a place of enormous control, and in order to get their pet project imposed on the Internet they're willing to try to use ICANN's control over the root and ignore whatever damage that might do. None of this would be a live problem if ICANN hadn't decided to expand the root and use it as a mechanism to communicate policy (full disclosure: I wouldn't even have a career if they hadn't decided that), but they did. The effort in the "no regulation" sentence is, I think, an effort to put a genie back in the bottle. (The "can write contracts" sentence is, of course, necessary to cut off other side effects of the "no regulation" sentence, and I think the arguments for it would be very weak without the "no regulation" sentence.)
"ICANN should not be allowed to impose -- directly or indirectly, via its contracts -- obligations on persons or entities whose only connection to the DNS is that they use a domain name for Internet communication, except for implementation of policies for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and which are developed through a bottomup, consensus-based multi-stakeholder process and designed to ensure the stable and secure operation of the Internet's unique names systems."
Doesn't this mostly just duplicate the language already in the mission statement? (If it gets us there, I'm not going to object, but it seems strange to write the same things twice.) What about collaborating with anti-abuse people in taking down names that are the source of attacks. Is that an imposition of an obligation on someone whose only connection to the DNS is the use you describe? It's not covered by any of those restrictions, I think. If it _is_ permitted, then we're back to the slippery slope we're trying to avoid. I appreciate very much the effort to solve this, but I'm decreasingly optimistic it's even possible in general language. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6140 / Virus Database: 4450/10889 - Release Date: 10/25/15 Internal Virus Database is out of date. _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6140 / Virus Database: 4450/10889 - Release Date: 10/25/15 Internal Virus Database is out of date.