[GNSO-Accuracy-ST] Potential Questions for ICANN Org

Stephanie E Perrin stephanie.perrin at mail.utoronto.ca
Tue Nov 23 19:47:19 UTC 2021

With respect, Mike, I don't think we should ask any of these questions 
until we ask"

Can the Compliance group share the legal review of their policies and 
procedures that they conducted in order to ensure compliance with data 
protection law and practices?

I would agree with Volker that presenting 29 new questions is really 
straying over the guidelines surrounding the role of the neutral chair.  
It is also far too much homework to load on us at this time.  I would 
also reiterate my call to cancel the meeting this Thursday, attendance 
is too low to be productive.  I appreciate the Chair's willingness for 
self sacrifice, but it is not reasonable to insist on this meeting at 
this time.

Kind regards

Stephanie Perrin

On 2021-11-23 11:07 a.m., Michael Palage wrote:
> Hello Volker,
> Thank you for sharing your concerns as I do take them very serious. In 
> fact, I believe there were times in the last EPDP Phase 2A work that 
> members of the BC raised concerns about Keith’s objectivity as chair 
> which he was successful able to navigate.
> So the first issue that I would like to address is what actions did I 
> specifically take.  If you notice I did not insert these “potential” 
> questions into the Google Doc.  What I did is share them with the 
> group to help stimulate discussion based upon me doing the homework 
> that was assigned to the Working Group. I am very much an eat your own 
> dog food type of person. I am not going to ask the Working Group to 
> undertake an assignment without myself doing it. This is my own 
> “checksum” to make sure that what is being asked of the Working Group 
> members is reasonable, or perhaps more importantly doable.
> Now when the Working Group convenes on December 2^nd to finalize the 
> list of questions, the Working Group as a whole may decide they only 
> want to send seven questions to ICANN. If that happens I am totally 
> fine with that outcome, and it would be inappropriate for me to 
> override the consensus of the group and insert any questions that I 
> wanted.
> While I have previously read the GNSO Working Group Guidelines that 
> you cited, I believe the more informative document that has guided me 
> as Chair is the ICANN Consensus Playbook. (P.S. Shout out to Marika 
> for suggesting that I read this document when I accepted this 
> appointment). I have been specifically guided by the role of the chair 
> to “facilitate” informed discussions and to make sure that I am 
> listening to the concerns of all stakeholders in striving to achieve 
> consensus. That is the North Star by which I will continue to serve as 
> Chair/Facilitator of this Working Group.
> One important point that I would like to remind everyone about is that 
> this Working Group is NOT making any specific policy recommendations. 
> What we are undertaking is a mostly factual exercise to scope the 
> issue and report back to Council for them to determine whether there 
> is a problem that needs to be addressed.  As it may not come as a 
> surprise to many, there are some Working Group members that believe 
> that there is no accuracy problem, whereas as others believe that 
> there is a problem.  Our job is to document the facts that currently 
> exists, and then provide a report to the GNSO Council by ICANN75 so 
> that they can make a determination as to next steps.
> Best regards,
> Michael
> *From:* Volker Greimann <volker.greimann at centralnic.com>
> *Sent:* Monday, November 22, 2021 6:09 PM
> *To:* michael at palage.com
> *Cc:* gnso-accuracy-st at icann.org
> *Subject:* Re: [GNSO-Accuracy-ST] Potential Questions for ICANN Org
> Hi Mike,
> while I appreciate your work and enthusiasm, I feel that you may be 
> overstepping your role as chair a bit here:
> As outlined in the GNSO Working Group Guidelines, the purpose of a 
> chair is to call meetings,
> preside over working group deliberations, manage the process so that 
> all participants have the
> opportunity to contribute, and report the results of the working group 
> to the Chartering
> Organization. These tasks require a dedicated time commitment as each 
> call has to be
> prepared, the agenda concretized, and relevant material has to be 
> reviewed. The chair shall be
> neutral. While the chair may be a member of any group which also has 
> representation on the
> working group, the chair shall not act in a manner which favors such 
> group. The chair shall not
> be a member of the working group for purposes of consensus calls.
> If the group only wanted to ask these seven questions, this does not 
> mean the chair gets to insert his own to make up for the perceived 
> deficit.
> The role of the chair is to be a neutral arbiter for the rest of the 
> group members, not a partisan for one or more of the groups 
> represented. As members, we need to trust that the chair is truly neutral.
> Please consider the importance of your role when making suggestions.
> Best,
> -- 
> Volker A. Greimann
> General Counsel and Policy Manager
> 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.
> This email and any files transmitted are confidential and intended 
> only for the person(s) directly addressed. If you are not the intended 
> recipient, any use, copying, transmission, distribution, or other 
> forms of dissemination is strictly prohibited. If you have received 
> this email in error, please notify the sender immediately and 
> permanently delete this email with any files that may be attached.
> On Mon, Nov 22, 2021 at 10:59 PM Michael Palage <michael at palage.com> 
> wrote:
>     Hello All,
>     As I mentioned in my previous email today, I found it a bit
>     disappointing that we have only proposed 7 questions to ICANN Org.
>     Therefore, over the weekend I did a lot of re-reading and
>     re-listening to our plenary calls and I have composed the
>     following working list of potential questions that the group may
>     want to ask ICANN. This is not an exhaustive list, but I will
>     continue to try and seed the discussion within the group prior to
>     finalizing the list of questions to ICANN.
>     Best regards,
>     Michael
>     Potential Questions:
>      1. Does ICANN Org have any internal documentation regarding
>         “accuracy” or “registration data inaccuracy” complaints which
>         they use for internal training and/or onboarding of new ICANN
>         Compliance team members? If so, can they please share it with
>         the Working Group?
>      2. If ICANN Org does not have internal training and/or onboarding
>         documentation to provide guidance on the meaning of accuracy
>         or registration data inaccuracy, is it up to individual
>         Compliance team members to apply their own subjective
>         interpretation of the relevant contracts and parties? If so,
>         how does ICANN Compliance management resolve potential
>         conflicts between divergent assessments from Compliance team
>         members?
>      3. The Working Group’s current best understanding of the
>         “contractual construct” regarding accuracy as understood by
>         the Working Group is:
>     Accuracy is syntactical accuracy of the registration data elements
>     processed by Registrars and certain Registries as provided by the
>     Registered Name Holder or Account Holder as well as the
>     operational accuracy of either the telephone number or the email
>     address.
>     To be determined to be syntactically accurate, the contact must
>     satisfy all requirements for validity (See Whois Accuracy Program
>     Specification Sections 1b-d). For example, for email addresses all
>     characters must be permissible, the “@” symbol is required, and
>     there must be characters before the “@” symbol.
>     To be determined to be operably accurate, the contact must be
>     operable as defined in the Whois Accuracy Program Specification
>     Section f. The RAA currently requires validation of syntactical
>     accuracy and verification of operational accuracy including an
>     affirmative response from the Registered Name Holder for either
>     email or phone.
>     Can ICANN Org share any thoughts or concerns with this contractual
>     construct based on their existing operational practices involving
>     accuracy?
>      4. Under this contractual construct cited above would the
>         following RDDS information be deemed accurate provided that
>         the registrar got an affirmative response from the email
>         account listed below:
>     Domain Name: DISNEY-LOGIN.ORG <http://DISNEY-LOGIN.ORG>
>     Registrant: Mickey Mouse
>     Organization: Disney
>     Email: disney-login at protonmail.com
>     Telephone: +1-407-934-7639
>     Address:1375 E Buena Vista Dr, Orlando, FL 32830
>     If ICANN Compliance was to receive a Data Inaccuracy Complaint in
>     connection with the above referenced RDDS data fields, and they
>     were to contact the Sponsoring Registrar who provided proof of an
>     affirmative response from the email would ICANN Compliance deem
>     this accurate and close out the ticket? If not why, and what next
>     steps would ICANN Compliance undertake.
>      5. In the Whois Accuracy Program Specification to the 2013 RAA,
>         there is a requirement to “verify” either the Registered Name
>         Holder’s email or telephone with an affirmative response. Can
>         ICANN Compliance confirm that there is no such affirmative
>         response requirement in connection with the 2003 Whois Data
>         Reminder Policy?
>      6. When ICANN Compliance audits Registrars regarding Whois Data
>         Reminder Policy obligations there is a requirement for
>         Registrars to provide “copies of each WDRP Notice or an
>         electronic database documenting the date and time, and the
>         content, of each WDRP notice sent under this policy.” However,
>         there does not currently seem to be any requirement the
>         Registrars prove that the reminder was received, just that it
>         was sent. As part of this audit process does ICANN inquire
>         about email bounce backs, disconnected telephone numbers or
>         returned postal communication, if so what are these follow-up
>         questions and/or remedial actions that ICANN takes.
>      7. The Whois Data Reminder Policy references “registrant” whereas
>         the Whois Accuracy Program references “Registered Name
>         Holder”. Section 1.16 of the 2013 RAA defines "Registered Name
>         Holder" as the holder of a Registered Name. Can ICANN
>         Compliance please reconcile the use of these terms.
>         Specifically does ICANN Compliance deem a proxy provider as
>         the “registrant” under the 2003 Whois Data Reminder Policy?
>         Additionally, does ICANN Compliance deem a proxy provider as
>         the “Registered Name Holder” under the 2013 RAA?
>      8. Is ICANN Compliance or ICANN Legal aware of any instances
>         where any contracting party has argued that the terms
>         “registrant” and the “Registered Name Holder” are not
>         equivalent. If so, can ICANN Org summarize this divergent
>         position taken by the contracting party and ICANN Org’s
>         response and how any dispute was resolved.
>      9. ICANN Compliance during their update to community at ICANN72
>         stated:
>     This isn't  much  new  information,  but  wanted  to  give
>     everyone  an
>     outline of how we've adjusted our compliance process since
>     essentially
>     GDPR which  was  May  of  2018  when  the  temporary
>     specification  went
>     into effect.  Namely,  the  things  that *we  need  to do  now 
>     are  to  obtain *
>     *additional information and background from our reporters in order
>     to *
>     *verify complaints, this usually confirming they're the registrant
>     if that’s *
>     *the case, getting additional stuff that might have been otherwise *
>     *displayed in the WHOIS prior to May of 2018. *(emphasis added)
>     Can ICANN cite the legal authority by which they are processing
>     this non-public Registrant data? Does ICANN acknowledge that they
>     are the sole Controller for this information that they are
>     collecting and processing? If this information is forwarded to
>     Registrars and/or Registries for action, does ICANN Org deem that
>     contracting party a Processor or Joint Controller? Has ICANN
>     undertaken a Data Privacy Impact Assessment (DPIA) in connection
>     with the processing of this non-public Registrant Data? If so can
>     it provide the Working Group a copy of that DPIA.
>     10. According to the quote above, ICANN Compliance stated that
>         complaints are “usually” from the Registrant. Does ICANN
>         provide any metrics on the Data Inaccuracy complaints from
>         Registrants/Registered Name Holders and third parties? If so
>         can ICANN Compliance provide those numbers.
>     11. One of the more popular Closure Code Descriptions cited by
>         ICANN Compliance for Registration Data Inaccuracy is “the
>         domain is suspended and the registrar is not required to
>         address the WHOIS inaccuracy complaint”. Given that there are
>         some Registry Abuse Programs that result in the suspension of
>         a domain after inaction by a Registrar, does ICANN appreciate
>         the potential gap in their reporting.  A complaint against a
>         Registrar regarding inaccurate registration data may be closed
>         out through no action of the Registrar, but instead solely the
>         action of the Registry. Does ICANN acknowledge that
>         non-complaint Registrars may be slipping through the cracks
>         because of the actions of pro-active Registry Operators.
>     12. Some of the Closure Code Descriptions listed by ICANN for Data
>         Inaccuracy include: the complaint is out of scope because it
>         is a duplicate of a closed complaint; the complaint is out of
>         scope because it is regarding a country-code top-level domain;
>         the complaint is out of scope because the complainant did not
>         provide the requested information; the registrar verified the
>         domain's WHOIS information is correct; the registrar corrected
>         its noncompliance; and the WHOIS data has been updated. Can
>         ICANN Compliance provide a list of all applicable/potential
>         Closure Code Descriptions for Data Inaccuracy?
>     13. What is the legal basis that ICANN believes a Registrar is
>         exempt from ensuring accurate registrant data with a
>         “suspended” domain name?
>     14. Has ICANN as part of its Registry and/or Abuse Audits every
>         surveyed Registries to determine how many domain names they
>         suspended under their Abuse Policy after the failure of a
>         Registrar to act?
>     15. Section 3.7.2 of the 2013 ICANN Registrar Accreditation
>         Agreement (RAA) states that “Registrar shall abide by
>         applicable laws and governmental regulations.” Does ICANN Org
>         have any active mechanisms to ensure compliance with this
>         enumerated obligation set forth in the RAA? If so what are they?
>     16. Does ICANN Org have any passive mechanisms by which to receive
>         complaints from the public sector in connection with potential
>         violations of Section 3.7.2 of the RAA? If so what are they?
>     17. Does ICANN Org have any passive mechanisms by which to receive
>         complaints from the public sector in connection with potential
>         violations of Section 3.7.2 of the RAA? If so what are they?
>     18. There are multiple terms in the 2013 RAA referencing
>         “reasonable and commercially practicable”; “commercially
>         reasonable efforts”; and “commercially practical updates” who
>         makes the determination on what is commercially practicable or
>         reasonable, i.e. ICANN, Contracting Parties, mutual agreement
>         between ICANN and Contracting Parties?
>     19. What standard does ICANN Compliance currently use in
>         determining commercially “practicable” and “reasonable”?
>     20. Has ICANN Legal provided guidance to ICANN Compliance on how
>         to determine commercially “practicable” and “reasonable”?
>     21. When was the current standard for “practicable” and
>         “reasonable” adopted and what are the mechanisms for modifying
>         this standard?
>     22. If a standard does not exist, when does ICANN Org anticipate
>         creating one.
>     23. Currently there is no choice of law provision in either the
>         2013 RAA or baseline Registry Agreement. However, in one of
>         the few arbitrations between ICANN and a contract party, ICANN
>         requested the Tribunal to apply California contract law, see
>         https://www.icann.org/en/system/files/files/terms-of-reference-09may12-en.pdf
>         .  Does ICANN Legal believe that California contract law still
>         applies in connection with any potential conflict in
>         interpreting either the 2013 RAA or the Registry Agreement?
>         Has ICANN Legal’s position change on the applicability of
>         California contract law since 2012, if so how and can ICANN
>         Legal provide an update on its applicability?
>     24. Section 1.e of the Whois Accuracy Specification Program
>         contained in 2013 RAA states that Registrars will “[v]alidate
>         that all postal address fields are consistent across fields
>         (for example: street exists in city, city exists in
>         state/province, city matches postal code) where such
>         information is technically and commercially feasible.” ICANN
>         Org and the Registrars engaged in a multi-year consultation to
>         evaluate the technical and commercial feasibility. It appears
>         that the last update given to the community was in March
>         2018.  Can ICANN Org please provide an update on this work and
>         an estimation completion date?
>     25. In connection with the work on address cross field validation,
>         the ICANN wiki states “ the objective of ICANN is to come to a
>         mutual agreement that will result in a minimum of two-thirds
>         (2/3) vote in support of the defined solution(s) by the ICANN
>         Accredited Registrars.” See
>         https://community.icann.org/display/AFAV. Does this 2/3
>         support vote for technical and commercial feasibility for
>         cross field address validation apply to the other commercial
>         feasible and practicable standards referenced in the 2013 RAA?
>     26. In WIPO UDRP Proceeding D2021-1050, the Panelist detailed
>         multiple “inaccurate disclosures” regarding the registrant of
>         the domain name in question and other “misconduct by the
>         Respondent and by the Registrar.” The Panelist further wrote
>         that “[t]his is an issue that the Panel believes should be
>         addressed by ICANN, and the Panel requests that the Center
>         share this decision with ICANN so that ICANN may consider
>         whether to impose restrictions on such behavior by
>         registrars.” Can ICANN confirm if WIPO ever contacted ICANN
>         compliance in connection with this dispute and what if any
>         actions did ICANN Compliance take?
>     27. Because WIPO Proceeding D2021-1050 documented a clear conflict
>         of interest between a Registrar and a Privacy Proxy provider
>         does ICANN believe it may need to revisit its reporting
>         Compliance report procedures?
>     28. During ICANN72 ICANN Compliance stated that several complaints
>         regarding access to non-public registrant data were closed
>         after they were deemed out of scope once that Proxy Provider
>         information was disclosed. Considering the findings in WIPO
>         Proceeding D2021-1050, can ICANN Compliance detail what if any
>         safeguards are in place to document and remedy false and/or
>         inaccurate information associated with Privacy and Proxy
>         registrations?
>     29. Does ICANN Compliance have a formal reporting channel for UDPR
>         and URS providers to share information with ICANN compliance
>         regarding false or inaccurate Registrant data?
>     _______________________________________________
>     GNSO-Accuracy-ST mailing list
>     GNSO-Accuracy-ST at icann.org
>     https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>     _______________________________________________
>     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-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
> _______________________________________________
> 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: <https://mm.icann.org/mailman/private/gnso-accuracy-st/attachments/20211123/0dfa8267/attachment-0001.html>

More information about the GNSO-Accuracy-ST mailing list