[Gnso-newgtld-wg-wt2] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 2 - 21 December 2017

Thu Dec 21 16:06:43 UTC 2017

Dear Work Track members,

Please find below the action items and discussion notes from today’s call.  These high-level notes are designed to help Work Track members navigate through the content of the call and are not a substitute for the chat transcript or the recording.

The referenced documents are attached.

Wishing you all a wonderful holiday and a very Happy New Year!

Best,

Julie

Julie Hedlund, Policy Director

--------------------------------------------------------------------------

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 2 – 21 December 2017 

1.  Calls Rotation Times and Next Meeting:

-- The calls rotate between 1500, 2100, and 0300 UTC (in that order).

-- The next meeting is Thursday, 18 January 2018 at 2100 UTC.

2. SOI Updates: None.

3. Proposals on High Level Agreements and further deliberations:

3.1 Base Registry Agreement (reference the attached document)

-- Looking at the discussions we've had on the registry agreement and trying to move toward to consensus, or no-opposition, to what we consider high-level agreement.

-- High-level agreement: Recommend a scaled back core agreement with additional specifications per category, with the goal of a single agreement with a more clear, structured, and efficient method for obtaining exemptions.

Discussion:

-- Is the definition of exclusive use registry?  Trying to avoid getting into the specifics of the different TLD types -- that discussion is being held at the full WG level.  Not all TLDs qualify as a brand TLD, but some are still exclusive use.

-- There is no restriction on someone applying for a non-generic term and then wanting to use it exclusively.  Example: .office, is under the code of conduct but isn't trademarked.

-- Is there consensus around exclusive use registries?  Also, is there consensus around closed generics?  Response: We are asking for consensus around having multiple agreements versus single agreements.  These types are just listed as an idea of what multiple types might be.  There are no conclusions on what these categories are.  If there are multiple TLDs in what form might ICANN sign a registry agreement?  We can remove the chart and ask whether there is support for a single agreement and say the issue of which categories are approved for future application windows was not addressed in this Work Track, except for the discussion of Closed Generics.

-- Categories tend to anticipate what future business models and then can restrict innovation.  Strive for ways to provide relief from contractual requirements that doesn't upset our policies, or have ways to add contractual requirements for certain categories.  If there is a category could show what relief they are seeking -- that is, why form a category?  Need to wait for the full WG to come to agreement on the categories.

>From the Chat:

Jeff Neuman: So Kurt - Basically acknowledge the categories that are already deemed acceptable with specifications and then a process for requesting relief for newly-developed models.

Jeff Neuman: The rationale as you stated is to promote innovation.

3.2 Registrant Protections (reference the attached document)

High-Level Agreement so far:

-- appears to be consensus to explore a different method to fund the EBERO process, but no consensus on what method to explore -- continue to discuss methods and models.

-- appears to be consensus to keep the EBERO process in cases where there is a failure of the back-end services provider, and also in keeping the triggers for the EBERO process the same as in the AGB with the existing critical registry functions.

Discussion:

-- Are brand TLDs exempt from EBERO now?  Also, if someone fails -- the question about registrant data is being handled.  Response: Currently brand TLDs have the same requirements in the code of conduct and spec 13 as other TLDs.  Also, there are no recommended changes to the existing EBERO structure and how it functions.

-- If there is a registry failure the goal in EBERO is to make sure everything continues to operate, so no need to contact registrants.

-- Under EBERO you just switch provider, but the rules don't change.  Registrants will be notified if the registrant is transitioned to a registry with different rules.  If there is an outage the registry notifies the registrars and the registrars notify the registrants.

-- EBERO = Emergency Back End Registry Operator.  It is not a failure of the front end, but of the back end.  The change of a front-end registry is a different process.

-- WT may want to examine whether or not single-registrant model registries should be exempt from other registrant protections such as data escrow.

-- Recently EBERO was triggered for the case of .wed.  The WT may want to consider analyzing further details in this matter when available.

-- Also consider analyzing instances where ICANN decided not to invoke EBERO when emergency thresholds were breached.

-- Still discussions about the desire to trigger an EBERO where there is a failure of the front-end registry operator and the back-end registry services provider is both capable and willing to continue to provide the Critical Registry Functions (reference the document for more details).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20171221/7002dbfb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Progress Document_Base Registry Agreement_clean.pdf
Type: application/pdf
Size: 41571 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20171221/7002dbfb/ProgressDocument_BaseRegistryAgreement_clean-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Progress Document_Registrant Protections_clean.pdf
Type: application/pdf
Size: 64628 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20171221/7002dbfb/ProgressDocument_RegistrantProtections_clean-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20171221/7002dbfb/smime-0001.p7s>