GNSO Council com. pdp Minutes

Last Updated: 31 August 2009
29 March 2004

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

29 March 2004.

List of attendees:
Bruce Tonkin - Registrars - chair
Greg Ruth - ISCPC
Ross Rader - Registrars
Ken Stubbs - gTLD registries
Philip Colebrook - gTLD registries
Cary Karp - gTLD registries
Grant Forsyth - Commercial & Business users C.
Lucy Nichols - Intellectual Property Interests C
Kiyoshi Tsuru - Intellectual Property Interests C.
Carlos Afonso - Non Commercial users C.
Marc Schneiders - Non Commercial users C.
Amadeu Abril I Abril
Alick Wilson
Demi Getschko
Thomas Roessler - ALAC liaison

Barbara Roseman - Staff Manager
Glen de Saint G�ry - GNSO Secretariat


Paul Verhoef - VP Policy supporting organizations - absent with apologies
Niklas Lagergren - Intellectual Property Interests C - absent with apologies, proxy to Lucy Nichols
Thomas Keller- Registrars - absent with apologies, proxy to Ross Rader
Antonio Harris - ISCPC absent with apologies, proxy to Greg Ruth
Tony Holmes - ISCPC absent with apologies, proxy to Greg Ruth
Philip Sheppard - Commercial & Business users C. absent with apologies, proxy to Grant Forsyth
Marilyn Cade - Commercial & Business users C. absent with apologies, proxy to Grant Forsyth
Jisuk Woo - Non Commercial users C - absent

Bruce Tonkin proposed reviewing the changed diagrams, particularly the fast track process with regard to:
- the role of the staff ,
- outside experts and
- the appeal process.
On diagram 1 the change was made at the beginning of the process in a link from when the registry operator makes a decision and believes that it is part of the contract if they talk to ICANN or not, if it affects the community, the community can raise the issue with ICANN through an appeal process, ICANN can address it and reverse the process.

Marc Schneiders
referred to the list of criteria
sub section 3,
Registry deliver to ICANN
1. Intent to change
2. Proposed change
3. Business process
4. Technical process
and asked why ICANN had to review the business side of the proposal which he maintained was irrelevant to ICANN's role unless it involved monopoly issues, which was more related to the technical implementation (cf. e.g. WLS)
Grant Forsyth saw the list as a review of competition issues and felt that the registry operator should explain the business impact of the proposed service. He went on to urge that it should be clear what information the registry operator was required to deliver to ICANN.
Bruce Tonkin agreed to delete 3 and 4 and added that once there were clear criteria for ICANN to make a change, a request to make a change would address the criteria.

Changes in Diagram 2
- there is an option for the registry operator to address issues ICANN may have raised and resubmit the proposal.
- when ICANN has finished the quick look process, the registry operator decides whether to proceed, registry operator announces intent, ICANN publishes a report, there is a period of public comment, ICANN gives approval and there is an opportunity for appeal by the ICANN community.
Grant Forsyth and Ken Stubbs both cautioned against making the process too lengthy.

Bruce Tonkin
suggested two options:

1. Delete public comment period, ICANN publishes its final report and there is an appeal option
2. Registry operator wants to proceed, short period of public comment which hopefully would save on an appeal process later.
At the point where ICANN would decide to provide approval the registry operator was free to go ahead. There was an independent process in the ICANN bylaws where reconsideration might be sought, when an error occurred in what was done.

Grant Forsyth
and Lucy Nichols preferred to defer comment and consult with their constituencies.
Ken Stubbs mentioned a hypothetical example where the registry operator submitted a proposal, the ICANN staff determined through the quick look process that it did not require a detailed review. The ICANN staff submitted the report to the ICANN Board. If the Board had to approve the change, even if it did not need a detailed review, there would normally have to be a public comment period prior to the Board approving that change as was required for the modifications in the .name contract. Thus he cautioned against a duplication of public comment periods.
The key question, to Bruce Tonkin, was whether the ICANN Board needed to approve changes and proposed seeking clarification on the issue from ICANN's General Counsel
The length of the public comment period versus and appeal process should be considered to encourage the registry operator to make changes more easily without the encumbrance of an appeal process.

It was also noted that there may be a break in time between when a registry operator decides to proceed with a change, and when the registry operator publicly announces the change. This will be reflected in the diagram.

