- Gnso-newgtld-wg-wt2 - lists.icann.org

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 19 January
by Julie Hedlund Jan. 19, 2017

Jan. 19, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 19 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording. See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. Please also see the attached slides referenced below. Excerpts from the chat room are included below for ease of reference. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 19 January 1. Registrant Protections -- Introduction [reading from slide 2] Question: How many applied or were an applicant and had a problem -- show of hands: 4 hands: Michael Flemming, Jeff Neuman, Rubens Khul, Heather Forrest, Kristina Rosette Principle D, Risk assessment and contingencies, application scoring [from slide 2] 2. Critical Registry Functions [reading from slides 3 and 4] Question: Are the current critical registry functions still sufficient or do changes need to be made? Yes/No/Other -- On overall registrant protections -- one was the notion of being able cover if a registry failed. Is there any protection other than those 5 functions where a backup registry need to take over, or are the 5 functions enough? -- There was the discussion on whether critical registry functions would need the additional functions of RCEP. -- It may be different for different types -- may need to have core critical functions regardless of how your TLD is characterized, and a "if this, then that" set. -- We do consider whether or not the COI is necessary for different categories. Really like the idea of overarching functions. -- Bring up the notion operation of a shared registration system -- in the chat if an EBERO is ever called up -- not responsible for adding new names. The problem with renewals some registries validate renewals as the validate new registration. -- Operation of certain systems that are critical. If there is a policy that affects renewals then EBERO won't be able to do it. >From the Chat: Jeff Neuman: Principle D is from the 2007 GNSO Policy Rubens Kuhl: While at NTAG, applicants concluded that ICANN COIs likely violated international guidelines against money laundering. I still think it is true. Trang Nguyen: @Rubens, I believe the issue was around the specific criteria in the AGB that states: The LOC ust name ICANN or its designee as the beneficiary." Many banks, U.S. and international viewed the "designee" as problematic because most if not all banks need to perform certain checks on the beneficiary, and they cannot do that for an un-named beneficiary. ICANN issued an advisory (https://newgtlds.icann.org/en/applicants/advisories/loc-beneficiary-require…) stating that it would be acceptable to name only ICANN as the beneficiary provided that the LOC is fully transferable. Trang Nguyen: Nonetheless, COIs were an issue for most applicants. Q50 received the most number of clarifying questions, by far. 82% of apps received a CQ on Q50. Kurt Pritz: My understanding is that If a Donuts rgistry went into EBERO, the registery would no longer be registering names, therefore the DPML would no longer be critical. Jeff Neuman: @Kurt - Is that an argument that the SRS is not a critical function? Rubens Kuhl: Jeff, the SRS is still required to update already registered domains. Jeff Neuman: @Rubens - correct.....that is the critical part, but not the rest of the SRS. Rubens Kuhl: But any policy layer is not critical. Rubens Kuhl: DPML, registrant verification and all other systems, processes and human resources that are in the policy layer are not critical. Kurt Pritz: @Jeff - no. It was an argument that we need not augment the existing core set with DPML. There might be renewals in an EBERO environment, does that require SRS? Jeff Neuman: I want to make sure we capture Trang's statistics for the record. Steve Chan: @Jeff, I believe Trang's statistics are from the Program Implementation Review Report, but it's also captured in the notes. Rubens Kuhl: Kurt, from a pratical standpoint I think it would be better for EBERO both not accept renewals and do not expire domains. Kurt Pritz: @ Rubens The hoped for ending is that someone else picks up the EBERO operated registry. If domains are not renewed or expired, would that complxity deter a successor from standing up Kristina Rosette (Amazon Registry): @Steve and Julie: Joined late because earlier call ran long. Can you include me among those who ran into issues with the COI during the application process? Thanks. Cheryl Langdon-Orr (CLO): that needs teasing out then Jeff. Kurt Pritz: It is a complicated area but I don't know of and haven't heard any evidence that indicates augmenting the critical functions list. 3. Emergency Thresholds [reading from slide 5] Question: Has any registry gone above the Emergency Threshold? Yes/No/Other/Ask ICANN for data Three questions: reached the threshold before, or has EBERO been used? If someone went above the threshold and EBERO wasn't used, then why? -- Need the data from ICANN but without attribution. Action Item: Ask ICANN 1) has the Emergency Threshold been breached 2) has EBERO been triggered? 3) If someone went above the threshold and EBERO wasn't used, then why? >From the Chat: Rubens Kuhl: Option D. Alexander Schubert: one would think both systems are bridged? Trang Nguyen: @Michael, I do not know if an EBERO has ever been officially triggered. We could check if that's a request from this WT. Trang Nguyen: Yes, will do. Jeff Neuman: @Trang, do you need that in a letter? Rubens Kuhl: @Trang, from IANA root zone journals I follow I believe it was never triggered... but that would only reveal actual transition, not possilble events where EBERO has been called to duty but RO went back online before a transition happened. Cheryl Langdon-Orr (CLO): I would go with Jeff's formulation with the ask ICANN. Trang Nguyen: I think I understand the ask. Will have to take this back internally and see what information we can provide. Kristina Rosette (Amazon Registry): To be clear, the intention is to ask "yes/no" and "If yes, on how many occasions?" without seeking identity of the RO, the issue, or which EBERO transitioned, correct? Michael Flemming: Yes Jeff Neuman: @Kristina - yes....but also to find out if the threshold was reached, but ICANN did not bring up an EBERO (And why or why not). Jeff Neuman: But no attribution to any registry or EBERO. Kristina Rosette (Amazon Registry): @Jeff: thanks. 4. Cost Coverage [reading from slide 8] Question: Are these cost measurements still sufficient to cover the critical functions for EBERO? Yes/No/Other -- There is the activation part and the readiness part. You have two parts not just one. The COI looks at the activation costs. -- This came from an RFI for entities that were interested in being an EBERO and from those responses ICANN asked for cost estimates on what they were charge ICANN to serve in that capacity. There were at least 10 responses. ICANN synthesized the responses. -- What true amounts would be to bring up an EBERO and how much ICANN would need to fund an EBERO provider. Rather than doing one COI per each registry, find a way to fund it so that you know the costs would be covered. -- The contract already states that once the threshold is breached the emergency Escalation will take place. Is this amount correct for the contract? -- We are contractually bound to agree that ICANN has the right at its discretion to move this to an EBERO, but ICANN decide to or not. If a technical backend -- a registry that said my EPP was down and I'll have it up in 30 hours there is no way ICANN is going to call up an EBERO. We should be discussing this in terms of a technical failure by a business that may or may not be the registry. -- The contract language is up for interpretation: "Emergency Escalation" may not mean EBERO. -- If you took the limited amount in a COI by itself it may not cover the costs of an actual transition. But if you look at what EBERO is paid and combined with the eventual release of COI funds to the registry that may be enough to fund the cost. How can we make sure that in the case of a technical failure that registrants are protected by having a provider in place to operate the critical functions of a registry until a decision can be made. We should explore other mechanisms to fund the program other than via a COI process, which is difficult to maintain and ensure that ICANN can receive the funds. The problem may be with the backend operator and not the registry. -- The COI was as much of a headache for ICANN as for the operators. Should also consider AGB as it relates to COI. -- Seems like we should be looking at setting up a fund made up of application fees and fixed fees. >From the chat: Kurt Pritz: If the COI is eliminated, this question on cost measurements does not matter much. Michael Flemming: But the cost analysis would be the same, regardless, no? Even if we do get rid of the COI, the cost would still come up somewhere. Rubens Kuhl: What I said is that EBERO has a readiness cost and an activation cost. Those costs that are COI-funded seems to only cover activation cost, not readiness cost. ICANN pays EBERO providers so they are ready even without incidents. Michael Flemming: There would still be a cost* Rubens Kuhl: Full disclosure: we have a contract clause in our back-end contracts to not take down TLDs that have not paid. their dues We can "snitch" them to ICANN, but won't take them down. Kurt Pritz: The slide says ICANN "will initiate an Energency Escalation" - it doesn't say "will transfer to an EBERO" - so if the slide reflects the contract then transfer is not mandatory. Kristina Rosette (Amazon Registry): I've always understood that Emergency Escalation is completely different from transfer to EBERO. Kristina Rosette (Amazon Registry): Section 7 of Spec. 10 sets out exactly what an Emergency Escalation is and how it differs if initiated by ICANN vs. by Registrars. Jim Prendergast: the contracted party is the front end. not the back end. Jeff Neuman: @Jim - yes. Which is why we may want to come up with a different model Jeff Neuman: It would be good to create a small team try and explore alternate models Rubens Kuhl: I think ICANN said that if a registry survived 5 years, it looks solid enough. Trang Nguyen: I was not with ICANN during the AGB development process, so don't really know how the 6 years were arrived at in Spec 8. Christa Taylor: A pooled insurance type of structure based on data could be an straight forward solution. As long as the data and the algoriithm are conservative it could be a viable option. Christa Taylor: If the business completely failed and went bankrupt without any notice, one would think that the back-end provider could take it over with the renewal revenues to help offset the costs. Christa Taylor: There is no 'cash cow' fund Jeff Neuman: @Christa - There may be some legalities of the creation of an insurance fund. Christa Taylor: @Jeff perhaps the wrong term but trying to convey the idea 5. Continued Operations Instrument -- Letter of Credit [reading from slide 12] Questions: 1. Are the requirements for the Letter of Credit still sufficient? Yes/No/Other 2. Can othe rmodels besides the Letter of Credit and the Cash Escrow Deposit be considered for the COI requirements? Yes/No/Other >From the chat: Kurt Pritz: The reaction of the backend to not being paid could be governed by a backend certification program (!!) Heather Forrest: Apologies, all - I have to drop off now for the Council meeting. Kristina Rosette (Amazon Registry): Yes, Paul McGrady gave a rather "spirited" presentation of the many ways heading down any kind of "insurance model" could create problems for ICANN Trang Nguyen: @Christa, in your suggested model, would there be different buy-in amounts based on number of DUMS, or would all TLDs be expected to contribute evenly to the insurance fund? Christa Taylor: +1 Kurt it could be part of it Jeff Neuman: But there are other ways including the appointment of "permanent EBEROs" and figuring out an amount that would compensate them for the expected amount of failures per year. Then using Registration fees to cover those costs Kristina Rosette (Amazon Registry): Can be considered or should be considered? Christa Taylor: @Trang needs more thought - could be DUM or another combination of DUM and minimals.' Rubens Kuhl: Business failures can have a high correlation with selling domains for pennies, so the outlook of future registration fees may not be as good... Jeff Neuman: I believe that snce we now have a number of years under our belt, we could could use that data to seek proposals from EBEROs (past or futuree) to see if there is a fixed annual fee that they could be paid for the year to cover any eventuality (given that an EBEROs obligations are very limited) 6. Considering When Registrant Protections don't apply [reading from slide 15] Question: Should more relevant rules be established for certain specific cases or categories of TLDs? -- There are some where registrants are brand licensees -- there are possibly some shades of gray where some need protection or not. -- If you went to existing EBERO or other providers that could provide those services ask what it would take to compensate you for an entire year with no questions asked you would get an amount that was high. >From the chat: Rubens Kuhl: EBERO without COI could be a best of both worlds option. Cheryl Langdon-Orr (CLO): agree Rubens Cheryl Langdon-Orr (CLO): but happy to explore new funding options Kurt Pritz: I agree with Rubens also. Here is a trial balloon on COI: Eliminate the COI. ICANN to fund the EBERO and temporarily maintain an abandon registry out of its regular revenue stream. This is because: (1) no registries have required EBERO intervention to date so projected incidents (and costs) should be low; (2) COI was problematic to implement on many levels (clarifying questions, different laws, etc); (3) the fees from 1000+ new registries, which is a number greater than expected, should cover costs, ICANN did not have this money when writing the Guidebook;(4) the cost of maintaining the existing registry functions is relatively low; (5) the most likely failure is a single registry business failure and the development of the backend registry marketplace would tend to guarantee that data is preserved in the event of a failure and any transition is straightforward. Phil Marano (Mayer Brown): Protections vis-a-vis .Brand TLDs and their licensees can be dealt with through other contractual means, and might not need not be mandatory for registry operators who are not in the business of selling domain names. Kurt Pritz: sorry for all that.

