[council] [Fwd: Revised draft GNSO Council minutes 17 January 2006]

["GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>]

[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