2019-08-19 New gTLD Subsequent Procedures PDP

Notes/ Action Items

Actions:

Reserved Names:

ACTION ITEM: Liaise with the RPM PDP WG to understand their discussions on reserved names and any overlap.

Registrant Protections:

ACTION ITEM re: ALAC General Comments on registrant protections: Ask ALAC to give examples of where applicants failed to meet the registrant protection standards that were allowed to proceed.

Notes:

1. Welcome and Updates to Statements of Interest: No updates provided.

2. Review of summary document – See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR4AI/edit?usp=sharing [docs.google.com]

a. Reserved Names (continued discussion, start at page 7)

Ability to reserve an unlimited number of second level domain names and release those names at the RO’s discretion through ICANN-accredited registrars.

-- A number of comments oppose any limit on these reservations.

-- Some support for some form of limit.

-- Concerns if names are being released from reservation after Sunrise.

-- RrSG – Concern/New Idea: Counter to the allocation of domain names via the registrar.  When names are released they should be allocated thorough the registrar.

Sunrise process for second-level domain names removed from a reserved names list and released by a registry operator.

-- Support a sunrise period for subsequent releases.

-- Process only required if commercially feasible.

-- INTA/Valideus: Second sunrise may not be feasible, but support measures to allow trademark owners, with trademark recorded in TMCH, to have right of first refusal.

-- RySG: Does not support

Discussion:

-- For geoTLDs important to be able to reserve names independent from any limits.

-- Right of first refusal extend right beyond TM owners in real world.

-- RPMs PDP WG discussed the 100 names that registries can reserve.  Also discussed QLP and ALP.

ACTION: Liaison with the RPM PDP WG to understand their discussions on reserved names and any overlap.

SAC090: Advisory on Stability of the Domain Namespace:

-- Names on the special use list.  .onion was added recently.

Questions from the SSAC:

-- If the IETF updates the special use list, how do the groups communicate with each other?

-- What if there is a round ongoing and there are strings that match something that the IETF is recommending to be reserved?  IETF liaison to the Board could be required to notify ICANN if a applied-for string is a match for a word the IETF is seeking to reserve.

-- How should ICANN discover and respond to future collisions between private names and proposed new ICANN-recognized gTLDs.

Discussion:

-- RFC6761 – how and why to have a special use domain: Do not operate like top-level domain registries.  Generally for different purposes, such as testing, or private applications.  The intent was that these would not enter the root at all.  They are not supposed to resolve.

-- Are these questions really for this PDP WG?  Seems to be one level up.

-- .onion was a good example – only resolves if you are using their app. 

-- Are these names temporary, or once they are assigned they are assigned permanently?  Most are permanent.  Need to know more about their criteria.  What is the policy question here?  Note that these are not TLDs.

-- IETF would not be looking to use a name that already exists as a TLD.

-- .home, .corp, .mail addressed through NCAP.

b. Registrant Protections (page 9)

High-Level Agreements:

-- Generally support or not oppose maintaining existing registrant protections, including EBERO etc.

-- Generally support providing TLDs exemption from spec 9 and spec 13 from EBERO requirements.

-- Supported improving the background screening process.

General Comments about registrant protections:

-- ALAC: Might be special circumstances that require adjusting the evaluation process.  Do a better job of applying standards.  ACTION ITEM: Give examples of where applicants failed to meet the registrant protection standards that were allowed to proceed.

-- Any exemptions to RPMs should be address by the RPM PDP WG.

General Comments on EBERO:

-- Not appropriate for some models of registries.

-- Requiring both the EBERO and COI is unnecessarily burdensome.

-- Relationship between an EBERO and COI should be clarified.

EBERO exemption for single registrant TLs (including under Spec 13):

-- ICANN Org: WG should clarify whether the EBERO exemption applies only to single registrant TLDS, or all ROs with Spec 13.

-- Exemption from EBERO should include exemption from COI and apply to registries with exemption from Spec 9.

-- SSAC: Exempting any TLD from EBERO should be considered carefully.

Proposal to extend the background screening exemption currently given to publicly traded companies to include exemption for officers, etc.

-- Some support and some oppose.  Split in the comments.  Suggest no support to change the status quo.

Proposal to make background screenings more accommodating.  Some support.

Timing of background screening.

-- ICANN Org: Given the large number of change requests on Q11 from 2012 round, consideration should be given to whether background screening should be performed during Initial Evaluation or at Contracting.

Proposed additional questions for background screening:

-- Some support and some oppose.  Address online.

Discussion:

-- What happens when the COI runs out or if the registry fails after the COI is returned?  These are important questions but not sure they can be addressed by this WG.

-- Spec 9, Registry Code of Conduct  -- there is a provision to get an exemption from the code of conduct (part of Spec 9) – only being used by the registry operator or its affiliates.  Here, for those entities being granted that exception they also should be granted exemption from Spec 13.

-- Sounds like it make sense to do the background check once and on the right people.