[reg-com] GNSO Council committee 29 March, draft minutes: Approval Process for gTLD changes pdp

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

Dear All,

Please find the draft minutes for the GNSO Council committee on Approval
Process for gTLD Service Changes policy development process, 29 March 2004
in text and html versions.

If you would like any changes made, please let me know.

Thank you very much.

Glen de Saint Géry
GNSO Secretariat

****************************************************************************
******************************
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



Absent


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
http://www.icann.org/general/archive-bylaws/bylaws-26jun03.htm#IV

Section 2 RECONSIDERATION

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.




<!--#set var="bartitle" value="GNSO Council com. pdp Minutes"-->
<!--#set var="pagetitle" value="GNSO Council com.pdp Minutes"-->
<!--#set var="pagedate" value="29 March 2004"-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'GNSO Council Teleconference Minutes'"-->
<p align="center"><font face="Arial, Helvetica, sans-serif">GNSO Council committee 
  on Approval Process for gTLD Service Changes policy development process<br>
  <br>
  <br>
  29 March 2004. </font> </p>
<blockquote> 
  <p><font face="Arial, Helvetica, sans-serif"><b>List of attendees:</b><br>
    Bruce Tonkin - Registrars - chair<br>
    Greg Ruth - ISCPC <br>
    Ross Rader - Registrars <br>
    Ken Stubbs - gTLD registries<br>
    Philip Colebrook - gTLD registries <br>
    Cary Karp - gTLD registries<b> </b><b><br>
    </b>Grant Forsyth - Commercial &amp; Business users C.<b><br>
    </b>Lucy Nichols - Intellectual Property Interests C<br>
    Kiyoshi Tsuru - Intellectual Property Interests C. <br>
    Carlos Afonso - Non Commercial users C.<br>
    Marc Schneiders - Non Commercial users C. <br>
    Amadeu Abril I Abril <br>
    Alick Wilson <br>
    Demi Getschko <br>
    Thomas Roessler - ALAC liaison<br>
    </font></p>
  <p><font face="Arial, Helvetica, sans-serif"><br>
    Barbara Roseman</font> - <font face="Arial, Helvetica, sans-serif">Staff Manager</font><font face="Arial, Helvetica, sans-serif"> 
    </font><br>
    <font face="Arial, Helvetica, sans-serif">Glen de Saint Géry - GNSO Secretariat<br>
    </font><br>
  </p>
  <p><font face="Arial, Helvetica, sans-serif"><b>Absent <br>
    </b> </font></p>
  <p><font face="Arial, Helvetica, sans-serif">Paul Verhoef - VP Policy supporting 
    organizations - absent with apologies</font><br>
    <font face="Arial, Helvetica, sans-serif">Niklas Lagergren - Intellectual 
    Property Interests C<b> </b>- absent with apologies<b>, </b>proxy to Lucy 
    Nichols<br>
    Thomas Keller- Registrars - absent with apologies, proxy to Ross Rader<b><br>
    </b>Antonio Harris - ISCPC<b> </b>absent with apologies, proxy to Greg Ruth<b><br>
    </b>Tony Holmes -<b> </b> ISCPC<b> </b>absent with apologies, proxy to Greg 
    Ruth<b></b><b><br>
    </b>Philip Sheppard - Commercial &amp; Business users C.<b> </b>absent with 
    apologies, proxy to Grant Forsyth<b><br>
    </b>Marilyn Cade - Commercial &amp; Business users C. absent with apologies, 
    proxy to Grant Forsyth <b> <br>
    </b>Jisuk Woo - Non Commercial users C - absent<br>
    <br>
    <b>Bruce Tonkin</b> proposed reviewing the changed diagrams, particularly 
    the fast track process with regard to:<br>
    - the role of the staff , <br>
    - outside experts and<br>
    - the appeal process.<br>
    On <a href="http://gnso.icann.org/issues/registry-services/approval-process-24mar04.pdf";>diagram 
    1</a> 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.<br>
    <b><br>
    Marc Schneiders</b> referred to the <a href="http://gnso.icann.org/mailing-lists/archives/reg-com/png00004.png";>list 
    of criteria</a> <br>
    sub section 3, <br>
    Registry deliver to ICANN<br>
    1. Intent to change<br>
    2. Proposed change<br>
    3. Business process<br>
    4. Technical process<br>
    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)<br>
    <b>Grant Forsyth</b> 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.<br>
    <b>Bruce Tonkin</b> 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.<br>
    <br>
    Changes in <a href="http://gnso.icann.org/issues/registry-services/quick-look-24mar04.pdf";>Diagram 
    2</a></font><font face="Arial, Helvetica, sans-serif"><b> </b><br>
    - there is an<b> </b>option for the registry operator to address issues ICANN 
    may have raised and resubmit the proposal.<br>
    - 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.<br>
    <b>Grant Forsyth</b> and <b>Ken Stubbs</b> both cautioned against making the 
    process too lengthy. <br>
    <b><br>
    Bruce Tonkin</b> suggested two options:<br>
    <br>
    1. </font><font face="Arial, Helvetica, sans-serif">Delete public comment 
    period, ICANN publishes its final report and there is an appeal option<br>
    </font><font face="Arial, Helvetica, sans-serif">2. Registry operator wants 
    to proceed, short period of public comment which hopefully would save on an 
    appeal process later.<br>
    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 <a href="http://www.icann.org/committees/reconsideration/";>bylaws</a> 
    where <a href="http://www.icann.org/committees/reconsideration/";>reconsideration</a> 
    might be sought, when an error occurred in what was done.<br>
    <br>
    <b><br>
    Grant Forsyth</b> and <b>Lucy Nichols</b> preferred to defer comment and consult 
    with their constituencies.<br>
    <b>Ken Stubbs</b> 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. <br>
    The key question, to <b>Bruce Tonkin</b>, was whether the ICANN Board needed 
    to approve changes and proposed seeking clarification on the issue from ICANN's 
    General Counsel<br>
    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.</font><font face="Arial, Helvetica, sans-serif"><br>
    <br>
    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. <br>
    <br>
    In <a href="http://gnso.icann.org/issues/registry-services/detailed-review-24mar04.pdf";>diagram 
    3</a> 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.<br>
    <b>Barbara Roseman</b> commented that after ICANN decided whether to provide 
    approval on the yes line, should be inserted, &quot;if the registry operator 
    implements change&quot;.<br>
    <br>
    <b>2. The Appeal process</b>.<br>
    <b>Marc Schneiders</b> referred to the appeal process which was in the ICANN 
    Bylaws but not yet implemented. <br>
    <b>Bruce Tonkin</b> proposed two options:</font></p>
  <p><font face="Arial, Helvetica, sans-serif">That a separate appeal process 
    be created for this particular set of decisions <br>
    That the process in the ICANN <a href="http://www.icann.org/general/archive-bylaws/bylaws-26jun03.htm#IV";>bylaws</a> 
    (section 3, Independent review of Board actions).<br>
    <br>
    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.<br>
    <b>Bruce Tonkin</b> proposed drawing a diagram from the<a href="http://www.icann.org/general/archive-bylaws/bylaws-26jun03.htm#IV";> 
    section from the bylaws</a> as the advantage was it included the information 
    that needs to be provided under Section 2.<br>
    Public comments and appeals should avoid being long and drawn out processes. 
    <br>
    <br>
    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.<br>
    <br>
    <b>Next Call:</b><br>
    1. <b>Bruce Tonkin</b> proposed scheduling a call with John Jeffrey, ICANN 
    General Counsel, with listen in only ports for interested parties to join.<br>
    2. Clarify the diagram on page 1 just to simplify the information the registry 
    operator needs.<br>
    3. </font><font face="Arial, Helvetica, sans-serif">Adding explicitly at what 
    point the registry should be making a change, in other words after the ICANN 
    approval,<br>
    4. </font><font face="Arial, Helvetica, sans-serif">Capture the reconsideration 
    process in a diagram.</font></p>
  <p><font face="Arial, Helvetica, sans-serif"><b>Bruce Tonkin</b> thanked everyone 
    for participating.<br>
    <br>
    The meeting ended at 22:55 CET Monday ; 6:55 Melbourne Tuesday 2 April, 2004</font></p>
  <p><font face="Arial, Helvetica, sans-serif"><b>Next meeting:</b></font><b><font face="Arial, Helvetica, sans-serif"> 
    tbd </font></b><font face="Arial, Helvetica, sans-serif"> </font><font face="Arial, Helvetica, sans-serif"> 
    <br>
    </font></p>
  <p><font face="Arial, Helvetica, sans-serif"><a href="http://www.icann.org/general/archive-bylaws/bylaws-26jun03.htm#IV";>ICANN 
    bylaws</a> http://www.icann.org/general/archive-bylaws/bylaws-26jun03.htm#IV<br>
    <br>
    Section 2 RECONSIDERATION<br>
    <br>
    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. <br>
    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. <br>
    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: <br>
    a. evaluate requests for review or reconsideration; <br>
    b. determine whether a stay of the contested action pending resolution of 
    the request is appropriate; <br>
    c. conduct whatever factual investigation is deemed appropriate; <br>
    d. request additional written submissions from the affected party, or from 
    other parties; and <br>
    e. make a recommendation to the Board of Directors on the merits of the request. 
    <br>
    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. 
    <br>
    5. All Reconsideration Requests must be submitted to an e-mail address designated 
    by the Board's Reconsideration Committee within thirty days after: <br>
    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<br>
    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 <br>
    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. <br>
    6. All Reconsideration Requests must include the information required by the 
    Reconsideration Committee, which shall include at least the following information: 
    <br>
    a. name, address, and contact information for the requesting party, including 
    postal and e-mail addresses;<br>
    </font><font face="Arial, Helvetica, sans-serif"> b. the specific action or 
    inaction of ICANN for which review or reconsideration is sought; <br>
    c. the date of the action or inaction; <br>
    d. the manner by which the requesting party will be affected by the action 
    or inaction; <br>
    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; <br>
    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; <br>
    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); <br>
    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;<br>
    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;<br>
    j. the grounds on which the requested action should be taken; and <br>
    k. any documents the requesting party wishes to submit in support of its request. 
    <br>
    7. All Reconsideration Requests shall be posted on the Website. <br>
    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. <br>
    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. <br>
    10. The Reconsideration Committee announcement of a decision not to hear a 
    Reconsideration Request must contain an explanation of the reasons for its 
    decision. <br>
    11. The Reconsideration Committee may request additional information or clarifications 
    from the party submitting the Request for Reconsideration. <br>
    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. 
    <br>
    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. <br>
    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.<br>
    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. <br>
    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. <br>
    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. <br>
    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. <br>
    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:<br>
    a. the number and general nature of Reconsideration Requests received;<br>
    </font><font face="Arial, Helvetica, sans-serif">b. the number of Reconsideration 
    Requests on which the Committee has taken action; <br>
    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;<br>
    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; <br>
    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;<br>
    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 <br>
    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. <br>
    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. </font></p>
  <p><font face="Arial, Helvetica, sans-serif"><br>
    <br>
    </font></p>
  <p><font face="Arial, Helvetica, sans-serif"> </font></p>
  </blockquote>
<hr>
<font face="Arial, Helvetica, sans-serif"> 
<p>&nbsp;</p>
<!--#include virtual="../footer.shtml"--> </font>