February 2006 - council - lists.icann.org

2a.
by Ross Rader Feb. 16, 2006

Feb. 16, 2006

2a. Examine whether consensus policy limitations in registry agreements are appropriate and how these limitations should be determined.

1 0

1c/1d
by Ross Rader Feb. 16, 2006

Feb. 16, 2006

Proposal: Merge 1c and 1d to read: 1c. Recognizing that not all registry agreements share the same Rights of Renewal, use the findings from above to determine whether or not these conditions should be standardized across all agreements.

1 0

1b.
by Ross Rader Feb. 16, 2006

Feb. 16, 2006

1b. Examine whether or not the term, expiry and cancellation conditions, and rebid considerations (“Rights of Renewal”) provide benefits to the ICANN community and if so, what they are, including whether such conditions encourage investment in registry operations.

1 0

changes to the draft PDP for discussion today
by Marilyn Cade Feb. 16, 2006

Feb. 16, 2006

This may be a duplicate; not sure that Glen has been able to post for me/ :"connectivity challenged" MSC. _____ From: Marilyn Cade [mailto:marilynscade@hotmail.com] Sent: Thursday, February 16, 2006 11:51 AM To: 'Marilyn Cade'; 'Glen van Oudenhove de Saint Gery' Subject: glen, can you post for me TO COUNCIL? Dear fellow councilors I have done a marked up version of the draft PDP. Thanks to whomever did the initial drafting - I suspect Olof and perhaps Bruce? Apologies for having my comments late, but since we are walking through the PDP today, I'd like to discuss the changes and of course, changes contributed by other councilors. The changes aren't really as substantial as they look, so please no panic over the red line, just read the substance. We can easily get through this on the call. Others may have changes as well, and if possible, perhaps can provide their suggestions via email as well, to the list. I also added in a bit more on the factual explanation of the sequence related to the two agreements, and that also .museum and .aero [did I capture all of the additional gTLDs] are open for public comment. I'll leave it to the policy staff to check the facts on that segment of the draft PDP. :-) I'm at the IGF, with limited electrical power and sporadic wireless so have a little challenge.. but I'm sure that our staff can easily check just the facts in the introductory paragraphs. :-) Best regards from Geneva!

1 0

[Fwd: Revised draft GNSO Council minutes 17 January 2006]
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 16, 2006

Feb. 16, 2006

