Dear Working Group members, Please see below the notes from the working sessions on 14 October at ICANN69 at 12:00 and 14:00 UTC. 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, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-10-14+ICANN69+Hamburg-+New+gT.... Kind regards, Julie Notes and Action Items: Actions: #17 Applicant Support: ACTION ITEM: Staff to copy the ALAC and RySG comments on metrics into the Metrics topic. Notes: 1. Updates to Statements of Interest: No updates provided. Review draft Final Report Public Comments – to prepare see the Public Comment Review Tool at:https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiUZ...: Overview: -- Reviewing the comments to decide how the WG will deal with them, if not already addressed in the Final Report. -- Not working on final text/language for the Final Report. -- Staff will complete the Public Comment Review Tool and the overall statistical report by 21 October. -- Not trying to count or weight the comments – some represent groups, some individuals. #17 Applicant Support: -- ICANN Org notes that ICANN is not a grant-seeking organization. Role could be more as a facilitator with those organizations and applicants. Referred to the Pro Bono Assistance Program. -- Think through how we can have ICANN serve in a facilitation role while also ensuring that organizations can help applicants by providing pro bono services. -- ICANN Board comment: “Alternatively, ICANN org – through the Pro Bono Assistance Program – could act as a facilitator in the introduction of industry players or potential funding partners to the prospective entrants.” Seems that this doesn’t suggest that ICANN org is seeking funding. Not sure why that is “pro bono” as that relates to services that are provided but not charged. ICANN org could be the facilitator, but the applicant gets the money. -- Via constant funding there might be an affiliation with ICANN and it might attract attention of the anti-monopoly agencies around the world (not sure it goes well with fiduciary duties of directors)
for such constantly funded registries. -- Might be helpful to have some context: in discussions over the years we’ve talked about the uniting of resources, such as how to reach all of the different parties. -- GAC comments: Some are definitional, which we can consider whether we need to provide more definitions – some are very difficult to define. -- One point the GAC raised is about ongoing ICANN fees. Some commenters supported that concept and some didn’t. Don’t see a clear answer coming from the community on yes or no. It will be difficult for the WG to make a concrete recommendation for ongoing fees. Consider whether there is some middle ground. -- Financial stability is important for second level registrants. If you can't pay the ICANN taxes, you probably aren't a safe bet for second level registrants. -- The WG didn’t come to agreement on differentiating applicant support for geos and non-geos. There are some comments on who ICANN org should work with to get funding, and those are implementation details we could pass on. -- On gaming: ask WG members from groups who submitted comments on gaming – be more specific as to why there would be more gaming and provide examples we can work with. -- Low numbers of applicants last round probably due to a combination of poor communications/marketing and disqualification of application if they do not qualify for Applicant Support. The other factor was poor marketing and communications. -- In part of the WG recommendations we say that unless the panel finds willful gaming they can convert to a regular application, but if there is willful gaming it can’t convert. -- INTA comment: That they did consider the possibility of gaming in order to prevail in the context of auctions and put in some guardrails there. INTA were flagging that the issue is a potential risk for all applicant support, not just with auctions. But we’ve already built in some guardrails: “INTA suggests that Implementation Guidance 17.7 be clarified such that the restrictions against gaming not apply solely to Applicants getting Applicant Support who prevail in an auction...” -- In terms of the RySG comments: “17.2 financial support should be clarified and/or expanded upon to include a variety of professional fees (beyond application writing and attorney fees) such as financial viability, securing funding, etc.” Also discussion of gaming – would like more specificity. WG will need to revise its recommendations also based on ICANN org comments. Need more information on this: “(see 35.2) Applicant Support applicants who have access to bid credits, multipliers, other should be protected from more sophisticated applicants who benefit financially from entering into a business combination or joint venture.” Move comments on metrics to the Metrics section. More clearly define “Going out of business”. -- NCSG comments: Look at outreach and communication section and see if we need to add. Facilitation for the Pro Bono Assistance Program should be made as early as possible. -- Line 22 ALAC comments: “We not only support a recommendation that “Community” should be broadly interpreted, but would go further to advocate that the way “community” is interpreted should be applied consistently throughout each aspect of the application process.” Need to make sure this is consistent with the Community Applications. -- Not sure why we can’t have two different definitions of community for Applicant Support and for evaluation of CPE. As well as for Community Objections. ACTION ITEM: Staff to copy the ALAC and RySG comments on metrics into the Metrics topic. #34 Community Applications: General Review of Comments: -- Re: ALAC’s comments don’t think the WG will be able to develop a concrete definition of what is community. -- Lots of groups that support the output completely. -- Needs to be two different standards – one for economic and non-economic-based communities – see ALAC comments – as a WG there is a general feeling that the way the CPE Guidelines were written in 2012 they were biased towards economic communities. The WG is working on revising the Guidelines to eliminate that bias. -- Swiss Govt. comments, line 11: “We note that consideration should be given to providing support for non-profit community-based applications, which is not included in final recommendations. In addition, we recall that one of the key criticisms of the Community Priority Evaluation (CPE) was that qualification as a Community application was far too difficult to achieve given the level of requirements or rather the severity of the material requirements or criteria set for this purpose. We are of the opinion that this point is not being sufficiently and effectively addressed by the SubPro PDP WG in its recommendations.” We did consider this although we talk about economic and non-economic – WG should make this clearer. -- Couple of comments on the scoring. We discussed this in the WG, but haven’t come to a conclusion. Even if we lowered the scoring to 12 from 14 that would have only resulted in one additional applicant being granted community status, so we have been concentrating on making the criteria more clear and attainable. -- ALAC comments: Going through comments (two documents) provided on the CPE Guidelines in the last few weeks. -- fTLD comments – they have Spec 12, community based, but didn’t have to go through CPE. Wanted to make sure in their comments that CPE Guidelines are more clear. -- Think more about the timing of when changes are made. Will consider more when we get to that topic. -- ICANN org has comments – a lot are which are in line with what we are already discussing – going through the Guidelines. -- Don’t see anything here that we aren’t already considering. -- <question>PICs are very problematic they allow contracted parties to bypass mandatory RPMs. It’s very curious why ICANN would want standardised contracts but allows private RPMs which have no oversight – Surely if a RPM is good enough for 1 gTLD it should apply to all gTLDs? Or if not none?</question> Board Comments on PICs/RVCs and Bylaws restriction on content regulation (falls in this topic as well as others): -- Question: Re: “In this context the Board also encourages the PDP WG to consider the mission-limitation that derives from the Bylaws, which state that ICANN will not restrict “services that use the Internet's unique identifiers or the content that such services carry or provide” (Section 1.1 (c)). The PDP WG may want to review the impact this provision might have on ICANN’s ability to enforce the content of community TLDs post delegation.” Board and ICANN Org comments casting doubt on whether community applications should proceed in the next round. Concerns about whether PICs/RVCs could conflict with the Bylaws. Can the Board provide any context? Why would a registry voluntarily agreeing to regulate itself be considered as content regulation? -- Avri Doria, Board: There will be differences between what the Board provided and what ICANN org provided. One set of issues relates to whether the commitments ICANN is responsible for enforcing can be enforced, or will they conflict with the Bylaws. If it requires looking at a complaint about content, is that an activity ICANN can engage in – enforcing a contract against a complaint about content. The Board is not making a comment about whether there should be priority or not, but we did look at what happened in the last round. The Board is asking whether there is a problem that could force the Board into the adjudication process. Is this a working method? How do we deal with the mission statement of no content regulation? -- The way the WG framed it is that there are ways to do this by treating it as a breach of contract that ICANN could have an outside panel make a determination (say a violation of a PIC) – that ICANN would only make a determination on what the registry agreed to do, on a breach of contract, not on content. -- If there is an issue with the Bylaws, the Bylaws can be amended. -- If it can only be solved with a Bylaws change then the Board would look at it. -- Avri Doria, Board: What we are saying now is please look at this and tell us if we are wrong. -- Seems like this is more of a legal determination. All the WG could say to the Board is that if they think there could be a violation of the Bylaws, if the community wants this then the Board needs to figure out it could be allowed in the Bylaws. -- The process for amending Fundamental ByLaws via the EC procedures would be pretty complicated. Moving PIC and RVC Dispute Resolution to an outside panel/provider would be more efficient. -- Will we find out way done the line that ICANN legal determines that the new PICs are not enforceable? We need input as to whether the wording allows us to have a new applicant have new PICs related to content. -- The Board is raising some important issues and not sure the WG has considered these issues. -- Section 1 of the ICANN Bylaws from the point of view that the restriction of content is not the be-all and end-all. The mission also involved in upholding security and stability. With respect to string similarity evaluation using PICs concerning different uses of singular and plurals of words seems to relate to security and stability. -- WG is not rejecting the Board’s comments, but trying to understand them better. -- Question: Is the issue PICs and RVCs as tools, or just as the intersect with content? Answer: Could be anything in the contract that could cover the content associated with the TLD. -- Jorge Cancio, Swiss, Govt.: In the 2016 Bylaws this was considered to be a good compromise that allows for different readings. There might be different interpretations of what the Board is posing in its question. The reading from the Board goes to trying to limit any legal dangers, but this is only one view of the mission. What does the restriction on content regulation mean in relation to the WG’s recommendation. The grandfathering in the Bylaws extends to any new PICs that are similar or analogous to the PICs previous to the 2016 PICs. There was an intention behind that to allow for similar PICs in the future. It is very important for this WG to look at the overall interpretation and the history of the creation of this piece of the Bylaws, and not just from a risk-mitigation approach. -- Avri Doria, Board: Risk aversion is part of its fiduciary role. The Board is asking for discussion, an understanding of the policy basis, finding a set of answers to the questions. Board always has to go back to the bottom-up, multi-stakeholder process. -- Don’t think the WG could agree on one interpretation of what the Bylaws mean, but even if we did it is irrelevant since only the Board can determine whether something violates the Bylaws. As a WG we have to decide what we think the policy should be and what we want to happen. The community needs to affirm that through its processes. If the Board approves the recommendation then the Board has to consider how and whether to approve and what that would entail. -- But if it's clear to us that something violates the bylaws, we shouldn't recommend that. If it's something grey instead of black and white then we could send the recommendation upstream. -- The WG shouldn’t just punt it to the Board. The Board is not going to amend the Bylaws to allow ICANN to regulate content. We should get a determination now and decide how to amend the recommendation. If it is already a process in the PICDRP that if ICANN determines something is related to content it can shift the evaluation to a third party, we should call that out in the recommendation. This should be a dialog with the Board now, to avoid a delay later. Don’t think we can afford punting this to the Board to determine later. -- The larger issue is that ICANN is an infrastructure group so they have stayed away from regulating content and maintaining content neutrality. -- The Board raised this issue concerning closed generics too. -- We need to get to the substance to ensure this is what we want to recommend and we all figure out how we want to make it happen. -- All ICANN is able to enforce is that stuff their bylaws define they can. That's expanded or shrunken elsewhere. Aligning / allowing agreements within that scope seems patently reasonable. -- Amending the Bylaws might actually increase risk.