[CWG-Stewardship] Service Level Expectations Design Team Template

[Lise Fuhr]

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 at icann.org
[mailto:cwg-stewardship-bounces at icann.org] På vegne af David Conrad
Sendt: 2. marts 2015 03:50
Til: ceo at auda.org.au
Cc: cwg-stewardship at icann.org
Emne: 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