Draft WHOIS Implementation Report
 
23 January 2003
 
This document provides:
An assessment of whether a recommendation is implementable
Information on issues that will need to be considered during implementation
Suggested additional text to clarify or improve the existing recommendations
 
Organization of the Analysis
 
The analysis is mostly contained in two tables. In Table 1 contains an assessment of whether the WHOISTask Force recommendations that relate to Registrars or Registries are implementable, the relative cost of implementation, and the level of support from registrars.
 
Table 2 contains information on issues associated with the recommendations that will need to be considered during implementation, and also where appropriate additional or alternative text to strengthen or clarify the existing recommendation.
 
Table Abbreviations
 
# The number of the recommendation
Cost What is the cost impact if the recommendation is implemented? (high/medium/low/?)
Enf Is the recommendation enforceable if it is implemented? (yes/no/?)
Feas Can the recommendation reasonably be implemented from a process point of view? (yes/no/?)
Supp What is the anticipated level of support for the recommendation from registrars? (high/medium/low/?)
Tech Can the recommendation be reasonably implemented from a technical point of view? (yes/no/?)
 
N/A Not applicable
 
| TABLE 1 | 
 | |||||
| # | WHOIS Task Force Recommendation | Cost | Enf | Feas | Tech | Supp | 
| 1 | Existing Task Force Recommendation:   Registrars must require Registrants to review and validate all WHOIS data upon renewal of a registration. (effectively an extension of RAA clause 3.7.7.1 above) The specifics of required validation remain to be determined by this Task Force or another appropriate body. | Low | Yes | Yes, although terms such as validate need clarification – see suggested alternative text | Yes | Med | 
| 2 | When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should not be included in the zone file until accurate and verified contact information is available. The details of this procedure are under investigation in the Names Council's deletes task force. | Low | Yes | Yes – although accurate and verified needs clarification | Yes | High | 
| 3 | When registrars send inquiries to registrants regarding the accuracy of data under clause 3.7.8 of the RRA, they should require not only that registrants respond to inquiries within 15 days but that the response be accompanied by documentary proof of the accuracy of the "corrected" data submitted, and that a response lacking such documentation may be treated as a failure to respond. | Low | Yes | No – needs major changes | No | Low | 
| 4 | Registrars modify
  their bulk WHOIS access agreements to eliminate the use of data for marketing
  purposes.     The suggested
  revised section 3.3.6.3 is: “Registrar’s access
  agreement shall require the third party to agree not to use the data to
  allow, enable, or otherwise support any marketing activities, regardless
  of the medium used.  Such media
  include but are not limited to e-mail, telephone, facsimile, postal mail,
  SMS, and wireless alerts.” The suggested
  revised section 3.3.6.5 is: “Registrar's access agreement shall require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties. | Low | Yes | Yes | Yes | High | 
 
 
| Table
   2  Detailed implementation analysis | ||
| # | Current recommendation with suggested
   enhancements | Comments and issues | 
| 1 | Existing Task Force Recommendation  Registrars must require Registrants to review and validate all WHOIS data upon renewal of a registration. (effectively an extension of RAA clause 3.7.7.1 above) The specifics of required validation remain to be determined by this Task Force or another appropriate body. | This is implementable IF: - the registrar presents the
  WHOIS data to the registrant at time of renewal (via website, fax, or postal
  message) = REVIEW - the registrant is required to
  check that the data is still current, and if necessary update the information
  = VALIDATE   It is not feasible for the
  Registrar to validate the data (e.g make phone calls to registrant, ring post
  office to confirm address exists etc). 
  A registrar may optionally use various heuristic techniques to do some
  data validation (e.g check that a USA city existing within a particular USA
  state) but such techniques are not applicable uniformly across the
  globe.  In general it is in the
  registrars best interests to get accurate data as it increases the chance of
  a successful renewal, so there are commercial incentives here for clever
  registrars.   | 
| Suggested
  replacement text: Upon renewal of a domain name, a registrar must present to the Registrant the current WHOIS information, and remind the registrant that provision of false WHOIS information can be grounds for cancellation of their domain name registration. Registrants must review their WHOIS data, and make any corrections. | ||
| 2 |  Existing
  Recommendation: When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should not be included in the zone file until accurate and verified contact information is available. The details of this procedure are under investigation in the Names Council's deletes task force.   | .The principle is OK, however the details of “accurate and verified” need to be clarified as per the next recommendation. | 
