[Gnso-newgtld-wg] Apologies and Notes from Listening to call (Long Note)
Jeff Neuman
jeff at jjnsolutions.com
Thu Jul 2 15:25:56 UTC 2020
I want to first apologize for missing the call last night. My dog "Angel" had a run in with my younger daughter's home baked chocolate cake. And our "Angel" used her paw to knock the cake plate, cover, cake and all on to the floor to help herself to a tasty dessert. For those of you that know what chocolate cake does to dogs, its not pretty. Needless to say, without a phone (but luckily with a mask), I hopped in the car with the dog and got to Animal Hospital. All is good now, but dog has a nasty "hangover" today.
I listened to the call this morning: (Huge Thanks to Cheryl and Steve for covering my absence)
Dissenting Views / Minority Reports
On the concept of Dissenting Views, I think ultimately you all got to the answer which is that for the Draft Final Report, we are including the concepts in the deliberation/rationale section though not official statements or minority reports from the dissenters. For example, we may state in the rationale "A few Working Group members did not agree with A, B and C because of {List general reasons}." But there will not be actual Minority Statements issued by those that disagree with the Working Group. Those Minority Reports will ONLY be including in the FINAL REPORT after a Consensus Call.
This is why we have been asking everyone to review not just Section (a) of each sub-part ( recommendations/implementation guidance sections), but also section (b) (rationale) for each Sub-part.
As Steve mentioned during the call:
1. The issues in the "Cant Live With" comments from Justine and the 2 other At-Large Members were already considered by Work Track 5 in their deliberations. This is why we do not need to summarize these new comments in either the Work Track 5 section or elsewhere in our report. If Justine and the 2 other at large members wish to submit this as a public comment to the Draft Final Report, they are free to do so and/or if they want to include it in a Minority Report AFTER the consensus call IN THE FNAL REPORT (later this year), they may elect to do so.
2. Other issues raised by Working Group members previously in other sections have already been included in deliberations/rationale sections. The reason they are is because they were based on new issues thoroughly discussed by the Working Group.
Private Resolution of Contention Sets: Thanks Jim and Paul for submitting your proposals and summarizing them on the call. And thanks to Cheryl for "tabling" the topic (In the non-American way). We will discuss these both (as well as the responses) next week.
Predictability Framework
A couple of points:
1. Council Role in Situation B
* The GNSO Council always maintains supervisory authority over the SPIRT.
* That said, for Non-Minor Operational Changes are not intended to go to the GNSO Council for their approval. The GNSO Council would have a right to object to the solution, but it was not intended to require GNSO Council approval. As Steve mentioned during the call, if they are true Operational Issues, the GNSO Council technically has no jurisdiction over the issue. More importantly, the GNSO Council does not have the expertise that is required to solve the Operational Issues. And of course this would bring the program to a halt.
i. The purpose of all of the Predictability Framework is to have a predictable process to resolve issues that arise after the publication of the Guidebook and to ensure that ICANN staff gets some advice from the SPIRT on Operational changes.
ii. The SPIRT Team is intended to be a representative body of experts on operational issues.
iii. The GNSO Council does not have that expertise nor do they represent the interests of New gTLD Applicants
iv. And remember, if there is a policy impact, then it is no longer in Category B, but rather Category C.
1. Change Log: This came up initially to address the fact that Categories A and B do not go to the GNSO Council for approval. Again, we can talk about whether the GNSO Council could object, but it should not have any sort of approval right of the Operational Changes.
1. Examples
* ICANN appoints a new provider of Pre-Delegation Testing. The new provider's system requires the use of certain authentication mechanisms that are proprietary in nature and therefore could require back-end operators to incur some development in configuring their systems to build this one off solution. This type of change could cause both development time and money for back-end service providers and therefore is a non-minor change.
i. ICANN Org presents this change to the SPIRT to collaborate on a solution.
ii. Together the SPIRT and ICANN Org develop a solution that requires the new provider to develop an open-source API that is easily accessible by back-end providers and saves significant time and money.
iii. The SPIRT Team recommends sending out notice to all applicants to inform them of the change and to see if there are objections from any of the applicants.
* After all applications are submitted, ICANN changes its Naming Services Portal to have the ability to add Applicants and Applications into its work flow. ICANN now wants to require that ALL communications with applicants now go through this new portal. Because of the switchover to this new portal, it turns out that the portal requires manual re-entry of all application sections by applicants. In addition, the cutover will require a hiatus of 4 weeks to the program.
i. ICANN Org presents this change to the SPIRT to collaborate on a solution.
ii. Together the SPIRT and ICANN figure out a mechanism that would enable a smooth migration of applications to the new system, but perhaps without some of the normal NSP functionality to start with. This would save both time and money and only cause a 1 week stop to the program/
iii. Together the SPIRT and ICANN Org create a document to send out to all applicants describing the changes, the impact and asking for additional feedback.
As you can see from these examples, they are not policy but are truly operational. In 2012, this would have been done by ICANN alone without any consultation of members of the community and applicants were forced to accept the changes and absorb all of the costs and delays. A SPIRT team of operational experts could add significant value. But the GNSO Council generally would not.
The GNSO Council would be informed through the Change Log of what was happening. It would receive information on all of the "decisions". And perhaps we can create a right to object. But putting the recommendations for Category B to the Council does not make sense. The Council has no expertise in these matters. Its akin to asking a Lawyer to fix an issue with your toilet or sink. Sure there may be a couple lawyers that could do it, but I would venture to say most of them are likely not as skilled Plumbers and requiring a set of lawyers to approve a plumbers solution would not make sense.
I hope this helps.
Jeff Neuman
JJN Solutions, LLC
Founder & CEO
+1.202.549.5079
Vienna, VA 22180
Jeff at JJNSolutions.com
http://jjnsolutions.com<http://jjnsolutions.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200702/08ae7757/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 113 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200702/08ae7757/image001-0001.png>
More information about the Gnso-newgtld-wg
mailing list