Notes and Action Items - New gTLD Subsequent Procedures PDP WG Work Track 1 Meeting 19 September
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.
Dear WT Members, You will see in the notes below that there was interest in receiving the data, related to SLA Monitoring and cases where RSPs have reached emergency thresholds, that was sent to the RySG RSP discussion group by Francisco Arias from ICANN technical services. Staff will request that this information be made available to WT1 as well. Best, Steve From: <gnso-newgtld-wg-wt1-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Tuesday, September 19, 2017 at 7:09 AM To: "gnso-newgtld-wg-wt1@icann.org" <gnso-newgtld-wg-wt1@icann.org> Subject: [Gnso-newgtld-wg-wt1] Notes and Action Items - New gTLD Subsequent Procedures PDP WG Work Track 1 Meeting 19 September 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.
participants (2)
-
Julie Hedlund -
Steve Chan