[gnso-whois-wg] July 18 call (was: Agenda July 11 call)

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Just a quick item prior to tomorrow's call, responding to Adam's comment
from last week which we never got to in last week's call.

I was not suggesting that Remedy was necessarily a "substitute" for Reveal.
If some access to the hidden data is necessary, then the Access methods
discussed in section 6 (arising from SGB) should be enough.  With Access
(that does not rely upon the OPoC), there is no need for an OPoC-executed
Reveal at all, so that's where the "substitution" lies.

I've said ever since the results of the subgroups were generally announced
that Reveal and Access are duplications of function.  One or the other, but
both are simply not necessary so far as I can see.

I'm particularly concerned that OPoC-Reveal does not specify or constrain
the standing of a Requestor to access the hidden data, and that suggests to
me that it presents a disturbing loophole to the Access criteria to be
established separately.  Also, I still don't think OPoC should have any
formal legal obligations to anyone except the Registrant, who should bear
all legal responsibility for the actions of the OPoC, with regard to
everyone else.

As for your concern about certification methods not yet existing, that's
the whole point of us trying to define one that can work effectively as
well as on a timely basis where appropriate.  Pat Cain told us in San Juan
that APWG was working on a form of certification, and we have a consultant
hired by ICANN to examine various options for us as well (from whom we have
not yet heard).  Palmer also suggested that bank regulators could fulfill
that function narrowly in the financial services realm.

If we are to achieve a genuine "consensus policy" in this WG, it would seem
to me that wee ought to work hard to explore these options, and not dismiss
them outright.  The time frame for this WG may not allow us to complete
that task, but then we should report it as unfinished business for moving
forward.

Talk to you tomorrow,

Dan

PS -- At this point some folks here may be tempted yet again to roll out
Rob Flaim's comment about disasters and catastrophes, originally made in
San Juan.  I hope to head this off at the pass right here, as I consider
that a political and inflammatory statement that moves us away from
potential consensus.  Not all options along the lines of pre-certification
must necessarily be "catastrophes" and I roundly object to such
implications.  This sort of rhetoric is simply not helpful to our process,
as it just divides us and obstructs us from moving forward by engaging
emotions instead of reason.  If this WG is to deliver on the high hopes
placed upon it, I think we need to stay away from this sort of spin
doctoring and leave that to the media punditsphere.  Time is now indeed
running out as we approach our final conference call.



At 11:27 PM -0600 7/10/07, Scoville, Adam wrote:
>Hi Dan -
>To try (in an ideal world) to add some clarity on this (and your e-mail
>on Friday that raised a similar point), and speaking strictly from my
>own personal point of view:
>
>- I agree with your basic point that the Remedy function is meant to be,
>if not necessarily rare (given that phishing is unfortunately common),
>limited to the very small percentage of very egregious cases. I think
>folks on all sides have used phishing as an example, but I don't think
>we've really explored what other similar situations would be equally
>grave. Obvious child porn? In any event, a) it's "to be defined", and b)
>it does not encompass "garden variety" (another undefined term)
>infringement or cybersquatting, in my view. I think someone from the
>registrar or ISP side, on a call, mentioned that in taking down they
>make a judgment as to whether there are clear criminal, as opposed to
>civil, violations.
>
>- But "explicit legal vetting" by "certified anti-phishing authorities"
>doesn't exist. To the extent that takedown happens now, it works at
>removing dangers to consumers very quickly: a) because the standard is
>flexible and can adapt to the case at hand, but is stringent enough that
>basically the takedown only happens when it's so egregious that there is
>little doubt in the ISP/registrar's mind that something seriously
>illegal is at issue. (That's probably why registrars and ISPs are
>comfortable taking down the material without any formal legal 'safe
>harbor'.); and b) because the party complaining doesn't need to
>institute any formal legal action, and can go straight to a party in
>control (the registrar or ISP).
>
>- This very limited view of the Remedy function is the answer (to your
>question of Friday) why it's no substitute for a Reveal function. In
>contrast to Remedy: a) Reveal affects the registrant much
>less--registrant information is revealed to a single requester, rather
>than the more drastic step of the whole domain being taken down and the
>registrants speech/conduct being cut off; b) Reveal takes more time--it
>comes into play after there has been some time for other avenues, such
>as communication with the registrant to work, and those avenues have
>failed; and c) it addresses different issues--by definition, ones that
>are less egregious, but nonetheless violations of law, and can wait for
>this process proceed.
>
>Just my thoughts... in case they are of any use.
>Talk with you all tomorrow.
>
>-----Original Message-----
>From: owner-gnso-whois-wg@xxxxxxxxx
>[mailto:owner-gnso-whois-wg@xxxxxxxxx] On Behalf Of Dan Krimm
>Sent: Tuesday, July 10, 2007 2:19 PM
>To: gnso-whois-wg@xxxxxxxxx
>Subject: Re: [gnso-whois-wg] Agenda July 11 call
>
>At 5:16 PM +0200 7/9/07, Philip Sheppard wrote:
>
>>3. Section 3.2 "REVEAL" versus "on request rapid take down by Registrar
>>when timely RELAY or
>>REMEDY fail".
>
>
>Philip,
>
>Thanks for the agenda.  I would suggest that this 3rd agenda item be
>reworded to replace "on request rapid take down" with "take down
>procedures".
>
>While the idea I had in mind recently (and I believe Milton also had in
>mind) was that once a case has been legally vetted then when it comes to
>the registrar from the vetting authority the registrar should not be in
>the
>position of making any judgments regarding the case, so from the
>registrar's point of view the take down would indeed be rapid (Milton
>used
>the words "immediate action").
>
>But I'd like to underscore that this presupposes an explicit legal
>vetting
>of the case from a certified authority of some sort, to whom the
>registrar
>answers.  So from the point of view of a random complainant, there would
>be
>no expectation of "on request rapid take down" in *all* cases simply
>because there was not a "timely RELAY or REMEDY".  The "request" needs
>to
>come from a legal authority.
>
>In the case of, say, certified anti-phishing authorities, the legal
>vetting
>would presumably be in place, and along with an explicit audit trail
>with
>well-defined criteria for time-sensitive cases there is no reason to
>expect
>any significant delays.  But if some random large complainant seeks to
>harass a small registrant in an anti-competitive manner (or to try to
>force
>legal response that would reveal registrant's shielded contact
>information), this should not meet with immediate response without some
>form of due process.
>
>Bottom line: we are talking about at least four players in this system:
>(1)
>registrant (including OPoC as agent for registrant), (2) registrar, (3)
>complainant, (4) legal authority.  The "rapidity" in this configuration
>is
>associated chiefly with the last step between the legal authority and
>the
>registrar.  In certain cases, the complainant and complaint-case-type
>will
>be pre-vetted, and thus it will be rapid for the complainant as well.
>But,
>not all complainants should expect rapid response in all cases,
>especially
>in the absence of legal vetting.  This was the gist of Milton's reply to
>Adam about this.
>
>I think my suggested edit above will capture this properly for the
>purposes
>of this meeting.  The original version seems to pre-suppose certain
>characteristics of the system that probably ought not be there.
>
>Thanks,
>Dan