<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="+1"><font face="Lucida Grande">I will try to answer
some of your questions, with the caveat that I am not a lawyer
<span class="moz-smiley-s1"><span>:-)</span></span>See
responses inline.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Thanks for your
thoughtful comments!</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Stephanie Perrin<br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande"></font></font><br>
</p>
<div class="moz-cite-prefix">On 2018-01-30 00:38, Ron Wickersham
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">I
have a question regarding responding to court orders. Even if we
don't
<br>
have that as the _only_ option for gaining access to the
registration data
<br>
(however brief or extensive it gets decided in the end) won't the
law
<br>
enforcement, and other parties, government and intellectual
property lawyers still have the option to request and obtain court
orders even
<br>
if that option is not included in the ICANN policy?
<br>
</blockquote>
Not all nation states require court orders. One of the arguments
for a central repository is to try to force better due process <br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
How can ICANN enforce contracts to ignore local or international
court
<br>
orders, or even force contractors to resist in any manner when
presented
<br>
with what appears to be a court order? I can't see ICANN revoking
Verisign's
<br>
contract to operate .com based solely on complying with a court
order for
<br>
a person/organization in the EU even if a court in the EU would
not issue
<br>
such an order for a European-based registrar, for instance.
<br>
</blockquote>
good point, I agree. see comment above<br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
My concern is that if we have the option that is proposed (and the
position
<br>
is well stated and convincingly argued for) that sets up special
rights for
<br>
law enforcement and other parties, then it appears to me that we
also get
<br>
the option 3 as well. Thus we have to attempt to monitor both
mechanisms
<br>
which makes it more difficult to ensure that the those individuals
and
<br>
organization that we are arguing should be protected are actually
protected.
<br>
</blockquote>
Special access for law enforcement and other parties is a problem,
but in my view it is unrealistic to try to ignore this....the goal
is to force better processes, better accreditation and control,
better transparency, and end user rights. This will be difficult,
but ignoring the problem favours less transparent work around
options (see you previous point)<br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
Also, no matter what the mechanism, I would like to see disclosure
of data
<br>
breaches disclosed immediately by registries and registrars even
if local
<br>
laws do not require public reporting of intrusions. And if
security of
<br>
the data from intrusion is part of the contract then auditing and
enforcement
<br>
of data security practices directly by ICANN should be
incorporated for user's protection.
<br>
</blockquote>
the provisions in the GDPR say 72 hours. you tell me whether that is
reasonable. My experience is in government, and let me tell you 72
hours would have been tight for my govt to figure out a data breach,
so asking for a more prompt response may yield confusion and no
better results. Obviously in operating systems there is more
urgency, but I am talking about static data here....<br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
If the registry or registrar contracts out proxy services, then
the
<br>
registry or registrar should be required to have that proxy
service make
<br>
themselves subject to ICANN policies through direct agreement with
ICANN
<br>
along with auditing and verification of security as well. If the
registrar
<br>
or registry goes belly-up then ICANN needs to step in immediately
and see
<br>
that the data stays protected. This should also be required of
archiving/
<br>
backup/escrow services.
<br>
</blockquote>
check the documents in the ongoing privacy proxy accreditation
implementation process....available here. I must confess I have not
had time to follow this working group as closely as I had wished,
there is a huge volume of work going
on....https://www.icann.org/resources/pages/ppsai-2016-08-18-en<br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
It may be just conspiracy theories, but if state actors and
powerful criminal
<br>
elements can penetrate any conceivable defenses, then any ICANN
policies are
<br>
really ultimately ineffective if the data is collected at all.
So I agree
<br>
that minimum data for current purposes must be part of the policy,
not the
<br>
traditional WHOIS menu -- because shouldn't employees (technical
and
<br>
administrative contacts) have the same protection as the owner of
the domain?
<br>
</blockquote>
This is why data minimization is key. The ECO report does go into
employee rights, briefly, and I agree that this is a concern. The
ECO report supports dropping tech contacts, and I agree.<br>
<blockquote type="cite"
cite="mid:Pine.BSO.4.64.1801292100380.20079@mail.alembic.net">
<br>
Thanks for the great work of our representatives on the policy
forming
<br>
areas of ICANN and for the informative comments on the mailing
list.
<br>
<br>
-ron wickersham
<br>
<br>
</blockquote>
</body>
</html>