1 0

Re: [Gnso-newgtld-wg-wt2] WT2 - Jan 19th, Thursday Meeting at 20:00 UTC Topic EBERO ( Emergency Back End Operator ) , COI ( Continuing Operations Instrument ) and LOC ( Letter of Credit) Data Escrow ( if time).
by Phil Buckingham Jan. 19, 2017

Jan. 19, 2017

Hi Everyone, Michael, thanks for circulating the agenda. If you could look at the agenda before the call that would be much appreciated, although I do appreciate time is of the essence in preparation for Namescon. We have put a question(s) at the end of each topic . Perhaps you would consider these questions ( and your answer ) beforehand , in preparation, so we could do a hands up / consensus vote on each .during the call. I would be particularly interested to establish if anybody, who encountered problems with Q50/ COI ./LOCs would be prepared to discuss on these on the call ( for their own application(s) and clients ) and what they feel would be an acceptable solution(s) to implement for R2. If you could let me know beforehand …… Many thanks. Kind Regards, Phil Phil Buckingham From: gnso-newgtld-wg-wt2-bounces(a)icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Michael Flemming Sent: Thursday, January 19, 2017 2:10 AM To: gnso-newgtld-wg-wt2(a)icann.org Subject: Re: [Gnso-newgtld-wg-wt2] WT2 - Jan 19th, Thursday Meeting at 20:00 UTC Dear All, Once again I am circulating the agenda in time for tomorrow's meeting on 19 January, 2017 at 20:00 UTC. My apologies as I was unable to get the slides out earlier. In the attachment is the material we will be covering and the slides we will be using. Phil and I look forward to meeting with everyone tomorrow. Kind regards, Michael Flemming On Fri, Jan 13, 2017 at 9:04 AM, Michael Flemming <flemming(a)brightsconsulting.com> wrote: Dear All, Please note the agenda for the meeting 19 January 2017, Thursday at 20 UTC. 1. Welcome 2. Updated SOI 3. Registrant Protections 4. AOB We didn't get to the Registrant Protections before the end of the meeting yesterday. Therefore, it was felt very strongly that we should have a follow up meeting next week to cover Registrant Protections. The good news is that our slides are already prepared. After I make a few edits I will circulate them today. All background material should be included. On the other hand I hope to begin discussing CC2 questions over email. I look forward to the meeting next week and hope everyone will be ready for constructive discussion. Kind regards, Michael Flemming -- Sent from my mobile.

1 0

WT2 - Jan 19th, Thursday Meeting at 20:00 UTC
by Michael Flemming Jan. 19, 2017

Jan. 19, 2017

Dear All, Please note the agenda for the meeting 19 January 2017, Thursday at 20 UTC. 1. Welcome 2. Updated SOI 3. Registrant Protections 4. AOB We didn't get to the Registrant Protections before the end of the meeting yesterday. Therefore, it was felt very strongly that we should have a follow up meeting next week to cover Registrant Protections. The good news is that our slides are already prepared. After I make a few edits I will circulate them today. All background material should be included. On the other hand I hope to begin discussing CC2 questions over email. I look forward to the meeting next week and hope everyone will be ready for constructive discussion. Kind regards, Michael Flemming -- Sent from my mobile.