[To: council[at]gnso.icann.org] Dear Council members, Please find the draft GNSO Council minutes of 17 January with 2 revisions: 1. The reason for the 8 council members not voting has been added for the record. 2. As well as this clarification: "Bruce Tonkin clarified the difference between a process and the outcomes of that process. In the existing dotCOM agreement a date of November 2006 was included. There was a specified process by which by certain dates, renewal proposals were required to be created and that the community was not advised about changing this process. The concern arose because the dotCOM draft agreement was posted 4 weeks before the window opened on the dotCOM renewal process and responses were required in less time than the original process would have permitted. " Thank you very much. Kind regards, Glen 17 January 2006 Proposed agenda and related documents List of attendees: Philip Sheppard - Commercial & Business Users C. Marilyn Cade - Commercial & Business Users C. Grant Forsyth - Commercial & Business Users C Greg Ruth - ISCPC - absent - apologies - proxy Tony Holmes Antonio Harris - ISCPC - absent - apologies - proxy Tony Holmes Tony Holmes - ISCPC Thomas Keller- Registrars Ross Rader - Registrars Bruce Tonkin - Registrars Ken Stubbs - gTLD registries June Seo - gTLD registries - absent Cary Karp - gTLD registries Lucy Nichols - Intellectual Property Interests C Ute Decker - Intellectual Property Interests C Kiyoshi Tsuru - Intellectual Property Interests C. - absent Robin Gross - NCUC. Norbert Klein - NCUC. - absent Mawaki Chango - NCUC Sophia Bekele - Nominating Committee appointee Maureen Cubberley - Nominating Committee appointee Avri Doria - Nominating Committee appointee 16 Council Members ICANN Staff Olof Nordling - Manager, Policy Development Coordination Maria Farrell - ICANN GNSO Policy Support Officer Liz Williams - Senior Policy Counselor Tina Dam - Chief gTLD Registry Liaison Glen de Saint Géry - GNSO Secretariat Invited Guests John C. Klensin Patrik Fältström GNSO Council Liaisons Suzanne Sene - GAC Liaison Bret Fausett - ALAC Liaison Michael Palage - ICANN Board member Quorum present at 19 :10 UTC. MP3 Recording Bruce Tonkin chaired this teleconference. Approval of the agenda Item 1: Approval of minutes - GNSO Council Vancouver meeting minutes 28 November 2005 - GNSO Council Vancouver meeting minutes 2 December 2005 - GNSO Council teleconference minutes 21 December 2005 Ken Stubbs, seconded by Maureen Cubberley moved the adoption of all 3 sets of minutes. Motion approved. Ken Stubbs and Maureen Cubberley recorded an abstention for the minutes of 21 December 2005, Ute Decker, Sophia Bekele, Mawaki Chango recorded abstentions for all the minutes. Decision 1: the GNSO Council minutes of 28 November 2005, 2 December 2005 and 21 December 2005 were adopted. Item 2: Update on new gTLD policy development process - advise constituency representatives Philip Sheppard would collect the constituency input for the Commercial and Business Users constituency. Ken Stubbs would collect the constituency input for the gTLD registries constituency and reported that the constituency was making progress with the statements. Caroline Chicoine would collect the constituency input for the Intellectual Property Interests constituency who were working on a draft. Mark McFadden would collect the constituency input for the Internet Service and Connectivity Providers constituency who were working on a draft. Ross Rader would collect the constituency input for the Registrars constituency who had started work. The Non Commercial Users constituency started work but had not yet appointed someone to collect the input. Bret Fausett would be the liaison to the GNSO on the issue and the At Large Advisory Committee had a 4 person task force working on drafting a response and feed back was also solicited from the At Large structures. Avri Doria reported that there were discussions in the civil society circles concerning the issue. Suzanne Sene reported that in Vancouver at the GAC Plenary there was agreement that the GAC would seek to develop principles for the introduction of new gTLDs and a draft could be expected by the Wellington meetings. Item 3: Update on WHOIS policy development - preliminary report on purpose of WHOIS http://gnso.icann.org/issues/whois-privacy/draft-Whois-preliminary.pdf - current work Maria Farrell reported that the Preliminary task force report on the purpose of Whois had been circulated to the task force for a vote at the task force meeting on 18 January, 2006 and would then be posted for 20 days public comment. The GNSO report to the ICANN Board on the GNSO's 'Recommendation for a Procedure for Handling Conflicts between a Registrar/Registry's Legal Obligations under Privacy Laws and their Contractual Obligations to ICANN' would be published for information on the ICANN website. Item 4: IETF draft on IDN issues Patrik Fältström and John Klensin joined the call. John Klensin summarising the IETF draft on IDN issues said that an ad hoc committee, appointed by the Internet Architectural Board (IAB) had been examining the general IDN situation for several months but it was a slow process because the committee was so diverse. The document would undergo significant changes, and it was impossible to predict how the IAB would react. Versions 1 and 2 would be brought in line with additional references and terminology, objections would be noted and discussions had clarified important issues with the inferences that should be drawn from them. If the liberal and unrestricted definitions of the standard providers on constraints were heeded, then it would be extremely easy for careless or malicious people to cause confusion, or fraud. Symptomatic of this phenomenon were the incidences in the spring, which ICANN was warned about 3 – 4 years ago. The work of the ad hoc committee and other groups had shown details, which were included in the IDN briefings during the ICANN meetings in Luxembourg and Vancouver 2005. When considering sophisticated means of preventing confusion, the user, as well as the registry and registrar communities had a tendency to look at the DNS strings and labels and see words - words in whatever languages they were most familiar with or wanted to speak. Seeing words in these strings was problematic as either assumptions, which might or might not be true, were made about the present characters and scripts, or assumptions were made about what ought to be permitted or claims were made about rights to permit elements which the DNS would not sustain. The problem ran afoul of applications' implementers who were protective of their users applying their own rules on what names were valid or invalid. This could lead to further problems of a registry or registrar selling a name and a registry registering a name that can not be resolved because the application designer deems it too dangerous or will not resolve or display the name. These issues were explored in the report and recommendations made to the IETF for modifying the protocol. There is a general principle that anything not restricted in the protocol will be used somewhere in the DNS. From discussions with the applications area directors about issues, it would seem reasonable to assume some Internet Engineering Steering Group (IESG) action but not in so far as what the IETF has written is not interoperable or written in such a way that the designers consider satisfactory. Bruce Tonkin commented that looking at the combination of the IDNA and the ICANN guidelines, there were degrees of freedom with particular characters, character equivalence tables etc. which led to two issues: - with different registries it made it difficult for an application designer because of changes over time - there were variations depending on which tld. John Klensin commented that the applications developers on the user application side should be differentiated from those on the registrar side where there was a problem. On the user side, in theory, unless the application developer decided that they had a higher obligation to protect their users above and beyond what the protocols specified, then all the application developer needed to do was to follow the standard and look up those things. No one committed to the global interoperability of the DNS, had suggested anything about per zone or per TLD rules which would change the look up rules. For the application designer, designing an application to look something up, the only issue was whether it could be found or not. Any restrictions, applied by the ICANN guidelines or other rules, including the JET guidelines in Chinese, Japanese and Korean, pertained to what was registered, not to the interpretation. The rules provided a way to bind names together, so if there were a potentially confusing pair or triplet of names, the rules provided a formal way to find the pair or triplet and provided a rule for the registry that if one of them were registered, the other could not be registered or if one were registered, the other could only be registered by the same registrant. Nothing on the look up side changed the interpretation of a name. However, there were propositions for violating the standards by changing the lookup rules which would only result in the fragmentation of the Internet. The registrar side caused concern as different registries applied different rules. The registrars might have to know which registry they were dealing with to know which rules to apply or to be able to predict the registry behaviour. However, this is an existing problem. This illustrates a situation where IDN makes everything worse by adding tens of thousands of characters, depending on how 36 or 60 odd characters would be counted that could be currently registered. Ross Rader commented that in section 4. Specific Recommendations for Next Steps policy and technical implications had not been sufficiently disentangled for bodies such as the GNSO Council or the IETF to continue further work. John Klensin responded: "If somebody made me king, I could tell you who ought to be doing it but no one is likely to do that." However he did suggest that depending on the position the IAB would take, stronger recommendations could be made. At the policy level there were two issues: country code registries would be affected as much as the gtld registries by IDN issues and while in principle if the GNSO Council reached agreement confirmed by the Board, gTLD behaviour could be mandated but not cctld behaviour. These problems should be confronted in cooperation and participation with other affected bodies. Rather than developing policy in the traditional sense, there should be agreement about what constitutes safe and unsafe practices followed by a clear concept and responsibility for the policy. For example, if a ccTLD were to adopt extremely liberal policies about registrations, countries with consumer protection in their political cultures would presumably come down on those registries in a less ambiguous way and with more authority, than ICANN could do. This is a new area for ICANN and the community which still needs clarifying. Patrik Fälström commented that in section 4 the IAB explicitly listed and compiled the issues in a way that had not been done before without identifying who should take care of each concern. Many of them were overlapping and should be taken into consideration by the IETF, ICANN policy work, application developers in writing applications, and the Intellectual Property Rights community looking at dispute resolution processes. The IAB was concerned that each organisation tried to solve their piece of the puzzle and assumed that the other pieces were taken care of by someone else. It is hoped that the IETF and ICANN, or similar organizations with overlapping or touching pieces of the puzzle could work together toward a total solution. The IAB is not expected to be more specific nor is that the goal of section 4 in the paper. John Klensin added a personal observation that any claim made by a person or organisation, to have the entire picture and decide boundaries, did not understand the problem and should not be trusted. The report lists elements under separate headings, but in fact they are not separable. Patrick Fältström cited an example from inside the IETF, where there was the potential for reissuing a new work group within the IETF, whom most believed fell into the DNS protocol and more traditional uses of the DNS but currently the stringprep and various kinds of algorithms were found in other places, which indicated that even inside the IETF there are multiple different working groups in different areas with various kinds of dependencies that were not found in a traditional DNS registry to registrar setting. Thus it is important to list all the issues so that each group is aware and as such section 4 of the report is important work. Sophia Bekele asked about the role of ICANN and registrars in the testbed and what it would achieve. John Klensin responded that he did not recommend the test bed, was involved peripherally in the formulation of the IDN guidelines and was not on the President’s IDN committee where these initiatives were coming from. Several issues were involved, in contrast to a year ago there was the assumption in the standard that if an IDN showed up as visible in an IDN aware application, that it would be displayed in the characters people would expect to see. For example: if the IDN showed up in Cyrillic or Chinese, there would be Cyrillic or Chinese characters on the screen. Currently it was not the case as browser vendors were differentiating between registries which displayed registration data to prevent confusion and as a consequence displayed their IDNs in native script form, and registries that were negligent and therefore browser vendors did not display their IDNs anywhere in the tree underneath the TLD in native character form. In such situations, whatever the standard is, until it conforms and is acceptable to application developers, they will be looking at the registries' behaviour and deciding what names can be displayed. As has been pointed out in the past, if there were a poor user or company dealing with an ASCII transliteration of its name for years and hating it, going to that user and proposing an improvement by replacing it with something that appeared on their screen like a series of characters would have low appeal. ccTLD Registries have an easier case than the gTLD registries in that they deal with, and make decisions about a relatively small number of scriptal languages. Whereas, with gTLDs it would be bad if ICANN were to discriminate against one language or another and how that would evolve would be up to the GNSO. Different registries making different registry policies is not new except that IDNs pose more opportunities for variation, confusion and scale. The IDN .IDN situation is a different complicated issue where John Klensin even rejected the use of the terminology. A tld registered in non ASCII character in the next level domain registered under that tld will be a non ASCII character possibly even in the same as the top level one assuming that the top level is in a homogeneous script . The original IDN committee suggested that new IDN tlds should be applied for as if they were new tlds with strange names. If ICANN were to adopt such policy then certain concepts about IDN tlds bound to countries would drop away. If the notion of IDN tlds bound to countries, as separate tlds rather than as an alias, were adopted different problems would arise. One of the advantages would be in the approval process, as no new tlds would be approved except for those already in the cue. The cue would build up in part by entrepreneurs discovering some countries could be persuaded to apply for an IDN tld in their name which would create a series a of new country code domains run as gTLDs without any restrictions and resulting in an entirely different situation. Are experiments necessary? Mechanically it is known that IDNs work and that the DNAME alias works with restrictions. Questions arise in implementation and if there were restrictions what they would mean in terms of the root server performance. Little is expected to be learnt by experiments. Cary Karp commented that problems could be avoided if the complex of issues were segmented and proper cross participation among the various groups was in place. What should be the GNSO council's role in assuring IDNs in the entire name space demonstrating technical capability before competition issues were addressed? John Klensin responded that GNSO and country code issues could not be isolated and ICANN should be sensitive that responsible behaviour was the key factor and discourage irresponsible behaviour. There were strong arguments for moving conservatively and the GNSO should take the lead in caution. The question arises whether there is the right to register a name in a given domain based upon a synonym or a translation of that name in the same or another string in the same domain. For example: Assume a registrant registrars General motors .com. General and motors are words translatable into a number of languages, thus would it be possible in .com to register the Russian equivalent of general and motors together as a name and would that constitute an issue to be handled by dispute resolution or some other way? Marilyn Cade asked whether the present or future gtlds strings should be allowed to be registered in all of the different IDN options. John Klensin stated that there were several separate problems. A distinction should be made between registering an alias for a name, the so called DNAME synonym, versus registering a different domain with that name. The difference is that if one puts in a Chinese synonym for com as a DNAME, pointing to the com domain at the second level, what appears to user with that synonym are going to be re registrations in com as there there is only one tree. If one does that there are a lot of reasons why those synonyms are not a good idea or do not solve the problem, but in terms of the particular issue of synonyms versus separate domains are quite safe. Another answer has to do with registering separate domains associated with names with the tlds. It is important to keep in mind that they are really separate domains no matter what they are called. The second problem is registering a second domain to what their synonyms are in another language, is with the exception of a very small number of tlds of which .museum is currently the striking example, travel may be next, that none of those tld names are names in any language, they are abbreviated strings. If com and biz were translated into Swahili it is not clear that there would be 2 names the same causing a conflict problem also possible in the alias case of opportuning the whole net synonym which opens up other problems at the top level. Bruce Tonkin commented that the General Motor example could be related to trade marks. John Klensin commented that it was one of the areas where the tradition of the trade mark field confined to countries and areas application did not work very well with the DNS. With the translations, whether it is a trademark or not may be the same issue as when something becomes confusing or not to the user. Lucy Nichols commented that trademark law broke down to national laws and according to the trademark. Famous trademarks may have a broader protection and may cover translations as well but was not the case across the board. John Klensin commented that stepping away from Indo European languages when using roman scripts and translating the little prints into some language in which the characters and page looked different, the pronunciation was not recognised, questioned whether any UDRP policy or decision would apply in conflict with top level domains. John Klensin emphasised that since the IDNs were technically, culturally and linguistically complicated issues the GNSO Council should to educate itself on the details rather than make assumptions about how things ought to work. A new sub section of section 4 was expected in the next draft which would point back to the Whois problem. There were complex issues between the IDNs, data bases that looked at ancillary information by registrars and the WHOIS problem. The IDN issue should be viewed in principle, as a system rather than as a text or cultural or language or IPR problem and should be considered in every policy. Bruce Tonkin thanked John Klensin and Patrick Fälström for bringing together the IDN issues in the report and proposed that there should be further discussions on IDNs and constrained IDNs, no tld with a "hyphen" for example, should be introduced at the root to begin with so as to minimise some of the issues highlighted Item 5: Update on status of proposed .com agreement Olof Nordling reported that there was no update on the proposed .com agreement and did not have further information. Michael Palage reported that the ICANN Board at its meeting on 10 January, did not get to the specific line item on the agenda. Ross Rader noted disappointment that there was no staff update on the .com agreement. Bruce Tonkin proposed formally requesting General Counsel for a report on the next steps. Grant Forsyth was concerned that the council had expressed its views but it appeared that the action on dotCOM was continuing without any guidance from council. In view of the situation, he posed 2 questions: - which staff member should have been on the call to inform council - what advice would be useful for the ICANN Board and staff, as further input on matters of policy would be useful to develop policy guidelines for the contracts? Item 6: Next steps on policy issues related to proposed .com agreement E.g - policy for renewal of gtld agreements - funding model policy (possible new policy) - policy for capping fees that a registry can charge - exclusions in agreements from future consensus polices or changes in consensus polices Philip Sheppard reminded the council of the resolution taken during the GNSO Council meeting on 2 December 2005 and urged council to proceed with analysing the issues and requesting an issues report. Whereas the GNSO constituencies participated in a review of the proposed settlement and have detailed statements on issues of concern; Whereas the GNSO Council supports the conclusion of the litigation between ICANN and Verisign; Whereas the GNSO Council does not support all articles within this proposed settlement; Whereas the GNSO Council believes that there are broader questions raised in the proposed settlement that need to be first addressed by the GNSO; The GNSO Council resolves: That the ICANN Board should postpone adoption of the proposed settlement while the Council fully investigates the policy issues raised by the proposed changes. Bruce Tonkin clarified the difference between a process and the outcomes of that process. In the existing dotCOM agreement a date of November 2006 was included. There was a specified process by which by certain dates, renewal proposals were required to be created and that the community was not advised about changing this process. The concern arose because the dotCOM draft agreement was posted 4 weeks before the window opened on the dotCOM renewal process and responses were required in less time than the original process would have permitted. Marilyn Cade stated that the Commercial and Business Constituency took the resolution very seriously and would support the idea of seeking independent expertise, chartering an issues report focusing on the areas where there appeared to be broad community agreement from the Vancouver workshop input and constituency statements, on the major problems relating to the dotCOM agreement. These included the policy for presumptive right of renewal, the funding model,the policy change that was inherent in the agreement, the traffic data ownership and control issue and exclusion to consensus policy. Marilyn Cade proposed providing an issues report, developing a timeline and that council would agree to hold a face to face meeting in the third week of February 2006, to devote considerable time to the issue and incorporate taking public comment at such a meeting. Marilyn Cade emphasised the need to develop a timeline that delivered, if not final policy, advanced policy by the Wellington meeting. Marilyn Cade clarified that the face to face meeting would use online tools and a conference approach for councillors not able to attend, public comments would be solicited and shortly after the meeting, draft policy recommendations arising from the issues report and the terms of reference would be published. In summary, the important issue was the need to develop the policy and to implement what had been resolved by the council. Grant Forsyth proposed engaging outside expertise to develop an issue report with the task of identifying issues of policy development related to the proposed .COM agreement. Once the issues are identified in an independent manner Council would have the possibility of progressing the issues in a helpful manner for the Board prior to concluding a .com agreement. Grant Forsyth clarified that he had suggested external expertise for the reason that Olof Nordling explained the difficulty he had in engaging on the subject with the council. Bruce Tonkin clarified two issues: i if the council were choosing to commence a policy development process, a motion was needed to request an issues report which only required 25% of the votes to pass the motion. - if that were agreed upon, the next issue was resources. ii the second issue concerned the implementation, would staff provide the report or would council call upon external expertise and if the latter, was there an available budget. Grant Forsyth, seconded by Lucy Nichols proposed: That the Council solicit an Issues Report related to the dot COM proposed agreement in relation to the various views that have been expressed by the constituencies. A roll call vote was taken and the motion passed. 13 votes in favour, Marilyn Cade, Philip Sheppard, Grant Forsyth, Lucy Nichols, Robin Gross, Mawaki Chango, Maureen Cubberley, Avri Doria, Sophia Bekele, Bruce Tonkin (2) Ross Rader (2), 4 abstention votes, Cary Karp (2) Ken Stubbs (2), 8 council members did not vote: Ute Decker (disconnected at time of vote, no proxy), Kiyosho Tsuru (absent no proxy), Tony Holmes (not on call at time of vote), Tony Harris (Tony Holmes, not on call at time of vote, could not vote proxy for Tony Harris), Greg Ruth ((Tony Holmes, not on call at time of vote, could not vote proxy for Greg Ruth), Norbert Klein (absent, no proxy), Tom Keller (2) (disconnected at time of vote, no proxy), June Seo (2) (absent, no proxy). Decision 2: That the Council solicit an Issues Report related to the dot COM proposed agreement in relation to the various views that have been expressed by the constituencies. Grant Forsyth seconded by Lucy Nichols proposed Given the shortness of time, and the potential conflict within the staff, that the council seek external expertise in the development and presentation of an issues report. Marilyn Cade proposed 2 friendly amendments: recognising that while there may be potential conflicts for the staff, no negative comment was being made about the staff recognising that there was no budget for this, that council proceed with authorising the expenditure of its reserve funds, or soliciting contributions through the constituencies. Bruce Tonkin proposed, and there was general agreement from the council, that staff should inform the council whether they could meet the request for an issues report and proposed consulting with staff on the issue, and if necessary, calling another meeting in one week. Bruce Tonkin declared the GNSO meeting closed and thanked everybody for participating. The meeting ended: 21:40 UTC. Next GNSO Council teleconference 6 February 2006 at 19:00 UTC see: Calendar -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

