[CCWG-ACCT] regulatory/mission issue WS2

Greg Shatan gregshatanipc at gmail.com
Fri Nov 6 22:22:46 UTC 2015


Becky,

Thanks again for your suggestion.  I think it's a good attempt to "cut the
Gordian knot" and avoid the issue of wrestling with a deeply flawed
proposed bylaw and I would support it.

It is unfortunate that some want to analyze this merely in "tribal" terms
or in terms of "appeasement."  This is a simplistic misdirection from the
more universal issues and problems with the proposed Bylaw.  It does expose
quite neatly, however, that for some this Bylaw is not here primarily to
try and "score points" in a discussion happening elsewhere in ICANN, one
that will not be resolved one way or the other in these Bylaws or in the
CCWG.  Those who want it here for a particular purpose see it only for that
purpose, and end up overlooking the fundamental infirmities, ambiguities
and difficulties inherent in the proposed Bylaw, whether one looks at it as
an instruction to our lawyers or as an attempt to draft an actual Bylaw.

As Becky notes, while there was support for the Bylaw, there was also
considerable concern about the effect it would have on contracts.  Any
solution has to take those issues into account.

We have still not resolved the issue of what is meant by a "service," an
ambiguous term that apparently may have a meaning specific to Telcoms
professionals but not one that is broadly understood or tends to exclude
other meanings in the context of a corporate Bylaw.  I am confident that
our lawyers (even though one is a Tech Transactions lawyer not unlike
myself) will not grasp what Malcolm thinks this conveys.  In any event, one
of the rules of good legal drafting is to avoid jargon or terms of art
specific to an industry, except in a document of such narrow application
that it will be instantly obvious what the meaning is. In any event, many
types of legal documents have "definitions" section, where terms are
defined and ambiguities resolved.

The new language proposed by Malcolm is somewhat enlightening (though
clunky) but doesn't really solve the problem, because it is still modifying
the term "services" where the real issue lies.

We have not resolved what is meant by "regulation" and what is excluded
from "regulation" even though it could reasonably be called regulation.  It
may seem self-evident to one steeped in ICANN that Consensus Policy is not
regulation (or that a registry or a registrar is not a "service") but that
is not otherwise clear from this Bylaw.

As for "content" -- it's not clear what that covers either.  Alan Greenberg
has asked for a clarification (not satisfactorily dealt with) that "unique
identifiers" are not "content" within the meaning of this Bylaw.  Are PICs
a form of "content regulation"?  How about the UDRP (which is clearly
permitted under Specification 1, even though it takes "use" (i.e., content)
into account)? Or the URS and the PDDRP?

The purpose is also far from clear from the language itself, although those
that placed it here seem to know what they think they want it to cover, and
hope to coax out of its opacity.  (And I think different people or groups
want different things out of the same language.)  I'm still not sure of all
the possibilities myself.  If the idea of the "services" clause is that
ICANN shouldn't have the power to "regulate" ISPs and IXPs, then it should
say so -- but I"m not sure that's what it's about.

It's also completely unclear what the linkage is between the last sentence
and the second sentence.  They sit next to each other in this particular
Bylaw, so some linkage is intended, but what that linkage is remains
largely obscure.

Now perhaps all this ambiguity and obscurity is a good thing, because the
reasonable interpretations of this Bylaw will vary so wildly that we will
spend years disputing its meaning and using it to support widely varying
conclusions, like the murmurings of some Delphic oracle.  In the end this
will probably do little to advance the resolution of the concerns at which
it is aimed, and may actually hinder such resolution.

Maybe we can still resolve the issues in Malcolm's redraft of the Bylaws to
everyone's reasonable satisfaction.  But we are working with poor
materials, and the result will still be troublesome for that reason. Your
revision has raised my hopes that we don't have to to do so.

In retrospect, we probably would have been better off with something that
did not look like a bylaw, but instead said in plain English, "We want a
bylaw that accomplishes the following:"  Of course, then we would have to
deal directly with the issues, instead of quasi-lawyering our way through a
series of unkempt phrases that will more likely bedevil us than serve us in
the years ahead.

