Re: [gnso-acc-sgb] RE: [gnso-whois-wg] Whois MAY/MUST with OPOC

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Margie,

Margie Milam wrote:

> I think this is useful.
>
> It may also be helpful to use a common definition to distinguish the
> OPOC information (which would be publicly available on an unrestricted
> basis) from the "Registrant's Underlying Information" which is the
> non-publicly available information that is being collected by
> registrars: the remaining registrant information (address/phone), the
> technical contacts and the administrative contacts.

  Good idea. Agreed.

>
>
> As I understand the work of Sub-B, the proposals relate only to who/how
> the Registrant's Underlying Information may be accessed.

Yes.

>
>
> The concerns about OPOC from my perspective arise mostly when the OPOC
> is an unrelated third party (such as a proxy service, registrar, ISP)
> that does not control the domain's content or activities, because the
> publicly available WHOIS may not provide sufficient information to
> identify and locate the responsible party.

  I have the same concerns.  Additionally I feel it is nearly not
feasible to have any third parties whom are not law enforcement
have access to any registrants data as oversight of those designated,
licensed or contracted, whichever method is determined by
this WG sgb, proposed or desires third parties has broad international
legal implications and seemingly ICANN nor DOC/NTIA are able
or willing to take responsibility.  So whom will take such oversight
responsibility?  The GNSO council, the GAC, or maybe a special
oversight group?

  Further, even some law enforcement agencies which do not meet
the test of the USTR approval, ergo law enforcement agencies
whom are not on the USTR's 301 list, should not be granted
access to registrants Whois non public data.

>
>
> Paul also raises another point that may need to be evaluated--how proxy
> services would be affected.  Is it the intent that proxy/id protect
> services be eliminated or that proxy services would be continued as is?
> If proxy/id protect services continue, it does not appear that any of
> the tiered access proposals will address how to access the contact
> information of the customer behind the proxy services.

  I believe that their is some interest in the GAC to eliminate
proxy/id protect services.  This can be accomplished IMHO,
but only if a policy and practice of commensurate protection
can be arrived at by this sgb.

>
>
>
> Margie
>
> -----Original Message-----
> From: owner-gnso-whois-wg@xxxxxxxxx
> [mailto:owner-gnso-whois-wg@xxxxxxxxx] On Behalf Of Milton Mueller
> Sent: Tuesday, May 08, 2007 7:49 AM
> To: Paul Stahura; gnso-whois-wg@xxxxxxxxx
> Subject: Re: [gnso-whois-wg] Whois MAY/MUST with OPOC
>
> Paul:
> This is a very helpful clarification of the nature of the OPoC
> proposal. It should be required reading, because it is becoming evident
> that many of the people who have problems with the OPoC proposal simply
> do not understand it.
>
> >>> "Paul Stahura" <paul.stahura@xxxxxxxx> 5/8/2007 1:09 AM >>>
> The attached (in word format, and below) is my attempt at summarizing
> the OPOC proposal and trying to understand for myself where the
> sub-group work MAY fit in.
>
> I used a MAY/MUST format, like IETF (see RFC 2119 for more info)
>
> I tried to keep it short, it's under 2 pages.  Hope it's useful... it
> was for me.
>
>
>
> Whois MAY and MUST
>
> An OPOC interpretation & summary
>
> Paul Stahura, May 07 2007
>
>
>
> With OPOC:
>
> 1.      Registered name holders MUST provide a) registrant, b) admin
> and
> c) technical contact as they do today.  Each contact has a number of
> fields.
> 2.      Registrars MUST output whois information for Active names
> (names
> that resolve).
> 3.      The information which was input for the registrant contact, but
> only the name, the country, and the state/province (3 fields of the
> contact) MUST be output.
> 4.      Registered name holders MAY specify all of the registrant,
> admin
> and technical contacts as having the same contact information, as many
> registrants do today.
> 5.      The registered name holder MUST specify one of the registrant,
> admin, technical or some other contact, to display in the whois output
> as the OPOC contact.
>
>         a.      Each OPOC contact which is input MUST contain the
> following fields: name, address, telephone number, email address and
> some other not-so-controversial-fields (such as name servers, dates,
> and
> other fields that are automatically generated during registration).
> Each OPOC contact which is input MAY contain other fields.
>         b.      This first OPOC contact MUST be output by the
> registrar.
>
> 6.      The registrar MUST allow the registered name holder to input a
> second OPOC. The registered name holder MAY specify another OPOC
> contact
> (for a total of two).  If the registered name holder specifies this
> second OPOC, the registrar MUST output it.
> 7.      The registrar MAY allow the registered name holder to input
> additional OPOCs.  Each of these OPOCs MUST be output by the
> registrar.
> 8.      The registrar MAY collect additional contact or other
> information, such as a billing contact, but is not required to output
> them in the whois.
> 9.      Any other information the registrar chooses to output MAY be
> output in the whois, such as legal text, or reseller contact
> information, such information that many registrars output in the whois
> today.
> 10.     The input information for the registrant contact MUST be output
> as the OPOC (and obviously also in the 3-fields of the Registrant, so
> therefore all the fields in the output), if the registrant does not
> choose another contact to be displayed [DEBATE, the OPOC proposal is
> silent on what happens if registrants do not specify an OPOC]
> 11.     The Registrant contact (3 fields of it are shown in the output)
> and the OPOC (in other words, all the contact fields shown in the
> whois
> output) MAY be the same contact information, and MAY be the contact
> information of a Proxy/ID Protect service, the same as today.  The
> Proxy/ID Protect service is the registered name holder, though it is
> licensing the name to a third party.
>
>         a.      In this case, the Registered Name Holder MUST accept
> liability for harm caused by wrongful use of the name, unless it
> promptly discloses the identity of the licensee to a party providing
> the
> Registered Name Holder reasonable evidence of actionable harm.
>         b.      The Registered Name Holder MAY/MUST disclose the
> identity of the licensee to other parties.  [DEBATE Subject of
> Subgroup
> B: Determine how and which legitimate third parties may access
> registration data that is no longer available for unrestricted,
> public,
> query-based access.]
>
> 12.     The OPOC contact MUST/MAY have certain roles/responsibilities
> and requirements.
>
>         a.      [DEBATE Subject of Subgroup A Define the roles,
> responsibilities, and requirements of the contacts available for
> unrestricted public query-based access, and what happens if the
> responsibilities are not fulfilled]
>
> 13.     The registrar MAY/MUST NOT output certain information of the
> registered name holder, if the registered name holder is a natural
> person. [DEBATE, I honestly do not know how the work of Sub-C will be
> used; I took a stab at the above].
>
>         a.      [DEBATE Subject of Subgroup C: to determine whether and
> how a distinction could be made between the registration contact
> information published based on the nature of the registered name
> holder
> (for example, legal vs. natural persons) or its use of the domain name
> (for example, commercial versus non-commercial use). [I'm unsure how
> this distinction would be used in the whois output, I assume  it has
> something to do with local privacy laws]
>
>

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402
E-Mail jwkckid1@xxxxxxxxxxxxx
 Registered Email addr with the USPS
Contact Number: 214-244-4827