ICANN/DNSO
DNSO Mailling lists archives

[nc-whois]


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

[nc-whois] Accuracy: Summary of issues. (Mostly (A))


As a follow-up to my previous summary of the comments, here's my
personal list of open issues and possible ways to address these.
This is mostly based on the comments we have received via e-mail,
with a focus on short-term concerns and recommendations.  Naturally,
this document doesn't cover the supporting comments.  One caveat:
I'm concentrating on arguments on the merits of proposals, and
leaving out enforceability concerns.

I'm organizing this by the three sections of the interim report's
accuracy recommendations, i.e.: (A) enforcement of the existing
policy -- this is the bulk of this message; (B) graduated sanctions
program; (C) possible additional steps.  



Some objections apply throughout all parts of the interim
recommendations.  Of particular importance is the objection against
the interim report's approach of trying to treat thick registries
like registrars.  The objection is based on the observation that
registries (1) work with data supplied to them by registrars, (2)
generally don't have direct contractual relationships with
registrants, and (3) are generally expected not to interfere with
the contractual relationships between registrars and registrants.

Also, several comments have criticized the use of unclear terms
throughout the recommendations, such as "blatantly false" data,
possibly provided "wilfully".  The criticism is, in part, based on
the observation that these notions may be hard to discern in
practice, and would involve highly subjective judgment if applied.



(A) Enforcement of Current Policy.


The comments received on this section can mostly be split into two
categories: Comments on issues with the current policy (RAA,
3.7.7.1, 3.7.7.2), and comments on specific steps suggested to
enforce that policy.  The issues with the current policy are
particularly important if this policy is to be applied more broadly
and more regularly in the future.


Concerns with the current policy


There are several comments which ultimately ask for a clear
definition of what constitutes inaccurate WHOIS data, or point out
problems with certain definitions which are implicitly assumed:

- John D. Berryhill points to an example of usable (!) contact
  information which is considered inaccurate by some complainant
  according to an ad-hoc definition of accuracy.

- Michael Palage's personal comments and the gTLD registries'
  constituency's comments both identify a scenario in which
  recommendation A 4 (e) is applied to a case in which perfectly
  valid contact data is illegitimately assigned to a domain name,
  and leads to a cancellation of domain names.

In order to address the second of these concerns, it may be useful
to introduce a distinction between (1) contact data which are valid
addressing informations, but should not have been assigned to a
specific domain name, and (2) contact data which do not constitute
valid addressing informations.  A 4 (e) should - if at all - only
applied in case (2).

In fact, in case (1) damage may be caused directly by the
publication of contact data in the WHOIS.  There may be a reasonable
expectation that a registrar immediately removes contact data from
the whois system upon receipt of a case (1) complaint, in addition
to starting a data verification procedure.

One way to handle John Berryhill's concern may be to adopt a
functional definition of accurate or inaccurate data, which assumes
inaccuracy only when contact information turns out to be actually
unusable.


A further concern raised by John Berryhill is the common use of
"role accounts": The current policy seems to require that a natural
person is identified as a contact for domain names. However, a
common practice uses role indications (like "hostmaster") for WHOIS
data purposes.  This practice actually increases the functional
accuracy of WHOIS data, since it reduces the need for frequent 
updates due to (for instance) personnel fluctuations and changing
assignments within an organization.  

The policy should be modified to accomodate this practice.  This may
possibly be accomplished by using an appropriate form of the
"functional" accuracy definition suggested above.


Several comments warn that the deletion of a domain name when
accurate contact information is not provided in a timely manner may
be a too draconian sanction; there are several suggestions that
placing the domain name on hold may be a more appropriate approach.

Michael Palage suggests that the domain name should be put on hold
"indefinitely", but that transfers or renewals should only be
possible upon provision of accurate contact detail.  Assuming that
"indefinitely" means "for the remainder of the registration period",
this may be a reasonable and feasible approach.


Another recurring object of concern was the fifteen calendar day
period in RAA 3.7.7.2.  Reasons for the objections included the
possibility that registrants may be on vacation for two or more
weeks, and that postal mail (which may be the appropriate way to
make the inquiry) can easily take more than fifteen calendar days -
in particular if registrants from developing countries are involved.

The cure to these problems would be an extension of the time frame
the registrant is given for correcting inaccurate WHOIS data.


Concerns with enforcement mechanisms


Several commenters were concerned about the potential for abuse
which may be created by systematic enforcement of the current policy
(e.g., by the internic.net web form, by registrars publishing
contact points for WHOIS complaints, etc.).  Possible abuses would
include an attempt to consume the registrar's ressources by placing
a large number of frivolous accuracy complaints.  Likewise, the
registrant may be harassed.

Suggested approaches to make this kind of abuse at least somewhat
harder are to require that the complainant identifies itself
(Palage; gTLD registries), and possibly declares that he makes the
complaint in exercise of legal rights or duties (Palage).


The (numerous) comments on the merits of the suggested use of
automated systems for screening registrations concentrate on the
cost of implementing these systems (both financial, in terms of
system slow-downs, and in terms of side effects on bona fide
registrations caused by inaccuracies inevitably contained in these
systems), and on their anticipated effectiveness.  In order to make
these arguments and judgments in a more systematic way (and to be
able to come to a define effectiveness), it's helpful to
conceptually separate (as suggested in the comment from the
Intellectual Property Institute of Canada) measures which are
targeted at improving the overall quality of WHOIS data quality, and
corrective measures in specific cases of inaccurate data.  

Given the obvious possibilities for truly bad faith registrants to
game any address plausibility tests, automated plausibility checks
most likely fall into the first category.  Accordingly, overall data
accuracy is the appropriate possible benefit to look at when judging
the costs.


(B) Graduated Sanctions

The necessity of the proposed graduated sanctions recommendations
has generally been disputed, in particular given ICANN's recent
enforcement efforts against NSI registrar.

More specific objections were directed at the inclusion of resellers
and intermediaries in the programs - the concern is directed at the
enforceability of any sanctions, given that resellers generally do
not have a direct contractual relationship with ICANN.

Also, it has been questioned whether the suggestion to collect any
fines from funds deposited by the registrar with the registry is
feasible or even desirable.


(C) Additional Recommendations

Few comments seem to even address these recommendations; where this
happens, there is support for C1, but not for C2 and C3.


-- 
Thomas Roessler	(mobile)	<roessler-mobile@does-not-exist.net>


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