I haven’t seen any responses. My personal view is that these are some thoughtful and informed responses by Jeff.
A useful reminder of some of the key bumps in the road to rolling out the 2012 programme as well as references to both the underlying policy issues and the subsequent implementation issues.
I think the analysis presented and the distinction between programme and policy implementation is a useful framework to be able to refer to for this group as we consider the next round issues and the questions raised by Anne.
Jonathan
From: Jeff Neuman [mailto:jeff.neuman@comlaude.com]
Sent: Tuesday, August 8, 2017 6:25 AM
To: Aikman-Scalese, Anne <AAikman@lrrc.com>; 'avri@apc.org' <avri@apc.org>
Cc: gnso-newgtld-wg@icann.org
Subject: Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] Meeting Invitation: New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 03:00 UTC
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.
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.
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).
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 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)
- 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.
- 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.
- The decision to protect IGO/INGO Names. That went counter to the GNSO Recommendations and therefore should have gone through the GNSO.
- 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.
- How the ICANN Board handled the Closed Generic issue – That should have gone back to the GNSO according to the Policy and Implementation group.
- 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?
Jeffrey J. Neuman
Senior Vice President |Valideus USA | Com Laude USA
1751 Pinnacle Drive, Suite 600
Mclean, VA 22102, United States
E: jeff.neuman@valideus.com or jeff.neuman@comlaude.com
T: +1.703.635.7514
M: +1.202.549.5079
@Jintlaw
From: Aikman-Scalese, Anne [mailto:AAikman@lrrc.com]
Sent: Monday, August 7, 2017 6:45 PM
To: Jeff Neuman <jeff.neuman@comlaude.com>; 'avri@apc.org' <avri@apc.org>
Cc: gnso-newgtld-wg@icann.org
Subject: RE: [Ntfy-gnso-newgtld-wg] Meeting Invitation: New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 03:00 UTC
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
Anne E. Aikman-Scalese |
Of Counsel |
520.629.4428 office |
520.879.4725 fax |
_____________________________ |
|
Lewis Roca Rothgerber Christie LLP |
One South Church Avenue, Suite 700 |
Tucson, Arizona 85701-1611 |
From: ntfy-gnso-newgtld-wg-bounces@icann.org [mailto:ntfy-gnso-newgtld-wg-bounces@icann.org] On Behalf Of Michelle DeSmyter
Sent: Monday, August 07, 2017 2:34 PM
To: ntfy-gnso-newgtld-wg@icann.org
Cc: gnso-secs@icann.org
Subject: [Ntfy-gnso-newgtld-wg] Meeting Invitation: New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 03:00 UTC
Dear all,
The following call for the New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 at 03:00 UTC.
20:00 PDT, 23:00 EDT, 04:00 London, 05:00 CEST
for other places see: http://tinyurl.com/y94xsmxx
ADOBE CONNECT Room : https://participate.icann.org/newgtldswg
If you require a dial-out, please email me with your preferred contact number at gnso-secs@icann.org
Let me know if you have any questions.
Thank you.
Kind regards,
Michelle
____________________________________________________________________________
Participant passcode: NEW GTLD
Dial in numbers:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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.