ICANN/GNSO GNSO Email List Archives

[reg-com]


<<< Chronological Index >>>    <<< Thread Index >>>

[reg-com] Approval Process for gTLD Service Changes pdp Draft minutes 4 March

  • To: "reg-com" <reg-com@xxxxxxxxxxxxxx>
  • Subject: [reg-com] Approval Process for gTLD Service Changes pdp Draft minutes 4 March
  • From: "GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx>
  • Date: Thu, 18 Mar 2004 10:45:04 +0100
  • Importance: Normal
  • Reply-to: <gnso.secretariat@xxxxxxxxxxxxxx>
  • Sender: owner-reg-com@xxxxxxxxxxxxxx

Please find attached the draft minutes of the March 4 Rome Meeting in shtml
and text version.

Thank you,

Glen de Saint Géry
GNSO Secretariat

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

4 March 2004.

List of attendees:
Philip Sheppard - Commercial & Business users C.
Marilyn Cade - Commercial & Business users C.
Grant Forsyth - Commercial & Business users C.
Greg Ruth - ISCPC -
Thomas Keller- Registrars
Ross Rader - Registrars
Bruce Tonkin - Registrars
Ken Stubbs - gTLD registries
Cary Karp - gTLD registries
Lucy Nichols - Intellectual Property Interests C
Niklas Lagergren - Intellectual Property Interests C
Kiyoshi Tsuru - Intellectual Property Interests C.
Marc Schneiders - Non Commercial users C.
Carlos Afonso - Non Commercial users C.
Alick Wilson
Demi Getschko
Amadeu Abril I Abril
Glen de Saint Géry - GNSO Secretariat
Barbara Roseman - Staff Manager


Absent

Antonio Harris - ISCPC
Tony Holmes - ISCPC
Jordyn Buchanan - gTLD registries


Bruce Tonkin proposed that the public comment process at the stage where a
registry operator checks with ICANN to see if approval is required under the
registry contracts should be removed. This ensures that registry operators
have an incentive to discuss a proposed change with ICANN as a courtesy even
if the registry operator does not believe that the change requires approval.

He stated the ICANN manager of public participation mentioned in the ICANN
bylaws would be a useful resource in the approval process for gTLD service
changes when public comment is required. The position was not yet filled and
Kieran Baker was currently acting manager.

A distinction was made between "approval" and "giving notice".
A registry operator may obtain approval for a change but choose not to make
the change.
When a registry operator gives public notice of introducing a change to the
gtld service, it would be appropriate for ICANN to publish the results of
any approval process that was undertaken

Bruce Tonkin referred to a chart which he had developed to map out the
process in which the public participation was taken out.

Marilyn Cade mentioned the example:

MC registry announces a new feature, ICANN agrees, that no approval
required, when the community looks at it there are objections.
Marilyn Cade asked what would happen in the case where a mistake was made.
Discussion brought out that it belonged to an appeal process.

Ken Stubbs made the point that if the registry engaged in contracts with
ICANN it may wish to discuss an innovative service in confidence, noting
that gtld registries compete with other tld registries including cctlds.


Marilyn Cade commented that the community provided legitimacy to ICANN to
avoid governmental regulation. The process should be balanced
.
Discussing approval of registry services as a monopoly.
Dealing with oversight of a monopoly failure
ICANN operates contracts on behalf of the community
Rationale made public

Need for stable operators.
When ICANN is required to publish information on a new service, there was
discussion on what publish should mean. This term will need to be explicitly
defined as part of the process, but should include at least the following:
- publishing prominently on the ICANN website
- advising GNSO constituencies via the available public mailing lists, and
notifying GNSO Council and chairs of the constituencies.

All committee members were invited to include criteria to be used during the
approval process for later analysis against the ICANN mission. The criteria
have been grouped in categories below for easier reference.
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

Bruce Tonkin undertook to seek advice from the ICANN General Counsel on
which of these criteria are within the scope of ICANN in accordance with its
bylaws.

Bruce Tonkin thanked all those present for their participation.

The meeting ended at 10:30 am local time (CET)
Next meeting: March 18, 19:00 UTC, March 19, 6:00 am Melbourne


<!--#set var="bartitle" value="GNSO Council com. pdp Minutes"-->
<!--#set var="pagetitle" value="GNSO Council com.pdp Minutes"-->
<!--#set var="pagedate" value="4 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>
  Rome meeting <br>
  <br>
  4 March 2004. </font> </p>
<blockquote> 
  <p><font face="Arial, Helvetica, sans-serif"><b>List of attendees:</b><br>
    Philip Sheppard - Commercial &amp; Business users C.<br>
    Marilyn Cade - Commercial &amp; Business users C. <br>
    Grant Forsyth - Commercial &amp; Business users C. <br>
    Greg Ruth - ISCPC -<br>
    Thomas Keller- Registrars <br>
    Ross Rader - Registrars <br>
    Bruce Tonkin - Registrars <br>
    Ken Stubbs - gTLD registries<br>
    Cary Karp - gTLD registries<br>
    Lucy Nichols - Intellectual Property Interests C <br>
    Niklas Lagergren - Intellectual Property Interests C<br>
    Kiyoshi Tsuru - Intellectual Property Interests C. <br>
    Marc Schneiders - Non Commercial users C. <br>
    Carlos Afonso - Non Commercial users C.<br>
    Alick Wilson <br>
    Demi Getschko <br>
    Amadeu Abril I Abril </font><br>
    <font face="Arial, Helvetica, sans-serif">Glen de Saint Géry - GNSO Secretariat<br>
    Barbara Roseman</font> - <font face="Arial, Helvetica, sans-serif">Staff Manager</font><br>
  </p>
  <p><font face="Arial, Helvetica, sans-serif"><b>Absent </b></font></p>
