Re: [gnso-whois-wg] Why OPoC Must have Relationship w/ Registrar/ICANN not just Registrant

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

This argument doesn't quite fly for me.  If it is the registrant's
responsibility to contract with an OPoC that will perform the Relay (and
perhaps Remedy) functions reliably, then if the OPoC fails to do so it
remains the registrant's liability, subject to potential remedy on the
domain.

I would suggest that the registrar still has an overall capability of
Remedy (remove the domain from DNS), even if the OPoC/registrant may have
more fine-tuned remedies available (remove a single offending web page, for
example -- this may already be a capability of admin or tech contacts at
present, depending on how registrants use those roles).

So, if the OPoC is served with some legal notice, and the registrant fails
to respond and the domain operation is not changed, the registrar can still
take down the domain.  It doesn't matter whether the OPoC failed to Relay
to the registrant, or the registrant chose not to respond after successful
Relay, or the registrant directed the OPoC not to Remedy after successful
Relay, etc.  All that matters is that there was no response or remedy
associated with the domain, and then the registrar can take it down.

If a registrant wants to protect oneself, there is no reason that benefits
the registrant for the OPoC not to perform the Relay (and perhaps Remedy)
functions, as failure to perform those functions does not benefit the
badly-acting registrant, and reliably performing those functions does not
"harm" the badly-acting registrant (i.e., it does not oppose the
registrant's intent to act badly, assuming the OPoC acts under direction
from the registrant especially in cases of Remedy).  In short, there is no
incentive for an OPoC not to Relay, and if the registrant directs the OPoC
not to perform a nuanced Remedy there is always the Damoclean sword of the
registrar hanging over the entire domain's head.

If, on the other hand, a good-faith registrant has problems with a
badly-acting OPoC that could cause problems, but that rests the
responsibility for choosing a reliable OPoC on the registrant, where I
think it belongs (like choosing a proxy service).  And, if a badly-acting
OPoC causes liabilities for the registrant, the OPoC's contract with the
registrant could funnel liability to the OPoC for recourse.

So, I still see no need for a Reveal function of OPoC, and no need for the
OPoC to register with the registrar beyond simply having the information
submitted to Whois for public display.

Dan



At 12:34 AM -0600 7/6/07, Scoville, Adam wrote:
>I think some who didn't attend the San Juan meeting have asked why an
>agreement with the registrar or ICANN is necessary.
>
>To summarize, a relationship only between the OPoC and the registrant is
>insufficient for the following reason: if the registrant of the domain is
>in some way a bad actor, a wronged third party needs the OPoC to perform
>its functions in order to communicate with the registrant, and to be able
>to identify the registrant sufficient to bring the right legal action
>against the right person in the right place. (If that can't be done, there
>is no law on the Internet.)
>
>If the OPoC doesn't perform its functions, under this scenario, the only
>party the OPoC is responsible to is the bad actor. Moreover, the OPoC may
>complain that the contract the registrant gave her never required her to
>perform the responsibilities we set out. So perhaps the registrant has
>breached the Registration Agreement by failing to require the right
>responsibilities of the OPoC? but all that gives is another reason the
>registrant is bad, which is no help in the original goal of communicating
>with or bringing legal action against the registrant.
>
>Two ways of binding the OPoC would be accreditation (i.e. ICANN verifies
>the OPoC's credentials and OPoC agrees to perform it's responsibilities as
>a condition of accreditation) or acknowledgement (i.e. when nominated as
>an OPoC, the OPoC must in some way acknowledge to the registrar that it is
>the OPoC and its responsibility to perform the specified OPoC functions).
>
>Perhaps with acknowledgement there is no indication ahead of time that the
>OPoC will do its job (as in accreditation), but at least a contractual
>relationship exists (the OPoC must respond to a query, and
>acknowledge-agree-that it must perform its set of responsibilities).
>
>- Adam