[Gnso-epdp-team] Revised Consensus Designation

Fri Jul 31 04:05:16 UTC 2020

My answer to Becky and Volker’s question is a bit different from Alan’s, as you might imagine.

1.       It makes no sense at this point to talk about which specific recommendations have consensus or not. There are several SGs or ACs who didn’t get _exactly_ what they wanted in specific recommendations. We are among them. Too bad. Petulant children cannot deal with such disappointment; adults operating in the real world can. We are all adults here. The issue now is whether one would vote to pass the entire policy or not. It’s binary now. Do you want there to be an SSAD or not? Pass the report, or not. Do not entertain the illusion that withholding support for this or that section will reboot the entire process and get exactly what you want. Please do not entertain the corrupt notion that you can sink this process and then go into backrooms with national governments or the ICANN board to make something different come out of it. You will get this report or you will get nothing.

2.       That vote – up or down – will not take place here. It will take place in the GNSO Council. The Council is all that really matters at this point. That is as it should be, that is how ICANN is supposed to work. Though they can participate in PDPs, ACs are advisory and are not charged with making Names policy. Thank you for your input, ACs, it was highly influential and useful. Now we take it to the GNSO.

3.       Alan tries to suggest that the Council cannot pass recommendations that do not have consensus support. See item #1 above. The Council will not be voting on individual recommendations. It will vote on the entire report. Based on the current configuration of the GNSO, there is no doubt that this report can pass the Council with Consensus support. The only real opponents on the Council are IPC and BC, who constitute merely 2/3 of a single Stakeholder Group.

4.       Of course the Board will recognize the consensus of the GNSO Council. On what basis would it not? It cannot substitute its own policy for the one we developed; that violates the bylaws. The most it can do is send it back to us. Hmmm, I believe that the Board’s connection to reality is sufficiently strong that it realizes the futility of a send-back. No holdouts will change their position after another round in the ring. We are all punch drunk, nothing is going to change. The EPDP report and its current consensus designations are accurate reflections of where different elements of the community stand on Whois reform. The preponderance of support is there. We’ve done it.

Look at this with some perspective. It’s actually a bit surprising that a report as complicated as this, addressing issues as contentious as this, has as much support as it does. Surely the board is aware of that.

Dr. Milton L Mueller
Georgia Institute of Technology
School of Public Policy

