<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: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;}
@font-face
{font-family:ArialMT;
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.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.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
@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:365760664;
mso-list-template-ids:239521240;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Times New Roman",serif;
mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:Calibri;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-start-at:3;
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:"Times New Roman";}
@list l0:level5
{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: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:832839883;
mso-list-template-ids:2016811092;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.25in;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.75in;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.25in;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.75in;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.25in;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.75in;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.25in;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.75in;
mso-level-number-position:left;
margin-left:4.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:5.25in;
mso-level-number-position:left;
margin-left:5.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
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 meeting.<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 meeting will be Tuesday, 24 May 2022 at 16:00 UTC.<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">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<o:p></o:p></span></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><span style="color:black"><o:p><span style="text-decoration:none"> </span></o:p></span></u></b></p>
<p class="MsoNormal"><b><span style="font-family:"Apple Color Emoji";color:black">🚨</span></b><b><span style="color:black">
</span></b><span style="color:black">1. Working Group members who haven’t yet done so: please review the Phase 1(a) Initial Report draft (attached) and indicate what changes/updates are essential before the Initial Report can be published by using the
<a href="https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit">
dedicated Google Doc</a> by <b>Friday, 20 May</b>. </span><b><span style="font-family:"Apple Color Emoji";color:black">🚨</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:black">Transfer Policy Review Phase 1 - Meeting #47</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">Proposed Agenda</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">17 May 2022</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Roll Call & SOI updates<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Welcome and Chair Updates<o:p></o:p>
<ol start="1" type="1">
<ol start="1" type="a">
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Policy Support Staff sent out a survey, asking which members will be attending ICANN74 in person<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">This is in order to guarantee access to the Transfer Policy Review PDP session room and a seat at the U-shaped table during ICANN74, you
will need to please complete the survey to confirm if you are attending on-site and taking part in this session by Wednesday, 18 May 2022.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Survey: https://forms.gle/ngWUUutRpaF87uJD8
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Please take five minutes to fill out this survey. If you are not planning to attend, you can answer “no” to the first question.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Thus far, no feedback has been received on the draft Initial Report, which signals the Initial Report is in good shape.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Stakeholder Group Updates:<o:p></o:p></span>
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level5 lfo1"><span style="font-family:"Calibri",sans-serif">Registries would like to continue to have conversations about Recommendation 13.1 – currently do not support. Notice this is flagged on the
agenda, so we can discuss then.<o:p></o:p></span></li></ul>
</li></ul>
</ol>
</ol>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Return to items in the preliminary recommendations flagged for further discussion during last week’s call (see
<a href="https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit" title="https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit">
<span style="color:#0563C1">here</span></a>)<o:p></o:p>
<ol style="margin-top:0in" start="1" type="1">
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal" style="color:black;mso-list:l0 level3 lfo1">Recommendation 7 (Jim Galvin)<o:p></o:p>
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Current draft: Preliminary Recommendation 7: [The working group recommends that ICANN org establish minimum requirements for the composition
of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org MAY change these requirements in response to new or updated standards, but any changes to the requirements MUST go in effect
with sufficient notification and time for contracted parties to implement the necessary updates. ] OR [The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax,
or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate.]<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">The big issue here was how to make something enforceable, but not too prescriptive – this will involve a balancing act. How specific should
the group get? <o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">It will be difficult to enforce who is properly creating a TAC – there are suggestions in the RFC with respect to randomness. It’s hard to
know if there is a problem, unless something breaks. The suggestion that there should be enforcement of this is interesting. It may be better to see if the same value is popping up and appearing, and that would be for registries to check, which will also be
difficult and possibly unacceptable to registries. <o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">The recommendation should be everything before the footnote brackets. The recommendation should be the first two sentences of Jim’s proposed
recommendation. It is important to provide some sort of guidance to contracted parties here.<o:p></o:p></span></li><li style="color:black;mso-list:l0 level4 lfo1;background:white"><span style="font-family:"Calibri",sans-serif">Proposed update to Rec. 7:</span><span style="font-size:11.0pt;font-family:ArialMT">
</span><i><span style="font-family:"Calibri",sans-serif">The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154 (and its update and replacement RFCs). In addition, where random values are required
by RFC 9154, such values MUST be created according to BCP 106. [Footnote: BCP 106 is a Best Current Practice and is an idempotent reference to the most recent version of the specification entitled “Randomness Requirements for Security”, currently RFC 4086,
which is how it is referenced in RFC 9154.]<o:p></o:p></span></i></li><li style="color:black;mso-list:l0 level4 lfo1;background:white"><span style="font-family:"Calibri",sans-serif">Some concerns about the language in the footnote being unknown or confusing to this average reader, and the group should make this more readable.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Some may, for example, be confused by the language of idempotent. BCP 106 is a static reference and will be tied automatically to the latest
RFC – the URL is always static. <o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">No objections to Jim’s proposed language.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Action: Policy Support Staff to extract Jim’s explanation – take verbal explanation and create text that could complement what a non-IETF
expert will understand. [Note: complete – please see: p. 3 of https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit.<o:p></o:p></span></li></ul>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level3 lfo1">Recommendation 9.2
<o:p></o:p>
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Saying one-way hash is the appropriate term of art. Saying that algorithms evolve with time is correct. Jim chose specific language that
is laid out in RFC 9154. A potential improvement could be, similar to the IETF, abstract out algorithm identifiers to separately deal with algorithms as they change. It may be overkill for this specific application.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Could this be an implementation note or footnote on the current 9.2?
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Proposed suggestion from Jim:
<o:p></o:p></span></li><li style="mso-list:l0 level4 lfo1;background:white"><span style="font-family:"Calibri",sans-serif;color:black">9.2 When the Registrar of Record sets the TAC at the Registry, the Registry MUST store the TAC securely, at least according to the minimum requirement
set forth in RFC 9154: using a strong one-way cryptographic hash with at least a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a per-authorization information random salt with at least 128 bits. [FIPS-180-4] National Institute of Standards
and Technology, U.S. Department of Commerce, "Secure Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4", DOI10.6028/NIST.FIPS.180-4, August 2015, <</span><span style="font-family:"Calibri",sans-serif;color:#0F54CC">https://csrc.nist.gov/publications/detail/fips/180/4/final</span><span style="font-family:"Calibri",sans-serif;color:black">>.
</span><span style="font-family:"Calibri",sans-serif"><o:p></o:p></span></li><li style="color:black;mso-list:l0 level4 lfo1;background:white"><span style="font-family:"Calibri",sans-serif">Delete text after one-way hash. Everyone beginning at using could be a footnote for the IRT.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></li></ul>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level3 lfo1">Recommendation 13.1<o:p></o:p>
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Everything before the comma seems supported by all.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Registries are uncomfortable with the language “enforced by the registries”<o:p></o:p></span></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><b><u><span style="font-family:"Calibri",sans-serif;color:black">13.1</span></u></b><span style="font-family:"Calibri",sans-serif;color:black">: A standard Time to Live (TTL) for the TAC MUST be 14
calendar days from the time it is set at the Registry, enforced by the Registries. </span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">Registries are not finding support among the registries for enforcement by registries because (i) transferring a domain name is an activity
that is done between registrars and registrants. Registrars have the relationship with the customer, not the registry. Putting the registry in an “ACK” capacity puts the registry in a position of making a decision for a customer for which the registry has
not relationship with. </span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">Do not see a situation where a registry is going to communicate directly with a registrant when a TAC is expired</span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">If this was to be a requirement, it would not just be an invalid TAC – this is creating an issue for the gaining registrar. One wouldn’t
want to use an “invalid TAC” message b/c this situation would have to be examined and investigated. Maybe there should be a new error code and error message and suggest that this is an expired TAC to report to the gaining registrar. This, however, is at odds
with the requirement that no one stores TAC values. Now the registry would not just have to set the TAC to null but also store all TACs and their dates of evaluation. The implementation, on its face, sounds straightforward, but when it is parsed, it is more
complicated. </span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">An invalid TAC message should be OK to send to the registrar, but this is good to discuss.</span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">Agree that the implementation is somewhat more complex than originally considered; however, forego the scenario where registry is in charge
and put it on the losing registrar. The issue for the registry is now being transferred to the losing registrar. The same question will have to be posed to registrar technical folks.
</span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">If you give a registry a role in the compliance of the TAC, that seems awkward at best, and not something that registries are supportive
of. Registries will now have an obligation to be responsive to anything they did or didn’t do with the TAC. When the enforcement is put on registries, the registry is added to the compliance side of a TAC and a transfer, and that does not feel like a helpful
transition. In the spirit of a transfer being a registrant engagement activity, it feels like it belongs with a registrant and not a registry.
</span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">How does this work today? Would the registry just take the word of the registrar?</span><o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">Yes, the registrar sets the TAC and is responsible for it. The first level of investigation would be to the registrar. If you ask the registrar
what they did, that would be the first order of what to be done. </span><o:p></o:p></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Asking Rys to be involved in the TTL was purposeful not a bug in ensuring the entire ecosystem did actually use a specific TTL, seeing as
there are thousands / tens of thousands RRs and much fewer RY platforms<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Pulling Rys in explicitly to compliance here is awkward and is adding registries to something they do not want to be a part of.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">When a registry receives a complaint from a registrar, and a name needs to be moved from one registrar to another, how would that be done?<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">That scenario is outside of this process because this is something that would be directed by ICANN and would be done manually.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">This is directly affecting the previous recommendation where the TAC is created upon request. It sounds like there is more due diligence
to unpack this and baggage associated with this that needs to be accounted for. Given the time constraints, this may not be able to be unpacked prior to public comment. This could be a good candidate for very specific input from the community.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">The WG is creating a new model for transfers. There is an important starting principle – there is a window of vulnerability associated with
that TAC. Currently, a transfer has a manual intervention – the registrant has to get the TAC and get it to the gaining registrar. The notion of enforcement is an interesting one. Enforcement from the point of view of ICANN or enforcement internally – are
all registrars going to be well-behaved? Probably not. Would like to be cautious about tying registries and registrars together in this process.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></li></ul>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level3 lfo1">Recommendation 13.2<o:p></o:p>
<ul style="margin-top:0in" type="disc">
<li style="margin-top:0in;margin-bottom:0in;mso-list:l0 level4 lfo1"><b><u><span style="font-family:"Calibri",sans-serif;color:black">13.2:</span></u></b><span style="font-family:"Calibri",sans-serif;color:black"> The Registrar of Record MAY set the TAC to
null:</span><o:p></o:p>
<ul style="margin-top:0in" type="disc">
<li style="margin-top:0in;margin-bottom:0in;mso-list:l0 level5 lfo1"><s><span style="font-family:"Calibri",sans-serif;color:black">At any time in response to a request from the RNH.</span></s><o:p></o:p></li><li style="margin-top:0in;margin-bottom:0in;mso-list:l0 level5 lfo1"><span style="font-family:"Calibri",sans-serif;color:black">After a period of less than 14 days by agreement by the Registrar of Record and the RNH.</span><o:p></o:p></li></ul>
</li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Leaving the recommendation at – the Registrar of Record MAY set the TAC to null – should be sufficient.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Agree this is OK – the registrar should be responsible and responsive to their customer. The reason there was a limit on it is a concern
that the registrar may set the TAC to null almost immediately and make transfers virtually impossible. If looking to shorten, the first bullet could potentially be removed.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">If there is no description of when Registrars may set TAC to null, this opens the door to set a TAC to null unscrupulously.<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Agreement to remove the first bullet, but keep the second..
<o:p></o:p></span></li></ul>
</li></ol>
</ol>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Discussion of Recommendation 19 email thread (please see <a href="https://mm.icann.org/pipermail/gnso-tpr/2022-May/000449.html" title="https://mm.icann.org/pipermail/gnso-tpr/2022-May/000449.html"><span style="color:#0563C1">here</span></a>)<o:p></o:p>
<ol start="1" type="1">
<ol start="1" type="a">
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Mike R. stated some concerns about the current language.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">This suggestion is slightly more specific – could we consider “evidence of fraud or material violation of the Registration Agreement” I.A.3.7.1<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Material breach should be sufficient – important to keep fraud in.
<o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">Will return to this item next week.
<o:p></o:p></span></li></ul>
</ol>
</ol>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Begin review of items flagged in <a href="https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit" title="https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit"><span style="color:#0563C1">Proposed
Revisions from Working Group members</span></a> document (if any)<o:p></o:p>
<ol start="1" type="1">
<ol start="1" type="a">
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">To date, no input has been received, but if you would like to include additional items, please include them in the Google Doc by COB Friday:
<a href="https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit">
https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit</a><o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-list:l0 level4 lfo1"><span style="font-family:"Calibri",sans-serif">It is conceivable that the group may start Change of Registrant earlier than expected. The more Staff has advance notice, the more we can
properly plan for the future meetings. It’s likely the group will discuss Change of Registrant at ICANN74. Staff already has the next iteration of the Initial Report that factors in the feedback from the next calls. The public comment forms are also ready
to go. The Prep week webinar week will provide an overview of the recommendations in the Initial Report.
<o:p></o:p></span></li></ul>
</ol>
</ol>
</li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">AOB<o:p></o:p></li></ol>
<ol style="margin-top:0in" start="6" type="1">
<ol style="margin-top:0in" start="1" type="1">
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal" style="color:black;mso-list:l0 level3 lfo3">Next call: Tuesday <span style="color:windowtext">24 May</span> 202<span style="color:windowtext">2</span> at <span style="color:windowtext">16:00</span> UTC<o:p></o:p></li></ol>
</ol>
</ol>
<p class="MsoNormal" style="margin-bottom:6.0pt;line-height:18.0pt"><span style="color:black"> <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"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>