GNSO Council Teleconference Minutes

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 (see Section 25 of the dotcom agreement ). 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