[council] GNSO Council draft minutes, 17 January 2006

[GNSO.SECRETARIAT@GNSO.ICANN.ORG]

[To: council[at]gnso.icann.org]

Dear Council Members,

Please find the draft minutes of the GNSO Council meeting held on 17 
January 2006.

Please let me know what changes you would like made.

Thank you very much.
Kind regards,
Glen

Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org

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 Interner 
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 agreements there was a specified process by 
which by certain dates, renewal proposals were required to be created 
and that the discussion did not concern changing this process. The 
concern arose because the dotCOM agreement was posted 4 weeks before the 
widow opened on the dotCOM renewal process and responses were required 
in less time than was permitted thus the specified time for the process 
should be followed.

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 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 emphasised the need to develop a 
timeline that delivered, if not final policy, advanced policy by the 
Wellington meeting.
Marilyn 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, 4 
abstention votes, 8 council members did not vote.

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