1 1

recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues 12 January 2017
by Terri Agnew Jan. 12, 2017

Jan. 12, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues held on Thursday, 12 January 2017 at 20:00 UTC. The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Wiki page: https://community.icann.org/x/FwSbAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 12 January 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues call on Thursday, 12 January 2017 at 20:00 UTC. Terri Agnew:agneda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Jim Prendergast:15 - the magic number Jeff Neuman:phil can you hit mute until you speak :) Terri Agnew:Please remember to mute when not speaking Terri Agnew:everyone can scroll themselves Jeff Neuman:It should be noted that there were MANY discussions between the GAC and the Board on Geographic and geopolitical names between the 2009 recommendation and what was eventually put into the Guidebook. But NO policy development process was ever commenced to discuss those protections during that time period Susan Payne - Valideus 2:we are dealing at 2nd level here though aren't we, or am I mistaken? whereas CWG-CTN is top level Michael Flemming:Second level Cheryl Langdon-Orr (CLO):yes understand it is 2nd level Cheryl Langdon-Orr (CLO):but the concerns I have heard raised reflect in Top andb2nd... Rubens Kuhl:Note that there are dissenting views regarding use of RSEP to release reserved names. ICANN is currently adopting such view, but some think it should be a different process, even in current policy guidance. Michael Flemming:I made a note on that Rubens, but you sum it up so sweetly. Cheryl Langdon-Orr (CLO):note in my time in suDA Board I fought to and succeeded to release Lower level names so I am not 'anti' Susan Payne - Valideus 2:OK, thanks Cheryl, understood. But in terms of what has been discussed in the CWG, we have only been talking about 2nd level Cheryl Langdon-Orr (CLO):understand that Susan Alan Greenberg:Sorry to be late. Cheryl Langdon-Orr (CLO):even in our Work in the most recent CWG whose name itself is specified separation of the levels N in community understanding and and concerns has always been a 'challenge' Cheryl Langdon-Orr (CLO):agree Jeff Rubens Kuhl:.com and .net are pretty old namespaces... new namespaces might require introductory measures, like sunrise. Legacy gTLDs are benchmarks, but a grain of salt in comparing is required. Kristina Rosette (Amazon Registry):Support creation of drafting team (which may not be smaller given interest), but agree on creating subteam avri doria:i still have not graduated beyond what was in the original GNSO policy of 2007. and that is a lost casue (personal opinion) Rubens Kuhl:One issue in allowing Brand TLDs is what happens if the TLD is repurposed to not be a Brand TLD, which is a registry operator option at anytime without consulting, just informing, ICANN. avri doria:i find having difrent such rules for different categories very problematic (again personal view) Mary Wong:For clarity (including for WT members not on the call), what is the specific focus and brief for the Drafting Team, and what will be its anticipated timeline to deliver its proposal? Susan Payne - Valideus 2:support drafting team too. I think it wouldmbe helpful for those who join to familiarise themselves with how we got from the policy to the AGB as not all of us are probably familiar with the full history Kristina Rosette (Amazon Registry):We should make clear that GAC representatives are welcome to participate.. Cheryl Langdon-Orr (CLO):one of many similar concerns Rubens... yes avri doria:Susan, that was easy, without going back to the GNSO the BoardStaff decided. Cheryl Langdon-Orr (CLO):indeed Kristina avri doria:I think they know they are welcome, but alwasy good to mention it again Jeff Neuman:Lets confirm the 2009 policy on this Kristina Rosette (Amazon Registry):Support confirming 2009 policy on gTLD Reserved Names (2nd & 3rd levels ASCII and IDN) Susan Payne - Valideus 2:sorry, audio issues Rubens Kuhl:Looking at collision lists, some popular legacy TLDs (both gTLDs and ccTLDs) deserve a bit of care. While I also support confirming the 2009 policy, this is a factor that new gTLD operators should assess and hopefully make informed decisions. Rubens Kuhl:I don't see possibility of human confusion, but some name collisions can occur. Rubens Kuhl:Due to suffix appending. Cheryl Langdon-Orr (CLO):and name collision needs to be avoided Cheryl Langdon-Orr (CLO):SAC90 Phil Buckingham 2:steve , emily - before i start , can one of you do the scrolling of the powerpoint . much appreciated. Christa Taylor:+1 Susan on the ship has sailed Steve Chan:@Phil, sure thing. Phil Buckingham 2:thanks Susan Payne - Valideus 2:yes, agree Phil Buckingham 2:+1 Alan - impossible Christa Taylor:Agree with Alan Michael Flemming:Can you hear me? Christa Taylor:no Julie Hedlund:Can't hear you Michael. avri doria:i go as far as to call it unreasonable (again personal view) avri doria:there are only 7 in the US? Christa Taylor:+1 Avri Rubens Kuhl:Jeff, just type s*** etc. ;-) avri doria:ah the s-word, the f-word ... modern Merican speak Jeff Neuman:s***, f***, p***. m************, c***, t****, and one other that escapes me for now Jeff Neuman::) avri doria:https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org… Susan Payne - Valideus 2:p***?? Jeff Neuman:oh yes c********** Steve Chan:FYI, the language Michael is reading is from the base registry agreement. Mary Wong:There is ongoing implementation of Board-adopted GNSO PDP recommendations regarding a few names for the Red Cross movement and names of IGOs. Jeff Neuman:I agree on this category and the IGOs Mary Wong:Per Alan, other Red Cross names are still under discussion. Cheryl Langdon-Orr (CLO):agree Susan Rubens Kuhl:One organisation that I don't believe deserves any special treatment is IOC. Rubens Kuhl:"I don't want to be buried in a Pet Cemetery,I don't want to live my life again." Mary Wong:@Michael, to add - what I said (i.e. long list currently now reserved under Spec 5) also applies to IGOs. The only reserved protections approved so far for IGOs are their names. Their acronyms are now on the list only on an interim basis. Cheryl Langdon-Orr (CLO):good point Jeff Rubens Kuhl:Which would allow the International Sugar Organization to get ISO.<something> instead of the International Standards Organization... Cheryl Langdon-Orr (CLO):agree again Susan Mary Wong:All, note that in the current implementation for Red Cross, IOC and IGOs - there will be an Exception procedure for the protected organization. Jeff Neuman:@alan - you would not believe the pushback we get from GDD to release names where express consent via letters on letterhead are provided Cheryl Langdon-Orr (CLO):thx Mary Phil Buckingham 2:it seems unlikely we will start Reg Protections tonite / today . How many would be up for a call next Thursday 19 same time . Call s in namescon week are canx Alan Greenberg:@Rubens, there is nothing on the table that would prohibit thee Standards Organization from registering ISO, All that is being propossed is that the character strings go into the trademark clearinghose so that a flag would be raised when the name is registerd. Susan Payne - Valideus 2:fine by me phil Terri Agnew:At this time the next call is scheduled for: New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues will take place on Thursday, 02 February 2017 at 20:00 UTC. Phil Buckingham 2:thanks terry Phil Buckingham 2:terri Emily Barabas 2:The leadership sync is on Wed. The slot at 20:00 UTC on Thursday is free. Alan Greenberg:All options ar eok with me. Jeff Neuman:ouch Michael Flemming:That is actual joy Cheryl Langdon-Orr (CLO):my calender needs updating then Steve Chan:2000UTC on 19 February does precede the GNSO Council meeting however. Jeff Neuman:Thanks all! Christa Taylor:Thank-you Susan Payne - Valideus 2:thanks all Phil Buckingham 2:well done Michael

1 0

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 12 January
by Julie Hedlund Jan. 12, 2017

