<html>
<body>
Becky, thanks for taking the time and effort to reply. Please see my
comments embedded. <br><br>
As with your comments, these are my personal comments and have not been
passed by my ALAC/At-Large colleagues.<br><br>
Alan<br><br>
At 17/12/2015 02:53 PM, Burr, Becky wrote:<br><br>
<blockquote type=cite class=cite cite="">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.</blockquote><br>
AG: That was not a "charge" but a concern. My reading of the
Board comments is that they have a similar concern. That does not make it
any more valid, but does imply that we are not alone in worrying that the
new mission statements, where some of the implications of the wording is
unclear, and where there may be implications due to interactions among
the various new clauses is a possible source of future problems in the
enforcing of the contracts that are at the core of our gTLD
responsibilities.<br><br>
That "grave concern" was an overall caveat. The text that
followed were the specific issues that we have identified to date. The
caveat was expressing the worry that there may be others lurking. You
will recall that the current grandfathering language was only invented
after the ALAC expressed concern over the proposed text allowing current
contracts (or parts of them such as PICs) from being questions via an
IRP.<br><br>
<br>
<blockquote type=cite class=cite cite="">1. According to the
Draft Summary, the notes to drafters incorrectly imply that ICANN’s
Mission is limited to the “picket fence.”<br><br>
<i>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.” </i></blockquote><br>
AG:The area in question is whether the parts of contracts that were not
developed through a bottom-up process (in some cases because the clauses
pre-date the process, or in the case of the RAA, were agreed to by
negotiation) might be invalidated due to the new Article I wording.<i>
<br><br>
</i><blockquote type=cite class=cite cite="">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.<br><br>
<i>I think we need to break this question down a bit. <br>
</i><br>
· <i>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.</i></blockquote><br>
AG: The specific question is whether the grandfathering that protects a
current contract will also include its renewal. It is a simple question
and presumably can be covered by careful wording of the Bylaw if the CCWG
agrees that this is what we want.<br><br>
<blockquote type=cite class=cite cite="">·
<i>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 <b>demand
</b>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.)</i></blockquote><br>
AG: We are in agreement here (except PICs post-date the application and
must be covered). <br><br>
<br>
<blockquote type=cite class=cite cite="">·
<i>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. <br>
</i><br>
· <i>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. </i></blockquote><br>
AG: The question was not open ended. It covers whether renewal is or can
be covered under the grandfathering, and whether we can have wording that
covers the unsigned contracts.<br><br>
<blockquote type=cite class=cite cite="">3. According to the
ALAC Draft Summary “anything which would allow an IRP to invalidate the
current contractual terms is not acceptable.”<br><br>
<br>
<i>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 (</i>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>I don’t have a
particular problem extending that to existing applicants who have yet to
sign registry agreements, though others might.</i></blockquote><br>
AG: Yes, when the issue of the unsigned contracts was first brought up,
come CCWG participants basically said Too bad - any new contacts will
have to work by the new rules", and the proposal was silent on the
issue, thus our concern. <br><br>
<blockquote type=cite class=cite cite=""><i>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.</i></blockquote><br>
AG: My concern is that if terms that under today's Bylaws cannot be
challenged, that should not change. If current practice is outside of
today's mission, it can be challenged today, and that is fine.<i>
<br><br>
</i><blockquote type=cite class=cite cite="">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. <br><br>
<i>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.</i></blockquote><br>
AG: No, the concern is that with the wording removed, ALL competition
issues are outside of our mission and we may not even be allowed to ask
the question or make the initial evaluation.<br><br>
<blockquote type=cite class=cite cite="">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.”<br><br>
<i>Good point, I am ok with that change</i>.<br><br>
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.<br><br>
<i>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. </i></blockquote><br>
AG: I am afraid that we read Section 3 differently. The references to,
for instance, the public interest and international participation are
wider in scope than the particular reviews (although the review do
address aspects of these). <br><br>
We (ALAC/At-Large) recently had an interaction with a senior compliance
officer where it was claimed that consumer trust was not a significant
concern (my wording), despite it being mentioned in the department's
mission statement. That misunderstanding is in the process of being
resolved, but it has made us particularly sensitive to the issue.
<br><br>
Is there a harm in referencing it in the Bylaws, as was done in an
earlier draft of the CCWG Proposal?<br><br>
Alan<br><br>
<br>
<blockquote type=cite class=cite cite=""> <br><br>
<b>J. Beckwith Burr <br>
Neustar, Inc. </b>/<b> </b>Deputy General Counsel & Chief Privacy
Offic<br>
1775 Pennsylvania Avenue NW, Washington D.C. 20006<br>
<b>Office: </b>+1.202.533.2932 <b>Mobile: </b>+1.202.352.6367
<b>/</b> <a href="http://www.neustar.biz"><b>neustar.biz</a><br>
</b>_______________________________________________<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></body>
</html>