ICANN ICANN Email List Archives

[gnso-whois-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-whois-wg] Draft outcomes report v 1.6

  • To: <gnso-whois-wg@xxxxxxxxx>
  • Subject: RE: [gnso-whois-wg] Draft outcomes report v 1.6
  • From: Dan Krimm <dan@xxxxxxxxxxxxxxxx>
  • Date: Thu, 9 Aug 2007 14:54:55 -0700

At 3:32 PM -0700 8/8/07, Metalitz, Steven wrote:


>I agree with Milton that the phrasing of the 6.3-type access is not
>quite right, though I disagree with his re-phrasing.  How about changing
>line 598  to read:
>"This type of access would be query-based to undisplayed data for any
>domain, subject to limitations on the purposes of access and the uses to
>be made of the data obtained."

This makes the statement too vague, and thus without specific meaning.  Why
remove the detail about what kinds of "limitations" in Milton's version?

See: "but with contractual/legal restriction of queries to the records of
particular domains and/or registrants needed to support a specific
investigation."

Is there something wrong with contractual/legal restrictions?  Are there
other purposes that you are aiming for, other than supporting a specific
investigation?  These are specifically defined limitations that protect
privacy without hampering investigations.  Looks balanced to me.  The vague
version removes the teeth from privacy protection (at best, leaves it to
future deliberations to define in detail; at worst, allows details to
remain undefined indefinitely).



>Regarding the options listed in lines 656-658 for access mechanisms,
>Milton's suggested third option could be accommodated by revising the
>first option (line 656) to read, "Self-certification by the Accessor,
>with safeguards such as penalties for misrepresentation or abuse."

This omits the affidavit.  The affidavit option should be retained
explicitly.  If there is disagreement about whether self-certification
should require such an affidavit, then this third option should be kept
distinct from the first option, and we can agree to disagree about whether
it is to be a recommended option or not.  This paragraph is simply laying
out the various options discussed, and so it should include all options
regardless of their level of agreement.



>Regarding lines 689-691, it occurs to me that there is considerable
>support, and perhaps even agreement (though I am sure not unanimity),
>for the following statement: "OPOC implementation should wait until a
>viable and broadly supported mechanism for access under this section has
>been developed."

I'm not so sure about this, and tend to disagree.

If we expect to develop a mechanism for access in practice, it may be
useful to have a strong motivation in place to drive such development.  If
there is no strong motivation to drive such development, it could readily
be stretched out indefinitely.  It is in some parties' interests to string
out these discussions for as long as possible without doing anything.  In
such circumstances, "consensus" will naturally be long in coming.

If on the other hand we create circumstances where everyone has some
benefit to be gained from finding consensus, then consensus will be more
likely to be found on a more timely basis.

The lack of such external circumstances is the primary structural flaw in
the current WG's consensus dynamics, which is why any genuine consensus
emerging from this group is going to be very narrowly drawn.

Dan




<<< Chronological Index >>>    <<< Thread Index >>>