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

Wed Dec 1 14:35:21 UTC 2021

Hello Roger,

The objection of the RrSG is noted. As per my previous email we will now
revert to this topic before we begin our GAP analysis.

Best regards,

Michael

From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> On Behalf Of
Roger D Carney via GNSO-Accuracy-ST
Sent: Wednesday, December 1, 2021 9:13 AM
To: gnso-accuracy-st at icann.org
Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition

Good Morning, 

Thank you for your note Michael, but I think it may be a bit misleading and
the RrSG does not (and did not) agree with the suggested updates to the
current working definition of accuracy.

As you have reviewed the call on Nov 4th several times, you will have noted
that I objected to these changes around the 1 hour and 11 minute point.
Specifically, around adding any mention of identity requirements as that is
just not the case in our contract or policy. I believe the reference to
ICANN's report/memo below in your email, leaves off some important
language/context. First, this report provides information on how ICANN
Compliance operates, it does not add requirements (that is only done in
contracts or Policy). Second, as I have mentioned several times, the mention
of "identity" here does not (and cannot, see first point) add any
requirements on the CP, it only states that ICANN Compliance may ask for
"...further information concerning their findings...", it does not ask or
even suggest that the Registrar do anything more than what they have already
done in their investigation.

The one item I do believe we agreed to was around the "affirmative response"
idea. I don't have the specifics on this one but I think Sarah brought up
support on adding language around that idea.

Additionally, as I (and others) have mentioned many times we did not provide
a proposed definition we provided the current working definition. I
understand that people may want to  update/expand that definition and I
believe that is why the GNSO Council formed this Scoping Team. 

I will also point to prior calls, like the Oct 21st call where this working
definition was presented, and we had agreement from several SGs, staff and
the Chair that this was the baseline definition that we would work from
moving forward. I will note that I saw no chat nor anyone speak in objection
to this working definition. I once again brought this point of agreement up
during our ICANN session (36 min) and once again I did not see or hear any
objections to this being the baseline. Obviously, some minor tweaks would
occur, but the suggested changes were not minor and adds responsibilities
that just do not exist today.

To be clear the RrSG does not agree with the suggested updates to the
working definition. 

Thanks

Roger

  _____  

From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org
<mailto:gnso-accuracy-st-bounces at icann.org> > on behalf of Michael Palage
<michael at palage.com <mailto:michael at palage.com> >
Sent: Tuesday, November 30, 2021 1:57 PM
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>
<gnso-accuracy-st at icann.org <mailto:gnso-accuracy-st at icann.org> >
Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
Construct/ Definition 

Caution: This email is from an external sender. Please do not click links or
open attachments unless you recognize the sender and know the content is
safe. Forward suspicious emails to isitbad at .

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, Skype:  LSSchulman

lschulman at inta.org <mailto:lschulman at inta.org> , 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

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