<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Susan,</p>
<p>regarding the analysis section, one brief point:</p>
<p>The cancellation or suspension of the registration does not
necessarily mean that the data was incorrect. In many cases, the
registrant simply ignored the message, saw it too late, did not
have it forwarded by a reseller, etc and therefore did not respond
by the time the registrar is obliged to take action. So if you
take a nice three week hiking tour, that is the best time for
anyone who wants to take down your domain name. Let's be careful
with drawing conclusions from data that can be interpreted in many
ways.</p>
<p>To the next paragraph, ICANN actually monitors suspended domains
and reaches out to registrars when such domains are unsuspended.</p>
<p>I disagree with the conclusion that a suspended domain should not
be unsuspended without verification as the suspension can have
occurred for a multitude of reasons that have nothing to do with
the registration data. (Most common on our registrar: Hacked
wordpress blogs with subsites that lead to phishing sites -
usually fixed by removing the subpages and updating the WordPress
by the registrant). As for the recommendation, that is a
significant implementation impact for little to no benefit. I see
no harm in having false data in the whois of a suspended domain.
And I also disagree with the second part of the recommendation, as
detailed above. And to the added question, yes, suspended domain
names can and will be renewed.</p>
<p>Re: Grandfathered domains:</p>
<p>I have significant concerns about the logistics of this
recommendation. Not having to touch legacy domains and their
owners unless there is active cause to do so has been a
significant part of the agreement between Registrars and ICANN
under the 2013 RAA negotiations. I also note that that usually
older domains are not as much a cause for <br>
</p>
<p>Re: Bulk Submission tool:</p>
<p>We should add something that submissions remain manageable by
registrars of all sizes, since receiving 300 single tickets or one
ticket with 300 domains can overwhelm the abuse function of
smaller registrars. So complaints using such a tool need to be for
one issue with multiple domains, not various issues with multiple
domains. So if they all use the same incorrect whois for example,
that would be a valid use, but if they all use different whois
data, they should be submitted individually. Rules for combining
UDRP complaints could inform on what should be applied here to
keep this tool relevant.<br>
</p>
<p>Proactive: The ARS is quite proactive and feeds directly into
compliance. Should ICANN undertake two or more projects with the
same goal at the same time? Also, is there actual value in
improving whois data quality where no other issue exists? We have
many cases where data is outdated because people moved and forgot
to update their whois. When we notice this we ask them to update,
but is this really an issue that needs fixing by the community? Is
Whois accuracy an aboslute goal in and of itself? I do not support
the recommendation that compliance should be more proactive in
monitoring. With Whois ARS and volunteer community effort,
sufficient proactive efforts exist.<br>
</p>
<p>Cross validation: Cannot be a compliance issue until it is agreed
between ICANN and registrars. The working group is still
deliberating. <br>
</p>
<p>Table on Page 18: The RT1 Recommendation refers to proactive
management and scaling of compliance activities, not proactive
assessment and enforcement. The RT1 Rec means that Compliance
should be proactive with regard to its own ability to perform its
function, not to expand on that function as the comment in the
table suggests.<br>
</p>
<p>Finally, the document keeps using the term TLDs where domain
names are meant. This should be updated. Example: "legacy tlds"</p>
<p>Recommendations:</p>
<p>#1: We should not recommend enforcement of a registry policy
against registrars. If anything, it is a contractual issue between
registries and registrars and thus behind the picket fence. If
anything, it would have to be enforced against registries not
properly implementing it. It therefore cannot be part of the
registrar audit.<br>
</p>
<p>#2: Strongly disagree with this recommendation, as detailed
above. Highly unfeasible due to requirement to touch hundreds of
thousands of customers to basically ask them to add or change
formatting on certain data. Customer support nightmare and costs
highly outweighing the benefits. Strongly opposed.</p>
<p>#3: Opposed, as detailed above.</p>
<p>#5: Agreed, provided we include measures to keep such reports
manageable, applying rules similar to the ones for joining UDPR
complaints together. Rationale: See above.</p>
<p>#6 Seems to duplicate Rec 2? Strongly opposed as detailed above.
Logistical nightmare. <br>
</p>
<p>#7 Opposed: This issue has been addressed by the GNSO, see:
<a class="moz-txt-link-freetext" href="https://gnso.icann.org/en/group-activities/inactive/2015/dmpm">https://gnso.icann.org/en/group-activities/inactive/2015/dmpm</a> Let
us not re-open issues that have already been debated at length by
the community. And why only the compliance team? <br>
</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 24.05.2018 um 20:54 schrieb Susan
Kawaguchi:<br>
</div>
<blockquote type="cite"
cite="mid:CAJjzonEedaD0_=KnBPj6m7kfC0S_e3r0M3_PwZ-pVnJTNLicHA@mail.gmail.com">
<div dir="ltr">Hello All,
<div><br>
</div>
<div>Please see the attached Compliance subgroup draft report. </div>
<div><br>
</div>
<div>Apologies to the subgroup in not providing this to you
earlier in the week for your review but thought it best to hit
the deadline for the draft report to the full working group. </div>
<div><br>
</div>
<div>This report still needs more work, I definitely did not
organize the information optimally and will continue to work
on that. I intend to use a table format for some of our
analysis as we did for the RT1 compliance recommendation. </div>
<div><br>
</div>
<div>Also there may be duplicative language as I moved things
around I may not have caught all of the changes. I also
intentionally left some duplicative language to remind me to
continue editing. </div>
<div><br>
</div>
<div>I am hoping the subgroup will meet next week for additional
discussion on the findings and recommendations. </div>
<div><br>
</div>
<div>Best regards, </div>
<div><br>
</div>
<div>Susan </div>
</div>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
RDS-WHOIS2-RT mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RDS-WHOIS2-RT@icann.org">RDS-WHOIS2-RT@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/rds-whois2-rt">https://mm.icann.org/mailman/listinfo/rds-whois2-rt</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
</body>
</html>