[CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

[Greg Shatan]

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.

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 <Becky.Burr at 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: +1.202.533.2932  Mobile: +1.202.352.6367 / neustar.biz
> <http://www.neustar.biz>
>
>
>
>
> On 1/15/16, 11:22 AM, "Malcolm Hutty" <malcolm at 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: +44 20 7645 3523
> >   Head of Public Affairs | Read the LINX Public Affairs blog
> > London Internet Exchange |
> >
> 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
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160115/c1cd0dd8/attachment-0001.html>