Dear all,

 

Just to flag that I have gone in and proposed some updated language to the current accuracy description.

 

For completeness, I have also set out some background information below.

 

Background

Whilst there are no explicit provisions in the Base Registry Agreement that refer to the accuracy of registrant data, the following sections and specifications of the Base RA have a nexus to the topic of registration data accuracy.

 

Specification 11

Certain gTLDs are subject to Category 1 and 2 Safeguards, which are contained in Specification 11 of the Registry Agreement. Safeguards 5-8 may have some relevance to registration data accuracy. Safeguard 5 requires that the registrant’s administrative contact information and the contact details of the relevant regulatory, or industry self-regulatory bodies in their main place of business, is up to date. Safeguards 6-8 require an up-to-date representation that the Registrant possesses any necessary authorisations, charters, licenses and/or other related credentials for participation in the sector associated with the relevant string.

 

Some ROs also include voluntary PICs under Specification 11 that are individual to either the RO, the gTLD or both. These PICs may contain additional validation, verification, or accuracy obligations. Since these are voluntarily adopted, it does not seem appropriate for the Accuracy Scoping Team to review these individual PICs. 

 

Community gTLDs

Section 2.19 of the Base Registry Agreement (which applies to Community gTLDs only), requires Community gTLD operators to establish naming conventions and requirements for registration by members of the TLD community. Community gTLD operators are also required to comply with the community registration policies set forth in Specification 12, establish procedures for the enforcement of registration policies, the resolution of disputes under registration policies and enforce such policies. Community gTLD operators are further bound by the Registry Restrictions Dispute Resolution Procedure. 

 

Depending on the language contained in each Specification 12, to conform with the application submitted for the TLD, many Community ROs have an obligation to undertake verification or validation of registrants. Community gTLDs are intended to serve specific communities and the provisions contained in each Specification 12 are therefore unique to each community gTLD. As above, it does not seem appropriate to review these individual terms. 

 

dotBrands/Specification 13

Specification 13 restricts the registrants of the TLD to the Registry Operator, its Affiliates or Trademark Licensees. Control of the DNS records associated with domain names at any level in the TLD is likewise restricted to these parties. Each dotBrand must conduct an internal audit at least every 12 months, and provide the results of this review to ICANN, to assess whether the dotBrand is operating within the scope of Specification 13. 

 

Thanks,

Sophie

 

 

Dear All,

 

Please find below the proposed agenda for the next Registration Data Accuracy Scoping Team meeting which has been scheduled for Thursday 24 March at 14.00 UTC. As a reminder:

 

1. RDA Scoping Team members to suggest further edits to the current accuracy description, based on the discussion from Thursday’s meeting, including, for example, updated language regarding Spec. 13: https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit by Wednesday, 23 March.
2. Still open: In advance of the next meeting on Thursday, 24 March, RDA Scoping Team Members to review the Gap Analysis Proposal Review. Note: this document was compiled by Support Staff in an effort to distill the proposals made by Scoping Team Members, including upsides and downsides noted by either the proposer or other team members in subsequent discussions. The document is not meant to restrict the group into choosing one proposal, but rather, the group should review all proposals and see which proposals provide a viable path to forward progress. Note: IPC Reps: please respond to the comments directed to you in Proposal H. https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit)

 

Best regards,

 

Caitlin, Berry and Marika

 

Registration Data Accuracy Scoping Team – Meeting #22

Thursday 24 March at 14.00 UTC

 

1. Welcome & Chair Updates (5 minutes)

 

2. Accuracy working definition / construct (30 minutes)
1. Consider input received on proposed description of current accuracy requirements and enforcement (see https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit)
2. Review survey responses – see https://docs.google.com/forms/d/e/1FAIpQLSdL-R4Tk7pP86bMIRMX1tH1IA9-UgbHFYVJyznlBcQjch99Pg/viewform
3. Confirm next steps

 

3.      Continue review of Gap Analysis Data Collection Proposals (30 minutes) (see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit)

a.      Review Scoping Team input on proposals (upside, downside and possible next steps)

b.      Confirm next steps

 

4. Confirm action items & next meeting (Thursday 31 March at 14.00 UTC)