Speaking for myself, if the purpose of this is to avoid, in general terms,
the imposition of unilateral restrictions on ISPs and IXPs, I am highly
sympathetic to that, and I don't think it runs at cross-purposes to my
concerns, except perhaps on the verges.  Similarly, if the purpose is to
stop ICANN from being used as a tool for the unilateral imposition of rules
designed to stifle the expression of opinions or the expression of creators
of content, and thereby create a less "open" Internet, I am highly
sympathetic to that as well.  A Bylaw that does both of those things, and
only those things, should have broad support from all stakeholder groups,
including the business and intellectual property communities.  However, a
Bylaw that cloaks itself in these things, but is intended to nullify
portions of ICANN's existing contracts or to protect those who engage in
illegal activity, including trafficking in stolen property -- I have no
sympathy with that whatsoever.  I think that is a highly improper and
inappropriate use of the CCWG and it is certainly something that is not
going to be viewed favorably in Congress or the NTIA -- nor should it be
viewed favorably by anyone in the ICANN community, no matter what "tribe"
you are affiliated with.

Greg

On Fri, Nov 6, 2015 at 2:51 PM, Edward Morris <egmorris1 at toast.net> wrote:

> Well put. I completely agree with Robin on this both in terms of substance
> and of procedure. We've already seen efforts to bring in content regulation
> through the back door, most recently in Dublin by some of our friends and
> colleagues. We need to make it plain, transparent and clear that content
> regulation is not part of ICANN's remit. The current language does so. The
> proposed change does not.
>
> Best,
>
> Ed
>
>
>
> Sent from my iPhone
>
> On Nov 6, 2015, at 7:38 PM, Robin Gross <robin at ipjustice.org> wrote:
>
> Unfortunately, this deletion would represent a big step backwards from
> consensus.  There were quite a few public comments from a wide range of
> stakeholders that made note of the importance of the phrase in the mission
> to limit ICANN from regulating in this matter, so deleting it now would
> cause considerable disturbance to the consensus and go against public
> comment.  I appreciate the pressure to appease the IPC, but this would be
> unfair to the many public commenters and other participants who have been
> relying on this critical language being included in the final text.
>
> Thanks,
> Robin
>
>
> On Nov 6, 2015, at 9:30 AM, Burr, Becky wrote:
>
> All:  At the risk of causing a riot, I confess that am getting
> increasingly concerned that we are confusing ourselves (and possibly the
> bylaws) by trying to include and explain the prohibition on regulation of
> services that use the Internet’s unique identifiers or the content that
> such services carry or provide.  Perhaps we would be better off relying on
> a clear Mission statement and enhanced accountability mechanisms to prevent
> mission creep? I could certainly make the argument, based on the proposed
> mission statement, that ICANN has no authority to regulate ISPs, or to use
> its authority over registries and registrars to do so indirectly.  (Please
> note, ICANN’s Bylaws currently authorize ICANN to enter into contracts.
> See  Article XV, Section 1).
>
> Should we discuss this approach?  The report language on ICANN’s Mission
> Statement, reflecting the recent changes to address IAB/IETF concerns,
> would then read:
>
> The Mission of The Internet Corporation for Assigned Names and Numbers
> ("ICANN") is to ensure the stable and secure operation of the Internet's
> unique identifier systems in the ways described below.  Specifically, ICANN:
>
> 1.  Coordinates the allocation and assignment of names in the root zone of
> the Domain Name System ("DNS"). In this role, ICANN’s Mission is to
> coordinate the development and implementation of policies:
>
> • For which uniform or coordinated resolution is reasonably necessary to
> facilitate the openness, interoperability, resilience, security and/or
> stability of the DNS; and
>
> • That are developed through a bottom-up, consensus-based multi-
> stakeholder process and designed to ensure the stable and secure operation
> of the Internet’s unique names systems.
>
> 2.  Coordinates the operation and evolution of the DNS root name server
> system. In this role, ICANN’s Mission is to [to be provided by root server
> operators].
>
> 3.  Coordinates the allocation and assignment at the top-most
> level of Internet Protocol ("IP") and Autonomous System ("AS") numbers.
> ICANN’s Mission is described in the ASO MoU between ICANN and RIRs.
>
> 4.  Collaborates with other bodies as appropriate to publish core
> registries needed for the functioning of the Internet. In this role, with
> respect to protocol ports and parameters, ICANN's Mission is to provide
> registration services and open access for registries in the public domain
> requested by Internet protocol development organizations, such as the
> Internet Engineering Task Force.
>
> ICANN shall act strictly in accordance with, and only as reasonably
> appropriate to achieve its Mission. Without in any way limiting the
> foregoing absolute prohibition, ICANN shall not regulate services that use
> the Internet's unique identifiers, or the content that such services carry
> or provide. ICANN shall have the ability to enforce agreements with
> contracted parties, subject to established means of community input on
> those agreements and reasonable checks and balances on its ability to
> impose obligations exceeding ICANN’s Mission on registries and registrars.
>
>
> *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/>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
> _______________________________________________
> 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/20151106/c95d66be/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list