See notes in red below for discussion purposes on the call.  My views are my own.

 

 

 

POSTED IN MY PERSONAL CAPACITY AND NOT AS CO-CHAIR; THIS DOES NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER OR ANY OF THE CONSITUENCIES THAT I MAY BE A PART OF.

 

Anne,

 

These are really good points, but taking off my chair hat, I do not believe all issues that arise (or have arisen in the 2012 round) were as a result of the implementation (or lack thereof) of the GNSO policies. Nor will each issue that will arise in the future be a result of implementation issues of the GNSO.

 

We will have to walk through carefully the line of demarcation, but I believe for example, there were a number of issues that were not issues of GNSO Policy Implementation, but rather were issues involving operational implementation of the program.  These are issues where the GNSO is not the body with the expertise (in my view) to resolve, but even if they were, the impact of the issues were felt more on the applicants themselves than on the Internet community as a whole.

 

Example 1:  The TAS Application Security Breach:  This was an operational implementation flaw which was not impacted by the policy.  The primary impact was felt by the new gTLD applicants and not the community as a whole.  Resolution of this matter was decided solely by the ICANN staff without any input from the applicants or the GNSO.  Reconvening a GNSO IRT is not an efficient way of resolving this issue and deciding the path forward.  Sure input could be solicited, but a panel of experts would have provided in my personal view better advice to the ICANN Org on what to do.  Wouldn’t a standing IRT best positioned to say “Go hire some experts”?  Why is it better to say (as in the draft Predictability Framework) that staff will “collaborate with the community”, given how vague that clause actually is.

 

Example 2:  Digital Archery Fail:  Sure we will be talking about how to resolve this issue for subsequent application windows, so this will not come up again.  But the primary impact was felt by the applicants themselves and not the community.  Thus, a GNSO Implementation IRT, in my view, would not necessarily be the appropriate way to handle.  The new system unilaterally selected by ICANN cost each applicant an extra $100 per application which was unanticipated. 

For me, the key words here are “selected by ICANN”.  I think the draft Predictability Framework would allow ICANN to make this kind of change and simply inform the community in advance.  The draft language says that staff can make procedural changes that have from “a minimal to a significant effect” on the community.  How does the Framework improve outcomes for a similar issue in the next round? 

 

Example 3:  Changes to the ICANN Registry Agreement midstream.  Perhaps here would be an appropriate use of a GNSO Implementation team. Others would argue, however, that the changes that were proposed (namely, giving ICANN additional opportunities to unilaterally amend the agreement, disproportionately impacted the Applicants more than the community).  As far as I know, most changes to the RA require public comment.  That is because the entire community can be affected by changes to the RA, not just the Applicants.   One BIG issue we have coming up is the GDPR.   I think that if there is going to be a change to the RA based on the GDPR, then that is a community policy matter.  In particular, there is an issue re obtaining Consent in relation to the EU law stating that IP rights should be easily enforceable in the EU.  This is NOT a question of just “changing the RA midstream”.  The issue is WHAT TYPE OF CHANGE TO THE RA IS ENVISIONED?   (I venture to guess that legal opinions on what is necessary to obtain Consent under the GDPR will vary.)

 

Example 4:  Changes to the Pre-delegation Testing criteria – Again, this was an operational implementation of the policy requiring adequate pre-delegation testing.  It had a disproportionate effect on the applicants and did not arise due to an issue with the implementation of the GNSO Policy.  I was thinking that there are aspects of pre-delegation testing that are being considered as a matter of policy in Subsequent Procedures.  Am I wrong about this?  My overall point, once again, is that if you are for the change, it’s program implementation, if you are against it, it’s policy implementation so you have to have a very clear understanding of who gets to make that call.

 

I could go on and on.  The overall point is that in my personal view, there are issues with the implementation of the GNSO policies, and there are other issues that I call issues with the implementation of the “GNSO Program.” Perhaps there are better ways to describe the issue to avoid the confusing terminology, but at the end of the day, setting up a GNSO Implementation Team for these issues, even with the new processes put in place, would not be the best may, in my personal way, to resolve. 

 

