Dear WG Members, Please see below the action items and discussion notes captured by staff from the meeting on 08 January 2018. These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript or recording. The MP3, transcript, and chat room notes will be provided separately. For reference see the following links to the documents, excerpts from the chat below, and also the attached slides: Drafting Team Discussion continued – Different TLD Types (Wiki Page: https://community.icann.org/x/YKLRAw and Working Document: https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJA... Drafting Team Discussion continued – Predictability Framework (Wiki Page: https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81... Best regards, Julie Julie Hedlund, Policy Director Actions/Discussion Notes 1. SOI Updates: None. 2. Work Track Updates: Work Track 1: -- Next meeting is 09 January at 0300 UTC. -- Draft recommendations on Application Fees and time permitting Variable Fees. Work Track 2: Next meeting is 18 January at 0300 UTC. Work Track 3: -- 09 January at 1500 UTC. -- Continuing third pass on objections -- specifically legal rights and confusing similarity objections. Work Track 4: -- Next meeting 11 January at 1500 UTC. -- Financial evaluation will be discussed including different models. -- Getting into details on how the evaluations will occur. Areas where there had been a lot of debate and consternation among applicants. Work Track 5: -- At the last meeting the WT5 members went through the Terms of Reference. A revised version is out for review. -- Circulating a request today for input regarding the definitions surrounding geographic names at the top level. -- Application types is a top that carries over into WT5. 3. Overarching Issue: Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81... ) -- Come up with a predictable process that will carry us through any issues. -- Examples from the last round as case studies include: 1. Change of vendor for an application type: Change that ICANN.org did of using a customized software solution to Sales Force. A change in the application process without input from the community. Would that type of change be done the same way under the next predictability framework. 2. Change in the pre-delegation testing procedures. Decided by the vendor of the pre-delegation testing in coordination with ICANN.org and consultants. Notice was provided to the contracted parties. Impacted the registries. 3. Change from Digital Archery to Random Selection process. Impacted applicants. Introduced because the intial way of moving forward with Digital Archery had security flaws. There was a comment period, but the decision was made by ICANN.org. 4. Name Collisions. Substantial changes that were made to the delegation process and launch processes. Several comment periods and research by consultants and input from the SSAC. Discussion: On the example of a freeze on the legal agreement: -- The episode from the last round cannot be repeated. Significant rules were changed in the registry agreement. -- Concerned about anything that would put some applications on hold, such as with GAC advice. May need to be some compromise to move forward with an application. -- If acceptance of an application is subjected to new terms being added to a contract (such as for technical/security changes), how do we handle that? Urge the GAC to issue broad advice before the next window opens. -- What do we do with a rolling contracting process? Individual applicants ought to be aware that a wholesale changes to terms of the agreement -- for those that haven't begun performance should have a right to challenge. Any examples of changes to the process that we could discuss with respect to a stress test? -- Also need to consider how to address changes as a result of Board decisions; whole class of changes where we can say, "sorry, we aren't going to change." We do have to contemplate what to do should an issue come up after the program has started. Provide some guidance on whether and when the program could be halted. -- Some changes may not fall into a policy or policy implementation category.
From the chat:
Jim Prendergast: outside the negotiation windows allowed for in the current RA, we cannot have the RA changing after ICANN has taken $$ from applicants. There needs to be some sort of freeze in place so applicants have prediciability when it comes to the nature of the relationship they will have with ICANN. Heather Forrest: +1 Jim - from a legal perspective there would potentially be a question as to enforceability of a contract (or parts thereof) lacking sufficient clarity for the parties Maxim Alzoba (FAITID): situation where TAS passwords were changed randomly without request from applicants Maxim Alzoba (FAITID): @Jeff, please add a task for me to supply additional info (cases e.t.c.) Phil Buckingham: Jeff , another change - ICANN advisories on answering questions ( especially Q50 ) Heather Forrest: (sorry - boring law professor comment here) - In terms of timing I'm thinking performance of the contract should start before changes occur Maxim Alzoba (FAITID): @Heather , formally ICANN has no responcibility for the failure to perform (unlike Applicants and RAs) Heather Forrest: @Maxim - I understand, but we're talking about validity of the agreement, ie whether the applicant/Registry can agree to a contract that lacks certainty, not whether ICANN can breach (if there is no valid contract, neither party can breach!) Rubens Kuhl: There were three type of PICs: mandatory for all, mandatory for some strings, truly voluntary. The first one was post-application change. Jim Prendergast: Thats why I think GAC advice that pertains to wide swaths of applications should be submitted prior to the opening of the round. Maxim Alzoba (FAITID): @Heather, the required wording of Letter of Credit allowes ICANN to send a note via SWIFT "we need your money" and a request for a money Susan Payne: Other "stress test" scenarios: .MAIL CORP and HOME. Although related to the name collision issue this issue is not resolved in relation to these three strings they are still in limbo Rubens Kuhl: @Jim, GNSO Policy can not dictate requirements for GAC. Maxim Alzoba (FAITID): @Heather, also in other industries the tactics of bait and switch leads to criminal cases for fraud Phil Buckingham: Jim +1 Susan Payne: and treatment of closed generics. I know this is a WT2 topic, but the scenario of changing the rules mid-process is relevant to predictability. Perhaps as an example of the impact of late GAC advice Rubens Kuhl: Specifically regarding changing the agreement, we might use the same approval thresholds among applicants that exists today among registries. Heather Forrest: We're not dealing with the typical consumer contract-type scenario, where the consumer lacks any bargaining power. We definitely don't want that applicants/ registries to have that perception. I suppose what I'm saying is that each applicant/registry needs to treat its agreement as 'unique', so to speak, and not just one of many identical agreements Maxim Alzoba (FAITID): I meant this thing (about changing a wholesale agreement) http://www.dca.ca.gov/publications/legal_guides/m-1.shtml and BAIT AND SWITCH - B&P 17500 (includes internet), CC1770(a)(9),(a)(10), 16 CFR Part 238 Maxim Alzoba (FAITID): but on the other hand - we can not entirely block ability of ICANN to change policies, it is about applicablility ot application process Maxim Alzoba (FAITID): during the application window Maxim Alzoba (FAITID): *applicability of such changes to the application process :) Rubens Kuhl: Possibly the same criteria that allows ICANN to implement Temporary Policies could justify changing things on the fly. Maxim Alzoba (FAITID): for example : some horrible security flaw of EPP is discovered and there is a need of a correction of some policy Mary Wong: Note that, in the implementation principles adopted by the GNSO Council in late 2015, there is a process within the IRT framework that provides guidance for escalation as well as referral back to the GNSO Council for new policy issues. Rubens Kuhl: "Temporary Policies. Registry Operator shall comply with and implement all specifications or policies established by the Board on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security of Registry Services or the DNS (“Temporary Policies”)." Alan Greenberg: Note emergency policies according to current processes, expire after a year. Alan Greenberg: Note temp policies are not in the Bylaws but in the Ry/Rr agreements and only apply after they are signed, so not clear they apply in the current situation. 4. Overarching Issue: Application Types (https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJA... ) -- What are we trying to achieve when we talk about establishing types of applications or categories? -- What we haven't identified the rationale why we should, if we should, different types of applications. Do we believe they should have different contractual requirements, priority, should not have all of the contractual requirements? Need to solidify this. -- In the last round we didn't call them "categories" but we had different classes. The only reason to have them is if we treat them differently. -- Number of members of the GAC that those from developing countries should have a category of applications that is treated different from those from developed countries. -- Object to the term "exceptions". A lot of the costs that might be different in different scenarios. Or situations such as a brand registry not needing to use registrars. Or the public interest. -- There will be demand for names with distinct purposes (such as geographic names). -- May need to be categories because not everyone will use a top-level domain in a standardized way. There should be some way to deal with uses in a way that was not conceived of in the round's beginning, or in the standard way. -- What is the goal of the TLD? The could result in variations in the contracts. -- What are we trying to achieve as a community? If we looked at what happened in the last round there were restrictions on community applications to create some level of trust. Why would the TLD be operated differently. -- Trying to extrapolate the reasons for why we created the previous categories. See if same rationale is useful. -- If we start making value judgments about certain application then we could get into content regulation. -- Perhaps where there is some restriction or validation or some way of appealing to a particular subset of the population of registrants that may be appropriate to look at as separate from the traditional open gTLD. -- May be a need based on the nature of the string being requested for a separate category. -- Is there anything from the CC1 and CC2 responses that would help with this discussion? There were cetain groups that did talk about the need to create categories. Input received through CC1 is available here: https://community.icann.org/pages/viewpage.action?pageId=59645660 -- ICANN.org would need to know if there are specific requirements in the registry agreement. -- There have been a number of categories identified, but need to identify where contractual or procedural differences are needed. Might not be about the category, but about the attributes. -- The top-level should not be the driving part; should consider the business model as well. If we are going to add categories it is important to keep in mind that our group will not imagine all of the business cases. -- Can we come up with a way to ask for differential treatment to allow you as a TLD to innovate or do a different type of business model. -- For those that belong to existing categories if you could look through those requirements and suggest what changes would be needed in the next round. Example, Brand TLDs needing a trademark.
From the chat:
Rubens Kuhl: Perhaps leaving that definition for last ? We would just need to specify how applications are treated, both equally and differently, and then finding names for the application groups that are treated differently. Susan Payne: Can we be clear about whether we are talking about new categories? or also the existing ones? Rubens Kuhl: @Maxim, they were already this way in 2012. For instance, a GeoTLD that is also a community TLD and is also a government-organisation registry. Maxim Alzoba (FAITID): I wonder if using of types of applications should be tag like (and not mutually exclusive ) Maxim Alzoba (FAITID): @Alexander, last time Offshores where added to EU region Annebeth Lange, co-lead WT5: We already have some categories already, haven't we, brands? Out of recognition of the interest of trademark owners? In the same way, as Alan said, there might be a group that are not "true" generics that should take care of the public interest. Alexander Schubert: @Maxim: E.g. Seychelles: EU? Martin Sutton: Jeff - we already have dotBrands and the rationale behind it, are you requesting for attendees to repeat these and for other categories established during the last application round? Maxim Alzoba (FAITID): @Alexander, I hope it was done for simplicity , but some big companies used it Annebeth Lange, co-lead WT5: Likewise, some geonames, that should be taken "care of" of the nations, through support/non-objection like for example capitols had in the AGB 2012 Susan Payne: Brand category already recognised the existing value and importance of the trade mark to the applicant, such that certain provisions of the base RA (including assignment of the registry to someone else) were incompatible with the existing legal rights Phil Buckingham: that should be the only "exception " - it is either an open or a closed TLD . . Business models whether commercial or not should NOT be templated ( as was last time ) Annebeth Lange, co-lead WT5: I agree, Susan, but there are also political "rights" to be taken into consideration for names of great value for nations Rubens Kuhl: Restricted TLDs: Brand TLDs, TLDs with eligibility requirements (Spec 12, PIC or simply registry policy), Exclusive Use TLDs. Donna Austin, Neustar: One of the aims of new gTLDs is to encourage innovation. Being too prescriptive may work against this principle. Maxim Alzoba (FAITID): +1 Donna Maxim Alzoba (FAITID): @Annabeth, different cultures sometimes have conflicting values and we will not be able to resolve it and thus the approach of protection of cultural values might not work Rubens Kuhl: I wonder if our charter gives us authority to look into merging Spec 12 (registration restriction for Community TLDs) and PICs. Because I believe Spec 12 is just a special case of PIC and PIC could be the overall umbrella for enforceable commitments. Hadia Elminiawi: I believe that as a community we want to give an opportunity to all categories/communities, while ensuring a fair process Donna Austin, Neustar: Categories become murky and difficult to process and evaluate when the strings are in contention. Kristina Rosette (Amazon Registry): +1 Donna. There's the additional issue that the speed (or lack thereof, more accurately) is not conducive to being prescriptive What is an innovative use at application could be completely obsolete 3+ years later (or 6+ as is the case with some of the still-pending contention sets). Jamie Baxter | dotgay: @Steve .. +1 ... for example it was about registration restrictions for some gTLDs, not about whether they were just community, geo or otherwise Phil Buckingham: Trang - I agree . Its is the contract that will require different specs pertaining to a "said category " . As you say the evaluators will evaluate according to the conrtract specifications . Annebeth Lange, co-lead WT5: And brands had special needs that in the end were listened to through the clearing house. But there might be other "categories" that have other needs that should be taken into consideration.