In diagram 3 the main change concerned giving the registry operator the option to make changes to their proposal, ICANN could incorporate the changes by the registry operator into the preliminary report, a 10 day public comment period is required, ICANN decides whether to provide approval, if yes, the ICANN Community has the opportunity to appeal, if no the registry operator decides whether to appeal, in both cases to ICANN.
Barbara Roseman commented that after ICANN decided whether to provide approval on the yes line, should be inserted, "if the registry operator implements change".

2. The Appeal process.
Marc Schneiders referred to the appeal process which was in the ICANN Bylaws but not yet implemented.
Bruce Tonkin proposed two options:

That a separate appeal process be created for this particular set of decisions
That the process in the ICANN bylaws (section 3, Independent review of Board actions).

The latter was deemed unsuitable as it was a lengthy process and perhaps not fitting in the issue and from the Registry operator point of view the issue would be how long it would take.
Bruce Tonkin proposed drawing a diagram from the section from the bylaws as the advantage was it included the information that needs to be provided under Section 2.
Public comments and appeals should avoid being long and drawn out processes.

The point was raised that if a separate appeal process was being considered, the ICANN bylaws would take preference in any case.It was necessary to have ICANN General Counsel clarify certain issues before further headway could be made.

Next Call:
1. Bruce Tonkin proposed scheduling a call with John Jeffrey, ICANN General Counsel, with listen in only ports for interested parties to join.
2. Clarify the diagram on page 1 just to simplify the information the registry operator needs.
3. Adding explicitly at what point the registry should be making a change, in other words after the ICANN approval,
4. Capture the reconsideration process in a diagram.

Bruce Tonkin thanked everyone for participating.

The meeting ended at 22:55 CET Monday ; 6:55 Melbourne Tuesday 2 April, 2004

Next meeting: tbd

ICANN bylaws


