[CCWG-ACCT] Board comments on the Mission statement

[Greg Shatan]

Bruce,

On Fri, Nov 20, 2015 at 7:41 PM, Bruce Tonkin <
Bruce.Tonkin at melbourneit.com.au> wrote:

> Hello Greg,
>
> >> ICANN shall not impose regulations on services (i.e., any software
> process that accepts connections for the Internet) that use the Internet's
> unique identifiers, or the content that such services carry or provide.
>
> I think as Andrew Sullivan pointed out - I would consider most of the
> processes that registries and registries use to register domain names as
> services that use the Internet's unique identifiers.   That is a very
> general statement.
>
> ​GS: Bruce, if you are talking about the software processes that underlie
the websites and email systems used by registries and registrars, I believe
that's correct.  But what do you believe is the impact of that?  Do you
think that what ICANN currently does or hopes to do would constitute
"imposing regulations on" these software processes?    ​


>
> >>  • "Some existing registry agreements may be out of compliance with
> ICANN's responsibilities if this change is adopted": I, for one, had that
> concern about the language that appears in the November 15 formal update.
> I believe that the current language actually resolves, rather than causes
> this problem.  If the Board disagrees, I think a far more specific
> discussion is needed -- one that clearly identifies the language (or
> change/deletion of language) that causes the Board's concern, and which
> provisions in which existing registry agreements might be out of
> compliance.  Dealing in abstract concerns is not particularly helpful.  As
> far as I know, it was not the intention of any of the drafters to nullify
> or expose to challenge any provisions of any registry or registrar
> agreements.  Of course, this should be clarified, and if the Board has
> identified a "land mine" in the language that has been planted in
> anticipation of a later attempt to challenge provisions of existing
> agreements, that land mind should be extracted and de-fused.
>
> I have asked the legal staff at ICANN to provide some examples.
>
> Here is one that occurs to me though.   The current new gTLD registry
> agreements in Specification 5   (
> http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm)
> have a provision that restrict the ability of a registrant to register a
> country or territory name, or names relating to the International Olympic
> Committee; International Red Cross and Red Crescent Movement.
>
> These are examples of content in domain names that have some
> restrictions.   There are no technical or security reasons for such
> restrictions.   The restrictions have been put in place on the basis of
> "public policy" advice from the GAC.
>
> ​GS: Bruce, I think you have (re)surfaced a couple of potentially
significant interpretive errors in looking at these provisions.  *First,
domain names are not "content."*  If we start treating domain names as
content, that opens up a whole Pandora's Box.  But even if we avoid that
larger issue, I think it is clear from the provision that domain names are
not "content" for the purposes of this provision.  Domain names are clearly
among the "Internet's unique identifiers" in this provision, so they can't
also be the "content" that is "carried" or "provided" by the "service."  I
think that if we could expressly associate "content" with "datagram(s)"
this would be clearer.  Alan Greenberg has raised this "domain names are
not content" (or perhaps more restrictively, "domain names are not
"content"" here) issue more than once, with unclear results.  This needs to
be clarified, at least in connection with this provision

>
>
> >>  • The use of the word regulate (which occurs on both the November 15
> and November 17 language, so I assume the Board's concern covers both
> versions).
>
> Yes - this is mostly a concern from ICANN legal staff.   My understanding
> is that "regulate" has a specific meaning in the US law context and applies
> to the role of governments.   I think it is possible to find another term
> that aligns with our practices.   Ie ICANN develops policies, and
> incorporates those policies in  registry, registrar and registrant (through
> their agreements with registrars) agreements.   ICANN has a compliance team
> to ensure that registries, registrars, and registrants comply with those
> policies.     An alternative formulation of the text could therefore be:
> ICANN does not impose "contractual terms" ...
>
> ​GS: Bruce, this is the second potentially significant interpretive error
you surface.  While "regulation" is most often used to describe
governmental/public entity action, it is not limited to that sphere.  But
if we look at U.S. government regulation as a guide, regulations are rules
and standards that are unilaterally imposed by the government in order to
implement laws (e.g., the Americans with Disabilities Act is a law, but
there are government-issued regulations that specify what must be done to
comply with that law).  That should be the definition that is carried over
into this provision.  I think it would be wrong and dangerous to consider
the policies developed by ICANN through the various policy development
processes as a form of "regulation."  Similarly, it would be wrong and
dangerous to consider the registry and registrar agreements to be forms of
regulation, especially given how they are developed.  Contractual terms are
by definition not "imposed."  They are agreed to (unless you are talking
about "contracts of adhesion," which is a very narrow category of forced
contract).  *Thus, I would very strongly reject the idea that "ICANN does
not impose contractual terms" is in any way an alternative statement of
"ICANN does not impose regulations." * If we go down that road, then
virtually everything ICANN does is regulation, and that is clearly not the
intent of this text.  That said, if there is any danger that one will be
interpreted as synonymous with the other, that needs to be clearly and
explicitly stopped.  If some as well-informed as yourself can stumble into
that mistake, then I think this is a clear and present danger, and one that
must be resolved before this provision is finalized.

>
> >>  • The definition of services: This is discussed above and in my prior
> email, so I won't reiterate here.  While it could be improved. but it
> clearly points in the right direction and away from the wrong one -- and
> that is critical.
>
> The Board certainly agrees with the intent of the language.   It just
> needs refinement.   Probably the best the group can do is to clearly define
> the intent, and allow time for appropriate language to be developed.
>
​


>
> Part of clarifying the intent is to give clear examples of what ICANN
> should not be doing as part of its role.
>
> Regards,
> Bruce Tonkin
>
> ​Greg​

>
> _______________________________________________
> 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/20151122/5661f7d2/attachment.html>