<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Correct, handling complaints is an important part. And I agree with the rest also. </p>
<p><br>
</p>
<p><a href="https://cispe.cloud/code-of-conduct/" class="x_OWAAutoLink">https://cispe.cloud/code-of-conduct/</a><br>
</p>
<p><br>
</p>
<p><a href="https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/43--guide-to-the-gdpr--codes-of-conduct-and-certifications.pdf?la=en" class="x_OWAAutoLink">https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/43--guide-to-the-gdpr--codes-of-conduct-and-certifications.pdf?la=en</a><br>
</p>
<p><br>
</p>
<p>Best regards, </p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255); font-family:Calibri,Arial,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Theo Geurts </p>
<p><br>
</p>
<p>Compliance & Policy Officer | <span style="font-size:12pt">Realtime Register B.V.</span></p>
<p><br>
</p>
<p>Ceintuurbaan 32A</p>
<p>8024 AA - ZWOLLE - The Netherlands</p>
<p><br>
</p>
<p>T: +31.384530759</p>
<p>F: +31.384524734</p>
<p>U: www.realtimeregister.com</p>
<p>E: legal@realtimeregister.com</p>
<p>Skype: geurts.theo</p>
<div><br>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Accred-Model <accred-model-bounces@icann.org> on behalf of jonathan m <jonathan.matkowsky@riskiq.net><br>
<b>Sent:</b> Sunday, July 29, 2018 6:09:09 PM<br>
<b>To:</b> Rod Rasmussen<br>
<b>Cc:</b> accred-model@icann.org; gdpr@icann.org<br>
<b>Subject:</b> Re: [Accred-Model] Codes of conduct</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">The issue of scaling is critical. But scaling also raises special<br>
considerations under GDPR as large-scale processing, and various use<br>
cases present different degrees of risk to the data subject.<br>
<br>
In terms of eligibility for access, only a defined set of user groups<br>
would be eligible for access, but only one of which would be<br>
legitimate interest-based processing requestors (and only for those<br>
types of requests for which legitimate interest-based processing is<br>
permissible under GDPR without consent). For legitimate interest based<br>
users (as opposed to other categories such as tasks carried out in the<br>
public interest or exercising official authority vested in the<br>
controller), they should be monitored by codes of conduct reflecting a<br>
governance system that is transparent, building on input from relevant<br>
stakeholders, and allowing organizations interested in being part of<br>
the governance to be invited to express interest. The EU Cloud CoC<br>
can possibly be used as a model for organizational framework of a code<br>
and its bodies – governance bodies and administration. Without<br>
prejudice to the tasks and powers of the competent supervisory<br>
authority, the monitoring of compliance with a code of conduct may be<br>
carried out by a body which has an appropriate level of expertise in<br>
relation to the subject-matter of the code and is accredited for that<br>
purpose by the competent supervisory authority. It must demonstrate<br>
its independence and expertise in relation to the subject-matter of<br>
the code to the satisfaction of the competent supervisory authority,<br>
establish procedures and structures to handle complaints about<br>
infringements of the code or the manner in which the code has been, or<br>
is being, implemented by a controller or processor, and to make those<br>
procedures and structures transparent to data subjects and the public,<br>
and demonstrate to the satisfaction of the competent supervisory<br>
authority that its tasks and duties do not result in a conflict of<br>
interests. The competent supervisory authority will then submit the<br>
draft criteria for accreditation of a body to the European Data<br>
Protection Board pursuant to the consistency mechanism in Article 63.<br>
<br>
Best,<br>
Jonathan<br>
<br>
<br>
On Wed, Jul 25, 2018 at 11:42 PM, Rod Rasmussen <rod@rodrasmussen.com> wrote:<br>
> Michael,<br>
><br>
> I don’t believe that codifying these issues and resulting disclosure<br>
> requirements works against the principals you are referring to here. On the<br>
> contrary, I think that creating norms and standards around these issues<br>
> resolves many things that are currently ambiguous at best. I think one way<br>
> of interpreting my remarks is that there are OTHER “ignoring these issues<br>
> won’t make them go away” concerns as well. :-) We have to be able to<br>
> balance the legitimate interests of registrants' (and other listed<br>
> contacts’) rights to privacy with the need to keep the Internet running<br>
> efficiently in a way that doesn’t Balkanize it based on policies set by<br>
> individual network operators’ tolerance for abuse who don’t have the time to<br>
> determine what domains or even TLDs are “baby versus bathwater”.<br>
> Balkanization will only invite intervention by other more powerful parties<br>
> that currently are not paying much attention and letting the ICANN community<br>
> figure these things out on its own. I think these challenges are both<br>
> solvable and necessary to address how we mature Internet domain name<br>
> policies from all perspectives. I bring them up though so we don’t lose<br>
> sight of the fundamental reality of how the Internet is actually working.<br>
> The Internet is basically a network of networks that agree to cooperate with<br>
> each other for the common good of all at a grand scale that is difficult for<br>
> humans to comprehend rather than a discreet set of one-off decisions made by<br>
> individuals that are relatively easy to discuss on a case-by-case basis. We<br>
> have to do our best to think at scale when talking about making policy.<br>
><br>
> I think we’ll need that $4 and more as Euros in Barcelona though to work<br>
> this all out - perhaps over a good bottle of Garnache Tinta!<br>
><br>
> Cheers,<br>
><br>
> Rod<br>
><br>
> On Jul 25, 2018, at 1:12 PM, Michael Palage <michael@palage.com> wrote:<br>
><br>
> Rod,<br>
><br>
> I hear your concerns, but I think Jonathan’s original comments about<br>
> “ignoring these issues won’t make them go away” remains on point.<br>
><br>
> In reviewing the Version 1.7 there does not appear to have been any<br>
> expansion on the Auditing and Penalties sections (Section IV, Paragraphs G &<br>
> J respectively).<br>
><br>
> The bedrock of the GDPR is about empowering Data Subjects with the right to<br>
> control the processing of their data and the latest model remains largely<br>
> devoid of this right. Until the IPC/BC decide to incorporate some type of<br>
> Data Subject “rights centric” approach into their model, I do not see how it<br>
> will pass EDPB muster.<br>
><br>
> Just my personal two cents as well. Perhaps with another 4 bucks we might be<br>
> able to split a cup of Starbucks coffee while in Panama.<br>
><br>
> Best regards,<br>
><br>
> Michael<br>
><br>
> From: Accred-Model <accred-model-bounces@icann.org> On Behalf Of Rod<br>
> Rasmussen<br>
> Sent: Wednesday, July 25, 2018 12:11 PM<br>
> To: jdm@riskiq.net<br>
> Cc: accred-model@icann.org; gdpr@icann.org<br>
> Subject: Re: [Accred-Model] Codes of conduct<br>
><br>
> Jonathan,<br>
><br>
> Thank you very much for your thoughts here! To me, this analysis of yours<br>
> screams for standards so that this can scale, otherwise we will end up with<br>
> a system that is far too much dependent upon manual determination of issues<br>
> by all parties to be useful in the real world of abuse that moves at<br>
> automated speeds (i.e. the bad guys registering or compromising domains at<br>
> scale (each using thousand of domains per day via automation). My thesis is<br>
> that you need a well-defined taxonomy of abuse types, domain abuse scenarios<br>
> (e.g. abusively registered, compromised in-part, compromised in-full), and<br>
> threat level (e.g. ongoing mass attack, ongoing targeted attack, potential<br>
> attack). From that you can build a matrix of what information is required,<br>
> what information about requestors can be readily revealed, and who is<br>
> requested to make what kind of actions and in what timeframe. For example,<br>
> for a wide-scale, current phishing attack using a compromised website, a<br>
> very timely response (within minutes or hours) of a technical contact and<br>
> registrant contact e-mail and phone number would facilitate solving both the<br>
> phishing attack and the potential for the registrant to be exposing PII of<br>
> its own users given that their website tied to a domain is compromised. The<br>
> identity of the requestor would not need to be confidential in such a<br>
> scenario since they *want* the registrant to know that the registrant has a<br>
> serious problem to solve that could put the registrant in dire straits<br>
> vis-a-vis GDPR. Separately, a detection of potentially malicious set of<br>
> domain registrations that have a high probability that they will be used to<br>
> launch various fraudulent and illegal scams based on prior observed behavior<br>
> could result in a longer-term response (day/days) with full information<br>
> about the registrant of the domain(s) and even other domains registered at<br>
> near the same time, being provided with the requestor’s information not<br>
> being revealed to the registrant without them going through process<br>
> themselves. The main thing is to agree on what information is appropriate<br>
> to reveal and how long the responses should take. From there, all parties<br>
> can build automated systems to create and accept responses for contact<br>
> information requests, with attestation of the harms driving the actual<br>
> process that ensues.<br>
><br>
> It’s all about proportionality and the ability for various harms to be<br>
> balanced in a non-biased fashion. I think that if we can approach the<br>
> various scenarios dispassionately and scientifically, we could provide solid<br>
> guidance on how any request for registration contact information is dealt<br>
> with across all registrar/registry players *and* requestors. The key is<br>
> putting together a good matrix that all stakeholders can live with, and then<br>
> making sure people involved in this in all roles understand how to work<br>
> within the system properly and *do*so.<br>
><br>
> The current ad-hoc situation on both the requestor and provider sides is<br>
> untenable and is already on the path to major negative consequences for all.<br>
> Beyond the waste of manpower and unintentional abetting of crime that we’re<br>
> already seeing, my major fear is that these negative consequences eventually<br>
> draw the attention of various national governments whose citizens are being<br>
> abused, who then decide how things should work instead of the parties<br>
> actually involved. That scenario historically doesn’t work out well for the<br>
> affected parties.<br>
><br>
> My 2 cents.<br>
><br>
> Cheers,<br>
><br>
> Rod Rasmussen<br>
> Speaking personally and not on behalf of any organization I am part of.<br>
><br>
><br>
> On Jul 16, 2018, at 3:54 PM, jonathan m <jonathan.matkowsky@riskiq.net><br>
> wrote:<br>
><br>
> All,<br>
><br>
> Any model that doesn’t take into account for transparency of processing that<br>
> a data subject has the right to typically object and freeze the processing<br>
> is not compliant with GDPR. I think the registrar as a controller must also<br>
> have the right to object. That doesn’t mean that the processing won’t<br>
> eventually continue if it is compelling and overrides the rights and<br>
> freedoms of the individual but subject to Chapter 7 of the GDPR.<br>
><br>
> When safety is a concern, then as long as the data subject knows which<br>
> supervisory authority is overseeing the code of conduct under which the<br>
> request is being made, it’s possible to protect the identity of the<br>
> requestor. This should be relatively rare.<br>
><br>
> Not every legitimate interest outweighs the rights and freedoms of the data<br>
> subject, and a privacy impact assessment is required. Not every legitimate<br>
> interest is entitled to the same weight under GDPR, and the risks and<br>
> severity of harm to the person must be considered especially when certain<br>
> interests at stake aren’t the same as those of the controller.<br>
><br>
> We need RDAP to accommodate these concerns. When law enforcement has<br>
> legitimate interests, they can use the same RDAP tier of access, but when<br>
> pursuing a criminal offense or investigation, a different model of access<br>
> must be accommodated under the LED etc.<br>
><br>
> Ignoring these issues won’t make them go away. I hope that truly<br>
> consensus-building voices participate in the EPDP, because it’s time we stop<br>
> trying to keep Whois to the greatest extent possible and instead design the<br>
> next generation to be better—more accurate, with more accountability and<br>
> integrity but also consistent with data protection laws and internationally<br>
> recognized norms. It makes sense to generally treat all people — regardless<br>
> of where they reside, with the same inherent rights and freedoms that<br>
> European laws are attempting to protect.<br>
><br>
> Jonathan Matkowsky<br>
> VP - Cybersecurity, Privacy & IP<br>
> JD, CIPT, CIPP/EU<br>
> RiskIQ, Inc.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Jonathan Matkowsky<br>
><br>
> *******************************************************************<br>
> This message was sent from RiskIQ, and is intended only for the designated<br>
> recipient(s). It may contain confidential or proprietary information and may<br>
> be subject to confidentiality protections. If you are not a designated<br>
> recipient, you may not review, copy or distribute this message. If you<br>
> receive this in error, please notify the sender by reply e-mail and delete<br>
> this message. Thank you.<br>
><br>
> *******************************************************************_______________________________________________<br>
> Accred-Model mailing list<br>
> Accred-Model@icann.org<br>
> <a href="https://mm.icann.org/mailman/listinfo/accred-model">https://mm.icann.org/mailman/listinfo/accred-model</a><br>
><br>
><br>
<br>
<br>
<br>
-- <br>
_____________________________<br>
Jonathan Matkowsky<br>
VP, Cybersecurity, Privacy & IP<br>
JD, CIPP/EU, CIPT<br>
PGP Fingerprint EB45 EF13 14B8 2A1A 1783 1154 B6B6 AE12 A604 D2EC<br>
<br>
RiskIQ, Inc. | 22 Battery St. 10th Floor | San Francisco, CA 94111 |<br>
1.888.415.4447<br>
<br>
<a href="http://www.riskiq.com">http://www.riskiq.com</a><br>
<br>
-- <br>
*******************************************************************<br>
This <br>
message was sent from RiskIQ, and is intended only for the designated <br>
recipient(s). It may contain confidential or proprietary information and <br>
may be subject to confidentiality protections. If you are not a designated <br>
recipient, you may not review, copy or distribute this message. If you <br>
receive this in error, please notify the sender by reply e-mail and delete <br>
this message. Thank you.<br>
<br>
<br>
*******************************************************************<br>
_______________________________________________<br>
Accred-Model mailing list<br>
Accred-Model@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accred-model">https://mm.icann.org/mailman/listinfo/accred-model</a><br>
</div>
</span></font>
</body>
</html>