Page History

PROPOSED AGENDA

1. Welcome/SOIs
2. Registry Services
3. AOB

BACKGROUND DOCUMENTS

SubPro WT4 Meeting #20 (1)

Mp3

AC Recording

AC Chat

Attendees:

Apologies:  Sarah Langstone, John Levine

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 

1. Name Collisions: 

Source data from GDD Technical Services, that acts as the basis for the information being presented by Rubens, is available on the Name Collisions Wiki page here: https://community.icann.org/x/Yz2AAw 

Slide 5: What's in today's agenda and what's still ahead: 

-- Results from GDD inquiry on reported collisions

-- Whether 2012-round gTLD should keep readiness after 2 years of delegation

-- Whether SubPro gTLDs should have readiness or not, and length of such readiness.

Slide 6: Report collisions from 2012-round:

-- No life-threatening collisions;

-- 18 unique TLDs represented in 34 occurences

-- Median of 3 occurences per TLD

-- Median of 22 days between delegation and report

-- 23 cases reported as service disruption, etc.

Slide 7: Reported collisions from 2012-round (cont.):

-- In 24 cases the registry was not contacted -- determined by ICANN Org that it was not necessary.

-- In 5 the registry was put in contact with the reporter, in 1 registry stopped controlled interruption, in 1 no action.

-- Few data on outcomes -- all 5 known outcomes the network was updated.

Slide 8: Two-year readiness for current new gTLDs:

All 2012-round gTLDs were required to pass a controlled interruption period and be able to respond within two hours for life-threatening reports for first 2 years of delegation.

Options:

a) 2012-gTLDs should extend readiness beyond the 2-year period

b) 2012-gTLDs should only have such readiness in those 2 years as currently foreseen in the framework

b) 1 year

Poll:

Option a: No one.

Option b: 6 in favor

Option c: 1 in favor

From the chat:

Sarah L Verisign: Rubens can we get back to you on this later this week rather than saying now?

Cheryl Langdon-Orr (CLO ): Sarah this is a temp taking not deffinative pol

Jon Nevett: we should do a cost differential before voting

Sarah L Verisign: I understand but I need to discuss this with other folks before making even a temp position

Jon Nevett: what is the cost of the readiness -- if not a lot, not big deal

Jon Nevett: if it is a lot, then it gets passed on

Alan Greenberg: Cost is lower for orgs that have multiple TLDs, since cost of readiness for 10 is no larger than 1 and TLDs come on line at different times.

Anne Aikman-Scalese (IPC): Agree with Alan that every new gTLD is different.  Initial evaluations on name collision risk could make a big difference here.

Cheryl Langdon-Orr (CLO ): thus my 'personal' comfort with the status quo on this at 2y

Alan Greenberg: My intervention was really in relation to THIS question, not just the 2012 gTLDs.

Slide 9: Framework -- Two-year readiness for SubPro gTLDs:

Question: Should gTLDs in subsequent procedures be subject for such 2-year readiness for life-threatening collisions?

Options:

a) Same 2-hour for life-threatening collisions readiness for first -- years. (Assume keeping 2 years.)

b) No need for readiness.

c) SubPro gTLDs should have readiness covering more conditions with -- hours/days SLA

Poll:

Option a: 4 in favor

Option b: 1 in favor; 3 against

Option c: None

-- Should there be different responses for different types of TLDs?

From the chat:

Dietmar Lenden - Valideus: 2 years would appear fair for all applicants past and present

2. Registry Services:

ACTION:  Send slides 12-16 to the list and ask the list to consider and discuss on the list the three straw-persons, contrasts, and slide 16.  Take up this conversation at this point in the agenda next week.

Slide 12: Straw-person #1

Slide 13: Straw-person #2

Slide 14: Straw-person #3

Discussion on Straw-person #1:

-- Change in SP#1: When registry services are proposed that is when the community has the opportunity to comment and provide input.  You don't know the impact that the services may have.  Don't want to discourge proposals for new services.

-- On the registry services policy -- they don't have to get input from the community except when ICANN makes a finding that a concern has to be evaluated.  Then the community comments on that concern via the report of the RSEP panel.  We can go beyond that for new gTLDs.

-- With respect to input on new gTLD applications, the community doesn't have a formal process but many of us review the applications.  There are informal methods and if there is an irregularity there are ways in ICANN to raise an issue.

/ Action Items

1. None

2. Registry Services

Slide 5

-- Recollection of past discussions. E.g., means of collecting info to build Exhibit A, may have less value if done in bulk/incorported into RSP Program. Undergoing discussions might streamline registry service adoption. Possible source of innovation.

Trang Nguyen: One additional note is that if a RSP program will exist in subsequent rounds, new registry services would have to be applied for by the RSP.

-- Q: Why? Registry services can be unique to a TLD/RO. Seems like it would be submitted by the RO. Jeff not certain that it's correct statement.

-  A: Trang Nguyen: The RSP would be the one delivering the registry service. So if an applicant's business model necessitates a registry service that a RSP is not already approved for, the RSP would apply for the registry service.

Anne Aikman-Scalese (IPC): QUESTION: just to clarify, Jeff, are you saying Registry operator can offer a new service and it would not be the backend provider of registry services who applies?