TOR .com PDP
by Philip Sheppard Feb. 16, 2006

Feb. 16, 2006

5. Use of Traffic Data While this whole section poses appropriate policy questions, those questions are linked specifically to one prospective service "traffic data". The policy questions raised by Traffic Data are wider than just Traffic Data. Thus the directions in this section should be generalised and cite "Traffic Data" as a "for example". We are all aware of the Wait List service as another "for example" to which these policy considerations would apply. Philip on behalf of Grant

1 0

IDN informational site is updated
by Bruce Tonkin Feb. 16, 2006

Feb. 16, 2006

From: Tina Dam Sent: Thursday, 16 February 2006 8:51 AM Subject: IDN informational site is updated Dear all, please note that the IDN area on the ICANN website has been updated. It should now be easier to find necessary information about IDNs as everything is compiled in this one area, including all ICANN announcements made on this topic. You can find this area via www.icann.org (right hand bar "current issues", link to "Internationalized Domain Names") or directly at http://www.icann.org/topics/idn/ We will continue keeping this area up to date with new announcements, workshops, papers and so forth. However, I realize that we currently still may be missing posting of important material, so please don't hesitate to contact me for any requests you may have for additional material, changes or any other comments. Kind regards, Tina Dam Chief gTLD Registry Liaison ICANN

