Dear Colleagues, I fully support direct staff involvement into this DT. May I also suggest, as one non exhaustive input, to request Icann staff to disclose what metrics it relies on ? Icann has been recognized as "committed to excellence" in sept 13 following the EFQM framework (https://www.icann.org/news/blog/iana-technical-operations-department-recogni...). I am quite familiar with this quality framework and I am certain they have a set of existing metrics in terms of service to customers, as well as targets for these metrics. Best Mathieu Le 02/03/2015 12:22, Lise Fuhr a écrit :
Dear all,
We have no objection to David's involvement, it is important to have as much knowledge as possible gathered in the teams (without the team becoming too big).
Best, Jonathan and Lise
-----Oprindelig meddelelse----- Fra: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] På vegne af David Conrad Sendt: 2. marts 2015 03:50 Til: ceo@auda.org.au Cc: cwg-stewardship@icann.org Emne: Re: [CWG-Stewardship] Service Level Expectations Design Team Template
Chris,
On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with? First, the potential areas of change need to be identified. There are three obvious ones:
1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation.
2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone).
3) NTIA's role in specifying/accepting reporting of actions taken by IANA.
There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world.
Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above):
1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic.
2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle.
3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability.
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill@afnic.fr Twitter : @mathieuweill *****************************