GNSO Council committee on Approval Process for gTLD Service Changes policy development process


18 March 2004.

List of attendees:
Philip Sheppard - Commercial & Business users C.
Marilyn Cade - Commercial & Business users C.
Greg Ruth - ISCPC
Antonio Harris - ISCPC
Tony Holmes - ISCPC
Thomas Keller- Registrars
Ross Rader - Registrars
Bruce Tonkin - Registrars
Ken Stubbs - gTLD registries
Philip Colebrook - gTLD registries
Niklas Lagergren - Intellectual Property Interests C
Kiyoshi Tsuru - Intellectual Property Interests C.
Marc Schneiders - Non Commercial users C.
Alick Wilson
Demi Getschko
Thomas Roessler - ALAC liaison

Paul Verhoef - VP Policy supporting organizations
Barbara Roseman - Staff Manager
Glen de Saint Géry - GNSO Secretariat

Absent
Cary Karp - gTLD registries - absent, apologies proxy to Ken Stubbs/Philip Colebrook
Grant Forsyth - Commercial & Business users C. - absent, apologies proxy to Marilyn Cade/Philip Sheppard
Lucy Nichols - Intellectual Property Interests C - absent, apologies proxy to Kiyoshi Tsuru
Carlos Afonso - Non Commercial users C. - absent, apologies proxy to Marc Schneiders
Amadeu Abril I Abril - absent apologies
Jisul Woo - Non Commercial users C - absent

Bruce Tonkin referred to the list of criteria divided into the following categories:
Issues that affect:
Adherance to Standards
Security and Stability
Technical standards
Competition
Impact on third parties
Degree of community support
Market forces

Bruce proposed going through the criteria list with ICANN General Counsel to clarify which of the issues were in the scope of ICANN so as to consolidate some of the criteria. Any additional comments should be sent to the mailing list.
Marilyn Cade proposed that the consultation with ICANN General Counsel should include the whole Council committee.

Bruce Tonkin referred to the diagram 1 he had developed and revised after the Rome meeting.
The exception, which caused concern was addressed in the diagram on the bottom right hand side of the page. What would happen if ICANN believed approval was not necessary, the registry made the change and something happened and the community was not satisfied,
- ICANN community reviews impact and appeals to ICANN if it believes that the change should have been subject to the approval process -Yes,
appeal to ICANN
- No, pursue processes outside of ICANN to reverse the change if necessary
If the change is affecting a third party and it is not in ICANN's scope to do anything about it, then there are other mechanisms, such as legal or the party negotiating with the registry operator. This would also apply if a registry operator had not approached ICANN in the first place.
Barbara Roseman commented that the possibility should be left open for the registry operator to go directly to the detailed process if they felt it appropriate.
To a question from Marilyn Cade, Bruce Tonkin clarified that the Registry operator always had the choice whether or not to go to ICANN as it was a business decision.
It is recommended that whenever the registry decides to make a change, it should first be discussed with ICANN
Marilyn Cade suggested that there was no portral of the mediation process if a registry decided not to go to ICANN and the community was unhappy with the process.
Bruce Tonkin suggested he would add more explicit terms at the bottom of the right hand page.

Diagram 2

Bruce Tonkin commented that the first two boxes:
1. Is the change likely to impact operational stability, reliability security and global interoperability of the Internet
2. Is the change likely to reduce competition in the registration of domain names?
the criteria (below) would be fitted in:

ICANN would review the criteria

Adherence to standards:
- Does it comply with Internet standards or de-facto standards
- Does it require open or closed standards to use
- Consistency with the end-to-end Internet protocol principle (= de-facto nature)
- Does it require users to use a closed standard software

Security and stability
- Does it disrupt the Internet
- Does it affect other protocols
- Does it cause cost at the edge
- Could it be offered closer to the edge of the Internet
- Are the effects to the users at large acceptable
- Do overall benefits to the community outweigh any negative impact
- Predictability, do we understand how it will affect applications and users, and how it affects stability
- Reliability - Is the change reversible, what is the cost of reversing

Impact on third parties
- Consequences of third party reaction
- Does it affect rights of stakeholders - e.g privacy, competition rights
- Does it affect all users without choice
- Does it change expectations of users
- Does it only affect the registrant of the stld versus users of the stld
- Could it harm legitimate interests (e.g intellectual property)
- What is the cost of failure to third parties (impacted stakeholders)
- Does it cause legal conflicts (e.g with local laws relating to disclosure of personal information)

Degree of community support
- Whether the service has been approved by sponsors community

Market forces
- Can the market measure whether good/bad idea, is there choice
- Does size matter (market power)
- competition analysis

Following that, ICANN provides a draft report to the registry operator
The registry operator has a comment period
ICANN provides preliminary report to registry operator

Stage at which ICANN makes a decision.
The registry operator has a decision to make too, continue with the process or not to continue with the process. If the registry operator decides to go forward, the process, which was up to this point confidential, becomes public.
The registry operator announces intent to make change and ICANN publishes preliminary report, public comment period is open and taking the comments into account, ICANN decides whether to provide approval or not. If it does provide approval, the ICANN community still may decide to appeal, if ICANN does not provide approval, the registry operator may decide whether to appeal.

Kenn Stubbs stated the following hypothetical case:

A registry operator, out of courtesy to enhance communications between the registry and ICANN, proposes a service to ICANN but makes it clear that it is not within scope. ICANN reviews and agrees with the registry operator that it is out of scope and it may also be a proprietary service, and is deemed by ICANN to out of scope, there should be no breach of any proprietary or confidentiality regarding that service. He added that it was necessary to have good communication channels between the registry operator and ICANN.

