Comment, please!

[Marc Schneiders]

Your point is very well made. In the original text there wasn't even
mention of asking the constituencies about their opinions, just
"experts", if called for. During the teleconference I asked to add
that.

So I think we should come up with a full procedure involving the GNSO
if needed. And how to determine when that procedure is needed is the
most crucial question.

Lots of changes to registries can be dealt with by ICANN staff. Some
cannot. How to determine between the two?

Another matter is, how to convince registries to ask ICANN about
changes and not simply implement them (like sitefinder) and wait what
happens.

On Tue, 16 Dec 2003, at 18:35 [=GMT-0200], Carlos Afonso
wrote:

> Hi Marc and all,
>
> The TR says the TF has to seek "The development of a "quick-look"
> procedure for quick approval of changes that do not harm the legitimate
> interests of third parties, threaten stability or security, nor
> contravene any existing ICANN policy."
>
> Here is the riddle: the delays (in my opinion, any request for rule
> changes from operators and sponsors must be analyzed carefully) are
> precisely caused by the process of deciding if the requests "do not harm
> the legitimate interests of third parties, threaten stability..." and so
> on. After this is verified, a "quick-look" should be trivial in either
> saying yes or no, or even a yes/no with modifications.
>
> I think we should worry about the very process of deciding which changes
> are "harmful" and which ones are not and how to expedite decisions here.
>
> rgds
>
> --c.a.
>
> On Tue, 2003-12-16 at 16:02, Marc Schneiders wrote:
> > Below the terms of reference that set the boundaries for comments on
> > the topic.
> >
> > Procedure for use by ICANN for contractual approvals or contractual
> > amendments to allow changes in the architecture or operation of a TLD
> > registry
> >
> > Description of Task Force:
> > ==========================
> >
> > ICANN has agreements with registry operators (for unsponsored TLDs) and
> > sponsors (for sponsored TLDs). In the agreements, ICANN designates the
> > operator (or sponsor) as the sole operator (or sponsoring organization)
> > for the TLD. In exchange, the operator or sponsor agrees that the TLD
> > registry will be operated according to various specifications, policies,
> > and other requirements. These agreements constrain the freedom of a TLD
> > registry or sponsor to make changes in the architecture or operation of
> > the registry that would not conform with those agreements, absent
> > ICANN's prior consent. ICANN has agreed that it will not unreasonably
> > withhold or delay this consent.
> >
> > Some examples of where ICANN is required to give consent include changes
> > to the fees for registry services, changes to the list of domain names
> > registered to the registry operator, and changes to the functional or
> > performance specifications included in a registry agreement.  Many
> > changes approved by ICANN in recent history have been minor and should
> > have been approved in under 30 days, and in other cases changes have
> > been more substantial, but not so substantial as to justify decision
> > making processes running for 6 months or longer.
> >
> > Where ICANN is required to give consent to a change, registry operators
> > require ICANN to make decisions using a timely, transparent and
> > predictable process.  Under the unsponsored registry agreements, ICANN
> > is also required to not unreasonably restrain competition and, to the
> > extent feasible, promote and encourage robust competition;  and not
> > apply standards, policies, procedures or practices arbitrarily,
> > unjustifiably, or inequitably and not single out a Registry Operator for
> > disparate treatment unless justified by substantial and reasonable
> > cause.
> >
> > The purpose of this policy development process is to create a policy
> > concerning the essential characteristics of the process by which ICANN
> > considers registry operator or sponsor requests for contractual
> > approvals or contractual amendments to allow changes in the architecture
> > or operation of a TLD registry.
> >
> >
> > Out-of-scope
> > ============
> >
> > Changes to the nature of the agreements between ICANN and registry
> > operators (e.g removing the requirement to meet functional and
> > performance specifications, and replacing with a more general
> > requirement to ensure security and stability).  This will be the subject
> > of further policy development associated with the review of the current
> > proof of concept for new TLDs, and the development of policies governing
> > the introduction of new TLDs.
> >
> > Additional obligations on registry operators or gtld sponsors beyond
> > what is already specified in their existing agreements.
> >
> >
> > In-scope
> > ========
> >
> > The development of a "quick-look" procedure for quick approval of
> > changes that do not harm the legitimate interests of third parties,
> > threaten stability or security, nor contravene any existing ICANN
> > policy.
> >
> > The development of a more comprehensive process for when the
> > "quick-look" process used by ICANN staff results in concerns of ICANN
> > staff that allows ICANN to obtain qualified outside expertise, including
> > through consultation with competition and technical experts.
> >
> > Mechanisms to protect the confidentiality of requests for contractual
> > approvals or contractual amendments to prevent unnecessary and premature
> > disclosures of proprietary commercial information to competitors.
> >
> >
> >
> > Tasks/milestones
> > ================
> >
> > (1) Develop guidelines for when approval is required to make a change
> > based on the existing registry agreements.
> > (for action by ICANN staff in consultation with registry operators and
> > sponsors)
> >
> > (2) Develop a check list of issues to consider when approving a change
> >
> > (3) Develop a process and timeline for responding to a request including
> > "quick-check" phase, and where a quick-check indicates a need for
> > further work - a timeline for obtaining expert advice and consultation
> > with significantly affected entities.
> >
> > (4) Develop a process and timeline for an appeals procedure for use by
> > registry operators.
> --
>
> Carlos Alberto Afonso
> diretor de planejamento
> Rits - Rede de Informações para o Terceiro Setor
> http://www.rits.org.br
> Rua Guilhermina Guinle 272 - 6º andar
> 22270-060 Rio de Janeiro Brasil
> telefone +55-21-2527-5494
> telefax +55-21-2527-5460
>