Jan. 12, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 12 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording. See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. Please also see the attached slides referenced below. Excerpts from the chat room are included below for ease of reference. In addition, the discussion follows the Google doc at: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8…. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 12 January Remaining Reserved Names and the Second Level [See slide 2] Geographic and geopolitical -- AGB did create reservations and currently the only authorization process that has been established is through the use of RCEP (Registry Service Evaluation Process). Probably not the most applicable process. -- GAC has taken the initiative of publishing a list of country and territory names -- around 16 or so names. -- Need to discuss whether we would suggest changes to policy. -- The ABG lists the reservations but the policy itself does not. Should we change policy to be consistent with the AGB? -- Any change to policy should be in line with the AGB and its lists of reservations. Also not the current GAC listing of names with country approval. Ensure that the list can be added to in a very easy way. Could recommend a PDP just on this aspect, but concern that this could become a significant roadblock. -- We are talking about the second level, not the top level. -- At a minimum we should agree whether we will stand by the 2009 policy recommendations or note that there is a gap between what happened with the AGB. Questions: 1) Need to confirm our agreement with the policy on geopolitical names (not geographic) -- the controversial names, and our understanding that going forward we will only deal with country and territory names and not say that any should be reserved. 2) If country and territory names are protected are we starting from the list in the AGB, which wasn't policy. If we stick to the list other negotiations between the governments and ICANN wouldn't apply. 3) Express whether the 2009 policy needs to be adjusted and make recommendations to the full PDP WG on what we should do with country and territory names. -- Suggestion: No need for restrictions for any TLD, but especially for BRAND TLDs -- harmonization with .com and .net. If we could make a clarification on that it would be beneficial. -- Probably a good issue for a smaller drafting team to consider. Need to handle it very carefully. -- Need to have participation from GAC on the Drafting Team. Can invite the GAC members on the list. Action Item: Send a call for volunteers for a Drafting Team on this topic. We can only issue a call to Sub Team members, but ensure that it is clear that GAC/ccNSO members on the Sub Team are encourage to join. >From the chat: Jeff Neuman: It should be noted that there were MANY discussions between the GAC and the Board on Geographic and geopolitical names between the 2009 recommendation and what was eventually put into the Guidebook. But NO policy development process was ever commenced to discuss those protections during that time period. Susan Payne - Valideus 2: we are dealing at 2nd level here though aren't we, or am I mistaken? whereas CWG-CTN is top level Michael Flemming: Second level Cheryl Langdon-Orr (CLO): yes understand it is 2nd level Cheryl Langdon-Orr (CLO): but the concerns I have heard raised reflect in Top andb2nd... Rubens Kuhl: Note that there are dissenting views regarding use of RSEP to release reserved names. ICANN is currently adopting such view, but some think it should be a different process, even in current policy guidance. Michael Flemming: I made a note on that Rubens, but you sum it up so sweetly. Cheryl Langdon-Orr (CLO): note in my time in suDA Board I fought to and succeeded to release Lower level names so I am not 'anti' Susan Payne - Valideus 2: OK, thanks Cheryl, understood. But in terms of what has been discussed in the CWG, we have only been talking about 2nd level Cheryl Langdon-Orr (CLO): understand that Susan. Even in our Work in the most recent CWG whose name itself is specified separation of the levels N in community understanding and and concerns has always been a 'challenge'. Cheryl Langdon-Orr (CLO): agree Jeff Rubens Kuhl: .com and .net are pretty old namespaces... new namespaces might require introductory measures, like sunrise. Legacy gTLDs are benchmarks, but a grain of salt in comparing is required. Kristina Rosette (Amazon Registry): Support creation of drafting team (which may not be smaller given interest), but agree on creating subteam Rubens Kuhl: One issue in allowing Brand TLDs is what happens if the TLD is repurposed to not be a Brand TLD, which is a registry operator option at anytime without consulting, just informing, ICANN. avri doria: i find having difrent such rules for different categories very problematic (again personal view) Mary Wong: For clarity (including for WT members not on the call), what is the specific focus and brief for the Drafting Team, and what will be its anticipated timeline to deliver its proposal? Susan Payne - Valideus 2: support drafting team too. I think it wouldmbe helpful for those who join to familiarise themselves with how we got from the policy to the AGB as not all of us are probably familiar with the full history. Kristina Rosette (Amazon Registry): We should make clear that GAC representatives are welcome to participate.. gTLD Reserved Names: -- Change policy or leave it as is? [reading policy from the chart] -- In 2001 when .biz, .info, etc. were signed we (Neustar others) were required to reserve .com.info, .biz.travel, etc. because of confusion, but agreed that there would be no confusion in the future so no reservations. -- Yes, we want to confirm the 2009 policy that says there should be no reservations. -- It's impossible to reserve because of the expanding list of TLDs. >From the chat: Rubens Kuhl: Looking at collision lists, some popular legacy TLDs (both gTLDs and ccTLDs) deserve a bit of care. While I also support confirming the 2009 policy, this is a factor that new gTLD operators should assess and hopefully make informed decisions. I don't see possibility of human confusion, but some name collisions can occur. Due to suffix appending. Cheryl Langdon-Orr (CLO): and name collision needs to be avoided Controversial Names: -- Current policy is that there should not be a category of Controversial Names that are reserved at 2nd and 3rd levels ASCII and IDN. -- There is no dispute policy mandated (and their isn't one). If we do want to confirm the 2009 policy we edit it and either remove the part about the dispute policy or stay that registries can determine the eligibility of their registrants in their own TLDs. -- Original thinking was that there could be a global dispute policy, but since the category was never created the dispute policy wasn't created. But a registry can make a rule to restrict controversial names in their registry. Registries already have that right. IOC and RCRC, and IGOs: -- No reservations originally, but later occurred and is included in the base registry agreement. -- Current active discussion between the Board and GAC on the reservation of country names (used within each country). -- Perhaps we shouldn't be looking at this while there are open discussions -- but could look at it if it hasn't been resolved elsewhere. -- For adopted policy it is just a few names. That list could change in the near future. There are other names that are on hold on a interim basis. -- Suggestion: Leave it be; don't revisit it. -- If reservations are in place we should state that there should be a mechanism for the release of those names to that specific organization. -- There is no mechanism for release of those names when the organization is consenting to their release. -- Allowing release to the right people is logical, but at the time they came out those people didn't care. >From the chat: Mary Wong: There is ongoing implementation of Board-adopted GNSO PDP recommendations regarding a few names for the Red Cross movement and names of IGOs. Jeff Neuman: I agree on this category and the IGOs. Mary Wong: Per Alan, other Red Cross names are still under discussion. Mary Wong: @Michael, to add - what I said (i.e. long list currently now reserved under Spec 5) also applies to IGOs. The only reserved protections approved so far for IGOs are their names. Their acronyms are now on the list only on an interim basis. Mary Wong: All, note that in the current implementation for Red Cross, IOC and IGOs - there will be an Exception procedure for the protected organization.

1 0

WT2 - Jan 12th, Thursday Meeting at 20:00 UTC
by Michael Flemming Jan. 12, 2017

Jan. 12, 2017

Dear All, Please note the agenda for the meeting this Thursdayt 20 UTC. 1. Welcome 2. Updated SOI 3. Remaining Reserved Names at the Second Level 4. Registrant Protections 5. AOB I will try to provide background material or at least a link to the excerpt to the Issue Report for the Registrant Protections tomorrow. We will likely be continuing the heart of our conversation over email because the number of meetings is restricted to the one this Thursday. Kind regards, Michael Flemming

2 1

Fwd: [Meeting Invite] New gTLD Subsequent Procedures Sub Team – Track 2
by Michael Flemming Jan. 10, 2017

Jan. 10, 2017

