[CWG-Stewardship] Service Level Expectations Design Team Template

[James Gannon]

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

I for one would hope that we treat any suitably qualified people who volunteer in an area equally regardless of who their employer is, considering the work output of a DT comes back to the CWG as a whole I don't see any overt conflict of interest. ICANN staff are stakeholders here too.

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of David Conrad
Sent: Monday, March 02, 2015 2:50 AM
To: ceo at auda.org.au
Cc: cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] Service Level Expectations Design Team Template

Chris,

On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo at 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