[dow3tf] Further thoughts on the state of our Best Practices proposal

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

Further thoughts on re-organizing the document.

As I touched on in my last message, the current "best practices" 
proposal does not really defined "best practices" per se, rather it 
mixes "items that ICANN need to further consider" with "items that other 
task forces are better suited to deliberate" with "best practices".

I have taken Brian's latest document and broken it up explicitly into 
three separate statements - "Further Considerations" - i.e. items that 
the GNSO Council needs to consider further, "Refer to other TF" - i.e. 
items that are not within our scope or mandate for consideration and 
lastly, "Best Practices" - items which might fit the definition of "Best 
Practices" that I culled from the IETF here:


Definition of "Best Practices"

"a vehicle by which the community can define and ratify the community's 
best current thinking on a statement of principle or on what is believed 
to be the best way to perform some operations"


It may not be necessary to break the best practice down further by actor 
as I previously mentioned. Additionally, further work needs to be done 
to cull best practices from the constituency position statements. A 
cursory review this morning indicates that there is a lot of input from 
these documents that we could consider provided that they fit within the 
goals that we have yet to agree upon (mentioned earlier.)

I'm happy to answer questions about this on the call.

Further Considerations;

ICANN should work with all relevant parties to continue to create its 
ongoing compliance program to ensure that contractual parties are 
meeting the WHOIS-related provisions of the present agreements.  ICANN 
should devote additional resources to such a compliance program in order 
to provide adequate support. See 
http://gnso.icann.org/issues/whois-privacy/raa-whois-16dec03.shtml. 
ICANN should work with and assist registrars in developing, in 
consultation with other interested parties, and by a date certain, "best 
practices" concerning the "reasonable efforts" which should be 
undertaken by registrars to investigate reported inaccuracies in contact 
data (RAA Section 3.7.8).  See 
http://www.dnso.org/dnso/notes/20030219.WhoisTF-accuracy-and-bulkaccess.html. 


2)	In developing such a program, ICANN should consider:

a)    The resources assigned to manage this plan, including up front and 
careful consideration of the costs associated with implementing various 
recommendations for registrars and flexible options for registrars to 
implement the policies in a compliant manner;

b)    The specific elements of compliance that the internet community is 
primarily concerned with;

c)    development and implementation of a graduated scale of sanctions 
that can be applied against those who are not in compliance with their 
contractual  obligations or otherwise violating the contractual rights 
under these agreements;

d)    Measurement and reporting mechanisms that allow appropriate 
analysis of the effectiveness of this ongoing program including existing 
compliance assistance mechanisms such as ICANN's online Whois data 
inaccuracy reporting tools;

e)    Continued outreach to and education of affected stakeholders to 
ensure that existing requirements and obligations are understood and met 
and that new requirements are captured and appropriately dealt with. 
This effort should ensure that ICANN advisories related to this issue 
are specifically brought to the attention of newly accredited Registrars 
and that resources be made available to the Registrar community to 
ensure that the impact and scope of these obligations are apparent and 
understood.

f) Requiring that Informational  resources be provided  to new 
Registrants and brought to their attention via the registration 
agreement that all Registrants must agree to prior to the activation and 
renewal  of their gTLD registration, based on a model version of 
materials, so that no registrar gains a competitive advantage from 
differential treatment of this requirement;

g)    Ongoing development and promotion of gTLD Registry, Registrar and 
Registrant best practices that foster the accuracy of the Registrant 
data contained in the Whois database

	3)	Any Best Practices that are viewed as being mechanisms for improving 
