[Rt4-whois] Today's (tonight's) conference call with ICANN Staff [SEC=UNCLASSIFIED]

Kathy Kleiman kathy at kathykleiman.com
Thu Feb 23 12:38:25 UTC 2012


Hi All,
I'll share my views about the call, Peter, and hopefully, everyone else 
will chime in. I thought the questions ICANN Senior Staff asked were 
good. They were certainly well-versed, and we did no initial 
presentation, but jumped right into the recommendations. They seemed to 
be seeking clarification and understanding.

After several of the answers, they said they understood the issues and 
what we were seeking to achieve far better --- e.g., on the reduction of 
"on its face" invalid information in the Whois database.

I thought it was a good meeting.  Other thoughts?
Best,
kathy

:
>
> Hi all,
>
> I apologise that I wasn't able to join the call. Will a recording or 
> transcript of the call be made available?
>
> Cheers,
>
> Peter
>
> *From:*rt4-whois-bounces at icann.org 
> [mailto:rt4-whois-bounces at icann.org] *On Behalf Of *Denise Michel
> *Sent:* Thursday, 23 February 2012 6:22 AM
> *To:* rt4-whois at icann.org
> *Subject:* [Rt4-whois] Today's (tonight's) conference call with ICANN 
> Staff
>
> Dear Team members,
>
> Thank you, again, for participating in this conference call with ICANN 
> Staff.
>
> Below, and attached, is a summary of the Team's recommendations to 
> help facilitate our discussion.
>
>
> Regards,
> Denise
>
> Denise Michel
> ICANN
> Advisor to the President & CEO
> denise.michel at icann.org <mailto:denise.michel at icann.org>
> +1.408.429.3072 mobile
> +1.310.578.8632 direct
>
> *WHOIS Policy Review Team Draft Report Recommendations*
>
> *Single WHOIS Policy*
>
> 1) ICANN's WHOIS policy is poorly defined and decentralized; Team 
> recommends Board oversee creation and publication of a single WHOIS 
> policy document; include gTLD WHOIS policy in Registry & Registrar 
> contracts, GNSO consensus policies & procedures.
>
> *Policy Review -- WHOIS Data Reminder Policy (WDRP)*
>
> 2) Board should ensure that Compliance develops metrics to track 
> impact of annual data reminder notices to registrants, and that these 
> metrics be used to develop and publish performance targets to improve 
> data accuracy over time (if not feasible, develop & implement an 
> alternative policy).
>
> *Strategic Priority*
>
> 3) ICANN should make WHOIS a strategic priority, allocate sufficient 
> resources to ensure Compliance is fully resourced to take a proactive 
> regulatory role, encourage a culture of compliance; Board should 
> ensure a senior member of the executive team is responsible for 
> overseeing WHOIS compliance.
>
> *Outreach*
>
> 4) ICANN should ensure that WHOIS policy issues are accompanied by 
> cross-community outreach, including outreach to interested communities 
> outside of ICANN.
>
> *Data Accuracy*
>
> 5) ICANN should take appropriate measures to reduce the number of 
> unreachable WHOIS registrations (as defined by the 2010 NORC Data 
> Accuracy Study) by 50% within 12 months and by 50% again over the 
> following 12 months.
>
> 6) ICANN shall publish annually an accuracy report on measured 
> reduction in "unreachable WHOIS registrations."
>
> 7) ICANN should publish status reports (at least annually) (with 
> figures) on its progress towards achieving goals set out by the Team, 
> the first to be issued before next review.
>
> 8) ICANN should ensure that there is a clear, unambiguous and 
> enforceable chain of contractual agreements with Registries, 
> Registrars, and Registrants to require the provision and maintenance 
> of accurate WHOIS data; as part of this, ICANN should ensure that 
> clear, enforceable and graduated sanctions apply to Registries, 
> Registrars, Registrants that don't comply with WHOIS policies, 
> including de-registration and/or de-accreditation for serious or 
> serial non-compliance.
>
> 9) ICANN should ensure that requirements for accurate WHOIS data are 
> widely and pro-actively communicated to current and prospective 
> registrants, and should ensure that its Registrant Rights and 
> Responsibilities document is pro-actively, prominently circulated to 
> all new and renewing registrants.
>
> *Data Access -- Privacy Services*
>
> 10) ICANN should develop and manage a system of clear, consistent and 
> enforceable requirements for all privacy services consistent with 
> national laws, balancing between stakeholders with competing but 
> legitimate interests, including, at a minimum, privacy, law 
> enforcement and industry around LE.  These should include: WHOIS entry 
> must clearly label that this is a private registration; privacy 
> services must provide full contact details as required that are 
> available and responsive (see above); standardized relay and reveal 
> processes and timeframes; rules for the appropriate level of publicly 
> available information on the Registrant; maintenance of a dedicated 
> abuse point of contact for the privacy service provider; privacy 
> service provider shall conduct periodic due diligence checks.
>
> 11) ICANN should develop a graduated and enforceable series of 
> penalties for privacy service providers who violate the requirements, 
> with a clear path to de-accreditation for repeat, serial
>
> *Data Access - Proxy Services*
>
> 12) ICANN should facilitate the review of existing practices by 
> reaching out to proxy providers to create a discussion that sets out 
> current processes followed by these providers.
>
> 13) Registrars should be required to disclose to ICANN their 
> relationship with any Affiliated Retail proxy service provider.
>
> 14) ICANN should develop a set of voluntary best practice guidelines 
> for appropriate proxy services consistent with national laws, striking 
> a balance between stakeholders with competing but legitimate 
> interests, including, at a minimum, privacy, law enforcement and 
> industry around LE. Voluntary guidelines may include: proxy services 
> provide full contact details as required; publication by the proxy 
> service of its process for revealing and relaying information; 
> standardization of reveal/relay processes & timeframes, consistent 
> with national laws; maintenance of a dedicated abuse point of contact 
> for the proxy service provider; due diligence checks on licensee 
> contact information.
>
> 15) ICANN should encourage and incentivize registrars to interact with 
> the retail service providers that adopt the best practices.
>
> 16) The published WHOIS Policy should include an affirmative statement 
> that clarifies that a proxy means a relationship in which the 
> Registrant is acting on behalf of another; the WHOIS data is that of 
> the agent, and the agent alone obtains all rights and assumes all 
> responsibility for the domain name and its manner of use.
>
> *Data Access -- Common Interface*
>
> 17) To improve access to the WHOIS data of .COM & .NET gTLDs (the Thin 
> Registries), ICANN should set-up a dedicated, multilingual interface 
> website to provide thick WHOIS data for them. (An "Alternative for 
> public comment": to make WHOIS data more accessible for consumers, 
> ICANN should set-up a dedicated, multilingual interface website to 
> allow "unrestricted and public access to accurate and complete WHOIS 
> information" to provide thick WHOIS data for all gTLD domain names.
>
> *Internationalized Domain Names*
>
> 18) The ICANN Community should task a working group (WG) within 6 
> months of publication to finalize (i) encoding, (ii) modifications to 
> data model, and (iii) internationalized services, to give global 
> access to gather, store and make available internationalized 
> registration data.  Such WG should report no later than one year from 
> formation, using existing IDN encoding.  The WG should aim for 
> consistency of approach across gTLDs and -- on a voluntary basis -- 
> the ccTLD space.
>
> 19) The final data model and services should be incorporated and 
> reflected in Registrar and Registry agreements within 6 months of 
> adoption of the WG's recommendations by the ICANN Board.  If these 
> recommendations are not finalized in time for the next revision of 
> such agreements, explicit placeholders for this purpose should be put 
> in place in the agreements for the new gTLD program at this time, and 
> in the existing agreements when they come up for renewal (as is case 
> for adoption of consensus policies).
>
> 20) Requirements for registration data accuracy and availability in 
> local languages should be finalized (following initial work by IRD-WG 
> and similar efforts, especially if translation or transliteration of 
> data is stipulated) along with the efforts on internationalization of 
> registration data. Metrics should be defined to measure accuracy and 
> availability of data in local languages and (if needed) corresponding 
> data in ASCII, and compliance methods and targets should be explicitly 
> defined accordingly.
>
>
> *-------------------------------------------------------------------------------*
> NOTICE: This email message is for the sole use of the intended 
> recipient(s)
> and may contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and 
> destroy all
> copies of the original message.
>
> This message has been content scanned by the Axway MailGate.
> MailGate uses policy enforcement to scan for known viruses, spam, 
> undesirable content and malicious code. For more information on Axway 
> products please visit www.axway.com.
>
> *-------------------------------------------------------------------------------*
>
>
>
> _______________________________________________
> Rt4-whois mailing list
> Rt4-whois at icann.org
> https://mm.icann.org/mailman/listinfo/rt4-whois


-- 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/rt4-whois/attachments/20120223/fc4c456a/attachment.html 


More information about the Rt4-whois mailing list