There seems to be a number of participants that did not receive the invitation for the meeting this Thursday. Therefore, I am forwarding this in the hopes that those who do not have this in their calendar may add it. Regards, Michael Flemming Dear All, The call for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues will take place on *Thursday, 12 January 2017 at 20:00 UTC.* 12:00 PST, 15:00 EST, 20:00 London, 21:00 CET For other times: http://tinyurl.com/hdpfxmb Adobe Connect room: https://participate.icann.org/newgtldsubteams/ You can connect your audio by following instructions in the pop up in the AC room, or use the Connect Me option below (also sent in the calendar invitation). Kind regards Michelle DeSmyter *You're Invited.* You've been invited to a GlobalMeet® phone only meeting. *Have the meeting call you.* Click the Connect Me link below. *No need to dial-in.* *Connect Me *[toolbar.conferencinghub.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__toolbar.conferencinghu…> *Not at your computer?* You can join by dialing one of the access numbers below. *Mobile:* tel://1-719-457-6209,*,,8650457825# <//1-719-457-6209,*,,8650457825> *Phone Only Controls:* https://toolbar.conferencinghub.com/pmc/pmc.aspx?conf= It9YhUoAI2rfs1zIA%2bAx3QmQT6tWBqeXWSFdqGVekIsztvtH9f% 2fwTmVoUoGQcXIjam6xqRJSb%2ft1Xa1F2iFDtJK8Rimw5MHjUZDWRcl3kja N7ZyZiz2RZ%2f8F4gxhagi8[toolbar.conferencinghub.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__toolbar.conferencinghu…> *Primary Access Number:* 1-719-457-6209 <(719)%20457-6209> *Guest Passcode:* 865 045 7825 *Additional Access:* USA 1-719-457-6209 <(719)%20457-6209> Canada, Calgary +1 403 407 5793 <(403)%20407-5793> Canada, Montreal +1 514 669 5928 <(514)%20669-5928> Canada, Toronto +1 647 426 9172 <(647)%20426-9172> Canada, Vancouver +1 604 222 7836 <(604)%20222-7836> Argentina (toll free) 0800 666 2649 Argentina (toll free) 0800 800 1223 Argentina, Buenos Aires +54 (0) 11 5172 6003 <+54%2011%205172-6003> Australia (toll free) 1 800 804 786 Australia, Brisbane +61 (0) 7 3015 0535 <+61%207%203015%200535> Australia, Melbourne +61 (0) 3 8687 0553 <+61%203%208687%200553> Australia, Sydney +61 (0) 2 8017 6064 <+61%202%208017%206064> Austria (toll free) 0800 8866 3413 Austria, Vienna +43 (0) 1 25302 1785 <+43%201%20253021785> Bahrain (toll free) 800 04212 Bahrain, Manama +973 1619 8739 <+973%201619%208739> Belarus (toll free) 8 820 0011 0341 Belgium (toll free) 0800 39279 Belgium, Brussels +32 (0) 2 400 6928 <+32%202%20400%2069%2028> Brazil (toll free) 0800 887 0233 Brazil, Rio de Janeiro +55 21 2730 6944 <+55%2021%202730-6944> Brazil, Rio de Janeiro +55 21 4560 0072 <+55%2021%204560-0072> Brazil, Sao Paulo +55 11 3351 7036 <+55%2011%203351-7036> Brazil, Sao Paulo +55 11 4935 7169 <+55%2011%204935-7169> Bulgaria (toll free) 00800 111 4950 Bulgaria, Sofia +359 (0) 2 491 6045 <+359%202%20491%206045> Canada (toll free) 1 855 950 3717 <(855)%20950-3717> Chile (toll free) 171 800 835 783 Chile (toll free) 800 363 514 Chile, Santiago +56 (0) 2 2666 0696 <+56%202%202666%200696> China (national) +400 613 8103 China, Beijing +86 10 5667 0003 <+86%2010%205667%200003> China, Shanghai +86 21 2039 7081 <+86%2021%202039%207081> Colombia (toll free) 01 800 518 0646 Colombia (toll free) 01 800 755 0102 Colombia, Bogota +57 1 508 8137 Croatia (toll free) 0800 805 940 Cyprus (toll free) 800 97424 Czech Republic (toll free) 800 701 532 Czech Republic, Prague +420 225 986 554 <+420%20225%20986%20554> Denmark (toll free) 80 70 35 86 Denmark, Copenhagen +45 32 72 78 10 <+45%2032%2072%2078%2010> Egypt (toll free) 0800 000 0593 Estonia (toll free) 800 011 1589 Estonia, Tallinn +372 622 6551 <+372%20622%206551> Fiji (toll free) 00800 3322 Finland (toll free) 0800 772 236 Finland, Helsinki +358 (0) 9 2310 1677 France (national) 0811 655 100 France (toll free) 0800 946 531 France, Paris +33 (0) 1 70 37 16 56 <+33%201%2070%2037%2016%2056> Germany (national) 01801 003 899 Germany (toll free) 0800 588 9170 Germany, Frankfurt +49 (0) 69 2222 10612 <+49%2069%20222210612> Germany, Munich +49 (0) 89 2030 31207 <+49%2089%20203031207> Greece (toll free) 00800 128 913 Greece, Athens +30 211 181 3824 <+30%2021%201181%203824> Hong Kong +852 3018 9111 <+852%203018%209111> Hong Kong (toll free) 800 901 787 Hungary (toll free) 068 001 9673 Hungary, Budapest +36 1408 8953 Iceland (toll free) 800 9847 India (toll free) 000 800 1008 367 India, Bangalore +91 (0) 80 6127 6710 <+91%2080%206127%206710> India, Chennai +91 (0)44 6688 6061 <+91%2044%206688%206061> India, Delhi +91 (0) 11 6641 1394 <+91%2011%206641%201394> India, Mumbai +91 (0)22 6187 5028 <+91%2022%206187%205028> Indonesia (toll free) 001 803 016 2541 Indonesia (toll free) 007 803 321 8927 Ireland (national) 1890 907 630 Ireland (toll free) 1800 937 649 Ireland, Dublin +353 (0) 1 526 9421 <+353%201%20526%209421> Israel (toll free) 1809 213 168 Israel, Tel Aviv +972 (0)3 721 7943 <+972%203-721-7943> Italy (toll free) 800 146 094 Italy, Milan +39 02 3600 8006 <+39%2002%203600%208006> Italy, Rome +39 06 8750 0676 <+39%2006%208750%200676> Japan (mobile) 0120 632 611 Japan (toll free) 0120 305 211 Japan, Chiba +81 (0) 43 321 6881 <+81%2043-321-6881> Japan, Fukuoka +81 (0) 92 290 6881 <+81%2092-290-6881> Japan, Hiroshima +81 (0) 82 558 6881 <+81%2082-558-6881> Japan, Nagoya +81 (0) 52 850 6881 <+81%2052-850-6881> Japan, Osaka +81 (0) 6 4560 2410 <+81%206-4560-2410> Japan, Sapporo +81 (0) 11 234 6881 <+81%2011-234-6881> Japan, Sendai +81 (0) 22 708 6881 <+81%2022-708-6881> Japan, Shizuoka +81 (0) 54 902 6881 <+81%2054-902-6881> Japan, Tachikawa +81 (0) 42 841 6881 <+81%2042-841-6881> Japan, Tokyo +81 (0) 3 4560 1270 <+81%203-4560-1270> Japan, Toyama +81 (0) 76 408 6881 <+81%2076-408-6881> Japan, Urawa +81 (0) 48 698 6881 <+81%2048-698-6881> Japan, Yokohama +81 (0) 45 677 6881 <+81%2045-677-6881> Kazakhstan (toll free) 8800 333 7554 Latvia (toll free) 8000 4418 Latvia, Riga +371 6601 3627 Lithuania (toll free) 8800 31449 Lithuania, Vilnius +370 5205 5468 Luxembourg +352 2088 1749 <+352%2020%2088%2017%2049> Luxembourg (toll free) 800 28433 Malaysia (toll free) 1 800 816 152 Malaysia,Kuala Lumpur +60 (0) 3 7724 8010 <+60%203-7724%208010> Mexico (toll free) 01 800 054 0370 Mexico (toll free) 01 800 733 4102 Mexico, Guadalajara +52 33 4162 4504 <+52%2033%204162%204504> Mexico, Mexico City +52 55 4777 2658 <+52%2055%204777%202658> Mexico, Mexico City +52 55 8421 0326 <+52%2055%208421%200326> Mexico, Monterrey +52 81 4162 5648 <+52%2081%204162%205648> Morocco (toll free) 0800 091 296 Morocco, Casablanca +212 (0) 520 48 0022 Netherlands (toll free) 0800 020 2597 Netherlands, Amsterdam +31 (0) 20 716 8345 <+31%2020%20716%208345> New Zealand (toll free) 0800 452 947 New Zealand, Auckland +64 (0) 9 929 1825 <+64%209-929%201825> New Zealand, Christchurch +64 (0) 3 974 2596 <+64%203-974%202596> New Zealand, Wellington +64 (0) 4 909 4674 <+64%204-909%204674> Nigeria, Lagos +234 1 277 3944 <+234%201%20277%203944> Norway (toll free) 800 56081 Norway, Oslo +47 21 00 48 15 <+47%2021%2000%2048%2015> Panama (toll free) 00 800 226 3770 Panama (toll free) 00800 223 1390 Panama, Panama City +507 8 335 913 Peru (toll free) 0800 55 092 Peru (toll free) 0800 78102 Peru, Lima +51 (0) 1 700 9571 Philippines (toll free) 1 800 111 013 99 Philippines, Manila +63 (0)2 395 3426 <+63%202%20395%203426> Poland (toll free) 00 800 121 4356 Poland, Warsaw +48 22 295 3570 <+48%2022%20295%2035%2070> Portugal (toll free) 800 784 442 Portugal, Lisbon +351 21 316 4093 <+351%2021%20316%204093> Qatar (toll free) 00 800 100 491 Romania (toll free) 0800 801 035 Romania, Bucharest +40 (0) 21 529 3992 <+40%2021%20529%203992> Russia (toll free) 8 800 500 9241 Russia, Moscow +7 495 646 9181 <+7%20495%20646-91-81> Saudi Arabia (toll free) 800 844 6641 <(800)%20844-6641> Saudi Arabia (toll free) 800 850 0219 <(800)%20850-0219> Singapore +65 6622 1957 <+65%206622%201957> Singapore (toll free) 800 616 3192 <(800)%20616-3192> Slovakia (toll free) 0800 002 002 Slovakia, Bratislava +421 (0)2 3321 5498 Slovenia (toll free) 0800 81193 Slovenia, Ljubljana +386 1600 8695 South Africa (toll free) 0800 999 434 South Africa, Johannesburg +27 (0)11 589 8321 <+27%2011%20589%208321> South Korea (toll free) 00798 6136 1454 South Korea, Seoul +82 (0) 2 6007 0079 <+82%202-6007-0079> Spain (toll free) 900 828 035 Spain, Barcelona +34 93 800 1946 <+34%20938%2000%2019%2046> Spain, Madrid +34 91 114 6653 <+34%20911%2014%2066%2053> Sweden (toll free) 0200 125 588 Sweden, Stockholm +46 (0) 8 5065 3956 Switzerland (toll free) 0800 740 360 Switzerland, Geneva +41 (0) 22 595 4795 <+41%2022%20595%2047%2095> Switzerland, Zurich +41 (0) 44 580 7207 <+41%2044%20580%2072%2007> Taiwan (toll free) 0800 666 596 Taiwan, Taipei +886 (0) 2 2650 7329 <+886%202%202650%207329> Thailand (toll free) 001 800 6136 1473 Turkey (toll free) 00800 4488 26642 Turkey, Istanbul +90 212 375 50 49 <+90%20212%20375%2050%2049> UAE (toll free) 8000 3570 2662 UK (03) +44 (0)330 336 6002 <+44%20330%20336%206002> UK (national) 0844 581 8062 UK (national) 0845 351 2782 UK (toll free) 0800 358 6385 Ukraine (toll free) 0800 500 896 Uruguay (toll free) 0004 019 0152 USA /Canada (toll free) 1-866-398-2885 <(866)%20398-2885> Venezuela (toll free) 0 800 162 7451 Vietnam (toll free) 1800 9226

