Re: [gnso-whois-wg] Comments on WWG report draft 1.5 -- Sections 1-4

[Christopher Gibson <cgibson@xxxxxxxxxxx>]

1.  Line 156 and consent.  See Dan Krimmâs message below.  Placing burdens on 
the registrant is unrealistic.  How will a registrant know that it is 
âresponsible for ensuring that the OPoC confirms the email address in order 
to complete the registration.â  I would agree with the principle of 
âconsent,â but only if it spells out the responsibilities to which the OPOC 
must agree.  Otherwise, there is no practical mechanism in the system for 
requiring an OPOC even to RELAY message to the registrant, let alone REVEAL in 
appropriate circumstances.

 

2.  As for cost issues, given the nature of online postings and their potential 
for abuse, registration comes with a degree of responsibility.  Any costs for 
permitting access under conditions that comply with privacy rights should be 
included in the costs of registration and not be forced as a âcost 
externalityâ on those who may be subject to wrongful activities and need to 
protect consumers or their own rights.

 

Chris Gibson

_____________

 * OPoC as agent to registrant, line 156:  I agree in part with Ross'

statement that "agency law can be used" to govern liabilities of the OPoC.

I would suggest that the OPoC need have no direct liability to the

registrar, but rather the registrant would be responsible for ensuring that the 
OPoC confirms the email address in order to complete the registration.  The 
OPoC must only confirm to the registrant that the OPoC consents to being the 
registrant's OPoC.

   

  ---- Original message ----

    Date: Tue, 24 Jul 2007 19:29:18 -0700
    From: Dan Krimm <dan@xxxxxxxxxxxxxxxx>
    Subject: [gnso-whois-wg] Comments on WWG report
    draft 1.5 -- Sections 1-4
    To: gnso-whois-wg@xxxxxxxxx
    >Here are some comments on Part 1 of the report. -
    Dan
    >
    >
    > * Procedure for determining agreement levels: As
    there seems to be some
    >disagreement as to whether points are agreed or
    not, I wonder if we could
    >have an explication in more detail of the
    definitions in the introduction,
    >lines 68-74. For example, what is the
    quantitative definition of "broad
    >agreement" and how exactly is it determined by
    the "ultimate authority"?
    >Does it draw off of the email list postings or
    only from whoever happens to
    >be able to show up for the live conference calls?
    If the judgment seems to
    >be mistaken, can we require the judge to explain
    the judgment, referring to
    >transcripts (and emails on the list)? Exactly
    what form of accountability
    >is available to ensure genuine consensus in case
    the ultimate authority
    >seems to be in error?
    >
    >
    > * Section 1, Line 81: Protecting personal
    privacy systematically is a
    >clear "public interest" issue, so I would
    strongly object to the framing of
    >this topic as "privacy versus public interest."
    Also, combatting fraud is
    >of strong interest to non-consumers such as banks
    and other institutions
    >that bear significant liability for such fraud. I
    would suggest instead:
    >
    >"Balancing personal privacy against harmful use
    of domains"
    >
    >In the second paragraph of section 1, there are
    references to "exceptions".
    >It is not explained what the exceptions refer to.
    I think we ought to
    >preface these comments with a statement that
    protecting personal privacy of
    >natural persons is the default stance, and that
    exceptions to this default
    >need to be carefully considered and limited to
    explicitly confirmed
    >legitimate circumstances.
    >
    >
    > * Proportionality of costs, lines 97-101: We
    should add that the
    >"implicit burden" of costs needs to be evaluated
    in context of the
    >resources of those who would bear those costs.
    (Fifty dollars makes a
    >bigger difference to me than to Bill Gates, to
    use an extreme case.)
    >
    >
    > * Section 2.3, verification of OPoC: Ross has
    voiced concerns about a
    >non-real-time registration process. So what if we
    require all information
    >(including OPoC email verification) to be
    completed before the registration
    >can be fully *initiated*? If this step is left
    out, then there would be no
    >"hold" on the domain name, and the registration
    process would be entirely
    >aborted. Given that there will likely be some
    considerable demand for
    >"on-demand OPoC services" to enable quick
    registration, I would expect that
    >there would be supply emerging naturally to serve
    that demand.
    >
    >
    > * OPoC as agenct to registrant, line 156: I
    agree in part with Ross'
    >statement that "agency law can be used" to govern
    liabilities of the OPoC.
    >I would suggest that the OPoC need have no direct
    liability to the
    >registrar, but rather the registrant would be
    responsible for ensuring that
    >the OPoC confirms the email address in order to
    complete the registration.
    >The OPoC must only confirm to the registrant that
    the OPoC consents to
    >being the registrant's OPoC.
    >
    >
    > * Proxy services, lines 176-196: I think I
    understand Ross' comments
    >here, and I would suggest that the intent of the
    agreement here is that
    >proxies should not be able to hide their contact
    info by designating an
    >OPoC, since they are essentially a sort of OPoC
    to begin with.
    >
    >In order to make the data collection and user
    interface consistent, the
    >requirement that proxies must designate
    themselves as an OPoC if they
    >designate any OPoCs at all would seem to satisfy
    that goal. If there are
    >more efficient ways to implement this setup, then
    perhaps the registrars
    >might suggest an alternative model that
    accomplishes an equivalent result.
    >
    >
    > * Section 3.2, Reveal, line 294 etc.: If the
    Reveal function of the OPoC
    >is to stand, then I suggest we must define the
    legal standing of requesters
    >to demand a Reveal. I would also suggest that
    self-declaration is not
    >sufficient to establish standing, but rather some
    form of legal due process
    >must be involved to avoid the potential for a
    sham legal notice to be
    >accepted for such purposes.
    >
    >
    > * Identity of registrant, Line 303: Identity of
    a registrant is not
    >hidden in the OPoC paradigm, only personal
    contact information. So I don't
    >understand in what cases legal notice is
    prevented from being served
    >without Reveal. I assume that ICANN can require
    the registrant (via its
    >contracts with registries and registrars, passing
    through to the
    >registrants) to legally bind the OPoC to Relay
    legal notices to the
    >registrant. Thus, it is possible to arrange the
    OPoC liabilities such that
    >the OPoC acts as a legal representative for the
    registrant, and any notice
    >served on the OPoC is binding on the registrant.
    >
    >
    > * Authentication, line 309: Given that the
    Access function should be
    >subject to authentication of those who would have
    access, then Reveal
    >should also be subject to authentication of
    requesters of hidden contact
    >information. There is utterly no reason that I
    can see that these two
    >methods should be treated differently in
    principle. If the only reason to
    >retain a Reveal function for the OPoC is to serve
    as a loophole when Access
    >is inconvenient, then we should remove the Reveal
    function and deal with
    >Access authentication on its own merits to
    satisfy legitimate needs on all
    >sides. I suspect the alleged "alternate/minority
    view" in lines 313-314 is
    >in fact a second supported view, but we need to
    clarify the process of
    >determining agreement levels in order to clarify
    this point.
    >
    >It should be reiterated that Access is superior
    to Reveal in that it need
    >not notify the registrant that personal contact
    data has been accessed,
    >when the registrant is indeed involved in
    fraudulent and/or harmful
    >activity surrounding the use of the domain.
    >
    >
    > * Reveal conditions, line 316 etc.: I think this
    overstates the cases,
    >even if requesters have been properly
    authenticated.
    >
    >For example, intellectual property infringement
    cannot be confirmed by
    >virtue of a mere claim, even with tangible
    evidence, because judicial
    >involvement is required to establish such
    judgments as fair use in the case
    >of copyrights, etc. Again, if legal notice can be
    served on the OPoC in
    >such cases (like C&D notices) and those notices
    can be legally considered
    >as served on the registrant, then there is no
    need to reveal.
    >
    >I also agree with Ross that alleged inaccurate
    Whois data in and of itself
    >(in the absence of any other claim of harm) is
    insufficient to mandate
    >revealing personal contact information.
    >
    >I see no way to determine if Relay has failed,
    other than lack of response
    >by the registrant. If there are time-delays to be
    considered, it seems
    >more appropriate to consider that in the context
    of Remedy, not Reveal.
    >
    >Bottom line: I still see no specific reasons that
    Reveal must exist
    >separate from Access, and I suggest it be removed
    abjectly from our
    >recommendations and that the implementation
    options be removed.
    >
    >
    > * Section 3.3, Remedy, lines 334 etc.: I agree
    with Vittorio's comments
    >that the OPoC's actions should be
    determined/controlled by the registrant.
    >This is commensurate with my comment above that
    the OPoC should be legally
    >bound as an agent for the registrant.
    >
    >
    > * Lines 338-340 (OPoC not actor for Remedy):
    This makes no sense to me
    >and I disagree with it. If there is some remedy
    that must be taken, either
    >the registrant or the OPoC may take such remedy
    as they see fit, but this
    >would be at the option of the registrant, not
    mandated by any standing
    >policy. There may be other remedies that the
    registrar may take if legally
    >appropriate remedies are not taken by the
    registrant or OPoC. It may be
    >advantageous for the registrant to take or direct
    a narrow remedy in order
    >to avoid a more comprehensive remedy by the
    registrar.
    >
    >
    > * Lines 341-345: I agree with Ross' comments
    here. This is a matter
    >between the registrant and the OPoC, with
    liability for the domain
    >conferred on the registrant. If the OPoC fails in
    anything of interest to
    >the registrant, the OPoC should be liable to the
    registrant, and the
    >registrant is liable for the domain.
    >
    >
    > * Implementation time line, lines 348-349: I
    would simply strike this.
    >
    >
    > * Section 4, compliance/enforcement: I disagree
    with the reveal-related
    >provisions here, in particular in lines 359 and
    361. Also, I see no
    >relevance to mentioning Relay in this
    circumstance. The only case that
    >seems to be pertinent and enforceable here is
    with respect to Remedy.
    >
    >In cases where a requester has made a request for
    action on the domain by
    >the registrar, we have yet to determine how such
    requests are to be
    >evaluated by the registrar, and whether such
    action is mandated, and if so
    >in what cases.
    >
    >
    >
    >