data verification on a global basis should be developed by or under the 
direction of ICANN, soliciting the cooperation of responsible 
registrars, and disseminated to accredited registrars and other relevant 
parties as part of ICANN’s ongoing educational and compliance 
initiatives.  In such efforts, recognizing that technology/software may 
play a role in developing this solution, ICANN should rely on the 
competitive marketplace for the provision of relevant technology and 
should mandate only the outcome, not how the Registrar accomplishes the 
outcome.  ICANN should consider retaining an independent third party 
which could, on a confidential basis, gather the critical underlying 
data germane to assessing current data verification practices in the 
registrar and other relevant industries, as well as from selected 
ccTLDs. In addition, ICANN should consider the work of the IETF, 
including its work on the IRIS protocol being developed by the CRISP 
working group.

4)	Specific examination of registrar data collection and protection 
practices should be undertaken, including investigating all options for 
the identification and viability of possible A) automated  and manual 
verification processes that can be employed for identifying suspect 
domain name registrations containing plainly false or inaccurate data 
and for communicating such information to the domain name registrant; 
and b) readily available databases that could be used for or to assist 
in data verification, taking into account the wide variety of situations 
that exist from region to region.  The GNSO Council or other Appropriate 
body should participate in specific examination of registrar data 
collection and protection practices to ensure consideration of policy 
implications, including various data protection regulations that may 
affect certain jurisdictions in which registrars operate.

10)	ICANN staff should undertake a review of the current registrar 
contractual terms and determine whether they are adequate or need to be 
changed in order to encompass improved data accuracy standards and 
verification practices as a result of the current PDP.

Refer to other TF;

5)	ICANN should also consider including the last verified date" and 
"method of verification" as Whois data elements, as recommended by the 
Security and Stability Advisory Committee.  See  Whois Recommendation of 
the Security and Stability Advisory Committee, available at 
http://www.icann.org/committees/security/sac003.htm. (“Whois data must 
contain a "Last Verified Date" that reflects the last point in time at 
which the information was known to contain valid data. It must also 
contain a reference to the data verification process.”).

Proposed Best Practices

•	Identification and public disclosure of a designated contact point for 
receiving and acting upon reports of false Whois data;

o	Plans to work with ICANN to train employees and agents regarding the 
Whois data accuracy requirements;

o	Taking reasonable steps to screen submitted contact data for falsity, 
including use of automated screening mechanisms, manual checking, 
spot-checking, and other verification techniques for submitted data;

•	Steps to correct false data in all registrations that are 
substantially identical to that in the initially false registration that 
has come to the registrar’s attention;

o	Steps to improve the accuracy of contact data submitted to it through 
re-sellers or other agents

o	Measurements for improving performance of the quality of the 
registrar’s Whois data

7)	ICANN should require domain name registrants to update and correct 
Whois data on an annual basis including, for example, clear instructions 
to domain name registrants of this obligation and special email 
addresses for expedited and priority handling of such updates.

8)	ICANN should consider requiring Registrars to verify at least two of 
the following three data elements provided by domain name registrants – 
phone, facsimile and email – and ensure that these elements function and 
that the Registrar receives a reply from these means of communication. 
Where none of the three data elements works, than the domain name should 
immediately be placed on hold.  If only one of the means of 
communication works, then the domain name shall be placed on hold for a 
period of 15 days in which the domain name registrant shall correct all 
of the WHOIS data elements.  If the domain name registrant fails to 
correct all of the WHOIS data elements during that time frame, the 
domain name registration shall be cancelled.

9)	Where a domain name registration is cancelled due to the 
non-functionality of WHOIS data elements – phone, facsimile, and email – 
the domain name can be reconnected for a fee to be set by the registrar. 
 Upon reconnection of any domain name in circumstances where the domain 
name had been placed on hold or was immediately cancelled, the Registrar 
shall verify all data elements before reconnecting the domain name.  The 
Registrar should ensure that the reconnection charge it imposes is 
sufficient to cover the costs of the heightened verification it must 
perform in reconnecting a previously cancelled domain.

--

                       -rwr








                "Don't be too timid and squeamish about your actions.
                                           All life is an experiment.
                            The more experiments you make the better."
                        - Ralph Waldo Emerson

Got Blog? http://www.blogware.com
My Blogware: http://www.byte.org