ICANN/GNSO GNSO Email List Archives

[council]


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

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

  • To: <council@xxxxxxxxxxxxxx>
  • Subject: [council] Separation of policy and implementation in task force reports
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Mon, 24 May 2004 11:48:37 +1000
  • Cc: <dow3tf@xxxxxxxxxxxxxx>, <dow2tf@xxxxxxxxxxxxxx>, <dow1tf@xxxxxxxxxxxxxx>
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcRBMTp2p4fVOCEhRsiGxpfHyoAv7A==
  • Thread-topic: Separation of policy and implementation in task force reports

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