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