The issues that I do believe the GNSO should be consulted on are where issues arise out of the specific implementation of the policy.  For the 2012 round, I would include the following issues as ones where the GNSO IRT could have (or should have been consulted)

 

1. The decision on which Rights Protection Mechanisms should be employed.  This was not an issue that went through the GNSO in the 2012 round (though the GNSO provided comments).  This would also include the decision of whether to have a centralized vs. decentralized clearinghouse model.  If you recall, ICANN staff initially proposed a decentralized model and a number of us in the community had to convince ICANN that such a mechanism would be fundamentally flawed.
   1. PLEASE NOTE, HOWEVER, THAT THE DECISION TO USE “SMD FILES” VS. OTHER TYPES OF ENCRYPTION, I BELIEVE WOULD FALL INTO THE CATEGORY OF OPERATIONAL IMPLEMENTATION (NOT POLICY).   Thus convening a GNSO committee for that decision would not have been practical.

 

2. The decision to protect IGO/INGO Names.  That went counter to the GNSO Recommendations and therefore should have gone through the GNSO.

 

3. Protection of Geographic Names:  Similar to IGO/INGO names, this was not consistent with the GNSO Policy and therefore, the GNSO should have been involved.

 

4. How the ICANN Board handled the Closed Generic issue – That should have gone back to the GNSO according to the Policy and Implementation group.

 

5. How the ICANN Board handled plurals vs. singular – That was a policy implementation issue, because it was ICANN staff’s interpretation of the GNSO Policy on not having confusingly similar strings.

 

So Anne, I do believe there is a line between Policy Implementation and Program Implementation.  And in either case, there should be predictable mechanisms to deal with those issues as they arise.  Not all of them should go to the GNSO, but similarly, not all of them should be decided by ICANN staff alone.

 

Perhaps a standing panel of “experts” to advise ICANN staff is one way forward?

 

 

 

Jeff and Avri,

The question I had was about where the REVISIONS to the Implementation Framework came from.   In other words, who authored them and what changes do the new provisions make to the existing Framework that resulted from the community-wide multi-stakeholder collaboration that Alan described?  That is the procedural question.

 

Separately, I think that if we now develop a category called “operational implementation”, we may be creating yet another dichotomy that  will cause “road bumps” in the next round.  Most of the issues that the Policy and Implementation Working Group considered as “case studies”  could also have been characterized as either “policy implementation” or “operational implementation”.  One big point of consensus in the Policy and Implementation WG was that the definition should not be controlling.  What was controlling was the notion that the matter “in controversy” (or if you will the “operational implementation question” ) needed to go back to the GNSO for ITS determination as to whether the issue involved policy or not.  (To use the new terminology mentioned on the call today, a GNSO determination as to whether the issue involves “policy implementation” or “operational implementation”.)

 

It may be more useful to talk about WHEN a problem arises rather than what type of problem it is.  For example, I believe that under the existing Framework, while IRT (Implementation Review Team) is still convened, IRT is supposed to figure out whether the issue needs to be raised with GNSO or not.  If we are trying to create a mechanism that will operate once IRT is disbanded, that is another story  - who makes the call?  (Someone asked a question in the doc about the possible need for a Standing IRT.) 

 

On the merits:  At issue here is “who decides whether an issue arising during the implementation phase is sufficiently controversial as to require GNSO advice?”  My point is that we should not revert to a system where ICANN staff is making the determination itself as to whether GNSO needs to consider the issue.  That was the whole reason behind the Policy and Implementation Working Group work.  Issues like “digital archery”, “name collision”, and changes in the terms of Registry Agreement can easily fall into the bucket of needing to be considered by the GNSO for either “Input”, “Guidance”, “Expedited PDP”, or “PDP”.    Labeling an issue as “operational implementation” doesn’t change that.  This is because, as we have learned with the history of the new gTLD program, if you are for the solution that ICANN.org develops to the issue that arises during implementation, then it is “operational implementation”.  On the other hand, if you are against the solution, it’s “policy implementation”.

 

Anne

 

 

 

 

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.