1 0

Draft Agenda for meetings in Washington - Fri 24 Feb and Sat 25 Feb
by Bruce Tonkin Feb. 16, 2006

Feb. 16, 2006

Hello All, Here is a draft agenda for the meeting of the Committee on new gTLDs. Feedback is most welcome! The terms of reference is available here: http://www.icann.org/announcements/announcement-06dec05.htm Friday 24 Feb (1) 9:00 - 10:00 am - Review ICANN mission and core values - identify core values that are relevant to introducing new gTLDs [From ICANN bylaws: Any ICANN body making a recommendation or decision shall exercise its judgment to determine which core values are most relevant and how they apply to the specific circumstances of the case at hand, and to determine, if necessary, an appropriate and defensible balance among competing values.] (2) 10:00 am - 12:00 noon - Review papers submitted (around 10) (see http://www.gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm) - Invite authors to make a short 10 mins presentation if they wish (must supply a A4 summary of presentation in advance), followed by 5 minutes of questions (3) 12:00 noon - 1:30pm lunchbreak onsite (4) 1:30pm - 3:30pm - PART 1 Should we have new gTLDs? THE AIM OF PART ONE IS TO TAKE AN OPEN MIND ABOUT NEW IDEAS AND PERSPECTIVES ON THIS ISSUE. THIS IS NOT THE PHASE TO CRITIQUE THE INPUT. - review impact of tlds added since 2000 - review constituency papers and compare with positions prior to 2000 - have the constituency position statements changed in any way based on the experience of the past 5 years? - review information from submitted papers plus public comments relevant to this question - review external influences - e.g alternative roots (both ASCII and IDN based), search engines, tld (cctld and gtld) registry competition, growth in Internet users that are non-English speaking and users that use different character sets - identify advantages and disadvantages (5) 3:30pm to 4:00pm - Afternoon tea break (6) 4pm to 6pm - PART 2 Should we have new gTLDs? - Yes or no? - Attempt to draft an initial policy position that has some level of consensus support from the GNSO constituencies - if consensus can't be reached - then see if there is a clear majority/minority position that can be developed. If so, identify clearly the reasons for each of these positions. - any output from this meeting will become part of an initial report for further feedback from constituencies and the public (7) 6pm - identify a local place for dinner for those that want to attend (assuming that participants are still on speaking terms after the debate above!) Saturday 25 Feb (1) 9am to 9:30am - review outcomes from Friday (note if the clear consensus on Friday is to have no new TLDs - whether ASCII or IDN based - then we can go home at this point :-)) (2) 9:30am to 12:00noon PART 1 Selection Criteria for new tlds - review selection criteria from the first round (Aug 2000) http://www.icann.org/tlds/tld-criteria-15aug00.htm - review selection criteria from the second round (Dec 2003) http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parta-15dec0 3.htm - review constituency statements - compare with those prior to 2000 - review information from submitted papers plus public comments relevant to this question - identify list of possible criteria - categorise these criteria - e.g technical, financial, market (purpose of TLD) (3) 12:00noon to 1pm - lunch break (4) 1pm to 3pm - PART 2 Selection Criteria for new tlds - analyse possible selection criteria - Attempt to identify which criteria have a degree of consensus support from the GNSO constituencies - For criteria that don't have clear consensus - attempt to identify which criteria have support from more than one interest group - any output from this meeting will become part of an initial report for further feedback from constituencies and the public (5) 3pm onwards - volunteers who don't need to rush to catch flights - to assist in tidying the venue Regards, Bruce Tonkin

