ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

[whois-sc] Draft 2 of Task force 3 terms of reference

  • To: <whois-sc@xxxxxxxxxxxxxx>
  • Subject: [whois-sc] Draft 2 of Task force 3 terms of reference
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 22 Oct 2003 18:28:44 +1000
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx
  • Thread-index: AcOYdoCz/+sakgC6Q76rKFIbu9wxHQ==
  • Thread-topic: Draft 2 of Task force 3 terms of reference

Hello All,

I have updated the terms of reference for task force 3 taking into
account the email comments from Steve Metalitz and the discussion over
the teleconference.  Attached is a red-line version, and there is a
plain text equivalent at the bottom of this message.

The major changes are:

- added consumer fraud as an example of a legal issue

- Added a reference to the OECD Guidelines for Consumer Protection in
the Context of Electronic Commerce.  Note as members of the committee
pointed out, WHOIS is of course not the only way such guidelines can be
met.  Ideally a business engaged in electronic commerce would meet such
guidelines based on their website alone.  I guess given that websites
often do not comply with these guidelines, some consumers use the WHOIS
to obtain information on the business.

- Clarified that the GNSO constituencies when viewed in the aggregate
rated accuracy as a top 5 issue

- Added other elements that MAY be verified  (noting however that over
time some of these elements may no longer be compulsory - for
consideration in area 2)

- added text to indicate that approaches other than the contact
information itself could be used to identify suspect registrants (e.g a
registration from an IP address associated with a country different to
the address provided by the registrant may signal a need for further
investigation).  I note that registrars often use a range of techniques
to prevent credit card fraud.  There is high correlation between names
that have been registered with fraudulent credit cards, and false
contact information.  Thus many potential registrations do not go
through today due to checking carried out by some registrars.    Best
practice documents in the area of credit card fraud may assist in the
area of improving accuracy - although there is some sensitivity in
publishing such information, as it helps some registrants avoid the best
practice controls.

- I have noted that the new policy mechanisms to improve accuracy need
to be evaluated

- I have clarified the text in the last action item to indicate that the
mechanisms to handle deliberate false information are the responsibility
of this task force and not some future policy development process.

Regards,
Bruce



Title: Improving Accuracy of collected data

Participants:
- 1 representative from each constituency
- ALAC liaison
- GAC liaison
- ccNSO liaison
- SECSAC liaison
- liaisons from other GNSO WHOIS task forces

Description of Task Force:
==========================

Data is collected from registrants at the time of registration to
facilitate future contact of the registrant for a range of reasons
including business issues (for example problems with payment), security
and stability issues (for example relating to fraudulent use of a domain
name, or failure of a nameserver associated with a domain name),
intellectual property infringement, and other legal issues (e.g use of a
domain name as part of [**INSERT a consumer fraud] or a criminal
activity).  Many users of the data perceive that there is an
unacceptable level of inaccuracy in the data that compromises its
ability to facilitate identifying and contacting registrants.