| Suggested Replacement text: When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should not be included in the zone file until the registrant has provided updated WHOIS information to the registrar-of-record (in accordance with recommendation 3 below). The details of this procedure are under investigation in the Names Council's deletes task force. | ||
| 3 | Existing Recommendation: When registrars send inquiries to registrants regarding the accuracy of data under clause 3.7.8 of the RRA, they should require not only that registrants respond to inquiries within 15 days but that the response be accompanied by documentary proof of the accuracy of the "corrected" data submitted, and that a response lacking such documentation may be treated as a failure to respond. | This recommendation is NOT
  implementable in its current form.   The 15 day period is not
  feasible given the time taken for a request to actually reach the registrant
  (due to postal delays, or just the registrant being on holiday).  It should be extended to 30 days to take
  into account typical international delivery times (e.g it typically takes 15
  days for mail to reach Australia from USA) for postal mail.  Registrars normally have periods of at
  least 30 days for a registrant to respond to a renewal notice for
  example.  Often registrars will first
  attempt to contact a registrant via email, and if that bounces, use postal
  mail (which tends to stay accurate for longer).   Note that this recommendation
  should only be dealing with issues of accuracy.  If there are other issues associated with a domain name (such
  as its use in criminal activity) there should be other mechanisms available
  to have the domain name disabled or deleted. These other issues should be the
  subject of a separate issues report, and subject to the normal policy
  development process.   In terms of requiring
  documentary proof - other than just storing the documentary proof -
  registrars are not authentication agencies (they collect information and
  store it in a registry) - they do not have skilled staff capable of detecting
  whether a document is real or a forgery, nor could they be expected to have
  staff with knowledge of all types of documents across all countries.   The recommendation needs to
  identify a cost effective minimum implementation.   There are two components: - contact of the registrant - correction of information   Contacting the registrant is a
  common problem for registrars at the time of renewal, and various methods are
  used.  Most registrars use a final
  step of placing the name  in REGISTRAR
  HOLD status or equivalent (the name is locked and removed from the zonefile).   Below is a possible
  implementation:   IN RESPONSE TO A COMPLAINT ABOUT
  WHOIS DATA   A registrar may seek evidence or
  justification from the complainant as to why the data is inaccurate, and if
  the complaint appears to be justified then: -        
    First phase: CONTACT phase - registrar sends an email to
  all contact points available in the WHOIS (e.g registrant, admin, technical
  and billing) to request the information be corrected - if no response is received
  after 30 days the name should be placed in REGISTRAR-HOLD status (or
  equivalent) - the registrar can continue to
  try to contact the registrant using various other means, but normally the
  registrant of an active name will contact the registrar themselves - the name would remain in
  REGISTRAR-HOLD status until the contact information is updated, or the name
  is deleted from the registry for lack of renewal - this protects the registrant
  from any attempts at domain name hijacking   CORRECTION phase  -registrar must present to the
  Registrant the current WHOIS information, and remind the registrant that
  provision of false WHOIS information can be grounds for cancellation of their
  domain name registration.  Registrants
  must review their WHOIS data, and make any corrections -A registrar may use various
  heuristic techniques to do some data validation (e.g check that a USA city
  existing within a particular USA state) but such techniques are not
  applicable uniformly across the globe. 
   -  Further work should be done to
  develop a dispute resolution process, whereby a complainant can provide
  evidence of the data being incorrect, and the registrant can provide evidence
  of the data being correct.  The
  complainant would pay the costs of such dispute resolution consistent with
  the UDRP process.   In the recommended new text, point (e) is effectively a dispute resolution process. This may require further work to elaborate. | 
| Suggested Replacement text: (a)Upon receiving a complaint
  about WHOIS accuracy, a registrar may seek evidence or justification from the
  complainant.     (b) If the complaint appears
  justified, then a registrar must at a minimum send an email to all contact
  points available in the WHOIS (including registrant, admin, technical and
  billing) for that domain name with :  a copy of the current disputed WHOIS information and requesting
  the WHOIS contact information be updated if the information is incorrect,
  and.  a reminder that if the
  registrant provides false WHOIS information that this can be grounds for
  cancellation of their domain name registration. -  (c)  If no response is received after 30 days a Registrar must place
  a name in REGISTRAR-HOLD (or equivalent) status, until the registrant has
  updated the WHOIS information.    (d) A registrar must take
  commercially reasonable steps (e.g apply some  heuristic automated data validation techniques (possibly via an
  automated tool centrally provided by ICANN)) to check that the new WHOIS information  is plausible.   (e) If within 60 days of the
  contact information being updated, an ICANN accredited dispute resolution
  agency informs the Registrar that the data is still incorrect, then the name
  will be placed in REGISTRAR-HOLD status until the dispute is resolved .   | ||
| 4 | Registrars modify
  their bulk WHOIS access agreements to eliminate the use of data for marketing
  purposes.     The suggested
  revised section 3.3.6.3 is: “Registrar’s access
  agreement shall require the third party to agree not to use the data to
  allow, enable, or otherwise support any marketing activities, regardless
  of the medium used.  Such media
  include but are not limited to e-mail, telephone, facsimile, postal mail,
  SMS, and wireless alerts.” The suggested
  revised section 3.3.6.5 is: | There is a need to clarify the definition of “marketing purposes”. This may require a small working group to define, possibly just in the form of examples (but not limited to) of marketing activities covered.   e.g text such as: “includes but not limited to the sending of unsolicited, commercial advertising, or solicitation to entities other that the data recipient’s own existing customers”   or “any communication, regardless
  of the medium, initiated for the purpose of advertising availability or
  quality of any property, goods, or services, but such term does not include a
  communication (A) to any person with that person's prior express invitation
  or permission, (B) to any person with whom the party has an established
  business relationship.”     |