Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017
Dear Work Track members, Please see below the action items and notes from the meeting today. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/x/ERohB. Slides are attached for reference and some chat room excerpts are included. Kind regards, Julie Julie Hedlund, Policy Director ---------------------------------------------------------------------------------------- Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 1. Name Collisions: Source data from GDD Technical Services, that acts as the basis for the information being presented by Rubens, is available on the Name Collisions Wiki page here: https://community.icann.org/x/Yz2AAw Slide 5: What's in today's agenda and what's still ahead: -- Results from GDD inquiry on reported collisions -- Whether 2012-round gTLD should keep readiness after 2 years of delegation -- Whether SubPro gTLDs should have readiness or not, and length of such readiness. Slide 6: Report collisions from 2012-round: -- No life-threatening collisions; -- 18 unique TLDs represented in 34 occurences -- Median of 3 occurences per TLD -- Median of 22 days between delegation and report -- 23 cases reported as service disruption, etc. Slide 7: Reported collisions from 2012-round (cont.): -- In 24 cases the registry was not contacted -- determined by ICANN Org that it was not necessary. -- In 5 the registry was put in contact with the reporter, in 1 registry stopped controlled interruption, in 1 no action. -- Few data on outcomes -- all 5 known outcomes the network was updated. Slide 8: Two-year readiness for current new gTLDs: All 2012-round gTLDs were required to pass a controlled interruption period and be able to respond within two hours for life-threatening reports for first 2 years of delegation. Options: a) 2012-gTLDs should extend readiness beyond the 2-year period b) 2012-gTLDs should only have such readiness in those 2 years as currently foreseen in the framework b) 1 year Poll: Option a: No one. Option b: 6 in favor Option c: 1 in favor
From the chat:
Sarah L Verisign: Rubens can we get back to you on this later this week rather than saying now? Cheryl Langdon-Orr (CLO ): Sarah this is a temp taking not deffinative pol Jon Nevett: we should do a cost differential before voting Sarah L Verisign: I understand but I need to discuss this with other folks before making even a temp position Jon Nevett: what is the cost of the readiness -- if not a lot, not big deal Jon Nevett: if it is a lot, then it gets passed on Alan Greenberg: Cost is lower for orgs that have multiple TLDs, since cost of readiness for 10 is no larger than 1 and TLDs come on line at different times. Anne Aikman-Scalese (IPC): Agree with Alan that every new gTLD is different. Initial evaluations on name collision risk could make a big difference here. Cheryl Langdon-Orr (CLO ): thus my 'personal' comfort with the status quo on this at 2y Alan Greenberg: My intervention was really in relation to THIS question, not just the 2012 gTLDs. Slide 9: Framework -- Two-year readiness for SubPro gTLDs: Question: Should gTLDs in subsequent procedures be subject for such 2-year readiness for life-threatening collisions? Options: a) Same 2-hour for life-threatening collisions readiness for first -- years. (Assume keeping 2 years.) b) No need for readiness. c) SubPro gTLDs should have readiness covering more conditions with -- hours/days SLA Poll: Option a: 4 in favor Option b: 1 in favor; 3 against Option c: None -- Should there be different responses for different types of TLDs?
From the chat:
Dietmar Lenden - Valideus: 2 years would appear fair for all applicants past and present 2. Registry Services: ACTION: Send slides 12-16 to the list and ask the list to consider and discuss on the list the three straw-persons, contrasts, and slide 16. Take up this conversation at this point in the agenda next week. Slide 12: Straw-person #1 Slide 13: Straw-person #2 Slide 14: Straw-person #3 Discussion on Straw-person #1: -- Change in SP#1: When registry services are proposed that is when the community has the opportunity to comment and provide input. You don't know the impact that the services may have. Don't want to discourge proposals for new services. -- On the registry services policy -- they don't have to get input from the community except when ICANN makes a finding that a concern has to be evaluated. Then the community comments on that concern via the report of the RSEP panel. We can go beyond that for new gTLDs. -- With respect to input on new gTLD applications, the community doesn't have a formal process but many of us review the applications. There are informal methods and if there is an irregularity there are ways in ICANN to raise an issue. -- If an applicant knows that if an applicant specifies a registry service and that it will go through more evaluation, that is a disincentive to provide that registry service early on. Then after signing the contract they will file an RSEP.
Dear all, Cheryl has asked that we consider an be prepared to discuss Slides 12, 13, and 14 in the attachment in our October 12 call – three Straw Proposals re new registry services in applications. Regarding the three Straw Proposals as to whether or not a registry operator needs to describe new services in its application, one item we have not fully considered is that the GAC is still likely to have input at the application stage. If the GAC has input, I don’t think we want to foreclose the GNSO or other policy (e.g. ALAC) input to the Board. There is also the Objection process to be considered and new registry services could be relevant to evaluating an Objection. (This is also why the Answer to Question 18 – purpose of the TLD is relevant.) One risk we face in Straw Proposals 1 and 3 (by not requiring new services to be listed in an application) is that the Community (including the GAC) may want more involvement in the RSEP process. For example, if no disclosure of new services is required in the application, should a public comment period for new services proposed via RSEP be mandatory? (This is a transparency issue.) The RSEP process is detailed at the link below. It says that the new service may or may not call for public comment if it “sets new precedent or has substantial effect on ICANN, third parties, or the DNS.” So at present ICANN org determines this I guess. To my mind there is a question whether a change in the application process that does not require a description of new services would necessarily implicate a reexamination of the RSEP process detailed here: https://www.icann.org/resources/pages/workflow-2012-02-25-en There is a comparison statement on Slide 15 which points out that Straw Proposal 2 requires all services to be described in the application. However, the second part of Straw Proposal 2, establishment of a “fast-track” for pre-approved services definitely contemplated that pre-approved services can be named and that would certainly allow for a friendly amendment to Straw Proposal 2 to state that all new services should be detailed but that pre-approved services can just be listed. So it seems that #1 and # 3 don’t require any listing of pre-approved services or new services. This would leave any new services to the RSEP process and leave pre-approved services undisclosed in the application. But the RSEP process doesn’t require public comment if ICANN org determines that is not needed. Straw Proposal # 2 requires listing of new services and assessment of any security/stability concerns, but could either specify (a) no listing of pre-approved services or a (b) simple listing of said pre-approved services (to be determined) without a lot of detail. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image001.png@01D341D4.67202B30] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Julie Hedlund Sent: Thursday, October 05, 2017 3:05 PM To: gnso-newgtld-wg-wt4@icann.org Subject: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 Dear Work Track members, Please see below the action items and notes from the meeting today. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/x/ERohB. Slides are attached for reference and some chat room excerpts are included. Kind regards, Julie Julie Hedlund, Policy Director ---------------------------------------------------------------------------------------- Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 1. Name Collisions: Source data from GDD Technical Services, that acts as the basis for the information being presented by Rubens, is available on the Name Collisions Wiki page here: https://community.icann.org/x/Yz2AAw Slide 5: What's in today's agenda and what's still ahead: -- Results from GDD inquiry on reported collisions -- Whether 2012-round gTLD should keep readiness after 2 years of delegation -- Whether SubPro gTLDs should have readiness or not, and length of such readiness. Slide 6: Report collisions from 2012-round: -- No life-threatening collisions; -- 18 unique TLDs represented in 34 occurences -- Median of 3 occurences per TLD -- Median of 22 days between delegation and report -- 23 cases reported as service disruption, etc. Slide 7: Reported collisions from 2012-round (cont.): -- In 24 cases the registry was not contacted -- determined by ICANN Org that it was not necessary. -- In 5 the registry was put in contact with the reporter, in 1 registry stopped controlled interruption, in 1 no action. -- Few data on outcomes -- all 5 known outcomes the network was updated. Slide 8: Two-year readiness for current new gTLDs: All 2012-round gTLDs were required to pass a controlled interruption period and be able to respond within two hours for life-threatening reports for first 2 years of delegation. Options: a) 2012-gTLDs should extend readiness beyond the 2-year period b) 2012-gTLDs should only have such readiness in those 2 years as currently foreseen in the framework b) 1 year Poll: Option a: No one. Option b: 6 in favor Option c: 1 in favor From the chat: Sarah L Verisign: Rubens can we get back to you on this later this week rather than saying now? Cheryl Langdon-Orr (CLO ): Sarah this is a temp taking not deffinative pol Jon Nevett: we should do a cost differential before voting Sarah L Verisign: I understand but I need to discuss this with other folks before making even a temp position Jon Nevett: what is the cost of the readiness -- if not a lot, not big deal Jon Nevett: if it is a lot, then it gets passed on Alan Greenberg: Cost is lower for orgs that have multiple TLDs, since cost of readiness for 10 is no larger than 1 and TLDs come on line at different times. Anne Aikman-Scalese (IPC): Agree with Alan that every new gTLD is different. Initial evaluations on name collision risk could make a big difference here. Cheryl Langdon-Orr (CLO ): thus my 'personal' comfort with the status quo on this at 2y Alan Greenberg: My intervention was really in relation to THIS question, not just the 2012 gTLDs. Slide 9: Framework -- Two-year readiness for SubPro gTLDs: Question: Should gTLDs in subsequent procedures be subject for such 2-year readiness for life-threatening collisions? Options: a) Same 2-hour for life-threatening collisions readiness for first -- years. (Assume keeping 2 years.) b) No need for readiness. c) SubPro gTLDs should have readiness covering more conditions with -- hours/days SLA Poll: Option a: 4 in favor Option b: 1 in favor; 3 against Option c: None -- Should there be different responses for different types of TLDs? From the chat: Dietmar Lenden - Valideus: 2 years would appear fair for all applicants past and present 2. Registry Services: ACTION: Send slides 12-16 to the list and ask the list to consider and discuss on the list the three straw-persons, contrasts, and slide 16. Take up this conversation at this point in the agenda next week. Slide 12: Straw-person #1 Slide 13: Straw-person #2 Slide 14: Straw-person #3 Discussion on Straw-person #1: -- Change in SP#1: When registry services are proposed that is when the community has the opportunity to comment and provide input. You don't know the impact that the services may have. Don't want to discourge proposals for new services. -- On the registry services policy -- they don't have to get input from the community except when ICANN makes a finding that a concern has to be evaluated. Then the community comments on that concern via the report of the RSEP panel. We can go beyond that for new gTLDs. -- With respect to input on new gTLD applications, the community doesn't have a formal process but many of us review the applications. There are informal methods and if there is an irregularity there are ways in ICANN to raise an issue. -- If an applicant knows that if an applicant specifies a registry service and that it will go through more evaluation, that is a disincentive to provide that registry service early on. Then after signing the contract they will file an RSEP. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
On Oct 10, 2017, at 6:31 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
Dear all,
Cheryl has asked that we consider an be prepared to discuss Slides 12, 13, and 14 in the attachment in our October 12 call – three Straw Proposals re new registry services in applications.
After our call, Policy staff suggested to WT4 leadership, and it was promptly accepted, to also list current policy and implementation(p+i) as another proposal. They also called our attention to the fact that SP2 is that looks more closely to current p+i, but that all 3 proposals look more similar among themselves at to current p+i than dissimilar. </co-chair>
Regarding the three Straw Proposals as to whether or not a registry operator needs to describe new services in its application, one item we have not fully considered is that the GAC is still likely to have input at the application stage. If the GAC has input, I don’t think we want to foreclose the GNSO or other policy (e.g. ALAC) input to the Board.
There is a public comment period for all applications that allow any stakeholder, organised or not in an SO or AC, to provide input on applications.
There is also the Objection process to be considered and new registry services could be relevant to evaluating an Objection. (This is also why the Answer to Question 18 – purpose of the TLD is relevant.)
If an applicant wants to settle a dispute with an objector, it can file a change request and add such registry service if that helps bring peace among the parties...
One risk we face in Straw Proposals 1 and 3 (by not requiring new services to be listed in an application) is that the Community (including the GAC) may want more involvement in the RSEP process. For example, if no disclosure of new services is required in the application, should a public comment period for new services proposed via RSEP be mandatory? (This is a transparency issue.)
That's a policy outside of the scope of this PDP.
The RSEP process is detailed at the link below. It says that the new service may or may not call for public comment if it “sets new precedent or has substantial effect on ICANN, third parties, or the DNS.” So at present ICANN org determines this I guess. To my mind there is a question whether a change in the application process that does not require a description of new services would necessarily implicate a reexamination of the RSEP process detailed here:
https://www.icann.org/resources/pages/workflow-2012-02-25-en <https://www.icann.org/resources/pages/workflow-2012-02-25-en>
The current RSEP implementation is known to be wrong and to have deviated from GNSO and Board approved policy. This is currently under efforts to rectified; that said, what was done in 2012 on what is still suggested by all proposals is to follow then-applicable RSEP implementation for evaluating such services, which aside scalability gains, also provider fairness among applicants and incumbent registries.
There is a comparison statement on Slide 15 which points out that Straw Proposal 2 requires all services to be described in the application. However, the second part of Straw Proposal 2, establishment of a “fast-track” for pre-approved services definitely contemplated that pre-approved services can be named and that would certainly allow for a friendly amendment to Straw Proposal 2 to state that all new services should be detailed but that pre-approved services can just be listed.
Sounds reasonable to me.
So it seems that #1 and # 3 don’t require any listing of pre-approved services or new services. This would leave any new services to the RSEP process and leave pre-approved services undisclosed in the application. But the RSEP process doesn’t require public comment if ICANN org determines that is not needed.
And ICANN Org can only request public comments if a service is found to be a possible security or stability risk. And in that case, there are actually two public comments: one when the matter is referred to RSTEP, for the panel to address both their views on the proposed service and concerns raised by the community, and one when the RSTEP findings are sent to the Board. So a properly-administered RSEP process following GNSO/Board policy either have 0 public comments or two public comments.
Straw Proposal # 2 requires listing of new services and assessment of any security/stability concerns, but could either specify (a) no listing of pre-approved services or a (b) simple listing of said pre-approved services (to be determined) without a lot of detail.
Which I believe goes to the other suggestion made before. Rubens
Rubens, Are you saying that staff recommended stick with current policy and current AGB language in Question 23 as an alternative? Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D34289.C53230F0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, October 10, 2017 5:43 PM To: Aikman-Scalese, Anne Cc: Julie Hedlund; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 On Oct 10, 2017, at 6:31 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Dear all, Cheryl has asked that we consider an be prepared to discuss Slides 12, 13, and 14 in the attachment in our October 12 call – three Straw Proposals re new registry services in applications. After our call, Policy staff suggested to WT4 leadership, and it was promptly accepted, to also list current policy and implementation(p+i) as another proposal. They also called our attention to the fact that SP2 is that looks more closely to current p+i, but that all 3 proposals look more similar among themselves at to current p+i than dissimilar. </co-chair> Regarding the three Straw Proposals as to whether or not a registry operator needs to describe new services in its application, one item we have not fully considered is that the GAC is still likely to have input at the application stage. If the GAC has input, I don’t think we want to foreclose the GNSO or other policy (e.g. ALAC) input to the Board. There is a public comment period for all applications that allow any stakeholder, organised or not in an SO or AC, to provide input on applications. There is also the Objection process to be considered and new registry services could be relevant to evaluating an Objection. (This is also why the Answer to Question 18 – purpose of the TLD is relevant.) If an applicant wants to settle a dispute with an objector, it can file a change request and add such registry service if that helps bring peace among the parties... One risk we face in Straw Proposals 1 and 3 (by not requiring new services to be listed in an application) is that the Community (including the GAC) may want more involvement in the RSEP process. For example, if no disclosure of new services is required in the application, should a public comment period for new services proposed via RSEP be mandatory? (This is a transparency issue.) That's a policy outside of the scope of this PDP. The RSEP process is detailed at the link below. It says that the new service may or may not call for public comment if it “sets new precedent or has substantial effect on ICANN, third parties, or the DNS.” So at present ICANN org determines this I guess. To my mind there is a question whether a change in the application process that does not require a description of new services would necessarily implicate a reexamination of the RSEP process detailed here: https://www.icann.org/resources/pages/workflow-2012-02-25-en The current RSEP implementation is known to be wrong and to have deviated from GNSO and Board approved policy. This is currently under efforts to rectified; that said, what was done in 2012 on what is still suggested by all proposals is to follow then-applicable RSEP implementation for evaluating such services, which aside scalability gains, also provider fairness among applicants and incumbent registries. There is a comparison statement on Slide 15 which points out that Straw Proposal 2 requires all services to be described in the application. However, the second part of Straw Proposal 2, establishment of a “fast-track” for pre-approved services definitely contemplated that pre-approved services can be named and that would certainly allow for a friendly amendment to Straw Proposal 2 to state that all new services should be detailed but that pre-approved services can just be listed. Sounds reasonable to me. So it seems that #1 and # 3 don’t require any listing of pre-approved services or new services. This would leave any new services to the RSEP process and leave pre-approved services undisclosed in the application. But the RSEP process doesn’t require public comment if ICANN org determines that is not needed. And ICANN Org can only request public comments if a service is found to be a possible security or stability risk. And in that case, there are actually two public comments: one when the matter is referred to RSTEP, for the panel to address both their views on the proposed service and concerns raised by the community, and one when the RSTEP findings are sent to the Board. So a properly-administered RSEP process following GNSO/Board policy either have 0 public comments or two public comments. Straw Proposal # 2 requires listing of new services and assessment of any security/stability concerns, but could either specify (a) no listing of pre-approved services or a (b) simple listing of said pre-approved services (to be determined) without a lot of detail. Which I believe goes to the other suggestion made before. Rubens ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
On Oct 11, 2017, at 4:09 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
Rubens, Are you saying that staff recommended stick with current policy and current AGB language in Question 23 as an alternative?
Nope, Staff alerted us that all 3 proposals are not that much different among each other and from current implementation, so they suggested it to also be considered in the whole process. Policy staff has a tradition of keeping a neutral standing and I would be surprised if they ever took position on anything, and they didn't in this case. I just tried to give credit were credit's due, since it was them that realised that. That said, I believe that moving forward comparing to current implementation will make sense for a good number of WT4 discussion topics, so this is likely to appear at some topics ahead. And looking ahead for the full WG Draft Report, I would be in favor in doing for the majority of themes, in fact. Rubens
1. Yes – that is what I meant when I said “consider as an alternative’. 2. Separately, could you please remind me what we said in Work Track 4 re registry rights in relation to idn equivalents to English TLDs owned by that registry? (This came up in Work Track 3 as to string similarity issues.) 3. Also, do we have any responses yet as to the request for input on revising the name collision framework (high risk, medium risk, low risk categories) as sent to (a) IETF (b) Ripe Labs (c) DNS Operations Analysis and Research Center (We note that Google is a Platinum Member and Amazon is a Bronze member) Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D34295.80A71430] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Wednesday, October 11, 2017 12:21 PM To: Aikman-Scalese, Anne Cc: Julie Hedlund; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 On Oct 11, 2017, at 4:09 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, Are you saying that staff recommended stick with current policy and current AGB language in Question 23 as an alternative? Nope, Staff alerted us that all 3 proposals are not that much different among each other and from current implementation, so they suggested it to also be considered in the whole process. Policy staff has a tradition of keeping a neutral standing and I would be surprised if they ever took position on anything, and they didn't in this case. I just tried to give credit were credit's due, since it was them that realised that. That said, I believe that moving forward comparing to current implementation will make sense for a good number of WT4 discussion topics, so this is likely to appear at some topics ahead. And looking ahead for the full WG Draft Report, I would be in favor in doing for the majority of themes, in fact. Rubens ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
P.S. I only point out Google and Amazon as members of the organization mentioned in 3.(c) below because both are applicants for the .mail TLD (now “on hold” and frozen due to name collision issues). For anyone who does not know, our firm represents the United States Postal Service. Thank you, Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D34298.C87F3B40] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Aikman-Scalese, Anne Sent: Wednesday, October 11, 2017 1:33 PM To: 'Rubens Kuhl' Cc: Julie Hedlund; gnso-newgtld-wg-wt4@icann.org Subject: RE: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 1. Yes – that is what I meant when I said “consider as an alternative’. 2. Separately, could you please remind me what we said in Work Track 4 re registry rights in relation to idn equivalents to English TLDs owned by that registry? (This came up in Work Track 3 as to string similarity issues.) 3. Also, do we have any responses yet as to the request for input on revising the name collision framework (high risk, medium risk, low risk categories) as sent to (a) IETF (b) Ripe Labs (c) DNS Operations Analysis and Research Center (We note that Google is a Platinum Member and Amazon is a Bronze member) Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image004.png@01D34298.C85C49F0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Wednesday, October 11, 2017 12:21 PM To: Aikman-Scalese, Anne Cc: Julie Hedlund; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017 On Oct 11, 2017, at 4:09 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, Are you saying that staff recommended stick with current policy and current AGB language in Question 23 as an alternative? Nope, Staff alerted us that all 3 proposals are not that much different among each other and from current implementation, so they suggested it to also be considered in the whole process. Policy staff has a tradition of keeping a neutral standing and I would be surprised if they ever took position on anything, and they didn't in this case. I just tried to give credit were credit's due, since it was them that realised that. That said, I believe that moving forward comparing to current implementation will make sense for a good number of WT4 discussion topics, so this is likely to appear at some topics ahead. And looking ahead for the full WG Draft Report, I would be in favor in doing for the majority of themes, in fact. Rubens ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
On Oct 11, 2017, at 5:33 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
1. Yes – that is what I meant when I said “consider as an alternative’.
2. Separately, could you please remind me what we said in Work Track 4 re registry rights in relation to idn equivalents to English TLDs owned by that registry? (This came up in Work Track 3 as to string similarity issues.)
Regarding specific cases where the IDN TLD happens to be a variant of the ASCII TLD, like .québec and .quebec, the recorded decision was to allow that to the same registry operator, provided some form of bundling is implemented. But it wouldn't apply for instance to translations and transliterations, like the Amazon or the Verisign ones in the 2012-round.
3. Also, do we have any responses yet as to the request for input on revising the name collision framework (high risk, medium risk, low risk categories) as sent to
(a) IETF (b) Ripe Labs (c) DNS Operations Analysis and Research Center (We note that Google is a Platinum Member and Amazon is a Bronze member)
We had this exchange in a message where you asked this Sep 12 and I replied Sep 14... nothing has changed since them. I'll quote my response of Sep 14: "Unfortunately there isn't much substance to report... IETF DNSop WG leadership seems unsure whether it would be a topic for discussion there, and no one responded to the list in DNS-OARC or RIPE DNS WG. What was mentioned both in lists and privately was a bit of surprise that such an effort was ongoing , even from ICANN staffers, and a sense of welcoming this discussion long before instead of after the application window. So my takeaways are: (1) That it was a good move (thanks to ICANN's OCTO suggestion), but a more targeted outreach should be done when we have something more concrete. (2) That we should focus IETF DNSop discussion more towards the Specia Use TLDs theme, something they clearly see as an overlap between IETF and ICANN and are willing to address (3) That DNS-OARC or ICANN DNS Forum would be the forums and events that we should keep interacting with. " Regarding DNS-OARC, the membership of DNS-OARC is quite diverse and representative... for instance, Verisign is the only Diamond (the highest level) member and their instance on name-collisions is very different from other applicants and registries. ICANN is a Platinum member, my employer is a Sliver member, JAS Advisors is a Bronze member, the US Army is a supporter member... considering that diversity I'm still comfortable with OARC as a forum to discuss these topics. And considering DNS-OARC is the source of the DITL data that was key in many decisions regarding name collisions, they are likely to still play a significant part in the continuation of this topic for the years ahead. Even for Goole and Amazon, that are members, their representatives on DNS-OARC meeting are usually not from the registry operations; for instance, Google's Warren Kumari is an SSAC member and he was the one that brought to the surface the certificate collision problem... so even those global companies have different units with possibly different motivations than their registry branch. We don't know at this point the 2018 scheduling of DNS-OARC Workshops, ICANN GDD Summit and ICANN DNS Forum, but as soon as those schedules become firm dates it will become more clear which of those meetings we should aim for to present the then-current revised framework and get their feedback. But that doesn't prevent sending partials to applicable mailing lists; from the 3 above, the only one I won't send this anymore is IETF DNSop, where the discussion theme (not the framework itself) was not well received. Rubens
participants (3)
-
Aikman-Scalese, Anne -
Julie Hedlund -
Rubens Kuhl