Data quality has been recognised as important by several groups.  For
example one of the OECD Privacy Guidelines (from:
http://cs3-hq.oecd.org/scripts/pwv3/pwhome.htm) states that: "Personal
data should be relevant to the purposes for which they are to be used,
and, to the extent necessary for those purposes, should be accurate,
complete and kept up-to-date"."    
[**INSERT  The OECD Guidelines for Consumer Protection in the Context of
Electronic Commerce (from:
http://www.oecd.org/dataoecd/5/34/1824782.pdf ) states that: "Businesses
engaged in electronic commerce with consumers should provide accurate,
clear and easily accessible information about themselves" and
"Businesses should not exploit the special characteristics of electronic
commerce to hide their true identity or location, or to avoid compliance
with consumer protection standards and/or enforcement mechanisms".]

The ICANN Security and Stability Committee (from:
http://www.icann.org/committees/security/whois-recommendation-01dec02.ht
m) stated that:
"It is essential that Whois data used to provide contact information for
the party responsible for an Internet resource is validated at the time
of a registrant's initial registration and on a regular basis
thereafter."

[**REPLACE Three WITH The] GNSO constituencies rated the issue of data
quality with respect to procedures currently followed by registrars to
promote accurate, complete and up-to-date data as one of their top 5
priority issues (see: [**INSERT
http://www.gnso.icann.org/issues/whois-privacy/table-whois-privacy-issue
.shtml,] and issue 6 in the WHOIS Privacy Issues Report at:
http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm
).

The main issues associated with data quality include:
- verification of data at the time of registration
- ongoing maintenance of data during the period of registration
- protecting against deliberate submission of false information

The types of contact data that may be verified for correctness include 
[**INSERT name (registrant, admin, technical and billing), domain name,]
postal address, email address, fax number, phone number, 
[**INSERT and other domain name related data.]  Verification software
can attempt to verify that a particular data element is correctly
formatted and exists.  Note however it is often difficult to obtain such
software that works on a global basis.  Another issue is ensuring that
the data is actually associated with the registrant (for example there
have been incidents of identity fraud, where the data is completely
verifiable but associated with another person).  Domain names are
provided purely electronically, and rarely involve delivery of a service
to a physical address, or delivery to a physical person.  This makes
[**INSERT automated ] verification more difficult.

The recent WHOIS policy development process created a new policy called
the WHOIS data reminder policy
(http://www.icann.org/registrars/wdrp.htm) that creates a process where
a registrant is reminded on an annual basis to update the WHOIS data.
There is also an established process whereby a user of the data may
lodge a complaint with a registrar to get the contact data corrected. If
the registrant does not correct the information, a registrar may cancel
the domain name licence.  (see clause 3.7.7.2 of the Registrar
Accreditation Agreement
http://www.icann.org/registrars/ra-agreement-17may01.htm).  The recent
WHOIS policy process also included a new policy to ensure that the
redemption grace period could not be used as a mechanism to avoid these
provisions (see Section 1B of
http://www.icann.org/registrars/ra-agreement-17may01.htm).

It is difficult to use verification or maintenance approaches for
registrants that deliberately provide false information.    The
high-cost mechanisms to verify contact information with a high degree of
uncertainty can be easily evaded by low-cost mechanisms at the disposal
of some registrants.  In such cases it may be necessary to collect
additional information associated with an online registration to aid in
contacting the registrant including credit card information, source IP
addresses, and website traffic logs, 
[**INSERT or use other approaches to identify registrations with
suspected false information.]  It also may be necessary to create
expedited procedures for responding to misuse of a domain name
associated with deliberately false information.

The purpose of this task force is to develop mechanisms to improve the
quality of contact data collected at the time of registration.


Out-of-scope
============
To ensure that the task force remains narrowly focussed to ensure that
its goal is reasonably achievable and within a reasonable time frame, it
is necessary to be clear on what is not in scope for the task force.

Given that [**REPLACE the previous GNSO WHOIS task force has WITH
previous ICANN policy changes
(http://www.icann.org/minutes/minutes-27mar03.htm) have] addressed
issues associated with maintaining accurate information (WHOIS data
reminder policy, and mechanisms for handling complaints about inaccurate
data), this will not be studied in this task force.  
[**INSERT The effectiveness of these mechanisms will need to be
evaluated by the ICANN staff and reported to the GNSO (for example 12
months after implementation of the policies).  Note not all the policy
changes agreed by the ICANN Board in March 2003 are implemented as of
October 2003.]

The task force should not consider issues associated with changing the
data elements that are collected.  This is the subject of a separate
task force.

The task force should not consider mechanisms for restricting the public
display for some data elements, which may lead to a reduction in the
provision of false information by those registrants seeking to protect
their privacy.  This is the subject of a separate task force.



Tasks/Milestones
================

- collect information on the current techniques that registrars use to
verify that the data collected is correct.  For example techniques to
detect typing errors by registrants intending to provide correct
information.  Survey approaches used by cctlds to verify that the
contact data collected is correct.

- collect information on techniques used by other online service
providers (where there is no physical contact with the registrant and no
physical delivery of goods or services) to verify that data collected is
correct.

- create a best practices document for improving data verification based
on the information collected that can be applied on a global basis

- determine whether any changes are required in the contracts to specify
what data verification is necessary at time of collection to improve
accuracy

- determine what verification mechanisms can be used cost effectively to
combat the deliberate provision of false information, and determine
whether 
[**REPLACE further policy development is WITH additional mechanisms are
]
necessary to provide traceability of registrants, or provide for more
timely responses for misuse of domain names associated with deliberately
false information.









Attachment: Draft2taskforce3.doc
Description: Draft2taskforce3.doc



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