[nc-transfer] NC Chair dialogue with attachment
[To firstname.lastname@example.org, email@example.com ]
Attached, please find rough minutes of the dialogue with Bruce Tonkin on
Monday/Tuesday 18/19 November.
If you would like changes made please let me know.
Dialogue with Names Council Chair on 18 November 2002
Transfer and WHOIS Task Forces
21 November 2002
The call originates from a conversation Marilyn Cade, Chair and Co-Chair of
the Transfers and Whois task forces, had with the Naames Council Chair, Bruce
The purpose is to have a chance to talk to the Chair regarding our efforts to
achieve policy recommendations this year, and other "lessons" learned from our
efforts within the Task Forces.
Bruce Tonkin - NC Chair
Marilyn Cade - Chair, Co-chair Transfer and WHOIS task forces
Glen de Saint Géry - DNSO Secretariat
Bruce Tonkin's opening comments were that it was important for task
forces to succeed to conclusions in this critical time and clear advice was
needed on how to proceed in the ICANN agreement.
Louis Touton produced a paper before Shanghai, follow-up sessions were held
with the Transfers and WHOIS task forces and he clarified positions at the Names
Council meeting on November 14.
Bruce Tonkin expressed his willingness to answer questions and give guidance
how to proceed from from the advice he had learnt on November 14, and in his
personal capacity as an Engineer.
Steve Metalitz: WHOIS TF:
What is the difference between those recommendations in the interim report
to be implemented without change to the agreement and those that need change
to the agreement?
What steps should ICANN take to enforce existing recommendations?
What is the standard to use to put recommendations into the report if they
do not require a change.
Bruce: A recommendation that ICANN strengthens compliance of contracts
is not a change to the agreement.
It is a recommendation for action for ICANN Staff to a Registrar or Registry
as distinct from a change that is contractually binding.
Steve: What are the specific steps for ICANN to take in recommendation
Bruce: Enforcement if they were doing something wrong would need change
in agreement and would be consensus policy.
Steve :Provide interpretation of existing agreement as done in the Registrars
recommendation, for example, remind registrant to maintain accurate data, this
is not requiring agreement, but action.
Bruce: Expressed a personal view : ICANN is reluctant to make contractual
Where ICANN directs Registrars to tell Registrants something, this should be
a consensus policy.
Ken Stubbs: Renewal of agreement is a new agreement.
Quoting paragraph 6 : ICANN should require Registrar to remind Registrant, he
mentioned that Registrars are also responsible to remind resellers.
This needs consensus policy.
Bruce: made a clear distinction and said "requires" needs consensus
policy while" ICANN needs to remind" is an action for ICANN. There
are two areas:
- Where the task force analyses issues and existing contracts
- Where change is required and specific changes should be made, there should
be a new consensus policy.
Marilyn Cade pointed to the Registrars responsibility to the reseller
as a gray area.
Ken Stubbs: said it was necessary to get clarification of how ICANN
views the reseller's relationship.
Bruce maintained that it depended on the structure of the agreement
between Registrar and reseller. The structure of the agreement being thatthe
reseller is acting as an agent.
Ken Stubbs said that an interpretation
of the Registrars agreement would be helpful.
Marilyn cade commented that in the existing contracts, broader awareness
and enforcement was needed.
Bruce said that when talking about a recommendation versus new consensus
policy one needs to look at who is responsible when enforcing a policy and the
requirement may be put on ICANN or the Registrar.
-Transfers: If it is the registry is required to enforce a policy, then the
contract between ICANN and Registry must be examined.
- ICANN makes recommendation to the Board, but if it is a party to a contract,
example the Registrars it falls into the area of consensus policy and requires
Steve Metalitz asked whether a recommendation and consensus policy would
be handled differently?
Bruce said the the requirements or process are the same, but a recommendation
on ICANN is different from a recommendation on the Registry or Registrar.
Jeff Neuman asked how it would be implemented.
Bruce stated that a "requirement" would be subject to negotiation
between the parties, while a recommendation does not need to be negotiated or
put in a conract, it would be "best practice".
Task forces could document what would be 'best practice" but it would not
Ken Stubbs suggested that ICANN create guidelines to be adhered to in
the accreditation process.
Marilyn Cade asked Bruce if he given thought to a transitional process?
Bruce Tonkin commented generally that the Reform process had set a rigid
timetable for policy - 100 days. The issue arises whether the task forces or
the new future Names Council can rely on timely input from the parties. Often
nothing happens for a long time and after the comment period expires comments
are received. The constituencies need to develop a procedure to respond in a
timely manner and need help from within the constituency, by individual members
as to how they can respond quickly.
Another problem is that over a period, opinions may change and these must be
How will the transition be made?
Continuity of expertise is important and consideration needs to be given how
to maintain the continuity and history.
Marilyn Cade said a rapid turnover would be disastrous, and Kristy
McKee also expressed concern about the short timeframe for the transition.
Bruce explained that progress should be seen but that all problems could
not be solved at once.
In the Whois there are areas of conflicting requirements.
Identification of small steps on a 3 month cycle is needed. Features should
be added progressively and changes should be well thought out.
David Safran stated that he would have a problem devoting enough time
to short time windows.
Ken Stubbs mentioned the very realistic problem that ICANN would not
have the necessary resources to move along with the policy and this would cause
a delay in implementation.
Bruce mentioned that prioritization is important in the Policy council
and Whois and Transfers have not been high priority issues.
Thomas Roessler expressed concern about how complex issues would be
handled and the time needed based on his calculations of how long the Whois
work has taken him.
Abel Wisman asked about the future of the task forces in general, and
whether the changes in ICANN predicted a different structure.
Bruce summarized the steps saying that there would be an issue report to the
policy council, a decision to deal with the matter in the policy council or
refer it to a task force, thus the structure and representation, except for
the representation of expertise, would be similar to what is now in place.
Marilyn Cade suggested putting forward policy recommendations in the short term
and prepare issues for further work, thus in the short term get recommendations
out this year.
Thomas Roessler asked what the recommendations for further action should look
To this, Marilyn and Bruce replied that documents should be preserved, details
given to guide the Names Council and policy councils in the next steps, as well
as setting standards.
Time limits were discussed and the conclusion reached was that they provide
stability and continuity, commitments can more easily be made for a shorter
time, the job gets done, date lines are needed but modifications should be possible
and that 6 months was a more realistic time for wrapping up a project. It was
suggested that smaller groups could do data gathering. In the future there will
be swing to a happy medium from the present accelerated pace that came after
a long period of go slow.
Bruce reminded the group that issue reports need real data and arguments
to work on.
Ross Rader asked if there were any obstacles in the consensus policy
that should be paid attention to?
Bruce explained that when a document was produced consensus vote of 2/3
was required, 1/3 disagrees, the Board approves it, and at the point of implementation
the Registrars and registries challenge the consensus. On more controversial
issues, there may be a majority of reasoned responses for or against and then
it would not be consensus. Thus make quite sure that sure that consensus is
claimed, because the whole process could be thrown out if something is added
and does not have consensus.
Marilyn Cade thanked Bruce Tonkin for the fruitful discussion,
giving his personal advice and the time he had spent with the group.
The call ended at 9:00 Tuesday Australian time, 17:00 EST, 22:00 UTC. Monday
|© DNSO Names Council