2 1

The Case for a Single Registry Agreement
by Kurt Pritz Dec. 16, 2016

Dec. 16, 2016

Hi Everyone: During past meetings of this group, we raised the possibility of creating new categories of TLD registries and separate versions of registry agreements for the next round. The primary purpose of the categories, as I understand it, is to obtain exemptions, concessions or accommodations to the registry agreement so that the TLD registries in a category can more easily / effectively / economically pursue its mission. I believe that exemptions from certain terms in the registry agreement, when appropriately and swiftly granted, will encourage innovative uses for TLD registries. While I fully support the position that TLD registries should be able to obtain exemptions from certain Registry Agreement terms based on their business model, I do not support the creation of TLD categories or different versions of the Registry Agreement a priori. The reasons for this are that: (1) categories are generally unworkable, (2) there is a more elegant way to achieve the goals of registries seeking a Registry Agreement matched to their needs, and (3) it will be faster from a policy and implementation standpoint to avoid considering many requested category suggestions. The difficulties with implementing different categories can be demonstrated by looking at past and future gTLD rounds. The single most important lesson from the 2003-04 sponsored TLD round was to avoid a system where delegation of domain name registries was predicated upon satisfying criteria associated with categories. There were ten applicants. The evaluation panel found only two of them qualified under the sponsorship criteria as applicants tried to “shoe-horn” their applications into the definition of “sponsored.” We could expect the same behavior in future applications once a category definition is created. The two most notable failures in this current (2012) round of TLD delegations were the two categories described by the Applicant Guidebook: Community Priority Evaluations and the attempt to measure the requisite government approvals for geographic names. Subjective criteria used in the Community Priority Evaluations did not yield repeatable results and even the objective criteria used for geographical names yielded errors and controversies. Suggested new categories already portend a confusing landscape. Community comment in the 2012 round suggested the creation of several TLD categories, for example: single-owner, country, not-for-profit, intergovernmental organization, socio-cultural, community and open. Depending on the category, various accommodations were suggested, for example, relief from: the requirement to sign an ICANN Registry Agreement, to use accredited registrars, pay ICANN fees or to follow consensus policy, or to follow instead the policy provisions outlined in the GAC’s ccTLD principles. The introduction of a number of new gTLD categories with a number of different accommodations will lead to a complex and difficult application, administration and evaluation process, in addition to a very complicated contractual compliance environment. For those who want a smoothly running, fair, predictable gTLD program, the creation of categories should be avoided. Nonetheless, fair and appropriately flexible agreements can be written without the need, time and complexity of the creation of additional categories or separate agreements. An exemption process can be created to encourage innovation while ensuring all policy goals embodied in the RA are met. The Registry Agreement was written largely to satisfy the policy goals of the new gTLD program. It is more straightforward to evaluate a registry requesting an accommodation against the policy goals of the agreement and grant the accommodation so long as the policies are not violated. For example, there is a policy that, “Strings must not cause any technical instability.” A simple implementation of this policy is the data escrow requirement (with Iron Mountain and NCC Group as the lone providers) to ensure ongoing operation in case of failure. It is conceivable that a different version of .bank might have emerged with a demonstrably valuable promise that data would not leave the confines of the .bank operator, which had demonstrated diversity and security capability beyond that of the escrow providers. In that case, the policy to enhance stability would be better served by granting an exemption for the data escrow requirement to the new .bank. The new .bank should not be required to form a category in order to gain an exemption. The working group can call for the creation of a process that considers forgiving certain contractual provisions whenever such a request promotes the goals of the new gTLD program and does not obviate the policy reason for the contractual clause in question. This is not so different from a smoothly running Registry Services Evaluation Procedure (RSEP). For example, when asked for an exemption, ICANN should require demonstrable evidence that: The exemption will further a goal of the new gTLD program (such as innovation or increased competition or choice). The exemption does not defeat the policy goal of the contractual provision. Stating the policy goal of the provision Demonstrating why the exemption does not defeat the policy goal In line with the RSEP, demonstrating no deleterious effects to stability, security, resiliency and competition. Similar to RSEP, this process should occur within a 15-day window. Just as in the RSEP, there will be similarity among applications that will become easy to administer. While it sounds complex, it is not compared to the nightmare that the new gTLD process will become, never adequately administering to an ever-increasing number of categories. The outcome of our policy discussion could result in a process that remains flexible and can adapt to new business models as they are developed. The alternative will be an ongoing attempt to create policy and implementation plans for new categories as they are conceived. This is not to say that TLD categories should be forbidden. Categories can self-form and create guiding principles, internal policies or other membership criteria. However, rather than painstakingly create policy governing the formation of specific categories and registry agreements, the group could call for an overarching process to accommodate and facilitate new business models as they develop. Thanks for taking the time to read and consider this. Sincerely, Kurt ________________ Kurt Pritz kurt(a)kjpritz.com +1.310.400.4184 Skype: kjpritz WeChat: kjpritz