1. ICANN shall have in place a process by which any person or entity materially affected by an action of ICANN may request review or reconsideration of that action by the Board.
2. Any person or entity may submit a request for reconsideration or review of an ICANN action or inaction ("Reconsideration Request") to the extent that he, she, or it have been adversely affected by: a. one or more staff actions or inactions that contradict established ICANN policy(ies); or b. one or more actions or inactions of the ICANN Board that have been taken or refused to be taken without consideration of material information, except where the party submitting the request could have submitted, but did not submit, the information for the Board's consideration at the time of action or refusal to act.
3. There shall be a Committee of the Board consisting of not less than three directors to review and consider any such requests ("Reconsideration Committee"). The Reconsideration Committee shall have the authority to:
a. evaluate requests for review or reconsideration;
b. determine whether a stay of the contested action pending resolution of the request is appropriate;
c. conduct whatever factual investigation is deemed appropriate;
d. request additional written submissions from the affected party, or from other parties; and
e. make a recommendation to the Board of Directors on the merits of the request.
4. ICANN shall absorb the normal administrative costs of the reconsideration process. It reserves the right to recover from a party requesting review or reconsideration any costs which are deemed to be extraordinary in nature. When such extraordinary costs can be foreseen, that fact and the reasons why such costs are necessary and appropriate to evaluating the Reconsideration Request shall be communicated to the party seeking reconsideration, who shall then have the option of withdrawing the request or agreeing to bear such costs.
5. All Reconsideration Requests must be submitted to an e-mail address designated by the Board's Reconsideration Committee within thirty days after:
a. for requests challenging Board actions, the date on which information about the challenged Board action is first published in a preliminary report or minutes of the Board's meetings; or
b. for requests challenging staff actions, the date on which the party submitting the request became aware of, or reasonably should have become aware of, the challenged staff action; or
c. for requests challenging either Board or staff inaction, the date on which the affected person reasonably concluded, or reasonably should have concluded, that action would not be taken in a timely manner.
6. All Reconsideration Requests must include the information required by the Reconsideration Committee, which shall include at least the following information:
a. name, address, and contact information for the requesting party, including postal and e-mail addresses;
b. the specific action or inaction of ICANN for which review or reconsideration is sought;
c. the date of the action or inaction;
d. the manner by which the requesting party will be affected by the action or inaction;
e. the extent to which, in the opinion of the party submitting the Request for Reconsideration, the action or inaction complained of adversely affects others;
f. whether a temporary stay of any action complained of is requested, and if so, the harms that will result if the action is not stayed;
g. in the case of staff action or inaction, a detailed explanation of the facts as presented to the staff and the reasons why the staff's action or inaction was inconsistent with established ICANN policy(ies);
h. in the case of Board action or inaction, a detailed explanation of the material information not considered by the Board and, if the information was not presented to the Board, the reasons the party submitting the request did not submit it to the Board before it acted or failed to act;
i. what specific steps the requesting party asks ICANN to take-i.e., whether and how the action should be reversed, cancelled, or modified, or what specific action should be taken;
j. the grounds on which the requested action should be taken; and
k. any documents the requesting party wishes to submit in support of its request.
7. All Reconsideration Requests shall be posted on the Website.
8. The Reconsideration Committee shall have authority to consider Reconsideration Requests from different parties in the same proceeding so long as (i) the requests involve the same general action or inaction and (ii) the parties submitting Reconsideration Requests are similarly affected by such action or inaction.
9. The Reconsideration Committee shall review Reconsideration Requests promptly upon receipt and announce, within thirty days, its intention to either decline to consider or proceed to consider a Reconsideration Request after receipt of the Request. The announcement shall be posted on the Website.
10. The Reconsideration Committee announcement of a decision not to hear a Reconsideration Request must contain an explanation of the reasons for its decision.
11. The Reconsideration Committee may request additional information or clarifications from the party submitting the Request for Reconsideration.
12. The Reconsideration Committee may ask the ICANN staff for its views on the matter, which comments shall be made publicly available on the Website.
13. If the Reconsideration Committee requires additional information, it may elect to conduct a meeting with the party seeking Reconsideration by telephone, e-mail or, if acceptable to the party requesting reconsideration, in person. To the extent any information gathered in such a meeting is relevant to any recommendation by the Reconsideration Committee, it shall so state in its recommendation.
14. The Reconsideration Committee may also request information relevant to the request from third parties. To the extent any information gathered is relevant to any recommendation by the Reconsideration Committee, it shall so state in its recommendation.
15. The Reconsideration Committee shall act on a Reconsideration Request on the basis of the public written record, including information submitted by the party seeking reconsideration or review, by the ICANN staff, and by any third party.
16. To protect against abuse of the reconsideration process, a request for reconsideration may be dismissed by the Reconsideration Committee where it is repetitive, frivolous, non-substantive, or otherwise abusive, or where the affected party had notice and opportunity to, but did not, participate in the public comment period relating to the contested action, if applicable. Likewise, the Reconsideration Committee may dismiss a request when the requesting party does not show that it will be affected by ICANN's action.
17. The Reconsideration Committee shall make a final recommendation to the Board with respect to a Reconsideration Request within ninety days following its receipt of the request, unless impractical, in which case it shall report to the Board the circumstances that prevented it from making a final recommendation and its best estimate of the time required to produce such a final recommendation. The final recommendation shall be posted on the Website.
18. The Board shall not be bound to follow the recommendations of the Reconsideration Committee. The final decision of the Board shall be made public as part of the preliminary report and minutes of the Board meeting at which action is taken.
19. The Reconsideration Committee shall submit a report to the Board on an annual basis containing at least the following information for the preceding calendar year:
a. the number and general nature of Reconsideration Requests received;
b. the number of Reconsideration Requests on which the Committee has taken action;
c. the number of Reconsideration Requests that remained pending at the end of the calendar year and the average length of time for which such Reconsideration Requests have been pending;
d. a description of any Reconsideration Requests that were pending at the end of the calendar year for more than ninety (90) days and the reasons that the Committee has not taken action on them;
e. the number and nature of Reconsideration Requests that the Committee declined to consider on the basis that they did not meet the criteria established in this policy;
f. for Reconsideration Requests that were denied, an explanation of any other mechanisms available to ensure that ICANN is accountable to persons materially affected by its decisions; and
g. whether or not, in the Committee's view, the criteria for which reconsideration may be requested should be revised, or another process should be adopted or modified, to ensure that all persons materially affected by ICANN decisions have meaningful access to a review process that ensures fairness while limiting frivolous claims.
20. Each annual report shall also aggregate the information on the topics listed in paragraph 19(a)-(e) of this Section for the period beginning 1 January 2003.