[nc-whois] NC Chair dialogue with attachment

["DNSO SECRETARIAT" <DNSO.SECRETARIAT@dnso.org>]

To: nc-transfer@dnso.org]
[To: nc-whois@dnso.org]
[To Bruce.tonkin@melbourneit.com.au]
[To mcade@att.com, harris@cabase.org.ar ]


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.
Thank you,

DNSO Secretariat

Title: notes/20020502.NCtelecon-agenda.html

ICANN/DNSO

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 Tonkin.

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.

ATTENDEES
Bruce Tonkin - NC Chair
Marilyn Cade - Chair, Co-chair Transfer and WHOIS task forces
Thomas Roessler
Abel Wisman
Dan Steinberg
Brett Fauset
Kristy McKee
Ross Rader
Grant Forsyth
Steve Metalitz
Jeff Neuman
Ken Stubbs

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 for action?

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 interpretations.
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.

Example:
-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 new obligations.

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 be "required".

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 accommodated.
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 like.
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

 

 

 

 

 

---

Information from:

© DNSO Names Council