Dear Work Track members, Please see below the 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/display/NGSPP/2018+Work+Track+1+Meetings. See the referenced document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84.... Kind regards, Julie Julie Hedlund, Policy Director Notes/Action Items from Work Track 1 Sub Team Meeting 20 February 2018: 1. SOI Updates: No updates. 2. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14) See: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84... Implementation Recommendation -- Improve Promotional Efforts (page 12): Implementation Recommendation -- Utilize partnerships to maximize outreach (page 13) Recommendation -- support beyond reduced application fees Recommendation -- understand obstacles and provide assistance accordingly General Agreements (page 14) Aspects for Further Discussion (page 14) -- Metrics -- Evaluation criteria -- Other elements -- did we provide the right tools? -- Objectives of the ASP define -- How to provide locally available consulting resources -- How to improve the learning curve -- Making the business case -- How do we penalize applicants for gaming -- String contention resolution auction considerations -- any? Discussion: -- Not as much support for penalizing -- but do they get their deposit back? -- The way the process that we ended up with was interesting (in the JAS Group). Sometimes there wasn't close coordination between the recommendations of the JAS and what the Board did: the punishment of having the application cancelled was rather scary to people. While gaming does need to be looked at that may be too strong. -- One issue we never quite got settled is how to do financial evaluation based on local economics? Keeping that cultural awareness. -- Good to look at the whole disadvantage community, not just the region. -- Do we have enough on the financial understanding? -- What do we need for metrics? -- Don't know how effective it was and whether it met the meetings of the community. How do we get the right information to say that we did get it right this time? Draft report should ask the questions. -- Add to document: perhaps a request /required post process interview or survey for all applicants under this process?
From the chat:
Maxim Alzoba (FAITID): who will decide if the attempt of gaming was undertaken? avri doria: the review process was arduous. so yeah, they would notice. avri doria: yeah, i co-chaired a group in ALAC that tried to pin it down, and we couldn't. seems to have been a panoply of reasons. Vanda Scartezini: @ avri- yes. not one answers fits all. depend on the country/ region.. Cheryl Langdon-Orr (CLO): perhaps a request /required post process interview or survey for all applicants under this process? 3. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8) Aspects for Further Discussion/Not Yet Agreed Upon Ideas (page 23) 1. Grandfathering clause? -- Establish what we mean by the SLA. -- Under what circumstance would grandfathering not be allowed? -- One thing that makes a draft report engaging is if there are areas where questions are asked. No bad thing to have elements partially unresolved. -- Not sure we can fully trust the current implementation of SLAs. 2. PDT on RSP and the capacity of all of hte TLDs supported by the TLD. Re-approval on some time period based on the number of RSPs. Abbreviated pre-approval (standard set of services). 3. Process Controls (page 24) -- Re: process controls -- there may be more sophisticated ways of monitoring for future performance as well as past. -- Can we detect small signs of degradation? -- Could just say that the concept of process controls looking at future performance degradation were also discussed in addition to looking at past peformance, but didn't feel that this was an approach that could be used. 4. Transfer Process -- Re: Transfer process -- There should be a warning sign if fees are not met. Something needs to be added to the first paragraph: "Conditional on financial obligations being met." There also should be a security and stability qualifier, but not sure who would do that -- ICANN, others? 5. RSPs as EBEROs (page 25) -- Need some kind of performance or timing aspect. -- Key point that is missing: ICANN had an obligation under the 2012 program to set in place and manage and operate an EBERO program for a 5-year term, with the idea that at the end of the 5-year period that program would end. This section is predicated on the assumption that ICANN no longer operates an EBERO program. Need a preamble: "On the understanding that in the subsequent round ICANN will cease to provide an EBERO program for cost savings or other reasons..." Might also address this by moving some text around. -- It might be reasonable for new entrants to be required for a period of time to have a financial instrument in place to guarantee ongoing operations, but that doesn't speak to the removal of the EBERO program. Rationale for adding above (page 26) -- COI as a pain point. -- Opportunity for the RSPs to pool the risk and furnish EBERO services for all their clients at a relatively low cost. -- Whether the EBERO service "insurance" should be provided to all the RSP clients and provided at no addtional charge is complex and merits more discussion. -- This system should work because there is no "single point of failure". Areas of Non-Agreement (page 27) For public comment (page 27)
From the chat:
Jim Prendergast: what is meant by "meets SLA"? is that 100% of the time? Maxim Alzoba (FAITID): SLA are in RA Maxim Alzoba (FAITID): s Maxim Alzoba (FAITID): and it is defined there Cheryl Langdon-Orr (CLO): agree on the benefits of including questions for community response Maxim Alzoba (FAITID): I was talking about .wed Maxim Alzoba (FAITID): where EBERO was reached due to not paying for backend services Maxim Alzoba (FAITID): that is why I was talking about the backends who were not the reason for EBERO Maxim Alzoba (FAITID): https://www.icann.org/news/announcement-2017-12-08-en Jonathan Robinson: So. Looks like process controls are a good idea but perhaps a little too ambiotous for now Vanda Scartezini: + 1 Jonathan Cheryl Langdon-Orr (CLO): security and stability must always be overriding principles Maxim Alzoba (FAITID): Have we seen yet EBERO costs for .WED? Jonathan Robinson: Thanks. I am not wedded to the preamble or formatting of the text. But, keen to ensure we don't add another layer of cost / overhead onto the industry. Maxim Alzoba (FAITID): NOTE: EBERO can be triggered without RSP's failure (for example not paying ICANN bills)