At 06:07 PM 1/15/2016, Greg Shatan wrote:

This is not "regulatory authority" at all. It the enforcement of a bilateral agreement between ICANN and the registry operator. I think this is a conflation of contractual enforcement and regulation, which are two different things. SNIP

Let me add one brief comment here before I run out the door, and then try to give a more detailed comment to this very interesting thread when I can compose a longer note. The problem we're wrestling with is that some "contractual enforcement" is, in fact, an exercise of something that closely resembles "regulatory authority," and we're trying to define where that line is. At one extreme, let's say ICANN enters into a contract with its office supply company - Staples - and it gets Staples to promise various things - a 25% discount, that it won't employ non-union labor, that it will deliver on Sundays, etc etc. Nobody (I wouldn't think) would have a problem with ICANN enforcing those contract terms, even without any "community consensus" on the matter, and without any need to show that doing so is within ICANN's narrow mission. That's the "contractual enforcement" side. At the other end of the spectrum, if ICANN says to a gTLD applicant that as a condition of entry into the root, it must charge its customers such-and-such, or use only union labor, or have a particular kind of "license," then it's engaged in something that looks a LOT like "regulation," because it has monopoly control over a valuable resource and its "contract terms" are, in effect, rules (or "regulations") that you must comply with (or leave the space entirely). And for those, ICANN should, in my opinion, be tightly bound to abide by the restrictions in the mission. David

If a PIC is vague that there is no reasonable understanding of its meaning, that would be a problem. I suppose it's possible such PICs exist, but they have to be a small minority of the overall PIC universe; examples of such PICs would be appreciated. Putting such "edge cases" aside, it's completely appropriate for ICANN to expect registries to comply with PICs and for ICANN to enforce compliance with those PICs just as they would any provision of the contract. Typically, there is a very high bar to voiding provisions of contracts, and even then there is preference to "blue pencil" them (i.e., the court rewrites them to be enforceable) rather than voiding them completely.

On Fri, Jan 15, 2016 at 5:53 PM, Burr, Becky <<mailto:Becky.Burr@neustar.biz>Becky.Burr@neustar.biz> wrote: I think this is a very useful discussion getting to the heart of the matter, so I would really like to encourage others to participate.

Question - you say

In other words, the idea that ICANN can "enforce" PICs without itself determining the standards that PICs seek to enforce simply doesn't stand up to scrutiny. As soon as ICANN is called on to enforce a PIC against a registry, it must necessarily assert that a particular kind of action is required by the PIC, and distinguish it from the action actually undertaken that the registry asserts to be sufficient. This is the core of regulatory activity. I have no problem whatsoever with ICANN engaging in this kind of regulatory behaviour for matters within its limited Mission, but if we invite ICANN to take this on for an unlimited range of objectives claimed to be in the public interest, we are essentially investing ICANN with a global policing power.

Ok, but can ICANN enforce the part of the contract that says you can¹t register in the domain unless you are licensed by an appropriate authority? I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I¹m grasping for a principle here.

J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: <tel:%2B1.202.533.2932>+1.202.533.2932Â Mobile: <tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz <http://www.neustar.biz>

On 1/15/16, 11:22 AM, "Malcolm Hutty" <<mailto:malcolm@linx.net>malcolm@linx.net> wrote:

...

Becky,

I agree that the existence of community applications has been an important part of the new gTLD process. I don't think the small limitation on the Mission we have agreed in the Third Draft Report would or should prevent ICANN creating new community TLDs in the future.

You give the example of .bank. I don't see anything in the Mission that inhibits ICANN in any way from saying that .bank has been created for the exclusive use of recognised banks, and that the only banks it recognises for this purpose are those with an appropriate banking license under applicable law.

This is quite different from regulating the behaviour of banks. If ICANN went on to say that any bank must report cash transactions over $10,000 to the US treasury, and any bank refused to do this it would take their domains away, then that would be an example of ICANN regulating the behaviour of banks, not of it identifying a particular user community. Though opponents of a limited Mission can try to blur this distinction with cleverly-constructed corner cases, I think this distinction is quite clear enough to be workable and to be objectively employed by an independent reviewer.

Turning to your example of environmental activists, I think it clear that if ICANN sets rules requiring disclosure of certain environmental practices then that is a clear example of behavioural regulation, that I don't think ICANN should be getting into. By contrast, if that registry promised to have a stakeholder council and then disbanded it, I think this would be a case of changing the organisational structure of the registry, no different from disbanding a customer complaints division (and no less objectionable).

In short, I think community TLDs should be allowed for identifiable communities; I don't think this carries any necessary implication that ICANN should get into the business of seeking to regulate the behaviour of the members of those communities (except as justified by reasons that actually are part of ICANN's Mission, of course).

