[GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition

Sat Dec 11 18:14:41 UTC 2021

Hello Sophie,

While I am not attempting to answer your previous question to Lori on her
behalf, I thought I would like to provide the following data points that may
help answer/clarify this issue for all parties in an asynchronous manner,
thus saving previous plenary time for other matters.  

In EPDP Phase 1 which the RySG fully endorsed, in Recommend 1 under "ICANN
Purposes for processing gTLD Registration Data" Paragraph 7 states in
relevant part "Enabling validation to confirm that Registered Name Holder
meets gTLD registration policy eligibility criteria voluntarily adopted by
Registry Operator and that are described or referenced in the Registry
Agreement for that gTLD." FN4 [The EPDP Team's approval of Purpose 7 does
not prevent and should not be interpreted as preventing Registry Operators
from voluntarily adopting gTLD registration policy eligibility criteria that
are not described or referenced in their respective Registry Agreements.]

Additionally, Paragraph 5 of Recommendation 1 in the EPDP Phase 1 report
further states that an ICANN purpose is Handle contractual compliance
monitoring requests and audit activities consistent with the terms of the
Registry agreement."

My recollection is that the RySG fully endorses the EPDP Phase 1 report
which is now consensus policy, so I am a little confused over the RySG's
concern about "belief" and "rights" since this seems to have already been
asked and answered. If the RySG's position on Recommendation regarding
purpose under Paragraphs 5 and 7 have change please let me know.  While
reviewing or proposing changes to the EPDP-identified purposes are outside
the mandate of this scoping team per the instructions of Council, we have
been instructed by Council to "identify this as an area of further work" if
"the scoping team finds that further review of these purposes is necessary."

Best regards,

Michael

From: Sophie Hey <sophie.hey at comlaude.com> 
Sent: Friday, December 3, 2021 1:01 PM
To: michael at palage.com; 'Lori Schulman' <lschulman at inta.org>; 'Sarah Wyld'
<swyld at tucows.com>; gnso-accuracy-st at icann.org
Subject: RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition

Hi all, 

Michael, Beth, Marc and myself would appreciate further clarity about what
information you are hoping to get from this question so we can pass this
along to the rest of the RySG.  I'm not sure we understand why you are
asking or its relevance to our current work.

During the next RySG call could you seek clarification from the RySG on
whether Registries believe they have a right under their Registry Agreement
to verify the accuracy of data elements that they process as part of domain
name registrations in their respective TLDs. Additionally, what steps if any
does ICANN Compliance take in connection with Registry Audits regarding this
verification.

 In speaking with our RySG colleagues, we received feedback that answering
the first part of the question which is framed around "belief" and "rights"
related to the Registry Agreement is not something the RySG is in a position
to respond to and probably not appropriate for them to do so.

The second part of the question you posed asks about steps ICANN Compliance
takes and is probably more appropriately addressed to them.

While the RySG is likely not in a position to respond globally, two of our
members provided responses about their individual gTLDs that we do want to
share.

.BANK and .INSURANCE:

Having worked at ICANN in a registry capacity and now operating fTLD for the
last decade, I fully appreciate that Registry Operators' business models can
vary greatly and thus I can only share fTLD's interpretations of our rights
and responsibilities for operating .BANK and .INSURANCE.

>From a community-based gTLD perspective and because fTLD's Registry
Agreements (RAs) for .BANK and .INSURANCE include unique elements, is that
we absolutely have the right, and in fact have the obligation, based upon
what is in our RAs, to verify the accuracy of domain name registration
information. The aforementioned unique elements include Section 2.19,
Obligations of Registry Operator to TLD Community; Specification 11, Public
Interest Commitments; and Specification 12, Community Registration Policies.

As a part of ICANN's audit of Registries in 2016 and 2017, our TLDs were
selected (.BANK in 2016, and .INSURANCE in 2017) and ICANN requested
verification information for a random list of domain registrations in their
Request For Information (RFI) and their RFI cited Section 2.19 and
Specification 12 as the basis of their request. 