7 6

Recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team - Track 2 - Legal Regulatory Issues
by Michelle DeSmyter Dec. 15, 2016

Dec. 15, 2016

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues held on Thursday, 20 October 2016 at 20:00 UTC. <https://urldefense.proofpoint.com/v2/url?u=http-3A__audio.icann.org_gnso_gn…> The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Wiki page: https://community.icann.org/x/2SC4Aw Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for 20 October 2016 Michelle DeSmyter:Dear all, Welcome to the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues call on Thursday, 20 October 2016 at 20:00 UTC. Phil Buckingham:Hi Michelle , Steve , Im in ! Phil Buckingham:thanks . Should be an "interesting " next hour ! Jeff Neuman:Hello all Jeff Neuman:vtLD (Validated top Level domains) Gg Levine (NABP):NABP is participating Gg Levine (NABP):Absolutely! Jeff Neuman:.bank yes Jeff Neuman:.pharmacy, .ngo / .ong Jeff Neuman:.law Gg Levine (NABP):TLD in which regigrants must meet registry standards prior to use of the domain Alexander Schubert:.gay :-) Jim Prendergast:Jeff has them allmemorized Paul McGrady:On a flight now, so only able to contribute via chat today. Alexander Schubert:Not yet delegated Jim Prendergast:still in contention, isnt it? Alexander Schubert:Still in contention Steve Chan:CTAG Alexander Schubert:CTAG! Steve Chan:Community TLD Applicant Group Paul McGrady:@Jeff Neuman - I have missed a call or two due to a family issue. DId we decide to include the Terms & Conditions from the Guidebook into this group or will they be looked at in another group? Thanks! Jeff Neuman:We consider feedback from everyone Jeff Neuman:@Paul - Yes.....but have not looked at them yet Paul McGrady:Perfect! Thanks @Jeff. Phil Buckingham:kurt - can you speak up a little Kurt Pritz:pretty close Kurt Pritz:I am in a crowded spot. sorry Kevin Kreuser:justification is the right term, IMO, but I think it should be a high bar Jeff Neuman:@kevin - Why a high bar? Alexander Schubert:Do we talk Spec 5? Phil Buckingham:alexander - spec 5 later Alexander Schubert:So is this top level or second level? Jeff Neuman:@Alexander - both Alexander Schubert:Seemingly 2nd.... Alexander Schubert:BOTH? Alexander Schubert:Apples & Oranges? Jeff Neuman:We will need to consider both reserved names at the top level as well as those at the second level Kevin Kreuser:bc the justification for most changes requested to the RA in this round were not due to something special in the applicant or the category that the applicant lived, but instead were based on the business' own limitations. TM rights and for protections I think are an exception. Multiple agreements for registrars can also be difficult to implement Jeff Neuman:How are multiple registry agreements difficult for registrars? (I am not disagreeing, but want to flush this out) Jeff Neuman:@Kevin - If one registry agreement has a different indemnity provision than another....how would that affect registrars Jeff Neuman:(as an example) Kevin Kreuser:depends on what changes are permitted by category. if technical, which I hope would not be the case, could cause difficulties Kevin Kreuser:nevermind us, we're just chatting Jeff Neuman:Not sure why that is.....I will call in. Kurt Pritz:one part of the COI question might be whether the COI is stiil Kurt Pritz:required Kevin Kreuser:@Kurt, ICANN would welcome eliminating the COI itself, but is still going to want a way to fund EBERO Cheryl Langdon-Orr (CLO):Finally into the AC Been on the audio bridge only until now Kristina Rosette (Amazon Registry):Someone should take a look at the transcript of the new gTLD session in Toronto. Many participants raised complaints and concerns about the COI. ICANN's responses seem unlikely to be different now, IMHO. Kurt Pritz:@Kevin. there are a lot of ways to skin that cat. For later substantive discussion Kevin Kreuser:absolutely Alexander Schubert:With reserved names we have to strictly distinguish between top and second level! Alexander Schubert:CWG Jeff Neuman:that was in 2006 Kristina Rosette (Amazon Registry):Are you talking about the 2006 WG? Kevin Kreuser:@Kristina, ICANN is holding and managing LOIs and Data Escrow agreements for all of these TLDs. It's an administrative nightmare. I cannot imagine they wouldn't love to be rid of them, perhaps by way of insurance of some manner, taking a portion of the applicant fee and dumping into a pool, etc as an alternatives Steve Chan:FYI, the document is un-synced...as Michael just noted. Paul McGrady:Kevin, we went down the "insurance" path in Round 1 and it was rejected. Start ups are not the same risk footprint as .Brands. Kristina Rosette (Amazon Registry):@Kevin: I think Paul McGrady has some views on ICANN as an insurer (although I was super sick in Dakar and could be misremembering). Kevin Kreuser:Understand re insurance, point was more I believe they would be open to exploring better alternatives Jeff Neuman:https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_… Michael Flemming:Staff, could we make a note in the Notes to capture the discussion on COIs that is taking place in the chat so that we may use this as feedback and come back to this when we are ready to have more detailed discussion? Michael Flemming:please* Michael Flemming:A lot of constructive discussion. Thank you, everyone. Michael Flemming:Thanks! Jeff Neuman:We should also split the top level from second level Alexander Schubert:+1 Annebeth Lange:+ 1 Cheryl Langdon-Orr (CLO):+1 Julie Hedlund:@Michael: I have copied it, but I'll note that it is redundant. The chat notes are captured separately by the Secretariat staff and is posted to the wiki. Alexander Schubert:And it Is split in the AG! Paul McGrady:@Kevin, lots can be done with the EBERO issue to drive out costs and uncertainty, thus reducing ICANN's involvement/risk. Alexander Schubert:Spec 5 is 2nd level, right? Michael Flemming:Yes Michael Flemming:Anything in the RA would refer to second level reservations Michael Flemming:...I believe Kevin Kreuser:some restrictions are at "all levels" Kevin Kreuser:country and territory, for exampel Jeff Neuman:I think we should take one by one Jeff Neuman:See what the policy recomendation was and then compare with what was done Steve Chan:Phil is discussing the existing Reserved Name Requirements (at that time) Annebeth Lange:And the Reserved Names report came in 2006 - not completely consistent with the AG Steve Chan:What is in the AC room is the recommendation table recommended for new gTLDs Michael Flemming:Yes, Phil is looking at the Roles of Reserved Names Table Jeff Neuman:The applicant Guidebook in Section 2.2.1.2.1 has the initial list of top-level reserved names Jeff Neuman:Then this section was added: 2.2.1.2.3 to cover red cross / olympics Cheryl Langdon-Orr (CLO):Indeed Annebeth that out of Synch is important to note Julie Hedlund:See the table at: https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_issu… Kristina Rosette (Amazon Registry):May I suggest that we start with what was in the AG and only revert back to the Reserved Names WG recommendations and the 2000/2003 Reserved Name requirements, as needed? Cheryl Langdon-Orr (CLO):works for me Kristina Annebeth Lange:I agree Annebeth Lange:It has been a lot of discussion between the result of the Reserved Names WG recommendations and the result in the AG Kristina Rosette (Amazon Registry):+1 Jeff Cheryl Langdon-Orr (CLO):+1 Kristina Rosette (Amazon Registry):Is there anyone who thinks that we shouldn't have reserved names on the top level? Annebeth Lange:The AG should be the starting point here Kevin Kreuser:home Alexander Schubert:hiome? Alexander Schubert:Yap: home Cheryl Langdon-Orr (CLO):4 Julie Hedlund:All: Just a time check. 2 minutes to the top of the hour. Cheryl Langdon-Orr (CLO):WT4 Heather Forrest:It seems to me that it would be helpful to have everyone in the group go back to the RNWG Report to understand the justifications reached by that group Jeff Neuman:@heather - yes please Annebeth Lange:And we have to remember that this was long time ago - before the AG that I think had input from more stakeholdergroups than RNWG Cheryl Langdon-Orr (CLO):Have to leave my next call is starting now Cheryl Langdon-Orr (CLO):Bye Paul McGrady:Thanks all! Annebeth Lange:Bye Alexander Schubert:Thanks! Jeff Neuman:@Annabeth - Agree, BUT we need to revise the policy so we need to understand the original policy Annebeth Lange:Absolutely, Jeff Heather Forrest:thanks everyone Robin Gross:thanks all, bye Alexander Schubert:Midnight :-) Robert Burlingame:Thank you. Bye. Annebeth Lange:Here too, ALexander Emily Barabas:Next call will be after ICANN57, invitation to be sent out

