Hi Peter Many thanks for spotting these anomalies. With so many versions buzzing around, it has been a real challenge to keep hold of everything. I am grateful you spotted this. Alice- please can you amend. Kind regards Emily On 8 May 2012 05:42, Nettlefold, Peter <Peter.Nettlefold@dbcde.gov.au>wrote:
** **
Hello again all,****
** **
Thanks Emily for circulating this for final comment.****
** **
I have not had time yet to read it all, but did notice a couple of potential issues with the IDN text.****
** **
The first is that the final paragraph of the revised findings that we worked on appears to have been dropped from the report (I’ve attached the email chain on this for reference). This read:****
** **
These are difficult issues, and there is ongoing work within ICANN in this area (e.g. the joint gNSO and SSAC working group on Internationalised Registration Data – IRD WG). As the need is imminent, this work needs to proceed with priority in coordination with other relevant work beyond ICANN’s ambit, to make internationalised domain name registration data accessible.****
Also, recommendation 12 remains in its original form in this version. I offered some comments on this on 3 May, and I’m concerned that this recommendation remains unclear. The current text reads:****
** **
*12. *ICANN Community should task a working group within 6 months of publication to determine the relevant internationalized domain name registration data requirements and evaluate the available solutions, especially those being successfully implemented by ccTLDs, at least for the adoption of IDN gTLDs, as already stipulated by the New gTLD Applicant Guidebook.The working group should aim for consistency of approach across the gTLD and – on a voluntary basis – the ccTLD space, and report within a year of being tasked.****
My comments from the 3rd were:****
*12. *ICANN **[p1] <#1372ac1e1c8fe24b__msocom_1>** should task a working group within 6 months of publication to determine the relevant internationalized domain name registration data requirements and evaluate the available solutions. This should have particular regard to solutions **[p2] <#1372ac1e1c8fe24b__msocom_2>** being successfully implemented by ccTLDs, at least for the adoption of IDN gTLDs, as already stipulated by the New gTLD Applicant Guidebook**[p3]<#1372ac1e1c8fe24b__msocom_3> ** . The working group should aim for consistency of approach across the gTLD and – on a voluntary basis – the ccTLD space, and report within a year of being tasked.****
I’m still unclear on whether the intent is to recommend that the ‘solution’ be imposed on all IDN gTLDs and/or recommend consistency across the whole gTLD space?****
** **
I offer the below, based on my best guess of the current intent. I’m not trying to alter the intent, only to clarify what is being recommended, so look forward to any comments on this:****
** **
*12. *ICANN should task a working group within six months of publication of this report, to determine appropriate internationalized domain name registration data requirements and evaluate available solutions (including solutions being implemented by ccTLDs). At a minimum, the data requirements should apply to all new gTLDs, and the working group should consider ways to encourage consistency of approach across the gTLD and (on a voluntary basis) ccTLD space. The working group should report within a year of being tasked.****
I hope this helps.****
** **
Cheers,****
** **
Peter****
** **
** **
** **
*From:* rt4-whois-bounces@icann.org [mailto:rt4-whois-bounces@icann.org] *On Behalf Of *Emily Taylor *Sent:* Tuesday, 8 May 2012 12:10 AM *To:* Alice Jansen; rt4-whois@icann.org *Subject:* [Rt4-whois] FINAL edit of the draft report - to be published*** *
** **
Dear Alice, dear All****
** **
On our last call, you empowered me and Kathy to have a final, final edit, once the whole report was put together. I have spent much of today working through the whole report, and attach a mark up showing some minor changes that I recommend making. ****
** **
As predicted, the new text combined with the old has created a few anomalies. In addition, there are one or two places where I have made changes (eg where public comment suggested we should make clear that we're not advocating going behind PDPs or existing processes - we all agreed to this, but forgot to put it in). I have listed them all out below for maximum transparency and so that you can see what I've done at a glance. They are also marked up in the attached version. My approach through out has been minimalist, and to move existing text rather than amend it. Sometimes, I've had to create new words, but have stuck to areas where I know we all agree, rather than plunging into controversial areas.****
** **
Alice has also done things like make sure "WHOIS" is consistently capitalised throughout. She will also go through one more time and clear up anomalies in US and UK spelling. ****
** **
*The way forward: I am asking Alice to accept all these changes now, produce a content page, and have the report published.*****
** **
*IF YOU HAVE ANY FINAL COMMENTS (PARTICULARLY ON LATEST CHANGES) PLEASE LET ALICE AND ME KNOW AS SOON AS POSSIBLE.*****
** **
** **
Kind regards****
** **
Emily****
** **
*---------------*****
** **
** **
** **
** **
So, here is a run down of the changes that I have made:****
** **
*Executive Summary, Findings and Recommendations*****
** **
Page 5 - the new language on studies was there along with the original wording. We agreed to keep the original wording, and sort of liked the new language. Reading the Exec summary through again, I find they duplicated and so went back to the original wording. ****
** **
Page 5 - removed the title "Conclusions" which led into original text. This had been removed, then reinstated, and again reading it through the whole Exec Summary came across as a lot of conclusions, followed by findings etc. So, removing the title, includes much of the text as continuing the "Debate" point, where it originally was. I also moved the paragraph about "Consumer Trust" to the Findings section before Recommendations 3 where it works very well, and introduces the Consumer study into our findings (it wasn't there before, which I think was an omission).****
** **
Page 5 - moved the original wording describing the Review Team's diversity etc to the final paragraph of "Work of this Review Team" on the following page.****
** **
Page 7 - Removed the word "honest" (a hangover from my original, bad tempered draft, subsequently toned down and this was missed), and changed "and encourage the " to "encouraging" to fit with the language of the rest of the sentence in the findings to Strategic Priority (rec 1). I also put in a footnote describing the NORC study where first mentioned. It fits better to go into a full definition in the text on Data Accuracy findings (as is).****
** **
Page 7 - it's marked as me, but I picked up and included text edits proposed by Peter on the Exec Summary (eg "the" included in 5th bullet point on page 7)****
** **
Page 8 - Peter's text included in second paragraph of Findings to Rec 3, and paragraph moved from original exec summary on consumer study, with first sentence tweaked to keep the flow.****
** **
Page 10 - Susan's wording and footnote explaining definitions included in the findings on Data Accuracy (NORC study terms).****
** **
Page 11 - A section starting "Anecdotal evidence suggests..." is added into the para on WDRP to fit with the Findings and Recommendations at the end of the report (which included this text inserted from the original "Findings")****
** **
Page 12 - Added "in accordance with ICANN's existing processes" in the bit about WDRP to reflect feedback from public comment, which suggested that it reads like we're trying to bypass PDP.****
** **
Page 15 - the text for findings is new. It was agreed on the list a couple of days ago.****
** **
Page 16-17 - the order of the final two recommendations has been reversed as agreed, and consequential changes made.****
** **
*Main report*****
** **
Page 18 - in response to feedback that said it looked as if I was claiming to be Chair of the ccNSO, I have created a table for the membership of the Review Team, rather than the previous bullet point format.****
** **
Page 36 - new Chapter 4 - I have changed the reference to Findings and Recommendations (which were originally included in the chapter itself).*** *
** **
Page 37 - we need to add in the references to Appendix numbers when they are published, and also double-check that page numbers for the report itself are accurate.****
** **
Page 37 - date of letter to compliance team is added.****
** **
Page 41 - two "also"s removed. Appendix numbers need adding.****
** **
Page 42 - emphasis added to quotation about budget, and "emphasis added" is included in text.****
** **
Page 42 - dates changed, and additional text brings this passage up to date. Footnote added "considered narrowly" in the text.****
** **
*Gap Analysis*****
** **
We had not really revisited this in the light of our updated findings and recommendations. Mostly, it's still very good, but there were a couple of anomalies.****
** **
Page 75 - removed "Conclusions" as these are now incorporated into Findings with the recommendations. Full and Substantial Failure are included in keeping with our findings and recommendations on data accuracy ****
** **
Page 76 - included short paragraph on compliance budget/staffing which lays the foundations for the findings.****
** **
Page 78 - this passage on The Proxy Registration System reflected the state of play on publication of our draft report - ie that we were making separate recommendations for privacy and proxy providers, and two alternatives for "common interface". The situation has now changed. I have dealt with this by removing a few paragraphs that talk about us not reaching consensus, and being sceptical about whether our recommended "voluntary best practices for proxies" would work. Removed the reference to alternatives completely on "Common Interface". and added a few words to try and pull back the sense on how all this relies on a functioning compliance team to work out.****
** **
Finally, I went through the Findings and Recommendations as set out in the Exec Summary and at the end of the report. They should be identical, and as noted above I made a few changes for consistency (where one had changed but not the other).****
** **
** **
** **
** **
****
** **
--
****
* *
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.****
** ** ** ------------------------------ ** ** ******
**[p1] <#1372ac1e1c8fe24b__msoanchor_1>**PN – I assume we’re asking ‘ICANN’ to this? ** ** ** ******
**[p2] <#1372ac1e1c8fe24b__msoanchor_2>**PN – I have not tried to change the intent, only to break the sentence in two – as the sentence was very long, and risked being unclear. ** ** ** ******
**[p3] <#1372ac1e1c8fe24b__msoanchor_3>**PN – I’m not 100% clear on what is intended here by the phrase ‘at least for the adoption of IDN gTLDs’. Does this mean the solution should be adopted *by* all IDN gTLDs? If so, I don’t think it’s currently 100% clear. Also, how does this fit with the following sentence which talks about aiming for ‘consistency across the gTLD…space’? I may be missing something, but while I support the intent of this recommendation – it’s not 100% clear to me. ** **
* ------------------------------------------------------------------------------- * 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.
* ------------------------------------------------------------------------------- *
---------- Forwarded message ---------- From: "Sarmad Hussain" <sarmad.hussain@kics.edu.pk> To: "'Kathy Kleiman'" <kathy@kathykleiman.com>, "'Emily Taylor'" < emily@emilytaylor.eu> Cc: "rt4-whois@icann.org" <rt4-whois@icann.org> Date: Sat, 5 May 2012 02:34:33 +1000 Subject: Re: [Rt4-whois] Fwd: IDN - a few more changes to bring it up to the readability of the rest of the Summary [SEC=UNCLASSIFIED]
I am Ok with the revisions. ****
** **
Regards, Sarmad****
** **
** **
*From:* rt4-whois-bounces@icann.org [mailto:rt4-whois-bounces@icann.org] *On Behalf Of *Kathy Kleiman *Sent:* Friday, May 04, 2012 9:20 PM *To:* Emily Taylor *Cc:* rt4-whois@icann.org *Subject:* Re: [Rt4-whois] Fwd: IDN - a few more changes to bring it up to the readability of the rest of the Summary [SEC=UNCLASSIFIED]****
** **
I like it, tx Peter and Emily. However, I defer to our lead IDN drafters, Sarmad and Michael, for final approval.
What I like is that it helps makes the whole issue approachable -- and hopefully the rest of the Community will spend more time and attention on this issue in which a core of dedicated people have worked so hard and so well.
Best, Kathy
****
Thank you Peter ****
** **
I think this is a good synthesis. One extra element, which is easily forgotten, is that internationalised WHOIS data isn't just an IDN problem, but one which has been around ever since Chinese, Arabic and Russian speakers have been registering domain names. So, the delay in addressing this has not just been a year (since introduction of IDN.IDN) or a decade (IDN.tld), it's even longer than that.****
** **
So, I've added some language for this, based on the first paragraph of the IDN chapter (highlighted below).****
** **
Kind regards****
Emily****
On 4 May 2012 08:08, Nettlefold, Peter <Peter.Nettlefold@dbcde.gov.au> wrote:****
Hello again all,****
****
As I’ve said previously, I’m no expert in this area, but to hopefully help move this forward I have attempted to pick up what seemed to be the major themes from both sets of text.****
****
I hope this helps, and please feel free to edit or discard as needed.****
****
Cheers,****
****
Peter****
****
****
*Findings*****
****
Developments associated with the WHOIS protocol and registration data have not kept pace with the real world. A significant example of this is International Domain Names (IDNs). IDNs have been available for registration at the second level for over a decade, and were introduced in 2010 at the root level. However, these developments were not accompanied by corresponding changes related to WHOIS. In short, the current WHOIS protocol has no support for non-ASCII characters, and cannot signal a non-ASCII script.****
This means that while domain names can now be written in a range of scrips (such as Arabic and Cyrillic), the contact information must still be transliterated into a format ill-suited to the purpose. The NORC Study on Data Accuracy highlighted IDN contact data as a major cause of apparent inaccuracy. ****
** **
The failure to reflect internationalised registration data does not just affect IDNs, however, and has existed for much longer - ever since domain names have been registered by registrants globally. Global users need to represent their local names, postal addresses and other contact and technical information in the script(s) which they use. ****
****
These are difficult issues, and there is ongoing work within ICANN in this area (e.g. the joint gNSO and SSAC working group on Internationalised Registration Data – IRD WG). As the need is imminent, this work needs to proceed with priority in coordination with other relevant work beyond ICANN’s ambit, to make internationalised domain name registration data accessible. ****
****
*From:* rt4-whois-bounces@icann.org [mailto:rt4-whois-bounces@icann.org] *On Behalf Of *Kathy Kleiman *Sent:* Thursday, 3 May 2012 11:43 PM *To:* rt4-whois@icann.org *Subject:* [Rt4-whois] Fwd: IDN - a few more changes to bring it up to the readability of the rest of the Summary****
****
Dear All, I appreciate the evolution of the IDNs text (and see nice changes in the findings). Canwe go a bit further? I was wondering if we might take one more attempt to a) define IDNs (for the many readers who will have no idea), b) and define better the ambiguous term "this environment".
For smarter (and more awake) people than I am, do you see a way to merge the two texts below? I truly want to make sure that everyone understands the importance and timeliness of our recommendations!
Also, I saw that Peter has some ideas in this area, but did not propose wording changes (I don't think). Does some of the text below cover your thoughts?
Best and tx, Kathy
*Findings/Kathy: *[from the Executive Summary] Policy and implementation of the Whois protocol and registration data have not kept pace with the real world. International Domain Names (IDNs) were introduced to great fanfare by ICANN in 2000, and in 2010 at the root level, without a corresponding change to its policies related to WHOIS.
What this means, is that while domain names can now be written in Arabic for example, the contact information for these domains must still be transliterated into a format ill-suited to the purpose. [from the Public Forum Slides] These are difficult issues, and members of the ICANN Community have worked hard to date, but the current Whois protocol has no support for non-ASCII characters and cannot signal a non-ASCII script. Some ccTLD registries and registrars have implemented ad hoc solutions and arbitrary mappings of local scripts onto ASCII code points, and as a result, IDN Whois data today often appears as a nonsense sequence of ASCII characters.
*Findings/Sarmad *Perhaps it should be no surprise that within this environment [*Kathy: which environment?] *, policy and implementation have not kept pace with the real world. A significant example of this is Internationalised Domain Names (IDN), which have been available for registration at the second level for over a decade, and at the Top Level for more than a year. During this time, WHOIS policies were not amended to accommodate the obvious need to support non-ASCII character sets even though there was a recognition that Internationalisation is essential for the Internet’s development as a global resource. There is ongoing work within ICANN (e.g. joint gNSO and SSAC working group on Internationalised Registration Data – IRD WG) in this area. As the need is imminent, this work needs to proceed with priority in coordination with other relevant work outside the ICANN’s ambit (e.g. WIERDS initiative at IETF), to make internationalised domain name registration data accessible.
The NORC Study on Data Accuracy highlighted IDN contact data as a major cause of apparent inaccuracy. Having internationalized data will also address this source of inaccuracy.
[end]****
* ------------------------------------------------------------------------------- * 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.****
** **
** **
-- * * 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.