ICANN/GNSO GNSO Email List Archives

[council]


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

Re: [council] Separation of policy and implementation in task force reports

  • To: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Subject: Re: [council] Separation of policy and implementation in task force reports
  • From: Marc Schneiders <marc@xxxxxxxxxxxxxx>
  • Date: Wed, 26 May 2004 22:56:54 +0200 (CEST)
  • Cc: <council@xxxxxxxxxxxxxx>, <dow3tf@xxxxxxxxxxxxxx>, <dow2tf@xxxxxxxxxxxxxx>, <dow1tf@xxxxxxxxxxxxxx>
  • In-reply-to: <AFEF39657AEEC34193C494DBD717922203D1F2A2@phoenix.mit>
  • Sender: owner-council@xxxxxxxxxxxxxx

Bruce (& council),

I find this difficult to read and understand (which is not your fault
but me being a foreigner even down under). Are you saying (as you did
in Rome during breakfast with Board) that each of our
decisions/recommendations should be accompanied by clear guidelines as
how to measure after a certain period whether it worked out? I then
thought and still think this is a very good idea. It avoids paralysis
amongst us. We can think and suggest lots of great policies, but what
then? It would help the process and our own satisfaction with it (and
subsequent energy to go on), if we could actually see after a year
(e.g.) that it did work, if only 33%.

Thanks for raising this issue!

Marc Schneiders
NCUC council rep

On Mon, 24 May 2004, at 11:48 [=GMT+1000], Bruce Tonkin wrote:

> Hello All,
>
> I have had a few questions related to whether a particular part of a
> task force report is specifying a "policy" versus a "specific
> implementation of the policy".
>
> The GNSO is "responsible for developing and recommending to the ICANN
> Board substantive policies relating to generic top-level domains."
>
> In general, with reference to the ICANN core value: "Where feasible and
> appropriate, depending on market mechanisms to promote and sustain a
> competitive environment.", the implementation of ICANN policies should
> be left to the competitive market.
>
> We need to ensure that the outcomes of a policy are clearly measurable,
> and therefore can be enforced.
>
> However part of a GNSO report on a policy recommendation needs to:
>
> (a) Include "An analysis of how the issue would affect each
> constituency, including any financial impact on the constituency;"
>
> and
>
> (b) include "An analysis of the period of time that would likely be
> necessary to implement the policy;"
>
> Probably the best way to be able to provide an analysis of how a new
> policy recommendation will affect each constituency, the financial
> impact of the recommendation, and the time need to implement the
> recommendation, is to consider a "reference" implementation of the
> policy.  The reference implementation should convince the community that
> the new policy will not negatively impact a constituency, and that the
> benefits of a new policy will clearly outweigh any additional cost to
> implement the policy.   The reference implementation is only one of many
> possible ways to implement a policy, and the market in general will be
> able to implement the policy in a range of different ways.
>
> For example, see the reference implementation of the new transfers
> policy at:
> http://www.icann.org/gnso/transfers-tf/report-exha-12feb03.htm
>
>
> To give a specific example.
>
> (1) New policy:
> "At least annually, a registrar must present to the Registrant the
> current WHOIS information, and remind the registrant that provision of
> false WHOIS information can be grounds for cancellation of their domain
> name registration. Registrants must review their WHOIS data, and make
> any corrections."
>
> (2) Reference implementation:
> For domains that are renewed each year, a registrar could remind the
> registrant, when they login to a website to renew a domain name, of the
> need to provide accurate WHOIS information, prior to renewing the name.
>
> (3) Other implementations:
> - a registrar could send an email once a year, with a copy of the
> current WHOIS information and requiring the registrant to update this
> information each year.
>
> (4) Measurement:
> - the registrar should keep a log of the reminders sent to each
> registrant and be able to report to ICANN on request.
>
>
> Task forces need to be careful to focus on what "new" polices are
> required, rather than waste time on discussing different implementations
> of existing policies.
>
> In some cases a task force may find that an existing policy principle is
> adequate, but that the policy does not seem to be applied in practice.
> This may need a new policy element to make it easier for ICANN to
> measure the adherence to a policy.
>
> When recommending new policies, task forces should give consideration to
> how the impact of a new change can be measured (e.g as part of a review
> process) and enforced.    It would be useful to establish a benchmark of
> the current situation, and thus be able to evaluate whether the new
> policy is successful in say 12 months time against that benchmark.
> This was not done in any of the recent policy recommendations from the
> GNSO.
>
>
> The generic issue of ICANN carrying out compliance monitoring and
> enforcement often seems to be related to ICANN resources to perform this
> function.  It would be timely for constituencies to raise any issues
> associated with compliance monitoring and enforcement through the budget
> committee as part of the current budget process.     The GNSO does not
> directly have a role in setting the ICANN budget.
>
> Regards,
> Bruce Tonkin
>
>
>
>
>
>
>
>




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