2 1

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 15 December
by Julie Hedlund Dec. 15, 2016

Dec. 15, 2016

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 15 December. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording. See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. See also the attached slides that are referenced below and posted on the wiki. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 15 December ACTION: Look at the new language of the registry agreement once it comes out and how that language may affect some reservations. Reserved Names at the Second Level – See the Google Doc at: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8…. >From the chat: Jeff Neuman: Remember the default...if we get no comments otherwise, the assumption is that whatever is applicable today will be applicable in the future. So speak up if you have an issue :) ICANN/IANA Names -- All Levels and 2nd & 3rd levels; Example reserved at all levels, ASCII only. -- Not adoped/not protected at the second level -- Doesn't seem to be support to change policy to reserve at the second level. -- Move in the direction of the AGB to not reserve at the second level. -- Before the AGB was final, ICANN had itself, IANA, and some others proposed to be protected, but if it wasn't going to protect other organizations it wasn't going to protect its own. -- The rationale was that if someone could pretent to be ICANN/IANA etc. -- Example has been reserved for a long time. Don't need to spend a lot of time on it. >From the chat: Rubens Kuhl: I think IANA still deserves such reservation. It's a "household name" of sorts. As in the IANA label only, not all the IANA labels. Example and ROOT-SERVERS are also worth keeping reserved, IMHO. ICANN is not worthy reserving. ;-) Example was also mentioned as an IANA label. Annebeth Lange, ccNSO: To reserve anything at second level, there should be a very good reason why. Why ICANN and IANA and not other international organisations? Jeff Neuman: @Annabeth - that is why ICANN took its name off the list Rubens Kuhl: IANA is not an organization, PTI is. IANA is similar to INTERNIC, a long-recalled name with a meaning. Annebeth Lange, ccNSO: Exactly :-) That is true, Rubens. You have a point. Rubens Kuhl: It's also of note that we could move such names to being "LRO material", as in someone which is not RIPE applies for .RIPE, RIPE could file an LRO. Greg Shatan: The iana.org domain name is used for emails instructing changes to the Root Zone, and for the website on which critical information is displayed. PTI also owns iana.com and iana.net. Jeff Neuman: @Rubens I know IP attorneys that could make similar arguments :) If a registry wants to reserve other versions of "example" it may do so on its own. But I see no reason why it should be protected by ICANN in all TLDs Trang Nguyen: There was a reserved names working group. The final report is posted at https://gnso.icann.org/en/drafts/rn-wg-fr19mar07.pdf and may provide some background info. Symbols -- not allow them except for hyphens. >From the chat: Jeff Neuman: the 2009 "recommendation" is the result of the final report from the reserved names working group. Rubens Kuhl: ICANN disallowed even the hyphen. Jeff Neuman: @Rubens - only when the hyphen is in the 3rd and 4th position Greg Shatan: This probably requires an IETF RFC, I'm guessing. Symbols, that is. Single and two-character IDNs -- Leave as is (no reservations). -- May be noteworthy to make mention of what is possible. >From the chat: Annebeth Lange, ccNSO: Just a heads up for the Standardized Framework for Release of Two-Character ASCII Labels to avoid confusion with corresponding country codes, published yesterday. And a comment to IDNs - there have been instances where a 2-letter IDN is to similar to a 2-letter ASCII, so that it could not be accepted. It was on first level, but still it might appear on second level as well. Single letters and digits -- accepted at 2nd and 3rd level -- No reservations. Suggest leaving as is. Any combination of two letters, digits -- There is now a measurement to allow for the release for these characters if registries folllow certain policy and implementation requirements to avoid confusion. -- Could change policy to note the implementation guidelines. -- This provision is to avoid risk of confusion with the country codes. Could warrant something in the policy acknowledging which combinations raise that concern (letter-letter, number-number). >From the chat: Susan Payne: Having said which, am I right in thinking that we are holding over the "country code" issue to discuss in the wider context of geo names? EP, EC, EU, AU, UN Annebeth Lange, ccNSO: As for geo-names, I think that should be kept at first level. GAC has been discussing 2-letter codes from ISO-list 3166 at second level, but I do not think they have - at least so far - been anxious about other geonames at second level. Tagged Names -- IDN guidelines are the default; an exception can be granted. Right now IDN guidelines would be ceilings. -- Currently the policy to implement the AGB reserves the hyphen in the 3rd and 4th location. -- This isn't the only way the IDN guidelines can be implemented. -- Suggesting not changing. >From the chat: Rubens Kuhl: I'll note that a registry might be allowed to not follow ICANN IDN Guidelines to the letter, by making an RSEP request that ICANN approves. So the guidelines are not the ultimate restrictions to it Jeff Neuman: The third and 4th hyphens could in theory be used for other types of IETF protocols..but to my knowledge they have not been NIC, WHOIS, WWW -- 2nd & 3rd ASCII (now includes RDDS); IDN -- This is a pain point for IDN registires -- forced to use ASCII only for the NIC label (could not use non-ASCII script) for the registry operation, but this has already changed. -- Talking about two different things -- reservation of the name versus use of the name. Not sure if there would be a change in the reservation policy. -- Not trying to translate them is what is important, but could consider saying that any translation could be used by the registry. -- For purposes of blocking a name do not try to translate it. Could change to using either NIC or a translation of NIC...(language that is not as strong). >From the chat: Alexander Schubert: Jeff is right! (about there being two different things).

1 0