<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I absolutely agree with Volker on the last three points. We absolutely have a mandate to examine what data is made available now - and WHETHER IT SHOULD BE AVAILABLE in the future. The fact is, laws that were not in place when the Whois protocol were developed about data protection are now in place for many jurisdictions now. And that means that, in those jurisdictions, access to registrant data that was okay in the past is now illegal. Yes, it makes things more difficult for some, but the argument that ease of access to data would be more difficult for some does not stack up against the reality global legislation that access to that data should be, at best, restricted or denied. So the mandate is not about who is facing more difficulties; it is about a changed environment in which data protection laws redraw the maps of who should have access to what data.<div><br></div><div>Holly<br><div><div>On 23 Sep 2016, at 1:46 am, Volker Greimann <<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"><p>Even though we are out of scope of the current discussion, I feel
the need to disagree.<br>
</p>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">I would strongly object
to any of those items being characterized as "content." And
even if they were "content," that is not a per se exclusion in
any way.</div>
</div>
</blockquote>
We need to differentiate between two things: Abuse by use of the
domain name in itself and abuse by use of additional services, such
as mail or hosting. The latter is content, not related to the
registration itself. In most cases, domain names are abused to
facilitate content-based abuse, but the abuse lies in the further
use, not the use of the domain name in itself. <br>
I personally feel that these forms of a buse are better dealt with
at the level of the service provider used for the actual abuse, but
that is another story and shall be told another time.<br>
<br>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">Many, if not most,
threats to security and other forms of abuse involve both the
registration of a domain name and the use of that domain name
in some fashion. It's clear and critical that we need to
allow for elements of use to be included in the purposes for
which RDS data is used.</div>
</div>
</blockquote>
Registration data of a domain name has no immediate connection to
its use.<br>
<br>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">This work is done now,
regularly and successfully, using WHOIS data among other
things. We have no mandate to restrict these uses (and as
Greg A. notes, we're at a point where discussion of
restrictions are premature).</div>
</div>
</blockquote>
Actually, we do have that mandate. Our mandate is to take the EWG
work and use it to build a new model of registration data
collection, storage and access that is complianct with all relevant
laws and legel requirements and provides the ability for those
legitimate needs to access that data that they are legally entitled
to access using the legally required means to access that data (say,
a court order).<br>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">As a final note,
discussions about whether something is "required" or
"difficult" or "impossible" are largely beside the point, and
also raise serious concerns. If a particular use of RDS data
is excluded because it's not absolutely required in every
instance, or because it's "difficult" but not "impossible" to
work without it, there are significant costs and consequences
that would arise from any such exclusion. Something that is
more difficult is more costly, more complex, more
time-consuming, more prone to failure, more burdensome and/or
more resource-intensive. Difficulty is a deterrent. </div>
</div>
</blockquote>
I hope to hear the same arguments in this and future PDPs when
contracted parties voice concerns regarding the costs of
implementation of new policies.<br>
And I hope you are not suggesting that just because it may be more
difficult or costly to access certain data (data that would be
considered legally protected private data in many jurisdictions) we
cannot erect such barriers as may be necessary to protect the rights
of those affected. <br>
I repeat an argument I raised a few weeks back: In most
jurisdictions you would need to first obtain a court order to access
the data of a internet subscriber or hosting service customer. As
the data is the same and these services are usually closer to the
violation than those of the domain registrant, why should we
consider that the private data of that registrant be protected any
less? The same rules should apply to these services.<br>
<br>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">We have no mandate as a
group to make things more difficult for current users of
RDS-type data or to deter legitimate activity.</div>
</div>
</blockquote>
We have a mandate, not to make it more difficult, but to determine
how anyone can access this data. As there are access levels
contemplated in the EWG report, I frankly do not understand why you
even make an issue of that. If access levels and restrictions are
part of the basic design, there already is one barrier that
currently does not exist, hence the difficulty to access is already
increased of todays' standards.<br>
<br>
Best,<br>
<br>
VG<br>
<blockquote cite="mid:CA+aOHUR4p7KLjo6PRou7m+buHaQdcjXY1Fv+DtpwkJ2aQhgnZA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Greg Shatan</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Sep 22, 2016 at 9:54 AM, Rob
Golding <span dir="ltr"><<a moz-do-not-send="true" href="mailto:rob.golding@astutium.com" target="_blank">rob.golding@astutium.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Safeguard 3: Should Registry Operators undertake
periodic security<br>
checks to analyze whether domains in its gTLD are being
used for<br>
threats to security, such as pharming, phishing, malware
and botnets?<br>
</blockquote>
<br>
</span>
None of which requires "registration" data ...<br>
<br>
pharming = content<br>
phishing = content<br>
malware = content<br>
botnets = traffic [and are primarily ip based not domain
based]<br>
etc<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Rob</font></span>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/gnso-rds-pdp-wg</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</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>
</div>
_______________________________________________<br>gnso-rds-pdp-wg mailing list<br><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</blockquote></div><br></div></body></html>