[Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 12 October 2017

Thu Oct 12 04:10:34 UTC 2017

Dear Work Track members,

Please see below the action items and notes from the meeting today.  These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/x/uYJEB.

Slides are attached for reference and some chat room excerpts are included.

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

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

NOTES/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.

Steven Chan

Policy Director, GNSO Support

ICANN

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

steve.chan at icann.org

mobile: +1.310.339.4410

office tel: +1.310.301.5800

office fax: +1.310.823.8649

Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.

Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO

Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/

http://gnso.icann.org/en/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171012/c0099237/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubPro WT4 Meeting #20 (1).pdf
Type: application/pdf
Size: 510753 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171012/c0099237/SubProWT4Meeting201-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2018 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171012/c0099237/smime-0001.p7s>