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@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.
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@icann.org [mailto:rt4-whois-bounces@icann.org] On Behalf Of Denise Michel Sent: Thursday, 23 February 2012 6:22 AM To: rt4-whois@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@icann.org<mailto:denise.michel@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. -------------------------------------------------------------------------------
Hi Peter Unfortunately, the call was not recorded, but I asked Alice to keep a full note, and she will circulate that as soon as possible. We had a very good discussion on the draft recommendations. Kind regards Emily On 23 February 2012 05:04, Nettlefold, Peter <Peter.Nettlefold@dbcde.gov.au>wrote:
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@icann.org [mailto:rt4-whois-bounces@icann.org] *On Behalf Of *Denise Michel *Sent:* Thursday, 23 February 2012 6:22 AM *To:* rt4-whois@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@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@icann.org https://mm.icann.org/mailman/listinfo/rt4-whois
-- * * 76 Temple Road, Oxford OX4 2EZ UK t: +44 (0)1865 582 811 • m: +44 (0)7540 049 322 emily@emilytaylor.eu *www.etlaw.co.uk* Emily Taylor Consultancy Limited is a company registered in England and Wales No. 7630471. VAT No. 114487713.
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@icann.org [mailto:rt4-whois-bounces@icann.org] *On Behalf Of *Denise Michel *Sent:* Thursday, 23 February 2012 6:22 AM *To:* rt4-whois@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@icann.org <mailto:denise.michel@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@icann.org https://mm.icann.org/mailman/listinfo/rt4-whois
--
I thought it was a good, and instructive meeting as well. I agree they were looking for clarification on our recommendations, and that means they had read and discussed them - all good. I also want to acknowledge James' suggestion that all of our recommendations be consensus recommendations. Our ability to stand as a group is quite important and was quietly demonstrated yesterday. Lastly, looking forward, it will be important for some, or all of us, to remain engaged as our recommendations are debated, accepted, and implemented. That too became clear yesterday. On Feb 23, 2012, at 7:38 AM, Kathy Kleiman wrote: 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@icann.org<mailto:rt4-whois-bounces@icann.org> [mailto:rt4-whois-bounces@icann.org] On Behalf Of Denise Michel Sent: Thursday, 23 February 2012 6:22 AM To: rt4-whois@icann.org<mailto:rt4-whois@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@icann.org<mailto:denise.michel@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<http://www.axway.com/>. ------------------------------------------------------------------------------- _______________________________________________ Rt4-whois mailing list Rt4-whois@icann.org<mailto:Rt4-whois@icann.org> https://mm.icann.org/mailman/listinfo/rt4-whois -- _______________________________________________ Rt4-whois mailing list Rt4-whois@icann.org<mailto:Rt4-whois@icann.org> https://mm.icann.org/mailman/listinfo/rt4-whois
My apologies too, I was out of office travelling. Denise, thanks for the summary. Omar 2012/2/23 Nettlefold, Peter <Peter.Nettlefold@dbcde.gov.au>
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
participants (6)
-
Denise Michel -
Emily Taylor -
Kathy Kleiman -
Nettlefold, Peter -
Omar Kaminski -
Smith, Bill