1 0

Re: Regarding issues report on IDNs (fwd)
by Cary Karp Feb. 16, 2006

Feb. 16, 2006

---------- Forwarded message ---------- Date: Wed, 15 Feb 2006 14:33:07 -0500 From: John C Klensin <klensin(a)jck.com> To: Sophia B <sophiabekele(a)gmail.com> Cc: Patrik Fältström <paf(a)cisco.com>, Marilyn Cade <marilynscade(a)hotmail.com>, Cary Karp <ck(a)nic.museum>, Tina Dam <dam(a)icann.org>, GNSO Council <council(a)gnso.icann.org> Subject: Re: [council] Re: Regarding issues report on IDNs Sophia, I needed to take some days to consider your note and, perhaps, to let things calm down a bit (I, of course, don't know what discussions have occurred on the GNSO Council list in the interim). I hope the clarifications and comments below are helpful, but suspect that we are nearing, and may have reached or passed, the point at which further comments from either a technical perspective, or even a "best interests of Internet users" one, are useful. I am going to respond to both your note of the 6th and that of the 5th below. My apologies in advance for the length of this note, but I'm going to try to respond to a number of almost-separate issues while trying to reduce the fairly obvious level of confusion that underlies some of the questions and assertions. --On Monday, 06 February, 2006 00:00 -0800 Sophia B <sophiabekele(a)gmail.com> wrote: > Great...we are making the technical difference and that they > can be separate .foo and .com and that they can be owned by > two differ registrars and that could be competing with each > other. At one level, that has always been the case and is self-evident. At another, it is extremely important that the Council understand how the DNS actually works, what the four major internationalization options are, how different options are seen by the user, and what their consequences and side-effects are in order to discuss these topics... at least from any standpoint other than narrow self-interest. Good tutorials on DNS operations, written with policy-makers in mind, are available; if you haven't been given the references, please ask. > That point made, what I am trying to address is 2 > business issues: > > 1- if 'mybrand' is to be protected i.e trademark in every > country...it is a matter of purchasing all the 'mybrand' > TDLs... It is at least a matter of "purchasing" 'mybrand' in _every_ TLD or of convincing relevant TLDs to not permit it to be registered (by you or anyone else). However, note that you may not be able to do this and you may not want to. Some countries require that you have a business locus in those countries to register in their TLDs, so, unless you open an office there, you may not be able to "buy" that name. In others, your ownership of a well-known trademark (if "mybrand" is one) may be more than sufficient to protect you: you may not have to actually "purchase" (register) the name and might actually be better off not doing so. Even if you manage to control all of the possible second-level domains of that name, you still need to make a judgment as to whether you have bought yourself adequate protection. If "mybrand.TLD-name" is a problem for you, "mybrand.some-SLD-name.TLD-name" may also be a problem. I note that, some years ago, a fairly well known trademark holder in the US decided to take exception to names of the form mickey.someschool.k12.fl.us and minnie.someschool.k12.fl.us So far, none of this has anything to do with IDNs. It might be an argument for not creating any more TLDs of any flavor, but it is worth noting that a new TLD increases your problem by well under 1/2 percent if names below the second level are ignored and by far less than that if they are considered. The place where IDNs enter in depends on whether you believe that, if you need to have control of every instance of "mybrand" in the DNS, you also need control of "muybrand" and "meinefabrikzeichen" (both of which can be perfectly well expressed in ASCII characters) or "xn--80aanvhbf1a" and a huge variety of other synonyms and translations. One can, of course, make a case that you are entitled to, or should protect, all of those things (of which there are many thousands) but one could also suggest that, at some point, silliness sets in. > 2-on the other hand, if mybarnd .com is to be protected 'in > every language' under gTLD, then 'com' in every language over > 200 translation need to be protected and approved by ICANN. First, as I think Cary has pointed out, "every language" puts one somewhere in the 6000 range, not 200. What is more important is that this problem exists today, with no further action being required on the part of ICANN. Using the admittedly crude examples above, "muybrand.com", "meinefabrikzeichen.com", and "xn--80aanvhbf1a.com" could be registered tomorrow if they have not been registered already. The only nuance that an IDN TLD system would add is the ability to refer to "xn--80aanvhbf1a.com" as something like "xn--80aanvhbf1a.xn--e1aajebclaqxm4e" (if using DNAMES or local aliases) or to register "mybrand.xn--e1aajebclaqxm4e" and "xn--80aanvhbf1a.xn--e1aajebclaqxm4e" in a new domain if separate domains were created. > So the guardians of this names i.eVerisign etc.. will be > translating and registering them. ARe they passing > the cost to the customer? Are we going to approve over 200 > maybe thousands of translations? This is, again, a situation in which being very clear about how the DNS actually works and about what one is talking about as a result is very important. For example, if the DNAME approach is used, and a DNAME record named .xn--e1aajebclaqxm4e is installed pointing to .COM, then there is no difference between mybrand.com and mybrand.xn--e1aajebclaqxm4e they are the same set of record entries. By contrast, whether or not "xn--80aanvhbf1a.com" could be registered, and on what basis, is strictly a registrar issue with the standard fee structure -- I believe that name could be registered today and that, if you didn't like it, you would need to go through a standard UDRP procedure. I would hope that, were ICANN to be willing to install a top-level DNAME record with the label of xn--e1aajebclaqxm4e, that there would be some cost-recovery for doing so, but the amounts would not be large. The question of which of well over 6000 DNAMEs would be inserted pointing to COM and how they would be chosen is a pure policy issue. And, were ICANN willing to create a separate top-level domain for xn--e1aajebclaqxm4e, the registration policies for that domain would be ... well, whatever was proposed and accepted. > What are the implications above? The implications clearly differ with the technology chosen. As I (and others) have pointed out before, few of the existing TLD names actually represent words in English (or any other language), so the matter of translations would be difficult and might call for some policy decisions. If one were trying to minimize policy issues, the DNAMEs or are clearly the better approach of those involving root changes and local aliases are a better approach yet. Presumably, if new names are going to be placed in the root (for either DNAME or delegation records), some procedure will need to be devised for applying for and registering those names and I would not predict that it will be easy to devise such a procedure while still being sufficiently fair to all language groups to minimize the risk of people feeling that they are forced into the development of alternate roots. If we do end up with alternate roots, your ability to register "mybrand" in all TLDs, or even to know whether you have done so, would be severely compromised. --On Sunday, 05 February, 2006 23:23 -0800 Sophia B <sophiabekele(a)gmail.com> wrote: >... > Please allow me to present this historic perspective, as well > as some relative considerations regarding the IDNs. > > 1) It is my understanding that ICANN has a fully authorized > TESTBED still ongoing with VERISIGN, operating almost 200 > languages under ".com". It is also my understanding that the > author of the DNAME proposal draft (published in Vancouver) is > from VERISIGN (they are the champions of this and the author > of the document is a fellow who launched the first Versign > testbed. Is it also a fact, pls correct me if I am wrong, to > state that this process sold 1 million names in 200 languages, > but really did not address the long-term solution? uhmm. I am no particular friend of Verisign's or their behavior, but I believe the explanation above is somewhat distorted. As I understand it, the vast majority of the names registered under the testbed have been converted to IDNA names and the relevant fees paid for standard registrations. More important, despite my use of some of them in the examples above, no one really wants to type in, or look at, any of these ACE-encoded names. In general, if I use one of the IDNA (punycode, as above) names in a DNS name context any modern/contemporary browser, I will see the native characters associated with that name. But nothing contemporary supports the "RACE" names that were used in the testbed. So, unless one finds a string starting with "bg--" and followed by an arbitrary-looking collection of characters to be amusing or of mnemonic value, that testbed, however badly it was handled, is now irrelevant. Verisign has permission to register IDNA names in COM and NET and has had it for several years. As far as I know, every other gTLD that has asked for permission to register IDNA-style IDNs has gotten that permission. These are not for testbeds, they are for production registrations. Now, I believe that testbed was very badly handled and that the way it was approved and handled reflects badly on ICANN (staff, Board, and the then DNSO Council) and on Verisign. My proposal that we be quite aggressive in being sure that "tests" are actually tests and not some sort of early-start mechanism was developed precisely because of that experience. We should at least avoid making the same mistake a second time. More on this below. > Further. John in his document suggested 20 languages for each > TLD just for the TEST right?. Suppose 20 languages or 200 > languages may NOT be considered EVERY language, how about when > we have two million languages? Someone mentioned that nobody > is going to put every language in every equivalent of say > ".com" translated. etc. or that English is the root language > of the Internet. Can we you think here that "WWIII" may not > be a problem. I do. At one level, I share your concern. I have no idea how the policy and approval procedures will work out when one starts talking about even hundreds of names that are somehow associated with each TLD or some set of TLDs. I have repeatedly sought for, defined, and proposed mechanisms for dealing with the need for internationalization at the TLD level as a client-translation problem, rather that trying to force those decisions to be global policy matters. While "WWIII" is probably hyperbole, I believe the most efficient way to get us to alternate roots and a badly fragmented Internet would be to respond to the perceived requirements for increased internationalization with a "just say no" attitude or one that can be interpreted as people from industrialized countries trying to keep populations from less-developed areas from using the Internet effectively. On the other hand, unless you succeed in persuading everyone in the world to adopt a writing system that uses Roman characters, the argument for IDNs, and IDNs at the top level (at least in appearance to the user) will not disappear. If we are going to do such things by entering names in the root, then it is useful to know what will work, what will not, and, to the extent to which we can make estimates, what the operational impact will be. I believe we should all be quite concerned about making root changes without at least some of that experience and knowledge. If people want to run experiments, then those experiments should be both controlled and informative. The choice of 20 was based on an estimate of the minimum number needed to give us some useful information. > 2)- Unfortunately English is the default language of the > Internet today and it is likely to continue to be. Nobody > questions that in a serious way - but what everyone wants I > believe is a reasonable usable field in every major language > today etc. for non-english speaking populations. Without > having to be condescending to the "non-West" as I am certain > they do understand English is here to stay, what we want to do > is really keep the other languages alive. From what I have > gathered, it seem that past discussions on this issues suggest > 'Textbook thinking" without due consideration of is what the > "non-US/West" wants. If we out to call it IDN and ICAAN > represents a true international organization, we need to NOT > only talk the talk, but walk the walk, applying the > cornerstone of globalization in a realistic way, 'think > global, act local'. I think that some of us who have been working on these issues for many years are at least as sensitive to these issues... and to finding ways to make things work effectively with a variety of scripts and languages, as you are. Some of us have even spent a good deal of time working with people in the "non-US/ non-West" trying to accomplish that while also trying to preserve the integrity of the DNS as a global Internet-object referencing resource. The problems are complex. The DNS is not an ideal solution to many of them for reasons that have little to do with English or even Roman characters. The nature of those problems and the range of alternatives have been rather extensively explored outside the ICANN and Roman-script contexts, especially in East and Southeast Asia. At the same time, slogans may not be helpful (e.g., the only practical way to realize "think global, act local" with regard to IDNs is to get internationalization issues entirely out of the DNS -- an IDN in the DNS is inherently global because the DNS is inherently global) and wishing the DNS, or the Internet more generally, worked in a way significantly different than it does won't make it so... any more than lamenting how much easier navigation would be if only the earth were flat is helpful to either navigation or earth-flattening. > 3) I may be presumptuous, but ICANN's argument of resorting to > using DNAME seem to come from the perspective of how ICANN > failed to be responsive for long and now "China" and others > are threatening to "break the single root". Therefore, > perhaps, we were left to a single view and a quick solution, > neglecting to entertain the CHOICES we may have for IDN. So, > the easiest implementation approach is DNAME, which is is to > just give the big registries all the languages without having > to change much in the technical stuff - ie. just re-point.com > to every language equivalent - no new TLDs etc. Actually, I think you misunderstand both the situation and the history. First, DNAMEs are, in Internet time, a relatively old proposal and protocol specification. I didn't invent them and neither did Verisign. Second, there was a proposal from the original ICANN IDN committee that no IDN TLDs be permitted in the root except on a separate application for new TLDs process. For an number of reasons --almost all of them consequences of how the DNS actually works and what is and is not possible as a result-- I still believe that was a wise recommendation, independent of anything China, Verisign, or others might "want" to do. Some of those who are still on the GNSO Council will probably remember that, because of issues with the number of languages in the world, I recommended that we try to sort out the use of IDNs at the second level and below in relevant ccTLDs before permitting them to be used at all... and recommended that several years before China made essentially the same suggestion (of course, by the time they made that suggestion, it was already too late since several gTLDs were doing production IDN registrations). Now, there has been a good deal of pressure from a number of directions to create aliases for country names in national languages. That pressure has actually been much more intense, with more threats, from other directions than from China. If an alias is what is really wanted and that alias must, for technical or political reasons, be in the root, then DNAMEs are the right way to do so. Other solutions are simply not aliases, they are separate domain names. To me, for separate domain names, the original IDN Committee/Katoh-san recommendation should still apply. As with IDNs below the top level and the "what languages" question, I understand the idea of an alias for a ccTLD in the relevant country's national language(s) much better than I understand what to do about gTLDs. Indeed, if I could make recommendations for the GNSO, I would seriously consider a recommendation that, at least for the next several years, the top-level IDN issue is, except for possible completely new applications domains with IDN-style names, entirely a ccTLD problem and that the gTLDs should not participate in any way in the evaluation of what is possible and reasonable other than continuing to register second-level IDNs under existing rules. > John's statement butteres this point: > > If a such programmer in China were to decide that, for her > users to have a good experience, .US and .COM should be able > to be referenced by using Chinese names, there is nothing that > the GNSO, ICANN, IETF, ITU, or the Great Pumpkin could do to > stop or prevent it. Even the control of the Chinese government > would be _extremely_ limited, since those Chinese names would > be visible only to users of that particular application with > that particular extension, and not "on the wire" or to either > DNS servers or the sites or hosts being reached. > > I think if this is the way we have looked at it, it seem that > our response is shortsighted (because it technical-oriented > only and did not consider the business issues) and is perhaps > why ICANN has failed achieve success in the IDN arena. > Instead of worrying about the political, policy and cultural > implications, first, we may have focused on the easy way > out...technical. In this case, contrary to what Cary said, I > think issuing DNAME is equally reckless as using new TLDs in > IDN. > The fact that the Chinese has already launched this process > (if we out to call them reckless) and ICANN who ought to know > better, is forced to 'follow' the same (can we call ICANN > "reckless") as well? Uhmm. Again, please understand enough about how the DNS works, and how name resolution and applications on the Internet work more generally, to be able to understand what is said above. The Chinese have not already "launched" anything along the lines of what I suggested. That proposal is not "technical-oriented only" and does consider the business issues (even if the business and cultural issues it considers critical might not be the same ones you would choose). That proposal was actually almost exclusively focused on political, policy, and cultural issues -- many of the technical folks, who prefer a less complex world, actually don't like it. And that proposal is not, in any way, related to DNAMEs -- it is a third alternative. As to whether "issuing DNAME" is "equally reckless" as "using new TLDs in IDN" (whatever that means), I would, again, encourage you to understand what is being proposed and what its technical implications are, if only because doing so is prerequisite to talking intelligently about the business issues (or even most of the political and cultural ones). The "new domain" issues are simply a superset (a rather large superset) of those associated with DNAMEs. DNAMEs supply aliases but, as I pointed out long before the GNSO became actively concerned with this, one still needs to decide who gets which names and what they point to. New domains raise the much more complex issues of allocations and operation, and domain-specific policies as well as those of name selection and assignment, issues that are largely invisible from the DNAME case. Could one adopt a DNAME model and reserve names for later "independent TLD" allocation? Of course. Could one restrict the DNAMEs that would be associated with gTLDs to some limited set, or even to zero if that were felt to be wise? Of course. There is nothing that is "all languages in the world or nothing" about any of the proposals I have heard seriously raised. >... > *Ok, pls correct me if I am wrong when I am trying to speak > DNAME implementation approach:* eg. CEO of mybrand.com has to > be protected in every language under a gTLD that means "com" > in every language, right ? meaning they have to come up with > 200 language translations of ".com" and ICANN can approve > DNAMES. No, they do not. And the fact that they do not is actually one of the attractions of the DNAME approach (except to the registrars and registries who are anxious to mount "there is now another new domain in which you need to register to protect your brand... please send money" campaigns. _That_ approach requires separate domains). > Then these companies, like Versign, can go and get > everyone of their.com name holders (40 million in this case) > names translated / transliterated into 200 languages to > everyone's satisfaction and register them all to get 200 x 45 > million DNAMES. *I hope I am on right track so far.* No, you are not. Please read the comments above and, more important, please make an effort to understand how the DNS works in general and how DNAMEs work in particular. > Are > they also going to charge the CUSTOMER (who has already paid > some $6 already) for the translation/transliteration work? > Also, if the customer then is upset by the accuracy of > translation or if the customer is sued by some other third > party saying that the wrong translation now impinges on their > own business, will VERISIGN pay for all lawsuit damages? I am > almost certain that these companies will NOT agree to this - > but this is the result of DNAMES. No, it is not. > Finally, from where I see it, *policy is to be made first in > complex situations as these.* Technology is a second - fact is > these systems seem to have been working for years already, as > China seem to have has deployed it for years on a large scale > - far larger than anything ICANN has done to date, I believe. No, China has done something else, and only relatively recently. Once you understand, throughly, how the DNS works and, in particular, the difference between the actions of a caching forwarder and a different TLD, I'll be happy to try to explain just what they are doing, and why, to you. >... > Therefore, as Avil suggested, I propose the alternatives and > solution should be explored by a joint consultation with > relevant IDN circles and the Council. Sure. As long as the capabilities and operations of the DNS are sufficiently well understood, and at a policy level, the range and scope of potential ICANN authority is reasonably well understood, that discussions of policies that imply flat earths and more convenient values of PI are avoided. Otherwise, while the discussions would certainly be interesting, the GNSO will waste its time and the world will ignore ICANN and move forward on its own path. > I myself recommend the POLICY option. Go for a solution > letting the people speaking a specific language (or script as > they like to say) is a part of their culture – to take care > of it. We can talk about specific implementation strategies > once we agree with the policy option! First, the proposal that comes closest to the type of solution you seem to propose above is one that you have rejected out of hand. Second, scripts and not the same as languages and people don't speak scripts: not understanding the difference can only increase your confusion. Third, as long as the DNS is to remain a global resource, a solution that involves letting those who speak a particular language to "take care of it" and go in their own direction is essentially impossible. Or, to put it differently, it is possible in only two ways: with client-level aliasing (which you have rejected) and with different DNS roots for each language group. The latter is inconsistent with both unambiguous global references on a global Internet and, by the way, with your having any possible hope of protecting your business name or trademark globally... except by legal action in each country in which a similar name might be used. regards, john

2 1

Washington meeting
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 15, 2006

Feb. 15, 2006

[To: council[at]gnso.icann.org] Dear Council Members, Please find some details for the Washington meetings. A more detailed agenda to follow. Schedule: 9am - 6pm on Friday 24 February 2006 8:30am - 3pm on Saturday 25 February 2006 Location: 2nd floor Look for the sign on the door of the conf room: "ICANN GNSO Council working session" 1133 21st Street, N.W., Washington, DC Some nearby hotels: M Street – managed by Marriott – ¾’s block away http://marriott.com/property/propertypage/WASRW 1143 New Hampshire Avenue NW Washington, District Of Columbia 20037 USA Phone: 1-202-775-0800 Fax: 1-202-331-9491 Wireless in the sleeping rooms Marriott on 22nd – about 2 blocks away http://www.thecapitol.net/MapsAndDirections/marriottwestenddc.htm Marriott Washington 1221 22nd Street NW Washington, DC 20037 Phone: 202-872-1500 Guest Fax: 202-872-1424 To reserve a sleeping room, contact the hotel directly. Wireless in the lobby, high speed connections in the sleeping rooms St. Gregory – ½ block away… http://capitalhotelswdc.com/StGregoryHotelWDC_com/ 2033 M STREET, NORTHWEST, WASHINGTON, DC 20036 - (202) 530-3600 (800) 829-5034 PH - (202) 466-6770 F High speed connections in sleeping rooms, no wireless. All are in the neighborhood of $200, and all are nice. Negotiated rates are only available if 15 rooms can be gauranteed so this has not been an option. Please book soon. Thanks and see you there! Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

4 4