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

Tue Nov 23 17:47:37 UTC 2021

Hello Lori,

The Google Doc is free for anyone to include questions.  There is no
requirement for consensus in connection with this specific task. That being
said individuals and/or groups that pose questions via the Google Doc will
be asked to explain/justify their inclusion.  This is exactly what Alan did
on our last call regarding the four questions he posed. The reason for the
"vetting" of questions is to ensure that we are not asking a question that
has been previously asked in the documents provided by ICANN Org or a
question that is totally out of scope.  Hopefully this provides the
additional clarity that you were seeking.

Best regards,

Michael

From: Lori Schulman <lschulman at inta.org> 
Sent: Tuesday, November 23, 2021 12:35 PM
To: michael at palage.com; 'Volker Greimann' <volker.greimann at centralnic.com>
Cc: gnso-accuracy-st at icann.org
Subject: RE: [GNSO-Accuracy-ST] Potential Questions for ICANN Org

Hi,

In reading this exchange, I do have a question for clarification.  Does the
list of questions have to have consensus or can anyone with a question add
to the list and it will be asked?  I favor the second the option.   As this
is not a policy document, I do not see why simple questions would need
consensus to be asked of ICANN org.  However, I may be misunderstanding the
task. 

With kind regards,

Lori S. Schulman

Senior Director, Internet Policy

International Trademark Association (INTA)

+1-202-704-0408, Skype:  LSSchulman

lschulman at inta.org <mailto:lschulman at inta.org> , www.inta.org
<blocked::http://www.inta.org> 

From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org
<mailto:gnso-accuracy-st-bounces at icann.org> > On Behalf Of Michael Palage
Sent: Tuesday, November 23, 2021 11:07 AM
To: 'Volker Greimann' <volker.greimann at centralnic.com
<mailto:volker.greimann at centralnic.com> >
Cc: gnso-accuracy-st at icann.org <mailto:gnso-accuracy-st at icann.org> 
Subject: Re: [GNSO-Accuracy-ST] Potential Questions for ICANN Org

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 2nd 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
<mailto:volker.greimann at centralnic.com> > 
Sent: Monday, November 22, 2021 6:09 PM
To: michael at palage.com <mailto:michael at palage.com> 
Cc: gnso-accuracy-st at icann.org <mailto: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
KEY-SYSTEMS GMBH

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W:
<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sy
stems.net%2F&data=04%7C01%7Clschulman%40inta.org%7C83f95b6584c242ade73208d9a
e9b8118%7C1b6dad14b17645319562fdf3080f9d47%7C0%7C0%7C637732805941122240%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000&sdata=kKAp2JZZQW9XzgTCsXes7n%2FC2OpxF0COcm9IE7AiMl8%3D&res
erved=0> 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
<mailto: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
<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdisney-log
in.org%2F&data=04%7C01%7Clschulman%40inta.org%7C83f95b6584c242ade73208d9ae9b
8118%7C1b6dad14b17645319562fdf3080f9d47%7C0%7C0%7C637732805941122240%7CUnkno
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn0%3D%7C3000&sdata=SiRkoZ0YiOaaRttCn5YbFkMKr76IDfQnfJle4skmpGw%3D&reserved
=0> 

Registrant: Mickey Mouse

Organization: Disney

Email: disney-login at protonmail.com <mailto: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.pd
f
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann
.org%2Fen%2Fsystem%2Ffiles%2Ffiles%2Fterms-of-reference-09may12-en.pdf&data=
04%7C01%7Clschulman%40inta.org%7C83f95b6584c242ade73208d9ae9b8118%7C1b6dad14
b17645319562fdf3080f9d47%7C0%7C0%7C637732805941132194%7CUnknown%7CTWFpbGZsb3
d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
sdata=9mq74Kobhb42jx0g4AIPYH28TBMO8UZ1F9mKzBRE9so%3D&reserved=0>  .  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
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity
.icann.org%2Fdisplay%2FAFAV&data=04%7C01%7Clschulman%40inta.org%7C83f95b6584
c242ade73208d9ae9b8118%7C1b6dad14b17645319562fdf3080f9d47%7C0%7C0%7C63773280
5941132194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tEwBS8S7JwZR1lOb0LhdZ9j2ln5B7Vt%2BivQ
CH8CAl2I%3D&reserved=0> . 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 <mailto:GNSO-Accuracy-ST at icann.org> 
https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.
org%2Fmailman%2Flistinfo%2Fgnso-accuracy-st&data=04%7C01%7Clschulman%40inta.
org%7C83f95b6584c242ade73208d9ae9b8118%7C1b6dad14b17645319562fdf3080f9d47%7C
0%7C0%7C637732805941142148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UcjkfnYkzCowLWYquuK%2
FIxrZImBEn6T3RaHYFVKJmTQ%3D&reserved=0> 

_______________________________________________
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
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann
.org%2Fprivacy%2Fpolicy&data=04%7C01%7Clschulman%40inta.org%7C83f95b6584c242
ade73208d9ae9b8118%7C1b6dad14b17645319562fdf3080f9d47%7C0%7C0%7C637732805941
142148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z1wZhUC3eShNiQjAqyefGHb5BeHfRG0zB%2FjlJmO
flHE%3D&reserved=0> ) and the website Terms of Service
(https://www.icann.org/privacy/tos
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann
.org%2Fprivacy%2Ftos&data=04%7C01%7Clschulman%40inta.org%7C83f95b6584c242ade
73208d9ae9b8118%7C1b6dad14b17645319562fdf3080f9d47%7C0%7C0%7C637732805941152
101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
aWwiLCJXVCI6Mn0%3D%7C3000&sdata=JE%2F3VVUE5cA7uY0r4NSDzgLAz4D34UGWiJPPU3ZFIu
g%3D&reserved=0> ). 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/68c9fb18/attachment-0001.html>