[dow3tf] Concerns and comments regarding IPC Proposal

["Ross Wm. Rader" <ross@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Note: These comments pertain to the proposal indicated here:
http://gnso.icann.org/mailing-lists/archives/dow3tf/msg00300.html]

In addition to the comments raised here on the task force mailing list,
I have several concerns with the IPC proposal that I would like to
discuss further with the task force before I table this proposal with my
constituency for more formal consideration. These concerns enumerated here.

I have also included a revised proposal that takes these comments into
account following this outline of our concerns.

General outline of registrar concerns;

Regarding Section I.A.1

** Registrars are not required to collect facsimile contact data from
registrants. Therefore, we propose that this clause be amended to remove
the requirement to check the accuracy of facsimile contact data and
lower the requirement to check two data elements to one.

Regarding Section I.A.2

** Email messages may bounce for any number of technical reasons and
should not be relied on to verify contact information except in very
specific circumstances. Therefore we propose that this clause be amended
so that _only_ a "permanent failure to deliver" notice from the remote
email server be considered as a suitable indicator of the
"contactability" of a registrant.

** This section also refers to facsimile data. We propose that it is
also removed.

** This section refers to a second contact type being verified. We
propose that this be removed in order to ensure consistency with the
amendments we propose for section I.A.1.

** This section provides a registrar with the discretionary ability to
place a domain name on hold without further attempting to contact a
registrant in the event that the registrar deems that the registrant has
wilfully provided inaccurate contact data. A refusal to act when it has
knowledge of actual damage creates potential liabilities for registrars
that we are unable to sufficiently mitigate under the terms of this
policy proposal. We therefore request that this segment of the proposal
be removed.

Section I.B

** This section requires a registrar to verify updated contact
information and all other associated data elements if a registrant
provides the registrar with updated contact information pursuant to a
complaint about the accuracy of the registrant contact data. This is an
expensive requirement that goes beyond ensuring "basic contactibilty" as
~  specified by the IPC. It is not clear that the expense of this measure
is justified, nor has the IPC presented any justification supporting the
desirability of this costly condition. Accordingly, we propose that this
clause be amended to require a registrar to verify the accuracy of
updated contact data provided to them by a registrant pursuant to a
complaint, but not be extended to include a requirement to verify all
contact data associated with the updated record.

Section I.C

** This section requires Registrars to proactively publicise an ICANN
implemented policy based on the notion that the WDPRS does not have
sufficient profile to ensure that third parties are aware that it
exists. A compelling case has not been made supporting the notion that
the Registrar community be made responsible for popularizing these
policies. We therefore propose that this section be removed from the
proposal and that ICANN undertake to publicise the WDRPS and any
relevant policies in a manner consistent with prior policy
implementations. We also note that forward thinking registrars will
likely include a notice of this sort in their whois output, or otherwise
provide third parties with specific instructions regarding the proper
useage of the WDPRS, but we are reticent to agree to any precedent
mandating behaviors specific to this purpose.

Revised version of the IPC proposal;

I. Steps to Verify & Correct Inaccuracy in Response to a Complaint

A.

	1.  If a registrar receives a complaint about the accuracy of
registrant data through the Whois Data Problems Reporting System, that
registrar shall take reasonable steps to verify the accuracy of that
data by contacting the registrant through at least one of the following
three methods: 1) email; 2) telephone number; or 3) postal mail.

	2. If one method fails (e.g., a permanent email delivery failure
message is returned to the registrar in response to a verification
request; the telephone number has been disconnected; or the postal
service is unable to deliver the message to the Registrant's address),
the domain name may be placed immediately on hold; or, another method
shall be used.  If a pursued method does not fail, registrar must allow
the registrant 15 days to respond with accurate information.

B.

	1. If a registrant responds to registrar notifications of inaccuracy
within the 15 day time limit, providing updated data, registrar shall
verify the accuracy of the updated data element(s).

	Verification may consist of the registrar using the updated data to
effectively contact the registrant, confirming the registrant's
correction of its contact data or by requesting that the registrant
provide the registrar with "proof of authenticity" of the contact
information (e.g., a photocopy of a driver's license or a utility bill).
If the updated element(s) remains inaccurate or cannot be verified,
registrar shall place the domain name on hold.


- --




~                       -rwr



Contact info: http://www.blogware.com/profiles/ross
Skydasher: A great way to start your day
My weblog: http://www.byte.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)

iD8DBQFBkSWY6sL06XjirooRAiT4AJ9z8KoGayrwzE+nSsWFFj7MPBlRaACfQvGg
rl+gkylt9lnRGfkng5S4uWc=
=I2mL
-----END PGP SIGNATURE-----