<html xmlns:v="urn:schemas-microsoft-com:vml" 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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle20
{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:430316242;
mso-list-template-ids:1506948242;}
@list l0:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@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;}
@list l1
{mso-list-id:439380639;
mso-list-type:hybrid;
mso-list-template-ids:-2146798198 -537501306 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:5;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:972709532;
mso-list-type:hybrid;
mso-list-template-ids:-1864574084 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3
{mso-list-id:1275862363;
mso-list-template-ids:-424241878;}
@list l3:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3: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="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:black">Dear TPR WG Members,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Please find below the notes and action items from today’s call.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">The next TPR WG meeting will be</span> on<span style="color:black">
<b>Tuesday, </b></span><b>21 December <span style="color:black">at </span>16:00<span style="color:black"> UTC</span></b><span style="color:black">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><br>
Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Emily, Julie, Berry, and Caitlin </span><o:p></o:p></p>
<p class="MsoNormal"><b><u><span style="color:black"><o:p><span style="text-decoration:none"> </span></o:p></span></u></b></p>
<p class="MsoNormal"><b><u><span style="color:black">Action Items<o:p></o:p></span></u></b></p>
<p class="MsoNormal"><b><u><o:p><span style="text-decoration:none"> </span></o:p></u></b></p>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$" title="https://urldefense.com/v3/__https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$">TAC
Working Document [docs.google.com]</a> (beginning on p. 15)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Page 16, charter question b1, rationale: Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.”<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Strike the sentence. It is covered earlier in the text.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 3, page 16:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: WG members to comment on the revised language of recommendation 3.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 5, page 16:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEMS: <o:p></o:p></b></p>
<p class="MsoNormal"><b>1. Staff to split the concepts in the recommendation into two parts as per comments from WG members.<o:p></o:p></b></p>
<p class="MsoNormal"><b>2. Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”.
<o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal">Charter Question b2:<o:p></o:p></p>
<p class="MsoNormal">Recommendation 6, page 17:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Staff to split the recommendation into three parts.<o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal">Recommendation 9:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.” WG to review the revised text.<o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b><span style="color:black">Transfer Policy Review Phase 1 - Meeting #2</span>8</b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:6.0pt;line-height:18.0pt"><b><span style="color:black">Tuesday </span>14 December<span style="color:black"> 2021 at
</span>16:00<span style="color:black"> UTC<o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Roll Call & SOI Updates<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">No updates provided.<o:p></o:p></span></li></ul>
<p class="MsoNormal">2. Welcome & Chair updates (5 minutes)<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Update from Sarah Wyld: Yesterday we participated in a panel at the NARALO monthly meeting and discussed the TPR PDP. Very useful discussion.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Update from Jim Galvin, RySG: Agree that the NARALO panel was helpful. Had a lot of really good discussion and asked some good questions
about the transfer process. Confirmation that we are addressing issues that are interesting and important.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">RySG Advice (Jim Galvin): Action to ask registries about providing the gaining registrar IANA ID to the registrar of record. People
are generally supportive of the concept. Some technical issues came up that we will provide more details about. Keep in mind that the IANA ID is only present for accredited registrars and isn’t present everywhere. Have to be able to accommodate those registrars
without an IANA ID. Also discussed which field to use and if there is an additional element then there needs to be a standard for it in the IETF, but that would be a relatively straightforward process.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Kristian Ormen: ccTLDs would probably all follow the policy even where the ID isn’t available.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jim Galvin: Whatever solution we provide needs to be compatible.<o:p></o:p></span></li></ul>
<p class="MsoNormal">3. Second reading: TAC and FOA (45 minutes) -- see: <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$" title="https://urldefense.com/v3/__https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$">TAC
Working Document [docs.google.com]</a> (beginning on p. 15)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Page 16, charter question b1, rationale:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.”<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Comment from Theo Geurts: “I suggest striking this if we do not know what happened it does not add any value. For all, we know a script
went haywire somewhere.”<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Think this was put in here is because we were looking for any changes in that data. Maybe just a wording change is needed.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Even if it did indicate some kind of ICANN compliance issue they wouldn’t be able to say what to do. Should be taken out?<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: Strike the sentence. It is covered earlier in the text.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 2:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Comment from Theo Geurts:
<span style="color:black">“</span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black;letter-spacing:.15pt;background:white">Note to WG, some registries create the TAC now and not the registrar. Perhaps this should be more clear
so all actors involved are aware that code changes are required.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">”</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Recommendations shouldn’t be considered in isolation. Maybe the answer is in relation to preliminary recommendation 6. There is a
variety of implementations that occur. The current state is that a TAC is created at registration and sits there until requested from the registered name holder. New recommendations state that the TAC is only created upon the request from the registered
name holder.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Maybe this could be included as an implementation note to put this in the context of recommendation 6.<o:p></o:p></span></li></ul>
<p class="MsoNormal">Recommendation 3:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Reconfiguring the language of the recommendation to be specific about the standards to be referenced. Do we want to cover this now?<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: Keep this as an ongoing action item for WG members to comment.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 5:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Comment from Theo Geurts: “<span style="color:#3C4043;letter-spacing:.15pt;background:white">These notifications need to be subject
to standard EPP poll messages.</span>”<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Need to define what is a failed attempt. Need to think about the lock in this context. “Failed attempt” may not be the right term.
Could refer only to “presenting an invalid TAC”.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Would still need some wording for an invalid TAC with respect to the lock.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We haven’t firmed up the final details, but if a TAC is presented to the registrar of record to the registry then the registry should
confirm that there are no registrar locks on the name. An nvalid TAC is whatever doesn’t match what is in the system.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation
of an invalid TAC”.</span><span style="font-family:"Calibri",sans-serif"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We need to tie the presentation of a TAC with the absence of locks.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What threat are we protecting against to allow these things to be uncoupled and expecting the user to do the right thing? It is more
likely that we want simple principles.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We are only creating the TAC at transfer in the future based on the current recommendations.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Seems unnecessary to tie these together. In today’s policy is “registry must remove the locks or provide registrars with access”.
Maybe we keep the same concept of “or”.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The gaining registrar can quite easily see that the name is locked. Don’t even take a transfer request if the domain is locked.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Looking at this recommendation, agree to change “failed attempts” to “presents an invalid TAC”. But do we need to be explicit about
what is an “invalid TAC”?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If the TAC is correct and the domain is locked it isn’t an invalid TAC.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It only matters if the TAC is invalid to send a notice; if the TAC is correct and the domain is locked, the losing registrar doesn’t
need to know.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Notification is required only if the TAC is invalid. Do we want to say what “invalid” means, or is that self-explanatory? The word
“invalid” seems clear enough, although we could include an implementation note.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Re: 3-5 number: Most have precautions in place to monitory multiple TAC requests since registry resources aren’t unlimited.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Don’t think we are getting multiple brute-force attempts.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">People are looking at the 3-5 number. What is reasonable from a security point of view? 10 is a common number as an absolute. 3 is
a common number too.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">How many attempts do you need to be successful for a brute-force attack? You would need to send a massive amount of requests, and you
will be shut out.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Suggestion: Are we trying to pack too much into recommendation 5? There are plenty of reasons why an invalid TAC could be sent. Most
likely the gaining registrar will be monitoring and attempting to correct the error. Is it worth trying to separating the issues? Staff could try to try to do recommendation 5a and 5b.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEMS: <o:p></o:p></b></p>
<ol start="1" type="1">
<li class="MsoListParagraph" style="mso-list:l2 level1 lfo4"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Staff to split the concepts in the recommendation into two parts as per comments from WG members.<o:p></o:p></span></b></li><li class="MsoListParagraph" style="mso-list:l2 level1 lfo4"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation
of an invalid TAC”. <o:p></o:p></span></b></li></ol>
<p class="MsoNormal"><b>Charter Question b2:<o:p></o:p></b></p>
<p class="MsoNormal">Recommendation 6:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="color:#3C4043;mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Re: “generate the TAC, set the TAC in the Registry platform, and provide the TAC to the RNH” -- Comment
from Sarah Wyld: “</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;letter-spacing:.15pt;background:white">added some words for clarity, otherwise it suggests that we generate, set, and provide the TAC ALL to the RNH (but actually only
provide is to the RNH).<o:p></o:p></span></li><li class="MsoListParagraph" style="color:#3C4043;mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Staff suggestion is to split this into three parts: 1) registrar is the contracting party setting the
TAC; 2) TAC is only generated upon request; 3) only after confirmed by the registry is a TTL set.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;letter-spacing:.15pt;background:white"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Re: “After confirmation that the TAC has been successfully set at the Registry, when the Registrar provides the TAC it should also
provide information about when the TAC will expire.” Comment from Jothan: Should this happen chronologically only after it has successfully been set with the registry, in order to ensure it works in harmony with any minimum standard of the registry?<o:p></o:p></span></li><li class="MsoListParagraph" style="color:#3C4043;mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;letter-spacing:.15pt;background:white">Staff is working on a diagram to work out the timing.<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: Staff to split the recommendation into three parts.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">Recommendation 7:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Is “disclosure” the right word in “The Working Group recommends that when the Registry receives the TAC, the Registry must securely
store the TAC using a one-way hash that protects the TAC from disclosure.” Or is “unintended” or “unauthorized”.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Seems to be the right term.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Could provide a footnote to clarify that the disclosure only happens when the un-hashed code is used to validate the transfer.<o:p></o:p></span></li></ul>
<p class="MsoNormal">Recommendation 8:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-family:"Calibri",sans-serif">Don’t seem to be any issues.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-family:"Calibri",sans-serif">But if this is becoming part of the transfer policy we could add a sentence clarifying that the AuthInfo Code is being replaced by the TAC.<o:p></o:p></span></li></ul>
<p class="MsoNormal">ACTION ITEM: Staff to add a sentence clarifying that in the transfer policy the term “AuthInfo Code” is being replaced by “TAC”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 9:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Re: “Once the Registry Operator has verified that the TAC provided by the Gaining Registrar is valid in order to accept an inter-registrar
transfer request,” Comment from Sarah Wyld: “is this clear enough? should we add something to indicate that this happens after the transfer is completed?” And from Roger: “+1. Also, should we say "...the Registry should clear the TAC..." instead of "null"
to allow flexibility?”<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Depends on what we decide on the losing FOA.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What do we mean by “clear the TAC” instead of “null” – a way of saying that the field is empty (so null).<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">May need to put a pin in this one to make sure there is consistency with the losing FOA recommendations.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“clear the tac” is a better English phrase to describe what’s happening. “set to null” is overly prescriptive as it treads into a technical
description.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Suggest not to be overly prescriptive on what needs to happen/sequence of steps at the back end at the registry. The policy can just
say what you expect to have occurred.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Could we simply say “Once the transfer is complete, the Registry should clear the TAC”? Or is this too prescriptive?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We can say this if we get rid of the losing FOA.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Don’t have to be prescriptive of when the steps take place – so no need to say that the TAC has to be cleared as a particular step (say,
when complete).<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The registry could also clear the TAC as soon as they have verified it.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We want to say that once the TAC is used it can no longer be used again.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.” WG to review the revised text.<o:p></o:p></b></p>
<p class="MsoNormal"><u><o:p><span style="text-decoration:none"> </span></o:p></u></p>
<p class="MsoNormal">4. AOB (5 minutes) <o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l1 level1 lfo1"><span style="font-family:"Calibri",sans-serif">Next call: Tuesday 21 December 2021 at 16:00 UTC</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></li></ul>
</div>
</body>
</html>