In 2017, when fTLD determined we could more effectively and efficiently
implement the Registrant verification process rather than continuing to
outsource it, we were directed to the RSEP process by ICANN GDD Staff,
despite this process being neither a Service, nor the proposed offering of
an Additional Service, as defined in the Registry Agreement. As a result of
ICANN's position, fTLD submitted an RSEP 

(see request 2017039 accessible here:
<https://www.icann.org/resources/pages/rsep-2014-02-19-en>
https://www.icann.org/resources/pages/rsep-2014-02-19-en) detailing our
migration from a static to a dynamic registration verification process. 

Notwithstanding fTLD's obligations to perform Registrant Verification per
our RAs with ICANN, the responsibility is further enumerated in our Registry
Registrar Agreement (RRA):

*	3.3.2. Obligations of Registered Name Holder. Registrar shall
require all Registered Name Holders to enter into a Registration Agreement
with Registrar. In such Registration Agreement, Registrar shall require such
Registered Name Holder to acknowledge and agree that the Registry Operator
reserves the right to deny, cancel or transfer any Registered Name
registration or transaction, or place any Registered Name (s) on registry
lock, hold or similar status, as it deems necessary, in its unlimited and
sole discretion: (i) to comply with specifications adopted by any industry
group generally recognized as authoritative with respect to the Internet
(e.g., RFCs), (ii) to correct mistakes made by Registry Operator, Registry
Service Provider, Registry Verification Agent, Registrar and/or any other
contractually obligated vendors in connection with a domain name
registration, or (iii) for the nonpayment of Fees to Registry Operator.

*	3.9.8. Registrant shall take all necessary action(s) as directed by
Registrar or Registry Operator in relation to compliance actions,
directives, or instructions from ICANN, and/or as otherwise directed by
Registry Operator in its sole discretion as being reasonably necessary for
the provision of Registry Services and enforcing compliance with Registry
Operator's Operational and Security Requirements and Operations Pledge,
including monitoring for compliance regarding the Registered Name.

.PHARMACY

The RA for .pharmacy obligates us to verify the accuracy of the information
provided by prospective registrants. To clarify, this verification is part
of the preliminary application and review process, not the actual domain
name registration process.

Sophie Hey
Policy Advisor
Com Laude
T +44 (0) 20 7421 8250 <tel:+44%20(0)%2020%207421%208250> 
Ext 252

 <https://comlaude.com/> 

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: 30 November 2021 19:58
To: 'Lori Schulman' <lschulman at inta.org <mailto:lschulman at inta.org> >;
'Sarah Wyld' <swyld at tucows.com <mailto:swyld at tucows.com> >;
gnso-accuracy-st at icann.org <mailto:gnso-accuracy-st at icann.org> 
Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition

Hello All,

As someone that watched the video recording twice allow me to recount the
events of Nov 4th.

In advance of the call there had been two "definitions" (contractual
construction / explanations) put forth for consideration.  One by the
Registrars and the one put forward by myself.

In an effort to reconcile these two definitions, I opted to mark-up the
Registrar's "definition".  The first change was replacing the phrase "shall
strictly" with "is."  Specifically I cited to Background Briefing Assignment
#1 which stated in relevant part that:

However, if the complaint is about identity (e.g., the registrant is not who
they say they are), Contractual Compliance may ask the registrar to provide
further information. (emphasis added).

After the group acknowledged that this excerpt from the ICANN briefing
document showed a larger remit than just syntactical and operational
accuracy, the "shall strictly" phrase was redlined and replaced with 'is.".
Alan Greenburg from ALAC tired to propose an alternative wording but the
redline stayed as "is".

The next proposed redline was inspired largely by the following excerpt from
the ICANN72 GAC communique which states in relevant part:

The GAC gives particular importance to the verification, validation and
correction of all registration data by registrars, and certain registries,
in line with their contractual obligations, and supports rigorous monitoring
and enforcement of such

contractual obligations by ICANN. (emphasis added)

These changes again were made with no substantive opposition from the group.

As I have stated previously these agreed upon changes where lost when the
document was exited at the end of the call. I have consulted with ICANN Org
and they are unaware of how these changes were lost. However, I believe the
video clearly shows that the deletion was NOT an intentional act because no
one spoke to the text being removed, it just disappeared.  Please review the
video for yourself, I have provided the time stamp to help make everyone's
review easier.

Now if the RySG and RsSG are going to maintain their objection to the
previous redline "definition" and instead advocate for the RrSG "definition"
we will address this topic AFTER the we conclude the questions to ICANN Org,
but before we begin our GAP analysis.

I do have a specific request for Marc, Beth and Sofie.  During the next RySG
call could you seek clarification from the RySG on whether Registries
believe they have a right under their Registry Agreement to verify the
accuracy of data elements that they process as part of domain name
registrations in their respective TLDs. Additionally, what steps if any does
ICANN Compliance take in connection with Registry Audits regarding this
verification as I do believe it is relevant to our discussion here in this
Working Group.

Listed below are a non-exhaustive list of Registry Operators that involve
some level of accuracy /registrant vetting beyond just email and phone
accuracy (syntactical and operational) as part of their registry operations:

1.	From the original 2001 proof of concept round, .AERO was one of the
first TLD that required the process of registrant data prior to being able
to obtain a gTLD domain name registration.  If you look at the current .AERO
registration website you will see the following requirement:

Obtain your .aero ID, prior to registration of your chosen domain name
through a .aero authorised registrar, this unique validity process screens
potential domain registrants thus ensuring the integrity and the exclusivity
of the .aero domain.

See https://information.aero/registration and
https://information.aero/node/add/request-aero-id 

2.	From the 2004 Sponsored round perhaps the best example was .XXX
which made the following representations:

5.0  PREVENTING ABUSIVE REGISTRATIONS

The Registry will authenticate members of the Sponsored Community, as part
of the name registration process. As part of this process, the Registry will
validate contact information for the Registrant, secure the Registrant's
affirmative consent to the Registry-Registrant Agreement, and issue unique
Membership Credentials. The Membership Application Process must be completed
before a domain name is permitted to resolve in the TLD.

See https://www.icmregistry.com/about/policies/launch/#general_aval

3.	fTLD submitted an approved RSEP to ICANN for the processing of
Registrant information prior to registration. The name of this RSEP is
Dynamic Registration Verification and is available here, see
https://www.icann.org/en/system/files/files/rsep-2017039-bank-et-al-request-
11dec17-en.pdf This webpage shows the information that fTLD collects from
prospective registrants as part of their verification process, see
https://www.register.bank/get-started/

4.	NABP, the Registry Operator of .PHARMACY, has also vetted
prospective registrants as part of its registration process, see
https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply

5.	In addition, every .BRAND Registry Operator has a requirement to
limit registrations in that TLD to either the Brand owner or "Trademark
Licensee" so this would be a further example of where a Registry Operator is
processing data about a Registrant (e.g. Trademark Licensee) that may or may
not appear in the Whois/RDDS output.

6.	There are also numerous RSEPs filed by Registry Operators seeking
"Registration Validation" which clearly go above just syntactical and
operational validation, e.g. Chinese Real Name Verification.

I hope this removes any ambiguity as to the events of Nov 4th.  If, however,
the RySG and RrSG maintain their objection we will revisit prior to our GAP
analysis discussion as noted above.

Best regards,

Michael

From: Lori Schulman <lschulman at inta.org <mailto:lschulman at inta.org> > 
Sent: Tuesday, November 30, 2021 1:06 PM
To: Sarah Wyld <swyld at tucows.com <mailto:swyld at tucows.com> >;
michael at palage.com <mailto:michael at palage.com> ; gnso-accuracy-st at icann.org
<mailto:gnso-accuracy-st at icann.org> 
Subject: RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition

Hi,

The changes were definitely tracked.  I was under the impression that we
agreed to those changes. If so, then they should be reinserted as a
compromise that we can live with for the purposes of the scoping exercise.
Any binding definitions will be negotiated by the eventual PDP. 

With kind regards,

Lori S. Schulman

Senior Director, Internet Policy

International Trademark Association (INTA)

+1-202-704-0408 <tel:+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 Sarah Wyld
Sent: Monday, November 29, 2021 3:27 PM
To: michael at palage.com <mailto:michael at palage.com> ;
gnso-accuracy-st at icann.org <mailto:gnso-accuracy-st at icann.org> 
Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition

Hi team,

I (of course) can't speak for the registries or answer this question, but I
do want to say, I'm glad the text in the screenshot was not updated. The
definition in that section of the document should remain as we had proposed
it back on Oct 29, and any changes should be tracked elsewhere. Maybe that's
why the changes were removed?

See you tomorrow, thanks! 

Sarah

-- 
Sarah Wyld, CIPP/E

Policy & Privacy Manager
Pronouns: she/they

 <mailto:swyld at tucows.com> swyld at tucows.com 
+1.416 535 0123 Ext. 1392

From:  <mailto:michael at palage.com> Michael Palage
Sent: November 26, 2021 12:02 PM
To:  <mailto:gnso-accuracy-st at icann.org> gnso-accuracy-st at icann.org
Subject: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/
Definition

Hello All,

For those colleagues that celebrated the Thanksgiving holiday yesterday, I
hope you had an enjoyable time with your family and friends and did not eat
too much.   I would also like to thanks those team members that showed up
for our brief Administrative Call yesterday.

In preparing for the call yesterday I noted some of the new additions added
by the RySG to the questions for ICANN staff. Thank you for these additions
Roger. This flagged a previous issue which I had raised with our ICANN
colleagues last weekend and it involves the current working contractual
construct / definition.

In the RySG questions they cited to the proposed RrSG accuracy "definition"
(aka contractual construct):

"Accuracy shall be strictly defined as syntactical accuracy of the
registration data elements provided by the Registered Name Holder as well as
the operational accuracy of either the telephone number or the email
address."

Last week when I was looking for the latest and greatest contractual
construct/definition I noted that there was a technical glitch when
reviewing the Zoom recording which I will summarize below.

If you go to the Zoom recording from the Nov 4th call you will see that the
red lined version of the contractual construct/definition which was agreed
to during the call and which is reflected below.  

 However, at the conclusion of the call as we were wrapping up the session,
these edits were lost 

Therefore, I would like clarification from the RySG do they wish to cite the
group's current working contractual construct/definition that was agreed to
during the Nov 4th call, or do they intend to cite to the RrSG pre November
4th call  contractual construct/definition?

I know these technical glitches, e.g. delta in Google Doc, Alan receiving
emails, and the unavailability email archives makes things a little more
challenging. However, I know our ICANN colleagues are working on the email
issues, and I am sure we will be able to achieve most of our work
asynchronously if we put our minds to it. 

Best regards,

Michael

  _____  

The contents of this email and any attachments are confidential to the
intended recipient. They may not be disclosed, used by or copied in any way
by anyone other than the intended recipient. If you have received this
message in error, please return it to the sender (deleting the body of the
email and attachments in your reply) and immediately and permanently delete
it. Please note that Com Laude Group Limited (the "Com Laude Group") does
not accept any responsibility for viruses and it is your responsibility to
scan or otherwise check this email and any attachments. The Com Laude Group
does not accept liability for statements which are clearly the sender's own
and not made on behalf of the group or one of its member entities. The Com
Laude Group is a limited company registered in England and Wales with
company number 10689074 and registered office at 28-30 Little Russell
Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ
Limited t/a Com Laude, a company registered in England and Wales with
company number 5047655 and registered office at 28-30 Little Russell Street,
London, WC1A 2HN England; Valideus Limited, a company registered in England
and Wales with company number 6181291 and registered office at 28-30 Little
Russell Street, London, WC1A 2HN England; Demys Limited, a company
registered in Scotland with company number SC197176 and registered office at
15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum,
Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the
State of Washington and principal office address at Suite 332, Securities
Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation,
a company registered in Japan with company number 0100-01-190853 and
registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com
Laude Domain ESP S.L.U., a company registered in Spain and registered office
address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further
information see www.comlaude.com <https://comlaude.com>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211211/caa77926/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17940 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211211/caa77926/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 14051 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211211/caa77926/image002-0001.png>