Bruce Tonkin commented that the process on page 1 described the case where ICANN Believed that it was not in scope, while page 2 dealt with cases that were deemed in scope but that there was opportunity for for dialogue between the registry operator and ICANN.

Diagram 3 dealt with a detailed review process.

The main difference between the quick look and the detailed review process was that the latter was much more of a public process. Either the registry operator decides to go through the full review process or ICANN believes that there are some issues with the submission and cannot give immediate approval.
Bruce Tonkin went through the chart and commented that an appeal process had not yet been added to the diagram.

In fact it picked up on the Intellectual property constituency's submission.
Asked about timelines, Bruce Tonkin responded that it was important to determine the process flow first and the timelines could be placed in later. The full detailed review, taking the time for ICANN reports to be delivered was estimated at 60 days.
Bruce Tonkin commented that the critical part of the detailed review was that it should be seen as the exception rather than the rule. Two past examples were mentioned, the Wait List Service (WLS) which would have been a detailed review process, while adding a second level to .name would probably have been a quick look process as it did not effect security or stability.
Consultation with ICANN staff was necessary to determine the length of the process.

Outside experts appeared to be missing in both processes but it was considered that once the criteria were clearly determined the choice of in house or outside expertise should be left to ICANN. A decision point in the diagram to clarify when it might occur was considered useful and should be documented.

In diagram 3, a decision point was suggested for the registry service, possibly before ICANN prepared the preliminary report. A natural decision point, not worth stating in the diagram, would be for the registry operator to stop the process. A second decision point would be when the registry operator revised the process which could lead to a partial or complete restart of it and which may involve a decision from the GNSO Council.
Bruce Tonkin commented that when drafting the processes, the idea was that the quick look would take place before the Detailed Review. Following the two processes in sequence, in the first process there would be dialogue between the registry operator and ICANN, whereby the registry operator could update the proposals according to the queries ICANN put forward and then the registry operator had the option to go ahead with a more detailed review.
*It was suggested that adding a word "proceed and/or revise" would clarify the concepts already captured in diagram 1, :
- Registry operator decides whether to continue with approval process "or revise", and in
diagram 2, quick look process,
- Registry operator decides whether to proceed "and/or revise"
in the case of revise, it would go back to stage 1.

*Bruce Tonkin suggested adding explicitly in the Detailed Review that there was an opportunity for the registry operator to provide its comments or responses and it should be clear when these comments or responses could be expected.
These could be included before ICANN published its final report
In addition, a registry operator response should be included in the public comment.

Thomas Roessler suggested that there were 2 decisions:

1. Registry operator decides whether they want to revise the proposal or start from the beginning.
Such permission should be granted
2. Registry operator decides that minor changes are being proposed and suggests limiting further input to some stage in the process.
This decision should be subject to review, probably by ICANN.

Bruce referred to the quick look process:
ICANN provides draft report to registry operator,
Registry operator comment period
ICANN provides preliminary report to registry operator
Preliminary report goes for public review before ICANN decides to grant approval
It was suggested that it could be matched: after public input occurred, ICANN would provide report
Registry operator would have a chance to address concerns raised in the report
ICANN publishes the preliminary report, public comment on preliminary report

*It was suggested that by inserting a few steps before ICANN publishes final report, Thomas's point could be captured, in that if the registry operator decided to change the proposal they could elect to start the process again

*It was further suggested that ICANN should decide where in the process the revised proposal would start again and that it might not have to go back to the beginning.

Examples were mentioned where community concerns were addressed prior to ICANN making its final report, such as in timing issues.

In Neulevel's diagram there was a lot more explicit involvement of the registry operator in the process. It was suggested that the role of ICANN's Manager of Public Participation should be more explicit and that the registry operator should be doing outreach as part of the process which could address some of the concerns of one or more communities such as the registrars or intellectual property.
*Bruce Tonkin proposed capturing some of Neulevel's input addressing the registry operator as managing the public outreach process.

It was felt that there should be a balance sought between ICANN and the registry operator in what change should be made.
Barbara Roseman commented that when ICANN prepared the preliminary report ICANN staff should make a decision where the change should go back to, trying to avoid the process being pushed back to the beginning and requiring the full 60 days.

*Bruce Tonkin suggested that it should be made explicit that before the preliminary report was finalized the registry operator had the opportunity to respond, and suggested capturing the option that the registry operator could submit changes during the process and ICANN could decide to treat the changes as relatively minor or decide that the changes required the process to restart

Bruce Tonkin proposed revising the diagrams and suggested filtering the criteria to what was in the and out of scope, closely linked to the ICANN mission and bylaws. He suggested that legal input was required and that this be done in consultation with Paul Verhoef and Barbara Roseman.

Paul Verhoef who had to leave the call early, suggested the following points:

For each step and loop in the process there should be a time indication so for any process through the steps, the total time period can be calculated.
ICANN should indicate how much time is needed for each of the steps concerning them.
The process needs to include a loop whereby ICANN itself determines that a registry should have come to ICANN.
The process needs to consider what happens once a registry pretends to get out of the process and then determines to do so without informing ICANN (possibly under another heading)
The Committee may need to start considering boundaries for the community commenting /public comments. There should be criteria whereby ICANN would be able to accept or reject comments.

The next meeting agenda was discussed:

It was agreed:

2. GNSO Council committee on Approval Process for gTLD Service Changes policy development process on Monday 29 March, 2004
2. GNSO Council meeting on Thursday 1 April 2004

The meeting ended at 21:10 CET Thursday 18; 7:10 Melbourne Friday 19, 2004

Next meeting:
Monday 29, March 2004, time, tbd