ICANN ICANN Email List Archives

[gnso-res-sga]


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

RE: [gnso-res-sga] Whois working group -- subgroup A (reponsibilities)

  • To: <gnso-res-sga@xxxxxxxxx>
  • Subject: RE: [gnso-res-sga] Whois working group -- subgroup A (reponsibilities)
  • From: "Patrick Cain" <pcain@xxxxxxxxxxxxxxxx>
  • Date: Wed, 9 May 2007 15:19:23 -0400

Hi,

This is very good, I have mostly minor requests. I hope that we can comment
on this one set instead of multiple, diverse versions to decrease confusion.
As requested on the call today, my comments are below.
I only copied the parts of Steve's answer that I wanted to comment on. They
are marked with pc>


1. WHO...

The OPoC must have the technical capability and permissions to take down a
registrant's site. 
        
        Pc>     Many of the OPOC interactions will be for active network
problems that don't get resolved
                with a 'site takedown', for example stopping a DOS attack.
It would be easy to say 
                "...capability and permissions to successfully deal with the
complainant's operational 
                issue (e.g., disable a URL, remove content, disable
communications with the server, 
                disable the DNS record)". 
                But that sounds really complex, but 'taking down the server'
is not covering all the 
                cases of OPOC activity.

-----------------------------------------------------
2. WHAT issues is the OPOC required to handle - or not: 

Upon communicating with the registrant, the OPoC must ensure that the
Registrant communicates a response or resolution of the applicable issue.

        pc>     I don't think this is a "WHAT", but goes under the "penalty
clause of 4. HOW?"

        pc>     Should the OPOC be required to tell the complainant that
notice was actually sent? Or in 
                IETF-speak: The OPOC SHALL notify the complainant when they
notify the registrant using similar                     mechanisms of the
original complaint. 
                It will be hard to determine OPoC culpability if the OPoC
can not send out a notice but claim
                to have done it.

-----------------------------------------------------
 
4. HOW would these responsibilities be enforced

If an OPoC fails  ...

        Pc>     These all sounded good for an OPoC failure, but what if the
OPoC acted like they were 
                supposed to and the registrant/idiot does not respond?
                I think here needs to be a brief section -- maybe the stuff
that I complained about 
                in #2 -- on 'registrants that use OPoC failure modes'.
Previous attempts at making a third
                party *force* someone to respond has not been fruitful.
Although I expect to get beat-up, 
                I think there needs to be some mechanism for the OPoC to use
besides waiting for the 
                registrar/registry to perform their suspension/conveyance
actions.
                Maybe a:

                If the registrant fails to acknowledge OPoC notification
receipt within [ten days?] the OPoC 
                is free to notify complainant of registrants' direct contact
information or to invoke other 
                sanctions of #4, (although this needs to be tweaked with
regard to national law). 


Pat Cain
        






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

Privacy Policy | Terms of Service | Cookies Policy