</blockquote>
<p><font face="Arial, Helvetica, sans-serif">Antonio Harris - ISCPC <br>
  Tony Holmes - ISCPC <br>
  Jordyn Buchanan - gTLD registries </font></p>
<p><font face="Arial, Helvetica, sans-serif"><br>
  <b>Bruce Tonkin</b> proposed that the public comment process at the stage where 
  a registry operator checks with ICANN to see if approval is required under the 
  registry contracts should be removed. This ensures that registry operators have 
  an incentive to discuss a proposed change with ICANN as a courtesy even if the 
  registry operator does not believe that the change requires approval. <br>
  <br>
  He stated the ICANN manager of public participation</font> <font face="Arial, Helvetica, sans-serif">mentioned 
  in the ICANN bylaws would be a useful resource in the approval process for gTLD 
  service changes when public comment is required. The position was not yet filled 
  and Kieran Baker was currently acting manager.<br>
  <br>
  A distinction was made between &quot;approval&quot; and &quot;giving notice&quot;. 
  <br>
  A registry operator may obtain approval for a change but choose not to make 
  the change. <br>
  When a registry operator gives public notice of introducing a change to the 
  gtld service, it would be appropriate for ICANN to publish the results of any 
  approval process that was undertaken <br>
  <br>
  <b>Bruce Tonkin</b> referred to a chart which he had developed to map out the 
  process in which the public participation was taken out. <br>
  <b><br>
  Marilyn Cade</b> mentioned the example:</font></p>
<p><font face="Arial, Helvetica, sans-serif">MC registry announces a new feature, 
  ICANN agrees, that no approval required, when the community looks at it there 
  are objections.<br>
  Marilyn Cade asked what would happen in the case where a mistake was made. Discussion 
  brought out that it belonged to an appeal process.<br>
  <b><br>
  Ken Stubbs</b> made the point that if the registry engaged in contracts with 
  ICANN it may wish to discuss an innovative service in confidence, noting that 
  gtld registries compete with other tld registries including cctlds. <br>
  <br>
  </font><font face="Arial, Helvetica, sans-serif"><br>
  <b>Marilyn Cade</b> commented that the community provided legitimacy to ICANN 
  to avoid governmental regulation. The process should be balanced<br>
  .<br>
  Discussing approval of registry services as a monopoly.<br>
  Dealing with oversight of a monopoly failure<br>
  ICANN operates contracts on behalf of the community<br>
  Rationale made public<br>
  <br>
  Need for stable operators. <br>
  When ICANN is required to publish information on a new service, there was discussion 
  on what publish should mean. This term will need to be explicitly defined as 
  part of the process, but should include at least the following:<br>
  - publishing prominently on the ICANN website <br>
  - advising GNSO constituencies via the available public mailing lists, and notifying 
  GNSO Council and chairs of the constituencies.<br>
  <br>
  All committee members were invited to include criteria to be used during the 
  approval process for later analysis against the ICANN mission. The criteria 
  have been grouped in categories below for easier reference. <br>
  </font><font face="Arial, Helvetica, sans-serif">Adherence to standards: <br>
  - Does it comply with Internet standards or de-facto standards <br>
  - Does it require open or closed standards to use<br>
  - Consistency with the end-to-end Internet protocol principle (= de-facto nature)<br>
  - Does it require users to use a closed standard software <br>
  <br>
  Security and stability <br>
  - Does it disrupt the Internet <br>
  - Does it affect other protocols<br>
  - Does it cause cost at the edge <br>
  - Could it be offered closer to the edge of the Internet <br>
  - Are the effects to the users at large acceptable <br>
  - Do overall benefits to the community outweigh any negative impact <br>
  - Predictability, do we understand how it will affect applications and users, 
  and how it affects stability <br>
  - Reliability - Is the change reversible, what is the cost of reversing <br>
  <br>
  Impact on third parties<br>
  - Consequences of third party reaction <br>
  - Does it affect rights of stakeholders - e.g privacy, competition rights<br>
  - Does it affect all users without choice <br>
  - Does it change expectations of users<br>
  </font><font face="Arial, Helvetica, sans-serif">- Does it only affect the registrant 
  of the stld versus users of the stld<br>
  - Could it harm legitimate interests (e.g intellectual property) <br>
  - What is the cost of failure to third parties (impacted stakeholders) <br>
  - Does it cause legal conflicts (e.g with local laws relating to disclosure 
  of personal information) <br>
  <br>
  Degree of community support <br>
  - Whether the service has been approved by sponsors community <br>
  <br>
  Market forces <br>
  - Can the market measure whether good/bad idea, is there choice <br>
  - Does size matter (market power) <br>
  - competition analysis<br>
  <br>
  <b>Bruce Tonkin</b> undertook to seek advice from the ICANN General Counsel 
  on which of these criteria are within the scope of ICANN in accordance with 
  its bylaws.<br>
  <br>
  <b>Bruce Tonkin</b> thanked all those present for their participation.<br>
  <br>
  The meeting ended at 10:30 am local time (CET)<br>
  <b>Next meeting</b>: March 18, 19:00 UTC, March 19, 6:00 am Melbourne<br>
  </font></p>
<hr>
<font face="Arial, Helvetica, sans-serif"> 
<p>&nbsp;</p>
<!--#include virtual="../footer.shtml"--> </font>


<<< Chronological Index >>>    <<< Thread Index >>>