Dear Working Group members, Please see below the notes from the meeting on 05 September 2019. 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/2019-09-05+New+gTLD+Subsequent+Pro.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Registry Services: ACTION ITEM 1 re: NCSG divergence, page 47 re: Interpreting that the divergence is not with the inclusion of certain services as approved registry services, it is it is an objection to one particular service – the Globally Protected Marks List -- under rights protection. Follow up with RPM PDP WG to see if they are discussing this issue, if not, add it to our discussion. ACTION ITEM 2 re: ICANN Org comment, page 47: Possible new high-level agreement: (ICANN Org comment) it would be helpful for us to make the recommendation that the implementation team revise the RSEP workflow to fit within the new gTLD processes and timelines and then put these as a couple of the examples -- (i.e., using priority number to order evaluation, using clarifying questions to address issues). ACTION ITEM 3 re: Question: Can we refine the reference to previously approved registry services that will be included by reference in the applicant guidebook and registry agreement to make it clear which services will be included in the applicant guidebook and which will be included in the RA? Answer: Certainly in the RA which is included with the AGB. We need to decide one way or the other. ACTION ITEM 4 re: IPC: Language of Question 23 required disclosure of new services. That requirement should not be changed since it is essential to evaluation. Check with IPC. ACTION ITEM 5 re: Additional fees associated with evaluations: MARQUES Comment: Supports a base application fee which all applicants should pay for standard evaluation with supplementary / top up fees paid for more detailed evaluation. Move to the discussion on fees. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary document – See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR... a. Applicant Reviews: Technical/Operational, Financial and Registry Services (continued discussion, Registry Services on page 46) See also: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved..., EXHIBIT A: Approved Services, pages 40 and 41. Please also see the web page at: https://www.icann.org/resources/pages/registries/registries-agreements-en Overview of Registry Services: -- Important to take a step back and do make sure everyone's on the same page so that when we go through the comments will see why some of the comments may be a little bit off the mark because they are not operating from the same page, or they may think that we're talking about something that we're not. -- “Registry Services” has a very specific definition in the agreement. -- Definition of “Registry Services” is defined in Specification 6: “a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above” -- See Exhibit A, Approved Services, page 40, number 1 is DNS Service – TLD Zone Contents. -- As an example, look at .family. -- On the chat people are indicating internationalized domain names. So there were two ways to get internationalized domain names into the agreement if a registry operator had proposed in its application that it was going to have languages as part of its service offering. Then at the time of signing the contract registries were given this language which is pretty much a template for all registries. 3.1, 3.2, and 3.3 is where they would list the languages that they have in the application. Now the second way was to have or subsequently to submit a request at a later point in time to add additional languages. -- And the way that I can add internationalized domain names is through a what's now called and very recently called sort of a fast track: Registry services evaluation requests. The reason it's fast track is it's a service that's pretty easy to add to a contract. -- A lot of amendments are done to add languages. -- So the services that fall under Category C and the definition of registry services are all going to be here in Exhibit A either initially because it was proposed in the contract or be because it's gone through one form or another of the registry services evaluations process. -- RSEP: Can be used in a bunch of different ways. Request for new services to be added, such as IDNs, lock service at the registry level, protected marks. Many of these are standard, such a registry lock. So many registries have requested them that approval is pretty routine. -- So one of the key discussions at work track for had and made it into the initial report was should some of these very standard services, just be considered pre-approved, meaning that registries did not have to have those evaluated during the application process. Nor did they have to have it evaluated through a subsequent registry services evaluation requests, with the caveat that they are proposing doing that service in the same standardized way that has already been approved. Registry Services -- Summary Document, page 46: -- First proposal was to allow for a set of pre-approved services that don't require additional registry services evaluation, either through the application process or through a subsequent our Sep this had support, not surprisingly, from the brand registry group the registry stakeholder group new star and you started also proposed, including the list that was provided in the initial report. -- Example: A number of registries because of the unique laws that China has there is a standardized mechanism that's been developed for registries to conduct their business there and is called that the “China gateway.” That is one of the most highly used validated services that are typically added by registries. -- There was divergence from the Non-Commercial Stakeholder Group: “In this section, the WG has buried rights to extend content control and excessive intellectual property protection into the evaluation and registry agreement. “The Globally Protect Marks List is viewed by NCSG and many others in the ICANN Community as a bastardization of the Policy Development Process. The NCSG -- and the GNSO -- and the ICANN Board flatly rejected the proposal of the Intellectual Property Constituency that certain strings be considered so sacred that they would protected across all New gTLDs regardless of the meaning and context of that gTLD. We rejected that idea as an ICANN Community because it is completely inconsistent with trademark law as we know it. . . That a few registries were able to slip in these widely-disputed and highly-controversial proposals via the Voluntary Public Interest Commitments and later the RSEP technical modification process does not make them technical, financial or operational commitments in any way, shape or form. These are in fact clear violations of the ICANN Bylaws and the limits that ICANN set to itself and the Community when it entered the transition from US government control.” -- ACTION: re: NCSG Comment -- Interpreting that the NCSG divergence is not with the inclusion of certain services as approved registry services, it is it is an objection to one particular service – the Globally Protected Marks List -- under rights protection. Maybe discussed in the RPMs PDP WG, but we should follow up. -- The general notion is that certain services are so standard that they should be in this sort of pre-approved bucket, that should be added to the that could be added to the agreement without undergoing additional evaluation. -- With the protected marks lists this is really an objection to the substance of the service. Not sure this is the right place to have that debate, meaning in the pre-approved services, but it is certainly something that the Non-Commercial Stakeholder Group wants to have a discussion on. -- Split the recommendation into two parts: Part 1 -- there should be certain pre-approved services and list the ones that don't have any kind of controversy around them. Part 2 -- if any services in general are allowed to be introduced, or have been introduced and there's no policy preventing them from being introduced, then there is not an issue from the policy perspective. -- We understand the Non-Commercial Stakeholder Group’s concern with the globally protected marks list, but the debate should not for this particular section. If they want to oppose that type of service that's certainly within their rights to do that. But if someone is proposing to release it in a standardized way that's been approved for other registries, and there is not a policy preventing that then that's one that should be on the list of standardized services. -- But as long as that service exists, and as long as a registry is implementing it in a standardized way that one should be added to the list. But we can certainly put a note saying that there is a philosophical objection to this particular service from the Non-Commercial Stakeholder Group and put the reasons why in a footnote, but that doesn't really relate to this particular section. -- ICANN Org comment: if an applicant chooses to offer one of the pre-approved registry services, the applicant would still need to go through an evaluation process to ensure that the applicant is capable of providing that pre -approved service. It would be helpful if the PDP working group can confirm this understanding is correct. -- Also, ICANN Org understands that this evaluation is not RSEP, which is only used for evaluating registry services that are not approved as per preliminary recommendation 2.7.7 from our initial report, but rather as another form of evaluation that is limited to assessing the applicants ability to perform the pre-approved registry service. It will be helpful, the PDP working group could also confirm if this understanding is correct. -- Applicants are asked to describe the registry services that they would like to provide and the manner in which they are going to provide it. That is all subject to the technical evaluation, a technical operational evaluation if the registry passes that evaluation then that is the only evaluation we're saying is needed for these quote pre-approved services -- that you would not need to separately go through a registration services evaluation panel and you would not have to do you know go through that entire process, but you would still like for all the registry services, you still have to show ICANN and the evaluators that you have a capability of offering the service. -- To confirm, they are all subject to evaluation in the standard technical operation evaluation as part of the application process. It's just they wouldn't have to go to a separate panel. -- There's a proposal to include one additional item and what we would do is list those as examples and perhaps then ask an implementation review team to confirm that that would be the right set and to see if there are additional ones. -- Re: RSEP should only be used to assess services that are not pre-approved: The main point of this recommendation is that it should be consistent, whatever processes used to evaluate new registry services for the new entrant should be consistent with the evaluation process of the existing to these and vice versa. -- Re: applications proposing non-pre-approved services should not be required to pay a higher application fee, unless an RSTEP is required: If the new entrant proposes a non-pre-approved service and it does not require constituting a technical panel because maybe the technical aspects are limited or understood then new applicants similarly, it should not have to pay a fee. This clause was added in order to foster innovation by not making it more expensive for the new entrance than it would be for existing registries. -- ACTION: Possible new high-level agreement: (ICANN Org comment) it would be helpful for us to make the recommendation that the implementation team revise the RSEP workflow to fit within the new gTLD processes and timelines and then put these as a couple of the examples -- (i.e., using priority number to order evaluation, using clarifying questions to address issues). Proposed draft language for Registry Services Evaluation: 2.7.7.17<https://www.google.com/url?q=http://2.7.7.17&sa=D&ust=1567696630863000&usg=A...>: “Applicants will be encouraged but not required to specify additional registry services that are critical to the operation and business plan of the registry. The list of previously approved registry services (IDN Languages, GPML, BTAPPA) will be included by reference in the Applicant Guidebook and Registry Agreement. If the applicant includes additional registry services, the applicant must specify whether it wants it evaluated through RSEP at evaluation time, contracting time, or after contract signing, acknowledging that exceptional processing could incur additional application fees. If the applicant has not included additional registry services, RSEP will only be available after contract signing.” -- Some support, some divergence. A lot of different comments that we've already addressed by saying that they are going to be evaluated as part of the application anyway. -- Question: Can we refine the reference to previously approved registry services that will be included by reference in the applicant guidebook and registry agreement to make it clear which services will be included in the applicant guidebook and which will be included in the RA? Answer: Certainly in the RA which is included with the AGB, ACTION: we need to decide one way or the other. Suggestions for additional registry services that could be pre-approved: -- WG could include a non-exhaustive list and leave for refinement in IRT Perspectives on whether the proposed registry services language changes the 2012 implementation of asking for disclosure of services versus disclosure being required. -- IPC: Language of Question 23 required disclosure of new services. That requirement should not be changed since it is essential to evaluation. ACTION: Check with IPC. Potential drawbacks of consolidating registry evaluations: -- RySG: Strongly supports batched evaluations for identical or nearly-identical applications by an RO (and its Affiliates). ACTION: Check to see if batching is mentioned elsewhere. Other Topics: Additional fees associated with evaluations: -- MARQUES: Supports a base application fee which all applicants should pay for standard evaluation with supplementary / top up fees paid for more detailed evaluation. ACTION: Move to the discussion on fees. ICANN Board: The Board is interested in recommendations for a mechanism that can be used when there are issues that block an application moving forward. -- Maybe more appropriate for objections or appeal mechanisms? b. Role of Application Comment (page 51) High-Level Agreements (see page 51) -- Confirm if it's being done already. If it's not, it may not be captured already by the applicant guidebook or elsewhere, so we should note that were re-confirming something that's it’s already done. But the reason we're stating it as a high level agreement is because we think it should be explicitly stated. Also, we should also indicate the high-level agreement on new stuff. -- Don’t position something that is already done as new. -- Start with Outstanding Items on the next call. Note about Name Collisions (upcoming topic): -- One of the things we're going to cover on that call is the interrelationship between the NCAP study and our work, and to the extent that we think that the study may cover some of those areas. We can defer to the studies or we can set some policy until such time that the studies, unless and until the studies produce some different result. 3. ICANN66 Schedule: -- Note that when the schedule is published it will say that the first two sessions are for WT5, but those are likely to be changed to full WG meetings, so note that in your travel plans. -- So the first two sessions are on Saturday and the other two sessions are on Monday.