A: Jeff Neuman: yes.  Not all Registry Services must be provided by the RSP

Slide 6 - SP#1

-- Reading slide

Slide 7 - SP#2

-- Reading slide

-- Believes bottom paragraph is already contained in Q23. Would not need to provide details for pre-approved services.

-- Last paragraph only reviews non-pre-approved services, so this is a change.

Jeff Neuman: P.S. it is BTAPPA, not BTPPA :)

Jeff Neuman: Bulk Transfer After Partial Portfolio Acquisition

Slide 8 - SP#3

-- Reading slide

-- Should remove contract negotiation process element in last sentence. Or change it to say that it may extend contract negotation (since RSEP possibly envisioned during contracting)

-- RSEP envisioned at contracting time, which would likely extend timeline.

-- Does this structure discourage disclosure of registry services at application time? If no new services proposed, does this speed up application processing? Anne in favor of disclosure at submission time. Some say having to disclose at submission time discourages innovation though.

--Many will say that RSEP is much more painful than during application evaluation. For RSEP, if there is a security and stability issue, does go through public comment. Also possible if there is a contractual ammendment. Many do not want to disclose as it may impact first mover advantage with innovative service.

Slide 9 - SP#4 (current implementation)

--  Reading slide (Note - Registry services were reviewed in context of technical and financial questions)

-- Should Q23 be viewed here as well for full context?

-- Reading Q23...

-- The following questions ask in detail (e.g., Q24, 25, etc.). Q23 is the big picture and not scored. 

-- Is the suggestion to remove Q23? Maybe not needed if there is only pre-approved services. How implemented, following questions, would still be needed. If you have the how, maybe you don't need the list.

-- Maybe a separate conversation neeeded to see where duplicative questions could be be removed.

-- Wasn't aware that Q23 removal would be in response to having a list of pre-approved services.

Rubens Kuhl: Anne, it's not that... what's in SP4 is a direct quote of AGB.. 

Anne Aikman-Scalese (IPC): Thank you Jeff.  I think this is a good question as it stands.  But it's possible we should have pre-approved services - they would have to be desribed in detail as a "safe harbor".

Jeff Neuman: IF there are new services, then yes we would need something that asks what those new services are and how they would implement it

Rubens Kuhl: SP4 doesn't have pre-approved services... even though 2012 AGB listed customary services, it gave no pre-approval status to them. 

Anne Aikman-Scalese (IPC): @Rubens - I think we are talking about developing pre-approved services.

Rubens Kuhl: Anne, we are. SP1, 2 and 3 all suggest pre-approved services. And that's a change from current implementation. 

Rubens Kuhl: Jeff, I believe the decision matrix will make it easier to pick individual decisions instead of an specific SP. 

Slide 10/11

-- Reading slide

-- #1 and #3 only requires applicant to inform about registry services that are not in the pre-approved list while #2 requires all services to be informed, although #2 only requires naming pre-approved services and to describe only additional services in detail.

-- #1 incorporates a list of pre-approved services by reference, although mentioning some, while #2 and #3 explicitly names a list

-- Is this a distinction without a difference? How different is by reference versus explicit list?

-- Whether or not an explicit list is needed would need to be taken to the list. 

-- What does a list of pre-approved services mean? The how would still need to be provided and evaluated?

Anne Aikman-Scalese (IPC): QUESTION:  Would there be a pre-approved manner of delivering DNSSEC as a "safe harbor" and only describe if you are doing it differently or uniquely

-- There are certain protocol needs to implement DNSSEC, but the specifics of how are widely varying.

Rubens Kuhl: In DNSSSEC: NSECxNSEC3, use or not use an HSM, supported algorithms etc. 

Anne Aikman-Scalese (IPC): Re last point on slide 11 - "last bullet point" - change "additional" to "new" in describing requirement to describe "new services"

Rubens Kuhl: Anne, since it's only a comparison instead of specific language I believe we just need to agree on the understanding, which is indeed "new" like you mentioned.

Slide 12

-- Pre-approved services

-- 2+ track

-- Timing

Slide 13 (with pre-approved services

-- Pre-approved services

-- 2+ track

-- Timing

Slide 14 (if there are pre-approved services)

-- Base Exhibit A services

-- IDN services following ICANN IDN guidelines

-- Non-mandatory block-type RPMs

-- BTAPPA ("Bulk Transfer After Partial Portfolio Acquisition)

Quoc Pham: a little off trace, I would like to just to make a statement that regardless of the straw-person that we put forward, applications should not be prioritised based on their listed registry services 

Anne Aikman-Scalese (IPC): @Quoc - very relevant and not at all off track

Rubens Kuhl: Quoc, that's what question 3. Timing is all about. 

Jeff Neuman: So, @Anne I am not sure there is a way to streamline all aspects of evaluating how one operationalizes those services that may have common protocols

Pre-approved services by reference

-- 6 yes

Take questions to list, especially since next call is cancelled-- If an applicant knows that if an applicant specifies a registry service and that it will go through more evaluation, that is a disincentive to provide that registry service early on.  Then after signing the contract they will file an RSEP.