[Gnso-newgtld-wg-wt1] Notes and Action Items - New gTLD Subsequent Procedures PDP WG Work Track 1 Meeting 19 September

Tue Sep 19 14:04:16 UTC 2017

Dear Work Track Members,

Please see below the action items and discussion notes from the meeting on 19 September. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording.

Slides are attached for reference.  

Kind regards,

Julie

Julie Hedlund, Policy Director

Action Items and Notes, Work Track 1, 19 September

RSP Accreditation Program (Slide 3)

Benefits and risks (Slide 4)

-- Is there any evidence of an issue about lack of competition?  Is that a mandate for this group?

-- BRG Supports the concept of an RSP program [see comments]. (Slide 5)

-- Point: Terminology re: accreditation program.   We are talking about a pre-approval process, not an accreditation program.

-- The data that ICANN has come out with wasn’t available when we did the initial draft.  The Registry RSP discussion group recently got additional information from Francisco and we are working through that to understand where the problems were, and a way to use the monitoring to resolve those problems.  There is data now.

Benefits and challenges (slide 7 & 8)

-- Nominet: Support for a lighter touch regulatory regime for established providers, support for any RSP programs would be conditional on the outcomes (slide 9)

-- Afilias, RySG, and Valideus provided comments on scalability (slide 13)

-- CIRA and Demys: feedback on additional program elements (slide 14)

-- BRG and ALAC: feedback on additional program elements (slide 15); Given ICANN's mandate on security and stability, it is most effective to set a minimum threshold for requirements up front. This seems consistent with BRG's comment to avoid barriers to entry in the marketplace.  

- 1.1.3 (slide 16)

-- Nominet: Does not see any other option than ICANN being responsible

-- Afilias, RySG, Valideus: Support for continuing to the use the model from the 2012 round

-- BRG: Support for using the same provide for testing associated with the RSP Program and application evaluation.

 Concern about statement by Afilias regarding involvement of Compliance team to confirm that all existing RSPs are meeting existing contractual requirements. This will be picked up on the next call. 

>From the chat:

Sarah L Verisign: Preapproval of an RSP without making commensurate changes to the test cases used during PDT might not improve performance at all if you take ICANNs data into account detailing the number of  EBERO triggering incidents that are occurring.  

Jeff Neuman: For clarity - and I did not have a role in drafting the comments for Valideus - but those were not challenges, but rather statements addressing the challenges raised by others.

Jim Prendergast, Afilias, Jannik Skou: Opposition to establishing an accreditation or preapproval Program at this time, recommendations for alternative mechanism to create process efficiencies (slide 10-11)

Justine Chew: Could someone remind me of the difference between "accreditation" and "certification" plse?

Donna Austin, Neustar: Justine, i don't think there is one.

Justine Chew: @Donna, really?!

Donna Austin, Neustar: Justine, in this discussion we have generally used them interchangeably. So I'm sure there is a difference, but in this context i don't believe there is.

Rubens Kuhl: Justine, this is an area where there is the market reading of the terms and the ICANN reading of it. Usually, certification goes into deeper assessment and checking of a capability, while accreditation is lighter. But due to registrar relations that are called accreditation in ICANN world, people usually equate accreditaiton with a contract framework. 

Jeff Neuman: In the ICANN context, "Accreditation" generally means that based on your application, you are approved to perform certain services in the future....

Jonathan Robinson: There was an earlier comment that an approval process could test the ability to scale. There is no evidence provided for the fact that this could be done effectively. Such a process goes beyond setting a minimum standard and (potentially) confers authority to the tester (ICANN) for performance testing beyond minimum standards

Jeff Neuman: "Certification" is a process that evaluates performance and certifies that you have met the performance standards (based on past behavior)

Jeff Neuman: So, Accreditation looks towards the future, Certification looks to the past

Jeff Neuman: But....that said....I am not sure that the comments here make that distinction and Donna is right that they use the terms interchangeably

Justine Chew: Noted. Thanks, Jeff. Thanks, Donna.

Jonathan Robinson: @Jeff. Agreed that one could argue for a disctinction but they do seem to have been used interchangablly here

- ALAC: Doubt expressed regarding value of ongoing expansion on gTLDs, issue is of relatively little importance to Internet users (slide 11)

- Question 1.1.2

- CIRA, Nominet, BC, Google, BRG: Feedback on the issue of scalability (slide 12)

- Support expressed for setting a minimum standard/threshold so applicants can be confident in their application passing through. That is different from evaluating live operating TLDs for performance. 

- At the time that an RSP is seeking pre-approval, they are going to need to identify system and capacity. Any RSP is going to provide a pretty good picture at that that time. Important to seperate that from the compliance function that takes place during operation.

>From the chat: 

Rubens Kuhl: Scalability problems could be number of TLDs, number of DUMs or number of  peak transactions. Usually the later is the one that hits more frequently. 

Jeff Neuman: They also need to provide supporting documentation to show evidence of their scalability.

Jeff Neuman: So, it would not just be affirmatively making that assertion, but demonstrating their ability

Rubens Kuhl: There is one small technical function that is linked to number of TLDs in DNSSEC, but it's unusual to hit such a problem. 

- The entire purpose is to set a minimum threshold. Too many barriers up front create hurdles that are difficult to prove up front and establish inappropriate barriers to entry. 

>From the chat:

Rubens Kuhl: The more features of a registry system ICANN evaluates, the more liability it creates if such infrastructure doesn't deliver on that promise. 

Donna Austin, Neustar: Agree with Jonathan, the pre-approval process is intended to establish that the potential RSP has the technical wherewithal to run a registry. 

Rubens Kuhl: And since new gTLDs are not getting the gigantic registration volumes once foreseen, scability concerns seem overzealous at this point.

Donna Austin, Neustar: Good point Rubens, and also highlight the difficulties associated with predicting registration volumes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170919/919052e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sub Pro Track 1 20170919 v2.pdf
Type: application/pdf
Size: 371895 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170919/919052e9/SubProTrack120170919v2-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-wt1/attachments/20170919/919052e9/smime-0001.p7s>