[gnso-whois-wg] RE: Draft outcomes report v 1.6

["Patrick Jones" <patrick.jones@xxxxxxxxx>]

I sent the email below to Philip last Thursday but thought it might help
generate discussion on the Draft Outcomes Report by forwarding to the full
WG. This email should not be considered Staff Implementation Notes.

 

Patrick

 

 

Patrick L. Jones

Registry Liaison Manager

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

Tel: +1 310 301 3861

Fax: +1 310 823 8649

patrick.jones@xxxxxxxxx 

 

 

  _____  

From: Patrick Jones [mailto:patrick.jones@xxxxxxxxx] 
Sent: Thursday, August 02, 2007 10:21 AM
To: 'Philip Sheppard'
Cc: 'Liz Gasster'; 'Denise Michel'; 'Daniel Halloran'
Subject: RE: [gnso-whois-wg] Draft outcomes report v 1.6

 

Philip,

 

I had originally provided Maria (on 27 July) some observations of
implementation issues in Version 1.5 of the Draft Outcomes Report. I have
reviewed Version 1.6 posted today and include my updated observations below,
which should not be considered Staff Implementation Notes to the Whois WG
Report.

 

Section 2.2 states that it is agreed that "There will need to be a change to
both the Registrar Accreditation Agreement (RAA) and subsequently
Registrar-Registrant's agreements to reflect this [OPoC] relationship." 

 

As an implementation detail, this section may require updates to the fields
of data in the public display of Whois information currently described in
the registry agreements.

 

Section 2.3 - the text in the third bullet reads that "verification of an
OPoC's active email address at the time of registration must be obtained
before enabling a web site to resolve based on the registered name." What if
a domain name is not used for a website, but for email only, or for some
other non-website related purpose? My impression is that this step could
require registrars to implement a new system and may change the registration
process. It would be useful to have more information from the Registrar
Constituency or registry community as a whole before this idea is considered
further.

 

Section 2.4 - This may be a cumbersome step to implement for registrars,
particularly if the OPOC is a third party (not the registrant or registrar).
Again, it would be useful to have opinions from the registrars on how
practical this step is. Perhaps consent can be accomplished via a check-box
during the registration process. This suggestion may only work if the
registrant or the registrar is the OPoC, not a third party. An option may be
to have the registrant select from a list of available OPoCs that have
already consented with the registrar to be an OPoC. This suggestion may not
be practical or scalable, but I raise it as an idea.

 

Could a registrar elect not to offer OPoCs (or third party OPoCs)? As a way
around the costs of verification and confirmation, a registrar could require
a registrant to only select the registrant itself or the registrar as the
OPoC, or only allow the registrant itself to be displayed.

 

