<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:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@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:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xmsolistparagraph, li.xmsolistparagraph, div.xmsolistparagraph
{mso-style-name:xmsolistparagraph;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle31
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle32
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle33
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle34
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle35
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle36
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle37
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle38
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle39
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle40
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle41
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle42
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle43
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle44
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle45
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle46
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle47
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle48
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle49
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle51
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:black;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">Hi Julie<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">My strong preference is to keep the call at the current time. We only actually have a few weeks before Cancun, since that is early March,
after which the northern hemisphere is back on daylight savings anyway and presumably this occasional problem goes away.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">If you do switch the time to 1800-1930 UTC then I oppose that time remaining fixed after daylight savings starts (since at that point the
calls become 1900-2030UK and much later for other Europeans) and would ask that we switch back to the 1700UTC slot.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Susan Payne<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Head of Legal Policy
<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Valideus <o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"> <br>
D: +44 (0) 20 7421 8255<br>
T: +44 (0) 20 7421 8299<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">M: +44 (0) 7971 661175<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">E:
</span><u><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><a href="mailto:susan.payne@valideus.com"><span style="color:blue">susan.payne@valideus.com
</span></a><o:p></o:p></span></u></p>
<p class="MsoNormal"><u><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><a href="http://www.valideus.com/">www.valideus.com</a><o:p></o:p></span></u></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
<br>
</span><b><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#769E91;mso-fareast-language:EN-US"><o:p></o:p></span></b></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org>
<b>On Behalf Of </b>Julie Hedlund<br>
<b>Sent:</b> 08 January 2020 21:28<br>
<b>To:</b> gnso-rpm-wg@icann.org<br>
<b>Subject:</b> [GNSO-RPM-WG] Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Dear All,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Per the action item below from today’s meeting, WG members are requested to indicate whether they would be available to attend the weekly WG meetings
<b><i>if they are moved from 17:00 UTC to 18:00 UTC</i></b> for 90 minutes (18:00-19:30). The request comes from some of the WG Co-Chairs as they have experienced occasional conflicts with the meeting time of 17:00 UTC.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">As noted during today’s meeting, PDP WGs typically keep the same time in UTC throughout the year, rather than changing the time based on changes between daylight saving time and standard time in the US or other countries.
This WG has maintained the same time in UTC for the last few years as do the other PDP WGs. However, the time is dependent on the availability and preferences of the Co-Chairs and the WG members. If the majority of WG members would be available and prefer
meeting at a different time in UTC the meeting schedule can be changed accordingly.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Julie<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Julie Hedlund, Policy Director<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">GNSO-RPM-WG <<a href="mailto:gnso-rpm-wg-bounces@icann.org">gnso-rpm-wg-bounces@icann.org</a>> on behalf of Julie Hedlund <<a href="mailto:julie.hedlund@icann.org">julie.hedlund@icann.org</a>><br>
<b>Date: </b>Wednesday, January 8, 2020 at 4:13 PM<br>
<b>To: </b>"<a href="mailto:gnso-rpm-wg@icann.org">gnso-rpm-wg@icann.org</a>" <<a href="mailto:gnso-rpm-wg@icann.org">gnso-rpm-wg@icann.org</a>><br>
<b>Subject: </b>[GNSO-RPM-WG] Actions: RPM PDP WG Meeting 08 January 2019<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Dear All,</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US" style="color:black"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US" style="color:black">Please see below the action items captured by staff from the<span class="apple-converted-space"> </span></span><span lang="EN-US">RPM PDP Working Group<span style="color:black"> call held on</span> 08 January 2019 at 17:00
UTC<span style="color:black">. Staff </span>will post<span style="color:black"> these to the wiki space. <b><i>Please note that these
</i></b></span><b><i>are<span style="color:black"> high-level notes and are not meant as a substitute for the recording</span>, chat room, or transcript</i></b><i><span style="color:black">.</span></i><span style="color:black"> The recording, Zoom chat,</span>
transcript<span style="color:black"> and attendance records are posted on the wiki<span class="apple-converted-space"> </span>at</span>:
<a href="https://community.icann.org/display/RARPMRIAGPWG/2020-01-08+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG">
https://community.icann.org/display/RARPMRIAGPWG/2020-01-08+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG</a>.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Best Regards,</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US">Julie<o:p></o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US">Julie Hedlund, Policy Director<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">==</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">NOTES & ACTION ITEMS</span></b><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Actions:</span></b><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Meeting Time: ACTION: Staff will ask whether WG members would be able to attend the WG call if it is moved to 18:00 UTC, nothing that the standard is to maintain the same UTC time year round as this WG and others have
been doing, do at 17:00 UTC.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Notes:</span></b><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">1. Updates to Statements of Interest:</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">-- Susan Payne: I am now a member of the Independent Review Process Implementation Oversight Team (IRP-IOT). Although this was notified back in Montreal the formalities of getting added to the group
have taken a while.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;color:black"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">2. Complete Discussion of Individual URS Proposals, see attached survey results slides and the wiki at:<span class="apple-converted-space"> </span><a href="https://community.icann.org/x/aACNBQ">https://community.icann.org/x/aACNBQ</a></span><span class="apple-converted-space"><span lang="EN-US" style="font-size:12.0pt;color:black"> </span></span><span lang="EN-US" style="color:black">--
Order of remaining proposals: 3, 30, 26, 7, 28, 19, 29, 5, 31, 21, 6, 33, 15, 22, 4, 14, 13, 17, and 16.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#3:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- This proposal seems to be aimed at addressing a scenario after the registry lock has been applied while the proceeding is ongoing. If that is what this recommendation is speaking toward then no objections.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Some confusion about the wording.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Suggest we look at how the renewal issue is handled under the UDRP and perhaps use that info to clarify the language of this proposal a bit so it is very clear. But happy to defer that until post-public comment (and
we can include some suggestions for clarifying in public comment so as to not delay the process now.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Provide some explanatory context in the Initial Report.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#30:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Very strongly oppose this proposal. Mandatory mediation would simply drag out what is intended to be a rapid procedure unnecessarily. I recognize that is a substantive ground for opposing rather than procedural in
terms of threshold for publishing for comment.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- Strongly oppose. Out of scope.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Could revisit in Phase II with UDRP.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Would like to see voluntary, but not mandatory.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Good intention but I don't see how parties can be compelled to undertake mandatory mediation. If parties don't want to then they will simply decline. So oppose for publication.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Survey reflected a certain level of support.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#26:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">--- Not opposed to proposal 26, but I think most if not all providers do already publish their roster of examiners, although may not take the further step of identifying number of appointments and links to cases by each
examiner (beyond the general publication of all decisions).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Could ask the community as to whether the providers can have some flexibility in complying.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Not a lot of opposition.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#7:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Do we have the authority/scope to recommend a change to WHOIS to add a new contact field, as this proposal suggests?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- This isn’t a field in the WHOIS. Not sure what purpose it serves to put it out for public comment.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- We could let the EPDP know that this is something that came up.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Strongly oppose. Although the concept of providing notice is a good thing, unless I have a retained client I don’t want to receive notice. Raises a host of issues that may be unintended.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- There were previous discussions on adding legal contact to WHOIS so we might put it out there just as a suggestion if the option exists.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Not sure that Legal Contact is a legal counsel per se. Having said that, I'm not convinced this is necessary. Admin Contact is sufficient, that person can deal with notice accordingly.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#28:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Providers already implement conflict of interest measures... they may differ slightly by provider, but wondering if we need to address this at the PDP level?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- I think it is provider specific, as in providers themselves have one.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Yes - providers each have internal conflicts policies that they employ, it’s just not a single uniform one... Also take that there may be concerns about proper compliance with these policies, but that is not a policy
question, but rather an implementation/compliance issue<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#19:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Strike the reference to UDRP (thoughout all proposals).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Covered with #18 and #20.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#29:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- This is cost-prohibitive for providers, particularly in URS where we don’t get a lot of filing fees. We’d have to translate a bunch of templates, etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Suspect it would benefit few. Goes beyond a mere technical fix.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Rationale is to create a form that could be easily analyzed and lots of cases could be reviewed without going through them case-by-case.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Interesting point about the word 'all' - seems to require retroactive application - will be interesting to see what public thinks if this goes out.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#5:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Several members oppose the proposal.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Some comments in support, some against.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- SOL from creation date makes no sense, as bad faith can take place much later in the domain lifecycle</span><span style="font-family:"MS Gothic"">
</span><span lang="EN-US">no - creation date of the domain name.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Creation date - this is George's argument that it's the first registration date that should set the date for limitation purposes and not any dates of subsequent transfer.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Registration date versus creation date – registration date could mean acquisition by a new owner. The original owner could sell to a bad actor who then implements bad faith use – that would be seen as a new registration
date, but not creation date.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- I am strongly opposed to the proposal, but it does have some support (and lots of opposition) to publication. If we publish we need to ensure the public understand what "creation date" means.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- The point of the proposal is a time limit for filing complaints. The example was “creation date”, but the specific implementation to be considered/decided by an IRT.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Agree that if it goes out for publication, then it must explain the terms "creation" and "registration".<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Many years ago there was a question under UDRP jurisprudence whether a renewal constitutes a new registration date but it has been pretty well settled for a while that it does not, without an attendant change in registrant.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- May need to put this proposal out for discussion with some contextual explanation to get feedback on time limits and laches.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- An effective SOL for filing complaints is a valid issue for publication.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Needs a lot of work before putting it out for comment.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Mixing up two types of law here – URS is contract law. Need to consider whether it’s appropriate to suggest imposing a British/Canadian/US version of the law on the rest of the world.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Renewal is not a new registration. The line of case that started to support that proposition were rejected by panelists as a group, Proposal 5 would be a major change in policy. I would reject this proposal and
perhaps include a separate proposal as to whether or not there should be a limitation period in URS cases. But this proposal is not workable.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#31:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- In general support to put out for public comment.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#21:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- This was merged with 22 when the IPs were previously reviewed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Very very strongly opposed to this as an overarching principle on such a lightweight RPM as URS as it will be used to bully registrants.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Merge with 22.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#22:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- There will be lots of nastygrams and most uninformed registrants will just not start a legitimate non competing business on a different domain.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- There are a handful of related proposals (like #21 and #22).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- I just don't see how this could work. At best I think we could request public comment on whether this should be studied.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Need to ask which costs a loser would have to pay.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- A 50/50 split indicates to me that we should publish the issue for public comment and further discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Knowing that this may happen could have a deterrent effect on bad actors.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Loser pays as a concept has a lot of nuance, including whether the loser participated in good or bad faith.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Will also inform future debate re same issue(s) to be presented in Phase II re UDRP.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- I would be interested on hearing from the broader community about (a) if/how this could be implemented and (b) in a way that wouldn't further slow down the URS process. Also, as Mike R. noted, this is surely to come
up in Phase 2, so a preview on how the community is feeling about this might be helpful.</span><span style="font-family:"MS Gothic"">
</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Registrant bought the domain name reg using some payment method, so there is some means by which a URS fee could be charged to that same payment method, enforceable via the domain name registration agreement.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Makes sense for UDRP. The problem here is that it isn’t correct to look at support/non-support as 50/50 in the survey. It’s one thing to ask if loser pay should be in URS and another if someone can put a bond in
escrow to protect themselves.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Beyond no mechanism and being effectively unenforceable, this concept would boost toothless threats and bullying.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Issue is that we are going far afield from what the URS was created for, which was to be fast and efficient. These may seem desirable in concept, they are inconsistent with the intent of the URS.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- There are arguments on both sides, but the question is whether this is doable. These are fairly extreme methods. Not sure this is the place for us to say that we should have a user pays model. We could ask the public
whether it should be studied.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Should we ask for comment on issues for a user pays model to help inform Phase 2.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Yes - put the question out for public comment... maybe we ultimately decide no consensus to make it a WG recommendation and that's fine but should put out for comment to collect the feedback</span><span style="font-family:"MS Gothic"">
</span><span lang="EN-US">(that
comment was re 21/22).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- It will solve very little because under the new ICANN model for new gTLDs and now .info and .org etc can charge $000s not only to buy the name but to register it every year – all they have to do is call it a premium
name. URS & UDRP won't help.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#6:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Proposal doesn’t seem to be clear.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Like a mutant form of consolidation or class action.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Would involve an extremely small number of cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Some support to put out for public comment.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Purpose: to facilitate joint complaints by multiple unrelated complainants against a single registrant who has registered many domains targeting multiple TMs of multiple parties - would be a very small subset of cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Odd fit for URS.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">#33:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- I do think this would be tough to handle and could lead to massively long decisions depending on number of parties and marks involved. If there was to be such a possibility it would seem the fee would need to go up
(perhaps each complainant would have to pay a fee) to cover the administrative and panelist time spent on these types of matters. But, essentially, this should be put out to the community<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-- Continue discussion on the next call.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">3. Meeting Time: ACTION: Staff will ask whether WG members would be able to attend the WG call if it is moved to 18:00 UTC, nothing that the standard is to maintain the same UTC time year round as this WG and others have
been doing, do at 17:00 UTC. <o:p></o:p></span></p>
</div>
<hr>
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the
sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this
email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company
registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30
Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus
USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see
<a href="https://comlaude.com" target="_blank">www.comlaude.com</a>
</body>
</html>