ICANN ICANN Email List Archives

[At-Large Advisory Committee]


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

[alac] New registry services update (2)

  • To: alac@xxxxxxxxx, als-discuss@xxxxxxxxxxxxxx
  • Subject: [alac] New registry services update (2)
  • From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
  • Date: Thu, 18 Mar 2004 10:59:35 +0100

fyi
-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/



----- Forwarded message from GNSO SECRETARIAT <gnso.secretariat@xxxxxxxxxxxxxx> 
-----

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


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




    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
     _________________________________________________________________


----- End forwarded message -----



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

Privacy Policy | Terms of Service | Cookies Policy