<html>
<body>
At 06:07 PM 1/15/2016, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">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<br>
</blockquote><br>
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.<br><br>
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. <br><br>
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.<br><br>
That's the "contractual enforcement" side. At the other
end of the spectrum, if ICANN says to a gTLD applicant that <i>as a
condition of entry into the root</i>, 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 <i>must</i> 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. <br>
<br>
David<br><br>
<br><br>
<blockquote type=cite class=cite cite="">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.<br>
<br>
On Fri, Jan 15, 2016 at 5:53 PM, Burr, Becky
<<a href="mailto:Becky.Burr@neustar.biz">Becky.Burr@neustar.biz</a>
> wrote:<br>
<dl>
<dd>I think this is a very useful discussion getting to the heart of
the<br>
<dd>matter, so I would really like to encourage others to
participate.<br><br>
<dd>Question - you say<br><br>
<dd>In other words, the idea that ICANN can "enforce" PICs
without itself<br>
<dd>determining the standards that PICs seek to enforce simply doesn't
stand<br>
<dd>up to scrutiny. As soon as ICANN is called on to enforce a PIC
against a<br>
<dd>registry, it must necessarily assert that a particular kind of action
is<br>
<dd>required by the PIC, and distinguish it from the action actually<br>
<dd>undertaken that the registry asserts to be sufficient. This is the
core<br>
<dd>of regulatory activity. I have no problem whatsoever with ICANN
engaging<br>
<dd>in this kind of regulatory behaviour for matters within its
limited<br>
<dd>Mission, but if we invite ICANN to take this on for an unlimited
range<br>
<dd>of objectives claimed to be in the public interest, we are
essentially<br>
<dd>investing ICANN with a global policing power.<br><br>
<dd>Ok, but can ICANN enforce the part of the contract that says you
can¹t<br>
<dd>register in the domain unless you are licensed by an appropriate<br>
<dd>authority? I understand that having rules for allocating new
TLDs is<br>
<dd>reasonably necessary to ensure the stability and security of the DNS,
but<br>
<dd>I don¹t understand how enforcing that the registry licensing
requirement<br>
<dd>is (in and of itself) UNLESS you say that the delegation
(community<br>
<dd>preference) was made on the basis of that commitment, and enforcing
the<br>
<dd>commitments underlying the delegation decision is an inherent
requirement<br>
<dd>of the policy itself. I¹m grasping for a principle here.<br><br>
<br><br>
<br>
<dd>J. Beckwith Burr<br>
<dd>Neustar, Inc. / Deputy<br>
<dd>General Counsel & Chief Privacy Officer<br>
<dd>1775 Pennsylvania Avenue NW, Washington D.C. 20006<br>
<dd>Office: <a href="tel:%2B1.202.533.2932">+1.202.533.2932</a>Â
Mobile: <a href="tel:%2B1.202.352.6367">+1.202.352.6367</a> /
<a href="http://neustar.biz">neustar.biz</a><br>
<dd><<a href="http://www.neustar.biz/" eudora="autourl">
http://www.neustar.biz</a>><br><br>
<br><br>
<br>
<dd>On 1/15/16, 11:22 AM, "Malcolm Hutty"
<<a href="mailto:malcolm@linx.net">malcolm@linx.net</a>>
wrote:<br><br>
<dd>><br>
<dd>>Becky,<br>
<dd>><br>
<dd>>I agree that the existence of community applications has been
an<br>
<dd>>important part of the new gTLD process. I don't think the
small<br>
<dd>>limitation on the Mission we have agreed in the Third Draft
Report would<br>
<dd>>or should prevent ICANN creating new community TLDs in the
future.<br>
<dd>><br>
<dd>>You give the example of .bank. I don't see anything in the
Mission that<br>
<dd>>inhibits ICANN in any way from saying that .bank has been created
for<br>
<dd>>the exclusive use of recognised banks, and that the only banks
it<br>
<dd>>recognises for this purpose are those with an appropriate
banking<br>
<dd>>license under applicable law.<br>
<dd>><br>
<dd>>This is quite different from regulating the behaviour of banks.
If ICANN<br>
<dd>>went on to say that any bank must report cash transactions over
$10,000<br>
<dd>>to the US treasury, and any bank refused to do this it would take
their<br>
<dd>>domains away, then that would be an example of ICANN regulating
the<br>
<dd>>behaviour of banks, not of it identifying a particular user
community.<br>
<dd>>Though opponents of a limited Mission can try to blur this
distinction<br>
<dd>>with cleverly-constructed corner cases, I think this distinction
is<br>
<dd>>quite clear enough to be workable and to be objectively employed
by an<br>
<dd>>independent reviewer.<br>
<dd>><br>
<dd>>Turning to your example of environmental activists, I think it
clear<br>
<dd>>that if ICANN sets rules requiring disclosure of certain
environmental<br>
<dd>>practices then that is a clear example of behavioural regulation,
that I<br>
<dd>>don't think ICANN should be getting into. By contrast, if that
registry<br>
<dd>>promised to have a stakeholder council and then disbanded it, I
think<br>
<dd>>this would be a case of changing the organisational structure of
the<br>
<dd>>registry, no different from disbanding a customer complaints
division<br>
<dd>>(and no less objectionable).<br>
<dd>><br>
<dd>>In short, I think community TLDs should be allowed for
identifiable<br>
<dd>>communities; I don't think this carries any necessary implication
that<br>
<dd>>ICANN should get into the business of seeking to regulate the
behaviour<br>
<dd>>of the members of those communities (except as justified by
reasons that<br>
<dd>>actually are part of ICANN's Mission, of course).<br>
<dd>><br>
<dd>>To those who disagree, I would like to point out the
inevitable<br>
<dd>>consequences of going down this route.<br>
<dd>><br>
<dd>>Some say that the registry should be "made to uphold"
these commitments,<br>
<dd>>while still thinking that this doesn't require ICANN to begin
creating<br>
<dd>>such behavioural rules itself. I think this profoundly
mistaken.<br>
<dd>><br>
<dd>>Suppose that a registry, such as for .eco, makes a commitment to
enforce<br>
<dd>>certain behaviour by its users, such as the publication of
relevant<br>
<dd>>environmental reports. As long as nobody is objecting, the fact
that<br>
<dd>>ICANN has contracted with the registry to do this doesn't really
have<br>
<dd>>any effect. The only time it matters is when someone
complains.<br>
<dd>><br>
<dd>>The only way ICANN gets involved is when someone comes to ICANN
and says<br>
<dd>>".eco promised to make their users disclose environmental
reports and<br>
<dd>>they're not doing so. Please enforce this requirement on the
.eco<br>
<dd>>registry".<br>
<dd>><br>
<dd>>What is ICANN supposed to do with this complaint? Proponents of
PICS<br>
<dd>>seem to think there is some magical wand that ICANN waives to
bring .eco<br>
<dd>>into compliance with its contract. This is nonsense. What
actually<br>
<dd>>happens is that ICANN contacts the registry and says "We've
had a<br>
<dd>>complaint you're not requiring publication of relevant reports,
is this<br>
<dd>>true? Please provide evidence that you are doing as you
previously<br>
<dd>>promised.". Most likely, the registry replies that they are
in<br>
<dd>>compliance with their commitment. The evidence offered, however,
may<br>
<dd>>well be open to differing interpretations: for example, .eco may
have<br>
<dd>>placed an extremely narrow definition on what constitutes a
"relevant<br>
<dd>>environmental report".<br>
<dd>><br>
<dd>>What is ICANN supposed to do next? On the one hand, it has a<br>
<dd>>complainant, who can show that the registry is not doing certain
things,<br>
<dd>>and argues that those things are required by the PIC. On the
other, it<br>
<dd>>has a registry, which can show it is doing other things, and
argues that<br>
<dd>>those things are sufficient to discharge the promise it had
previously<br>
<dd>>made in the PIC.<br>
<dd>><br>
<dd>>It seems to me that there are really two options for how to
proceed:<br>
<dd>><br>
<dd>>i) ICANN could be so deferential to the registry interpretation
as to<br>
<dd>>accept its position pretty much automatically: so long as the
registry<br>
<dd>>didn't simply admit non-compliance, and its claim to compliance
wasn't<br>
<dd>>manifestly ridiculous, ICANN could simply stop there. But what is
the<br>
<dd>>value in requiring ICANN to "enforce" PICs to such a
limited standard?<br>
<dd>>If that's all we're going to do, why not save ourselves a lot of
bother<br>
<dd>>(not to mention raising expectations from some stakeholders only
to<br>
<dd>>inevitably disappoint)?<br>
<dd>><br>
<dd>>ii) Alternatively, ICANN could investigate the case and come to
its own<br>
<dd>>view as to whether what the registry has done is sufficient to
discharge<br>
<dd>>its contractual obligation. However it can ONLY do that by first
forming<br>
<dd>>a view as to what the PIC requires. So in the putative case,
ICANN could<br>
<dd>>only enforce a requirement to make reasonable environmental
disclosures<br>
<dd>>if it itself determines what it considers constitutes a
reasonable<br>
<dd>>environmental disclosure. Likewise it can only enforce a
commitment to<br>
<dd>>prevent harassment by setting standards for what constitutes
harassment,<br>
<dd>>it can only enforce a commitment take down copyright infringing
material<br>
<dd>>by deciding whether particular publications infringe copyright,
and it<br>
<dd>>can only enforce a commitment to prevent access to certain web
sites by<br>
<dd>>minors by deciding both what age constitutes a minor, and what
are<br>
<dd>>acceptable means for identifying them and for excluding them from
access.<br>
<dd>><br>
<dd>>In other words, the idea that ICANN can "enforce" PICs
without itself<br>
<dd>>determining the standards that PICs seek to enforce simply
doesn't stand<br>
<dd>>up to scrutiny. As soon as ICANN is called on to enforce a PIC
against a<br>
<dd>>registry, it must necessarily assert that a particular kind of
action is<br>
<dd>>required by the PIC, and distinguish it from the action
actually<br>
<dd>>undertaken that the registry asserts to be sufficient. This is
the core<br>
<dd>>of regulatory activity. I have no problem whatsoever with ICANN
engaging<br>
<dd>>in this kind of regulatory behaviour for matters within its
limited<br>
<dd>>Mission, but if we invite ICANN to take this on for an unlimited
range<br>
<dd>>of objectives claimed to be in the public interest, we are
essentially<br>
<dd>>investing ICANN with a global policing power.<br>
<dd>><br>
<dd>>Some may be happy to see ICANN go down that route. I would not: I
think<br>
<dd>>it has neither the capacity nor the legitimacy. But I am also
worried by<br>
<dd>>those who have managed to convince themselves that it is possible
to<br>
<dd>>enforce PICs for an unlimited range of purposes without itself
becoming<br>
<dd>>embroiled in setting the rules for those purposes. Those people
are, I<br>
<dd>>believe, simply kidding themselves.<br>
<dd>><br>
<dd>>Malcolm.<br>
<dd>><br>
<dd>>--<br>
<dd>>Â Â Â Â Â Â Malcolm Hutty |
tel: <a href="tel:%2B44%2020%207645%203523">+44 20 7645 3523</a><br>
<dd>>Â Â Head of Public Affairs | Read the LINX Public Affairs
blog<br>
<dd>> London Internet Exchange |<br>
<dd>
><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net">
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net</a>
<br>
<dd>
>_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W<br>
<dd>
>DDkMr4k&m=F3FlEVYbysKtCNonZguZbv90urP8qDBk_08KcwSbnzQ&s=ksR3GCVlhY-LMF3l9w<br>
<dd>>mgX_POXp3jz25-xZ5f0KkUo-E&e=<br>
<dd>><br>
<dd>>Â Â Â Â Â Â Â Â Â
London Internet Exchange Ltd<br>
<dd>>Â Â Â Â Monument Place, 24 Monument Street,
London EC3R 8AJ<br>
<dd>><br>
<dd>>Â Â Â Â Â Company Registered in England
No. 3137929<br>
<dd>>Â Â Â Â Trinity Court, Trinity Street,
Peterborough PE1 1DA<br>
<dd>><br>
<dd>><br><br>
<dd>_______________________________________________<br>
<dd>Accountability-Cross-Community mailing list<br>
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br><br>
</dl><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br>
*******************************<br>
David G Post - Senior Fellow, Open Technology Institute/New America
Foundation<br>
blog (Volokh Conspiracy)
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post<br>
</a>book (Jefferson's Moose)
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n </a> <br>
music
<a href="http://tinyurl.com/davidpostmusic%A0" eudora="autourl">
http://tinyurl.com/davidpostmusic </a> publications etc.
<a href="http://www.davidpost.com /" eudora="autourl">
http://www.davidpost.com
</a> <br>
******************************* </body>
</html>