[CCWG-ACCT] Personal Responses to Draft Summary of ALAC Issues on Mission (Recommendation 5)

[Nigel Roberts]

But won't ALAC change their mind next week?


On 12/17/2015 07:53 PM, Burr, Becky wrote:
> According to the Draft Issues document circulated by Alan Greenberg,
> “ALAC has a grave concern that the wording used to restrict ICANN’s
> mission may have inadvertent results which severely impact its ability
> to carry out its intended mission.”  That’s a pretty serious charge and
> I thought it would make sense to begin a substantive discussion of the
> ALAC points.  Here is my attempt to start that conversation.  In the
> hope of moving this issue forward quickly, I am stepping out of my role
> as rapporteur here and expressing my personal views.  I apologize in
> advance for the length of this post, but wanted to respond as fully as
> possible to the ALAC Draft.
>
> 1.According to the Draft Summary, the notes to drafters incorrectly
> imply that ICANN’s Mission is limited to the “picket fence.”
>
> /I believe this is inaccurate.  ICANN’s Mission is specifically
> described as coordinating the development and implementation of
> bottom-up policies for which uniform coordinate resolution is reasonably
> necessary to facilitate the openness,, interoperability, and/or
> stability [of the DNS].  The note to drafters says that RAA Spec 4 and
> RA Spec 1 “are intended and understood to be within the scope of ICANN’s
> Mission.” /
>
> //
>
> 2.According to the Draft Summary, the ALAC wants a legal opinion that
> provides assurance that the “many areas of contracts” outside the
> so-called “picket fence,” established by negotiation, or other than
> through a PDP “may be renewed without change in the areas in question.”
> This concern also extends to new gTLD operators who have not signed
> contracts yet.
>
> /I think we need to break this question down a bit. /
>
> //
>
> ·/First, recall that the Mission specifically empowers ICANN to
> “implement” policies.  Also recall that the text we have provided states
> “ICANN shall have the ability to negotiate, enter into and enforce
> agreements with contracted parties in service of its Mission.”  Most of
> the provisions of the RA and RAA of concern should be covered by these
> authorities, IMHO./
>
> //
>
> ·/Second, I acknowledge that there could be some new gTLD
> applicant-provided PICs and new gTLD applicant-provided operating rules
> that fall outside of ICANN’s Mission Statement.  For example, suppose
> the applicant for .singlemaltscotch specified in its application (which
> is, in turn, incorporated into its Registry Agreement) that all
> registrants in the domain must be 21 years old.  That requirement
> probably is not strictly necessary to facilitate the openness,
> interoperability, resilience, security and/or stability [of the DNS].
> While I don’t think that ICANN has the authority to *demand *that the
> registry operator adopt such a policy, I have no problem whatsoever with
> ICANN holding the registrant to that policy if it was offered as part of
> the application.  (Others may well disagree with me.)/
>
> //
>
> ·/Third, rather than speaking in generalities, could we talk about some
> specific provisions that arguably fall outside ICANN’s Mission and its
> implementation authority?  I’m asking both sides for contributions on
> this point. /
>
> //
>
> ·/Finally – the request for a “legal opinion.”  I will repeat what I’ve
> already said, these kind of open-ended questions produce very expensive,
> very unsatisfying legal opinions. Rather than chase this option, once we
> agree on the problem statement, let’s ask the lawyers if there is
> language that could be added to reinforce the likelihood that any
> challenge will be resolved in the manner we collectively anticipate. /
>
> 3.According to the ALAC Draft Summary “anything which would allow an IRP
> to invalidate the current contractual terms is not acceptable.”
>
> /I don’t think that there is a risk of invalidating the current
> contractual terms – and the language that we have discussed as an
> additional note to drafters would reinforce that (/This means that the
> parties who entered into existing contracts intended (and intend) to be
> bound by those agreements.  It means that neither a contracting party
> nor anyone else should be able to bring a case that any provisions of
> such agreements on their face are ultra vires.  It does not, however,
> modify any contracting party’s right to challenge the other party¹s
> interpretation of that language.) /I don’t have a particular problem
> extending that to existing applicants who have yet to sign registry
> agreements, though others might./
>
> /But seriously, is ALAC asking for a guarantee that certain provisions
> cannot be challenged?  That is not a reasonable ask IMHO.  That’s
> because it is always the case that ICANN could choose to enforce a
> provision of an existing agreement in a manner that is a frank violation
> of the Mission.  I’ve previously provided several examples in the
> context of 3.18 of the RAA, which I believe is – on its face –
> consistent with Mission, but which could be enforced in a manner that is
> not./
>
> //
>
> 4.ALAC continues to object to the removal of the “where feasible and
> appropriate” caveat to the Core Values regarding reliance on market
> mechanisms to promote and sustain a competitive environment.
>
> /ALAC takes exception with my point that “ICANN does not possess the
> requisite skill or authority to intervene in the competitive market,”
> citing the RSEP provisions regarding concerns about significant
> competition issues.  I think the example completely supports my point
> here.  In the RSEP, if ICANN has competition concerns, it has the
> authority to “refer the matter to the appropriate competition
> authority.”  From that point it is entirely up to the appropriate
> competition authority to exercise its sovereign authority with respect
> to antitrust law.  If the concern is that somehow the omission of the
> “where feasible and appropriate” language would prevent ICANN from
> making such a referral (which I don’t believe is the case), then I am
> happy to clarify.  But taking competition law into its own hands is,
> IMHO, a very clear example of the kind of regulatory authority that
> ICANN should not have./
>
> //
>
> 5.ALAC objects to the Commitment to “preserve and enhance the neutral
> and judgment free operation of the DNS,” pointing out that the NTIA
> requirement is limited to the “neutral and judgment free administration
> of the technical DNS and IANA functions.”
>
> /Good point, I am ok with that change/.
>
> 6.The ALAC believes that the AoC commitment to “consumer trust” should
> be in the ICANN Commitments and Core Values rather than in the AoC
> reviews provisions of the Bylaws.
>
> /Section 3 of the AoC describes what the “document” (the AoC)
> accomplishes:  it affirms key commitments by //DOC and ICANN, including
> commitments “to promote competition, consumer trust, and consumer choice
> in the DNS marketplace.”  The context for promoting consumer trust is
> found exclusively in Section 9.3, which describes the reviews that must
> be undertaken in connection with the expansion of the top level domain
> space.  This issue was debated extensively within the CCWG.  A general
> commitment to promoting consumer trust threatens massive scope creep IMHO. /
>
>
> *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
>