<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1956667321;
mso-list-template-ids:-139564154;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Dear Working Group members,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Please see below the notes from the working sessions on 19 October at 20:00 UTC.
<b><i>These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat,</i></b> which will be posted at:
<a href="https://community.icann.org/display/NGSPP/2020-10-19+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2020-10-19+New+gTLD+Subsequent+Procedures+PDP</a>.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Kind regards,<br>
Julie<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">Notes and Action Items:</span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span> <o:p></o:p></p>
<p class="MsoNormal">1. Updates to Statements of Interest: No updates provided.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">2. Meeting with the SSAC re: draft Final Report – highlighted issues:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SSAC’s Work Party looking at two areas: 1) SSR issues in the draft Final Report; 2) Gap analysis – issues not in the draft Final Report.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">a. Root Zone Delegation Rates<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SSAC/Rod Rasmussen, Chair:<o:p></o:p></p>
<p class="MsoNormal">-- This gets into one of the biggest issues. Lots of issues were well addressed in SSAC advice.<o:p></o:p></p>
<p class="MsoNormal">-- There are some issues that are outstanding around measuring and monitoring: how do you make decisions on when things are not going well? When and how the metrics are dealt with.<o:p></o:p></p>
<p class="MsoNormal">-- Related to that is the concept of the SPIRT.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: OCTO recent paper on early warning system. Technical community couldn’t agree on a solution, objective tests or metrics, so ICANN should just ask. See Public Comment Forum announcement -- Recommendations for
Early Warning for Root Zone Scaling at <a href="https://www.icann.org/public-comments/recommendations-early-warning-root-scaling-2020-10-05-en">
https://www.icann.org/public-comments/recommendations-early-warning-root-scaling-2020-10-05-en</a>
<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair:<o:p></o:p></p>
<p class="MsoNormal">Does the SPIRT provide the overarching framework? It is more focused on specific issues, not an overarching process. Could there be an oversight group that could say when things need to slow down?<o:p></o:p></p>
<p class="MsoNormal">--WG/Jeff Neuman, Co-Chair: How to incorporate SSR expertise and decision making into the SPIRT. WG didn’t discuss that as part of the SPIRT role, but it can call experts on issues. Meant to deal with process issues; and serve as a shepherd
on possible policy issues.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Geoff Houston: OCTO document is just an opinion. There are contrary views.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: SSAC concern is that there might be overarching systemic SSR issues and it’s not clear that the SPIRT is set up to review those types of issues, or is empowered to do something about it.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: SSAC concern when it comes to contentious issues, such as root zone delegation, where you could have experts who don’t agree; if these got referred to the SPIRT it’s not clear how the SPIRT would make decisions
and what criteria it would use. SPIRT should not make SSR conclusions/recommendations without the appropriate technical expertise.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: The SPIRT is not a decision maker; but to help ICANN understand the potential impacts and make sure that when it comes to making a decision the right parties are involved. SPIRT could make sure that the experts
are involved.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: Who would have the authority to slow down delegations? WG: Ultimately the ICANN Board. The way we instructed the SPIRT is to make sure we can alert the stakeholders to the possible impacts. Board wanted
that clarified in the comments. Transparency would be very important.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: Could consider having an SSAC liaison.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">b. How names are constructed: IDNs / Variants / Restricted character combos<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SSAC/Rod Rasmussen, Chair:<o:p></o:p></p>
<p class="MsoNormal">-- Interesting things around determining contention sets that from a technical aspect doesn’t make a lot of sense to look at intended use to decide if a string is confusingly similar.
<o:p></o:p></p>
<p class="MsoNormal">-- You can look at strings as they are and have some rules around that.<o:p></o:p></p>
<p class="MsoNormal">-- Inconsistencies on how plurals were addressed in the prior round.<o:p></o:p></p>
<p class="MsoNormal">-- Concerns about SWORD tool.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: SWORD tool -- Recommendation was to eliminate it.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: Not using intended use for putting things in contention sets and treatment of plurals and singulars; WG was considering doing a study on plurals and singulars – but the plurals were acquired so they went away
by consolidation.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Ram Mohan: On intended use – this should not be considered a defining characteristic on whether a string should be placed in a contention set or not because intended use changes over time. Also, and expected use may not be how
it is used in real life. Thought it was not a good idea to apply intended use as a defining characteristic, although it could be something to note.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: You have the issue where the intended use changes over time and what are the rules for that?
<o:p></o:p></p>
<p class="MsoNormal">-- WG/Paul McGrady: Example of .apples – applied for by the Apple Growers Association and say they won’t sell computers, etc. Could have a side agreement with Apple computers.
<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Ram Mohan: What happens if someone registers bad.apples and uses it to talk about bad experiences with Apple computers? The fundamental thing we are saying it’s a bad idea to have intended use being a defining factor, but could
be an identifying factor. Need to think about how to mitigate the risks, but it not always black and white.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: Whether it is the definitive factor or a factor someone won’t be happy if someone registers bad.apples.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">c. DNS Abuse itself and a proxy for other meta issues<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: These are issues that were noted as part of the last expansion as being potential issues with the original delegations. But the majority of TLDs were okay. But where there are problems, are those lessons
learned? Does there need to be a PDP? How does that interact with subsequent rounds? Is it a gating factor? There is an engineering concept of being able to do something in a new space. Are there best practices that would be rolled out for the new gLTDs?
Want to see any issues mitigated up front. Where is that properly handled?<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: The abuse that occurs in TLDs now is not because something is new versus old. It happens because it is a registry or ccTLD that doesn’t take down sites. Shouldn’t put restrictions on newer TLDs without dealing
with older/legacy TLDs. Needs to be handled on a global level, although GAC didn’t like that the SubPro didn’t make a recommendation on this. There are a lot of people in the ICANN community that think if we can’t get the legacy players to do something we
should put it on the new gTLDs and then make the legacy TLDs adopt the rules in their renewed contracts. We think the appropriate place is for the GNSO Council to set the policy on DNS abuse.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: What were the primary drivers of concentrated abuse? Pricing? - undoubtedly at 1 cent, poor filtering of bad actors registering names? likely. Would be really good to have a solid understanding to make good
decisions. Lack of experience for new operators? Maybe, maybe not. Lots to know. Don’t think anyone wants to punish new operators, but we want to make sure things are successful.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Donna Austin: The data is important. ICANN has been talking about bad actors for some time, but are yet to provide evidence of what they are talking about. Also important to keep the conversation in perspective: are we talking about
DNS abuse or abuse conducted on the Internet?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">d. Registry Testing / Pre-evaluation process for Back End Operators<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SSAC/Rod Rasmussen, Chair: <o:p></o:p></p>
<p class="MsoNormal">-- Idea of having back-end operators prove that they can do it over and over again doesn’t make tons of sense; it becomes interesting when you think about the scaling. How do you test when you have a lot of concentration with back-end
operators handling thousands of TLDs? What about the next .com? <o:p></o:p></p>
<p class="MsoNormal">-- Might want to say that there is a base set of testing and then also testing for special circumstances.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: We aren’t trying to say that ICANN is certifying back-end registries. The way you need to think about the pre-evaluation program is doing the evaluation earlier in time than you would have done it during the
application process. It isn’t a certification or pre-approval. We do state that if you say you are using a pre-evaluated back-end operator but using new/additional services that the back-end operator wasn’t evaluated for then the back-end operator has to
be re-evaluated for those services.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: Suggesting that ICANN org could produce an “RSP 101” type of document. There is the applicant side and the backend side. Lessons learned.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">e. TLD Types<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: SAC103: One of the things was that it was easy to become a publicly traded company. There is a concern about bad actors being able to game this.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: In general most publicly traded companies have strict requirements/obligations for avoidance of crime; we didn’t ignore it but we didn’t think ICANN could have different regulations for different jurisdictions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">f. Name Collision / Interaction with Private TLD proposal<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: We continue the work on name collisions. We are moving forward to try to answer the Board questions. There is enough time to get that work done before new gTLDs are launched.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: There are members of the WG have been debating whether the work of the NCAP should be a dependency for certain elements of the next round. The NCAP is not making any recommendations as to whether their work
should be a dependency for the next round; that would be a decision by the Board.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: It is not up to the SSAC or NCAP to make any recommendations concerning whether name collisions should be a dependency for new gTLDs. We are trying to develop a framework to mitigate risks so that people can
make better informed decisions.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: .corp, .home, and .mail are not in scope for this WG. It is a matter of opinion as to what should be the dependencies for the next round. If something is a dependency we need to decide at what point we need
to make a decision?<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: Outside of our remit too, although the question needs answering.<o:p></o:p></p>
<p class="MsoNormal">-- SSAC/Rod Rasmussen, Chair: SAC113 on Private Namespace – that is an ICANN/IETF interaction for creating a name/s that would be reserved from ever being published. It would have that space for private use. That is to try to address
the issue that people keep picking up names and trying to do that; it would mitigate but not stop that practice.<o:p></o:p></p>
<p class="MsoNormal">-- WG/Jeff Neuman, Co-Chair: We know this was talked about as an issue between ICANN/IETF, but it has wider ramifications. .onion and the satirical paper The Onion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>