Hi, On Wed, Jan 20, 2016 at 12:30:40AM +0000, Malcolm Hutty wrote:
and that item 1 is a legitimate choice as an exercise of ICANN's authority within its Mission, and that (2) is an objectively reasonable definition for ICANN to adopt as part of implementing that choice.
As I tried to state on the call today (alas, I think I was not entirely coherent, so my apologies), I think even the above takes us a little too far. I don't think Malcolm and I disagree too much here, but I'm leery of the ratholes lurking under the cover "objectively reasonable definition". But I don't think we need to rely on it. I believe that the reason ICANN has something to enforce in gTLD contracts is because ICANN is making a decision [1] about delegating a name from the root zone. ICANN makes that decision based on information it has before it, including the various operational constraints that an applicant is offering to undertake. Because this is a matter of a contract between ICANN and some other party, ICANN has the right and (at least arguably) responsibility to enforce the terms of the contract. So, imagine someone applies for the TLD foobar and claims that every registrant beneath foobar must bar foos, and must be able to show that by virtue of the baz certificate they get from Bob's Bait Shop and Notary on Main Street. Imagine that ICANN agrees to this and delegates on that basis. In that case, that's what ICANN has to enforce. Note that what ICANN is enforcing is someone else's commitments on the basis of which ICANN did something (decided to permit a delegation). For that state to persist, ICANN needs to enforce the terms, or else admit that its policy control over the root zone is meaningless because people can offer anything and then just change their mind later. I believe the tightened mission and new powers nevertheless conspire to discourage such agreements. First of all, because of the clarified mission, ICANN can (and should) use judgement to refuse to embroil itself in some of these kinds of TLD schemes. The more the scheme looks like, "We're going to impose rules on what people can do all the way down the tree," the more ICANN should say, "We're not interested." If a term can't effectively be enforced (and "carries down the tree" rules can't be, in effect, without dedelgating the top of the tree), ICANN should stay away. More generally, anything that takes ICANN far afield of its narrow mission should be avoided. But second, ICANN the corporation doesn't need to do that alone any more, because the empowered community gives the corporation the foundation from which to refuse such requests. "We'd love to, but our community doesn't want us to do those sorts of things and they wrote the bylaws to prove it." And if ICANN the corporation does not act that way, and the community objects, the community will now have the tools necessary to reign in such regulatory and contractual adventures. "Oh," you may say, "But what if the community supports the foo barring, and discriminates against foos and is generally bad?" I agree that is a danger, but I claim there is no set of rules we could write that will avoid that danger. The entire accountability effort depends on the empowered community. If the community decides to neglect its responsibilities in this area, then it will be impossible to ensure such decisions don't get out of hand, regardless of what the decisions are. Best regards, A [1] The mechanics of who actually performs the delegation by putting the string in a zone file are not relevant to this. As far as I know, nobody disputes that ICANN gets to make the decision. -- Andrew Sullivan ajs@anvilwalrusden.com