ICANN ICANN Email List Archives

[gnso-acc-sgb]


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

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

  • To: <gnso-acc-sgb@xxxxxxxxx>
  • Subject: [gnso-acc-sgb] RE: [gnso-whois-wg] Whois MAY/MUST with OPOC
  • From: "Margie Milam" <Margie.Milam@xxxxxxxxxxxxxxx>
  • Date: Tue, 8 May 2007 16:17:57 -0600

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.

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

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.  

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.   
 

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]

 






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

Privacy Policy | Terms of Service | Cookies Policy