> If the GNSO adopts these recommendations (either because
> all the dissenters flip or it decides to adopt recommendations
> with non-consensus support, AND the Board decides that it should
> go ahead (despite the cost, the potential LONG implementation time, and the belief of many that it will not meet their needs, then that's the end game. With "something" in place or planned, there is no way the GNSO (with 3/4 SGs basically supporting it) would we revisit this again in our life-times.

If it fails to proceed, the problems we now have are still there. Perhaps as the BC/IPC predict, there may be legislative alternatives. Perhaps if all this would be was a glorified ticketing system, then we should just build a ticketing system. Then at least we have statistics...

Perhaps the Board will decide that it needs to understand WHY we are in this position. It didn't just magically appear in a puff of smoke - there have been plenty of warning signs.

Alan

At 2020-07-30 06:13 PM, Becky Burr wrote:

I'd love to hear reactions to Volker's question (If the requestor side does not see this as an improvement over the status quo, what are we left with? What is the purpose in building this SSAD if those who are set to benefit from it do not seem to want it?) .  How should the Board see this?

On Thu, Jul 30, 2020 at 11:26 AM Volker Greimann < vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:
Conditional support is support in my book.
In my personal opinion, I should again stress that as CP we are proposing to build this system for the requestor side, not for ourselves. If the requestor side does not see this as an improvement over the status quo, what are we left with? What is the purpose in building this SSAD if those who are set to benefit from it do not seem to want it?
We seem to have divergence on Priority Levels, SLAs and Financial Sustainability. So are we better off with a system without these and should strike the recommendations altogether?
As to financing, in the end, we will still have to figure out how this system is financed and I doubt the solution ICANN comes up with will be any different than what we have proposed, especially since I doubt we will ever agree to registrants or CPs paying for this. The general principle of whoever orders the music shall pay for the band will always apply.
I would therefore like to urge all parties withholding their support to re-think their positions and move away from these all-or-nothing approaches. Having caught a small fish is better than not catching a fish at all.
Best,
--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net<http://www.key-systems.net/>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Oliver Fries and Robert Birkner
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

On Thu, Jul 30, 2020 at 2:36 PM Thomas Rickert <epdp at gdpr.ninja<mailto:epdp at gdpr.ninja>> wrote:
All, sorry itâ€™s me again.
Rafik just pointed out to me that he has written about conditional support in his e-mail. That is true and I should have mentioned that. However, conditional support is nothing that GNSO rules know as a term and the cautious interpretation thereof by the Chair is also nothing that the rules know. We will see how this plays out, but
- I would prefer for objections and support to be unambiguous so that the chairâ€™s designation is made easier (and less prone to be complained about)
- conditional support might be interpreted less cautiously as objections, particularly if there is more movement on the level of support before the deadline.
Best,
Thomas

Am 30.07.2020 um 14:14 schrieb Thomas Rickert <epdp at gdpr.ninja<mailto:epdp at gdpr.ninja>>:
Hi Rafik, all,
I hope you forgive me for writing a few lines in my personal capacity. These are not ISPCP comments, but I will point out that the ISPCP does not object to any of the recommendations in the spirit of collaboration and to support the work we have done. Are we happy with everything in the report, certainly not, but we are where we are. We know this is a challenging topic from a legal and a policy perspective and we all have to trust in the system to be improved over time when there will be more trust in such system and less areas that are unknown.
Looking at the number of objections is quite shocking. We only have full consensus on 1 recommendation. A few quick points:
1. How shall a system be implemented / operationalised absent a recommendation on financial sustainability? We have divergence there, which means that we have nothing for the Council or ICANN Org to lean.
2. Accuracy was taken off the table by the GNSO Council, so I am not sure whether it is adequate wo withhold support for recommendations because the accuracy part has not been worked on. Many ISPCP members have an interest in the accuracy discussion, but that will be dealt with elsewhere.
3. Recommendation 18 is bordering divergence. The system will only get better if there is a good process for making it better within the boundaries of what can be done under GNSO rules. I think the compromise that was struck is a good basis for that. Changes to the system will be even harder if there is no good support for Rec. 18.
4. Question for Rafik: How will you deal with conditional support? As far as I know the rules, there is nothing describing conditional support. Will you consider these as objections? That would change the landscape, in particular with respect to Rec. 18.
Thanks for reading thus far.
Best,
Thomas

Am 30.07.2020 um 12:07 schrieb Rafik Dammak <rafik.dammak at gmail.com<mailto:rafik.dammak at gmail.com> >:
Hi all,
Thanks for reviewing the consensus designation and sending by the deadline your input to indicate support or objection to recommendations. I revised the consensus designation based on what was received by the deadline.
I will give 24 hours for final review to check the revised consensus designation, 31st July 12:00PM UTC. The staff still needs to finish attaching the different pieces for the final report by the deadline. I would like to emphasize one thing in particular. Regarding ALAC conditional support for SSAD related recommendations, unfortunately I have cautiously interpreted them as opposition for several reasons.  Of course, if the ALAC disagrees with this designation, they can share their input by the deadline.
I cannot find any mention in the GNSO working group guidelines covering such cases. I also cannot recall similar precedents in previous GNSO PDP WGs. The consensus designation is supposed to be final at the time of publication and report submission and shouldnâ€™t be amended when moving to GNSO council review since they are to some extent the basis for council decision on approving or not. The GNSO council will review the report and policy recommendations in order to make a decision. I will highlight in my communication by the time of submission and during the presentation of the report the positions indicated by the groups regarding consensus and their minority statements. I understand the intent and request for consideration made to GNSO council but procedures didnâ€™t envision such a situation of having consensus designation in undecided or pending state and in my role as chair or council liaison I am bound to follow the procedures. I cannot guarantee GNSO council decisions or actions.
On a separate note, in order to close out final issues, can RrSG can respond to Laureen's last message on PPSAI (recommendation #19)? On recommendation #7, I took the note of the latest language agreed by RySG and BC, removing the RySG no-support of the recommendation. I have concluded that BC doesnâ€™t agree to drop the footnote and as result I have taken note of the NCSG opposition in the consensus designation.
Best Regards,
Rafik
<Consensus designation table - 30 July 2020 .docx>_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200731/7916baa1/attachment-0001.html>