[RDS-WHOIS2-RT] Compliance subgroup draft report

Fri May 25 16:02:00 UTC 2018

Hi Susan,

regarding the analysis section, one brief point:

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.

To the next paragraph, ICANN actually monitors suspended domains and 
reaches out to registrars when such domains are unsuspended.

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.

Re: Grandfathered domains:

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

Re: Bulk Submission tool:

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.

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.

Cross validation: Cannot be a compliance issue until it is agreed 
between ICANN and registrars. The working group is still deliberating.

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.

Finally, the document keeps using the term TLDs where domain names are 
meant. This should be updated. Example: "legacy tlds"

Recommendations:

#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.

#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.

#3: Opposed, as detailed above.

#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.

#6 Seems to duplicate Rec 2? Strongly opposed as detailed above. 
Logistical nightmare.

#7 Opposed: This issue has been addressed by the GNSO, see: 
https://gnso.icann.org/en/group-activities/inactive/2015/dmpm Let us not 
re-open issues that have already been debated at length by the 
community. And why only the compliance team?

Volker

Am 24.05.2018 um 20:54 schrieb Susan Kawaguchi:
> Hello All,
>
> Please see the attached Compliance subgroup draft report.
>
> 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.
>
> 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.
>
> 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.
>
> I am hoping the subgroup will meet next week for additional discussion 
> on the findings and recommendations.
>
> Best regards,
>
> Susan
>
>
> _______________________________________________
> RDS-WHOIS2-RT mailing list
> RDS-WHOIS2-RT at icann.org
> https://mm.icann.org/mailman/listinfo/rds-whois2-rt

-- 
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: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

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: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rds-whois2-rt/attachments/20180525/49174a97/attachment.html>