<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:439380639;
mso-list-type:hybrid;
mso-list-template-ids:-2146798198 -537501306 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l1
{mso-list-id:972709532;
mso-list-type:hybrid;
mso-list-template-ids:-1864574084 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1621498629;
mso-list-template-ids:1818920784;}
@list l2:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2: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 l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2: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>04 January 2022 <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">Recommendation 3:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any.<o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal">Recommendation 5:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: For recommendation 5.1 revise the recommendation to remove the second bullet.</b><o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: For recommendation 5.2 the WG to review and suggest revisions.</b><o:p></o:p></p>
<p class="MsoNormal"><b><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>9</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>21 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: No updates provided.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Welcome & Chair updates (5 minutes)<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">There will not be a WG meeting on 28 December.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The Project Change Request was approved by the GNSO Council on 16 December to move NACKs from Phase 2 to Phase 1a. The Project Plan
and charter are updated.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Update from Jim Galvin, RySG: drafted a summary about including the IANA ID about including it in the Registrar of Record. Several
ways that information could be provided. Whatever choice will impact registrars. The RySG will present a proposal to the registrars via the Tech Ops group with the result to feed into the WG’s discussion.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Would be useful to have the various options presented to the WG.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jim noted that several WG members will be involved in the Tech Ops discussions, but he will make sure that the WG will be in the loop.<o:p></o:p></span></li></ul>
<p class="MsoNormal">3. Second reading: TAC and FOA (45 minutes)<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!p4lHPnH0iN_MfQJDBOQ7D-uetrsUffDPOcZ_48v12A2pX79Yv5bRJ3EKX3Ugi-tzkVR-im7-UQ$" title="https://urldefense.com/v3/__https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!p4lHPnH0iN_MfQJDBOQ7D-uetrsUffDPOcZ_48v12A2pX79Yv5bRJ3EKX3Ugi-tzkVR-im7-UQ$">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">Recommendation 3:<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 5.1:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What are we trying to solve with this recommendation? Is it brute-force attacks? Or a user issue? Or both?</span><span style="font-family:"Calibri",sans-serif"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Should we ask the Registry Stakeholder group whether brute-force attack is really a problem? Registries would have the most information.
If they see this as a possible problem then we need to address it.</span><span style="font-family:"Calibri",sans-serif"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Staff was doing some thinking about this and wondering how much of an issue brute force is. Maybe it was more of an issue when the
TAC is generated with registration, but not with the recommendation to have the TAC generated on request. We have changed the TAC considerable from how AuthInfo works today based on our recommendations.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jim Galvin RySG: Never heard another registry talk about it. This is more of an ordinary operational issue for a registry. They monitor
their systems. If a registrar is doing brute-force attacks it isn’t going to tell anyone/no registrar will see it. Only the registry can see it. This doesn’t need attention. Don’t think we will get any information by asking registries.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Let’s assume that this is not a brute-force recommendation but a user experience recommendation. We should clean it up accordingly.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Shouldn’t the Gaining Registrar get a notification? They should be notified, but that should be covered in the normal operations.
<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Not sure we need a notification for every successive failure.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From a user experience point of view we should think about the right way to handle this. Maybe the path is what the registry does after
X failed attempts it disables the transfer, negates the code, and tells the registrar that transfers aren’t allowed. For the user experience consider what type of action you want to get the situation fixed?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Combine bullets 1 and 2: As an alternative to “successive attempts” – after the 5<sup>th</sup> and every 5<sup>th</sup> after that the
registry sends the notice to the Registrar of Record.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We don’t have any data on how often this happens.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We are trying to give the best user experience around the transfer.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">In favor of data that would support a certain number of failed attempts.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we’re wanting to provide notice to the RNH, a single notice after a # of failures would suffice. The question then becomes what
that # is.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Helpful to improve the registrant experience, but one notification should be enough.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Think about what problem we are trying to solve. The Registrar of Record needs to know that an invalid TAC is presented if they have
no knowledge that a domain name is transferable. The onus falls on the Gaining Registrar to deal with invalid TACs. It might be helpful to present one notification to the Registrar of Record, but otherwise there isn’t a need for anything further.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If the Losing Registrar gets a notice (as the Registrar of Record) that an invalid TAC was provided to the RNH then the Losing Registrar
will want to get in touch with the Gaining Registrar and to notify the RNH as good customer service.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Should we add language that talks about what happens if the registry fails it where there’s a lock? Does it matter why the registry
is failing the transfer.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What happens when the TAC exists with a lock? If a domain name is locked and you can’t set a TAC, that will create operational issues.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Think we all know that there is an intersection between transfers and locks. There is a user experience issue to be addressed here.
Can locks be present if you set a TAC? How would a registry make the distinction between a lock that makes a domain name transfer eligible and one that doesn’t. You want a lock on to protect until the transfer. From a registry point of view some registries
offer lock services and registrars also offer them. What happens when you have both? We haven’t played all of the scenarios.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Seems that the lock overrides everything. Should the TAC be able to be set at the registry with the lock on? Can a lock be put on
if there is a TAC? Would the lock override the TAC?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">A lock should be able to be placed on the domain even if a TAC is set for the domain.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">But then how do you effect the transfer? How does a registry know it’s valid?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Today’s policy says the Registrar of Record has to remove the locks within 5 days or allow the RNH to remove them.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If the TAC matches and the domain is unlocked, it’s a valid request.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The registrar has to remove their locks for a domain name to be transfer eligible.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The policy needs to say something about the registry removing its locks when presented with a valid TAC.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Don't think the registry should even check the TAC if the domain is locked.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It's an order of operations really: Is domain locked? Yes, deny transfer request. No, check TAC.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">No reason to check the TAC if it’s locked.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Could be that there is a step to be taken if the domain name is locked.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">There are other reasons (like court orders) that domains can be locked. We need to recognize that at the registry or registrar. Don’t
think that we have to differentiate too much. The registrant still has to go back to the Registrar of Record to resolve that lock. That covers all the locks we are talking about.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Think that the Registrar of Record has to be responsible for resolving all locks that they were a party to before they set a TAC. Leaves
open the possibility that if the registry has it locked then the Registrar of Record may not know. That should be addressed too.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Three scenarios: Registrar or Record can resolve just by explaining to the RNH that there’s a lock. Resolve may not be to the transfer.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It may be that the manual process has to transfer from the Registrar of Record to the Gaining Registrar. The Registrar of Record should
not be obligated to notify the RNH of a lock that it doesn’t know about.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Policy has to say that the registry has to account for the transfer process in the case of a commercial lock.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Think we have the basic framework: Is domain locked? Yes, deny transfer request. No, check TAC. Need to put in place where the difference
decisions/triggers happen.<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: For recommendation 5.1 revise the recommendation to remove the second bullet.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recommendation 5.2:<o:p></o:p></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Maybe an intermediate step – need to clear out the language and somehow put that in place of the Registrar of Record has to take action.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Don’t think the Registrar of Record should have to reach out (MUST). Could be changed to MAY. But this help ICANN Compliance to follow
up, such as a requirement to document?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we set this to 5 attempts and the Registrar of Record sees it but it is successful after that, maybe the Registrar or Record could
just note that in its investigation in case Compliance follows up.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Do we have data that justifies this recommendation? What are we trying to solve here?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The purpose is for the user experience to be consistent and predictable for the registrant.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Maybe it should be that the Registrar of Record MAY notify the RNH or investigate. Or just leave as MAY investigate. Don’t make either
one more important. Maybe once you investigate you decide you don’t need to notify.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If you have the option to notify or to investigate, then you can choose what to do.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">No sense in creating a requirement that can’t be enforced.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Maybe a way to get out of this: Instead of 5.2 this could be changed to an implementation note to accompany this section that for notifications
in 5.1 the Registrar or Record should investigate and notify as necessary.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Even if it’s a implementation note isn’t it still a requirement?<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we make it a MUST but a big OR – between investigation and notification that addresses enforcement.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we use SHOULD or MAY then there is no way to check compliance.<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Make sure the language is crystal clear.<o:p></o:p></span></li></ul>
<p class="MsoNormal"><b>ACTION ITEM: For recommendation 5.2 the WG to review and suggest revisions.</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4. AOB (5 minutes): Next call: Tuesday 4 January 2021 at 16:00 UTC<o:p></o:p></p>
</div>
</body>
</html>