Section 2.5 - The ICANN Consultation on RAA Amendments (posted on 27 July
2007), http://www.icann.org/topics/raa/, includes a link to discussion
material from San Juan on data escrow of proxy registration information (see
Private Registrations and Registrar Data Escrow Requirements,
http://sanjuan2007.icann.org/files/sanjuan/RDEPrivacy.pdf). This may be
useful to the discussion in 2.5.

 

Section 2.6 - Most gTLD registries are required to display admin, technical
and billing contacts for a registered name, but registrars are only
obligated in the RAA to display the admin and technical contacts. Should
this difference be reconciled? If OPoC is implemented, there is probably not
a need to display the Admin and Billing Contacts. 

 

EPP (Extensible Provisioning Protocol, the XML protocol used by registries
and registrars in the collection and storage of registration data) provides
for a disclosure information flag to select by type the amount of
information to be returned in a query. See RFC 4933
(ftp://ftp.rfc-editor.org/in-notes/rfc4933.txt). RFC 4933 obsoletes RFC
3733, which appears in current gTLD registry agreements. The following
information may be useful for the Whois Working Group (see Section 2.9 of
RFC 4933):

 

"The EPP core protocol requires a server operator to announce data
collection policies to clients; see Section 2.4 of [RFC4930].  In
conjunction with this disclosure requirement, this mapping includes data
elements that allow a client to identify elements that require exceptional
server operator handling to allow or restrict disclosure to third parties.
 
 A server operator announces a default disclosure policy when establishing a
session with a client.  When an object is created or updated, the client can
specify contact attributes that require exceptional disclosure handling
using an OPTIONAL <contact:disclose> element.  Once set, disclosure
preferences can be reviewed using a contact information query.  A server
operator MUST reject any transaction that requests disclosure practices that
do not conform to the announced data collection policy with a 2308 error
response code.
 
If present, the <contact:disclose> element MUST contain a "flag" attribute.
The "flag" attribute contains an XML Schema Boolean value.  A value of
"true" or "1" (one) notes a client preference to allow disclosure of the
specified elements as an exception to the stated data collection policy.  A
value of "false" or "0" (zero) notes a client preference to not allow
disclosure of the specifies (sp) elements as an exception to the stated data
collection policy."
 
Two gTLD registry agreements currently provide for the separation of short
and full format of data in the public display of Whois information, .CAT and
.TEL. The agreements cite to RFC 3733 (obsoleted by RFC 4933 in May 2007),
which includes the use of the disclosure information flag in EPP. The short
format is intended to be displayed when a registrant (presumably an
individual, but this could be used for natural persons) elects during the
registration process to only display the short format in public Whois. 

 

I have not seen discussion of the disclosure information flag within the
Working Group as an option for dealing with natural persons vs legal
persons, but it is worth exploring.

 

Section 3.2 Reveal Function

 

What if the reveal function was offered at the registry level, by agreement
that must be executed between the requester and the registry? Registrants
would have to consent in the registration process that a registry may reveal
full contact information provided certain contractual conditions are met.
The registrar could do this by contact as well. I encourage the Working
Group to review the public Whois language in the .NAME Registry Agreement
(http://www.icann.org/tlds/agreements/name/registry-agmt-appo-8aug03.htm),
which provides an Extensive Whois option for requesters that obtain a
password from the registry. In order to obtain a password, a requester must
represent that:

*       The password will be used exclusively in accordance with the terms
and conditions set forth in the agreement;
*       All Whois searches are, and will be, conducted only for the purpose
specified;
*       Requestor will not share the password with any individual or entity
that is not bound by the Extensive Agreement;
*       Requestor acknowledges liability for damages suffered by Registry
Operator as a result of any violation of the Extensive Agreement by
requestor, any authorized user of the password, or any other individual or
entity to whom the requestor or its Authorized Individual Users have shared
the Password and/or the Data; and
*       Except as necessary to accomplish the specified, legitimate purpose,
requestor will not share information derived from .name Whois with any
individual or entity that is not bound by the Extensive Agreement.

In accepting the Extensive Agreement, a requestor is required to represent
that the password will be used only for:

*       Address resolution and/or other Internet technical management;
*       Enforcement of legal rights, not including marketing;
*       Law enforcement/national security;
*       Consumer protection;
*       Crime and/or fraud detection and/or prevention;
*       Authorized transfer of domain name registration to a new registrar;
*       Authorized transfer of domain name to a new registrant;
*       Journalism; or
*       Other specified lawful purposes.

Section 3.3 Remedy Function

 

While Version 1.6 is an improvement on 1.5, the Draft Outcomes Report does
not clearly describe the purpose of the Remedy function. Because the
description of the Remedy function is not clear, it is difficult to envision
implementation options. The report now states that "Implementation is
required outside of the scope of WHOIS services." I am not clear on how this
function is to be implemented in registry and registrar agreements, if at
all.

 

Section 5 Type of Registrant and Display Implications

 

As mentioned Section 2.6 above, EPP provides a disclosure flag to
distinguish between the types of data displayed in a Whois record. This
separation is an option for handling the distinction between data displayed
for natural persons vs. legal persons. The Working Group should discuss this
- as far as I can tell, this has not been raised in WG discussions. Two
registry agreements (.CAT and .TEL) already provide for separation of short
and full format of data for the public display of Whois information. The
.NAME Registry Agreement provides for different levels of Whois information
to be displayed, depending on whether the query is for Summary, Standard,
Detailed or Extensive Whois data.

 

The report would benefit from more information on the distinction between
legal and natural persons.

 

Changes to the display implications may have to be reflected in altered
terms in the gTLD registry agreements.

 

Section 6 Access

 

The section presumes that registrars may only provide full access to
registrant data, but registries could provide this data by agreement with a
requester. .NAME has such a process in place. See
http://www.icann.org/tlds/agreements/name/registry-agmt-appo-8aug03.htm.
This is an option, and should at least be discussed by the Working Group.

 

Section 6.6 Authentication:

 

The .NAME Agreement contains language on authentication for obtaining access
to Extensive Whois data: "Registry Operator may implement a program for
streamlining the contracting process by enabling authenticated organizations
(e.g. the International Trademark Association, etc.) to act for Registry
Operator in authenticating and entering enforceable contracts with their
members."

 

If you would like further information or clarification on any of the
observations raised in this email, please let me know.

 

Patrick

 

Patrick L. Jones

Registry Liaison Manager

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

Tel: +1 310 301 3861

Fax: +1 310 823 8649

patrick.jones@xxxxxxxxx 

 

 

-----Original Message-----
From: owner-gnso-whois-wg@xxxxxxxxx [mailto:owner-gnso-whois-wg@xxxxxxxxx]
On Behalf Of Philip Sheppard
Sent: Thursday, August 02, 2007 5:42 AM
To: gnso-whois-wg@xxxxxxxxx
Subject: [gnso-whois-wg] Draft outcomes report v 1.6

 

 

Please find attached the outcomes report version 1.6.

 

This I hope captures the last two weeks of discussion on list and on our two
calls.

Changes compared to v1.5 are:

- new and clarified text;

- revised levels of support;

- revised section 7 (with text transferred from section 2);

- new section 8 (further studies).

(I considered issuing a red-line tracked version but there have been too
many changes to

make this a useful tool.)

 

I would like to call a halt to changes of substance on the issues: these we
have well

covered.

I would like to invite any comments where you feel any opinion on the
substance is NOT yet

recorded.

Please do NOT repeat earlier opinion: that will just make life more
challenging to weed out

duplication.

Please do WITHDRAW earlier statements of disagreement if you now believe the
revised text is

something that you can support.

 

Comments are open for one week until mid-day Thursday 9 August.

 

After that we will issue version 1.7 which will factor in any changes (as
above) along with

factual and contextual additions from ICANN staff.

 

I will advise later how long version 1.7 will be up for comment before
completion of the

group's work.

Many thanks.

 

Philip Sheppard

Chairman