To those who disagree, I would like to point out the inevitable consequences of going down this route.

Some say that the registry should be "made to uphold" these commitments, while still thinking that this doesn't require ICANN to begin creating such behavioural rules itself. I think this profoundly mistaken.

Suppose that a registry, such as for .eco, makes a commitment to enforce certain behaviour by its users, such as the publication of relevant environmental reports. As long as nobody is objecting, the fact that ICANN has contracted with the registry to do this doesn't really have any effect. The only time it matters is when someone complains.

The only way ICANN gets involved is when someone comes to ICANN and says ".eco promised to make their users disclose environmental reports and they're not doing so. Please enforce this requirement on the .eco registry".

What is ICANN supposed to do with this complaint? Proponents of PICS seem to think there is some magical wand that ICANN waives to bring .eco into compliance with its contract. This is nonsense. What actually happens is that ICANN contacts the registry and says "We've had a complaint you're not requiring publication of relevant reports, is this true? Please provide evidence that you are doing as you previously promised.". Most likely, the registry replies that they are in compliance with their commitment. The evidence offered, however, may well be open to differing interpretations: for example, .eco may have placed an extremely narrow definition on what constitutes a "relevant environmental report".

What is ICANN supposed to do next? On the one hand, it has a complainant, who can show that the registry is not doing certain things, and argues that those things are required by the PIC. On the other, it has a registry, which can show it is doing other things, and argues that those things are sufficient to discharge the promise it had previously made in the PIC.

It seems to me that there are really two options for how to proceed:

i) ICANN could be so deferential to the registry interpretation as to accept its position pretty much automatically: so long as the registry didn't simply admit non-compliance, and its claim to compliance wasn't manifestly ridiculous, ICANN could simply stop there. But what is the value in requiring ICANN to "enforce" PICs to such a limited standard? If that's all we're going to do, why not save ourselves a lot of bother (not to mention raising expectations from some stakeholders only to inevitably disappoint)?

ii) Alternatively, ICANN could investigate the case and come to its own view as to whether what the registry has done is sufficient to discharge its contractual obligation. However it can ONLY do that by first forming a view as to what the PIC requires. So in the putative case, ICANN could only enforce a requirement to make reasonable environmental disclosures if it itself determines what it considers constitutes a reasonable environmental disclosure. Likewise it can only enforce a commitment to prevent harassment by setting standards for what constitutes harassment, it can only enforce a commitment take down copyright infringing material by deciding whether particular publications infringe copyright, and it can only enforce a commitment to prevent access to certain web sites by minors by deciding both what age constitutes a minor, and what are acceptable means for identifying them and for excluding them from access.

In other words, the idea that ICANN can "enforce" PICs without itself determining the standards that PICs seek to enforce simply doesn't stand up to scrutiny. As soon as ICANN is called on to enforce a PIC against a registry, it must necessarily assert that a particular kind of action is required by the PIC, and distinguish it from the action actually undertaken that the registry asserts to be sufficient. This is the core of regulatory activity. I have no problem whatsoever with ICANN engaging in this kind of regulatory behaviour for matters within its limited Mission, but if we invite ICANN to take this on for an unlimited range of objectives claimed to be in the public interest, we are essentially investing ICANN with a global policing power.

Some may be happy to see ICANN go down that route. I would not: I think it has neither the capacity nor the legitimacy. But I am also worried by those who have managed to convince themselves that it is possible to enforce PICs for an unlimited range of purposes without itself becoming embroiled in setting the rules for those purposes. Those people are, I believe, simply kidding themselves.

Malcolm.

-- Â Â Â Â Â Â Malcolm Hutty | tel:

<tel:%2B44%2020%207645%203523>+44 20 7645 3523

...

  Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | <https://urldefense.proofpoint.com/v2/url?u=htt p-3A__publicaffairs.linx.net>https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=F3FlEVYbysKtCNonZguZbv90urP8qDBk_08KcwSbnzQ&s=ksR3GCVlhY-LMF3l9w mgX_POXp3jz25-xZ5f0KkUo-E&e=

         London Internet Exchange Ltd     Monument Place, 24 Monument Street, London EC3R 8AJ

     Company Registered in England No. 3137929     Trinity Court, Trinity Street, Peterborough PE1 1DA

_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************