[DT-F] our task? Re: REVISED: Design Team F kickoff

Mon Apr 13 03:07:36 UTC 2015

I doubt that involving the CSC in the root zone process will be feasible based on what I understand to be a very limited oversight role for the CSC.

Chuck

From: Suzanne Woolf [mailto:suzworldwide at gmail.com]
Sent: Sunday, April 12, 2015 10:49 AM
To: Milton L Mueller; CWG DT-F
Cc: Gomes, Chuck
Subject: our task? Re: [DT-F] REVISED: Design Team F kickoff

On Apr 11, 2015, at 11:40 AM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

I think Suzanne is raising a number of really good questions. To me, they highlight the arbitrariness, if not the impracticality, of trying to break some of these issues into fragmented "design teams" that provide proposals after a week of discussion.

I'm not sure the situation is quite so grim as all that. I admit I'm dismayed that AFAICT the CWG effort hasn't gotten down to this level before, but maybe that demonstrates that the design team approach is getting us to issues we haven't tackled until now.

Suzanne is right that the post-NTIA relationship between IANA, RZ Maintainer, and a possible appeals or auditing process is intimately linked with general IANA-specific accountability measures, with the role and functions of the CSC, and so on. To me it seems to lend support to the idea of having an IANA-specific governance structure and a PTI board that includes representation from names, numbers and protocols as well as Rootserver operators.

I've tried to consider the questions (below) while being agnostic as to the answers (specific structures, etc.) To me the immediate task has to do with figuring out what we need to accomplish before we decide on mechanisms for doing it. (Trying to do this work and the CCWG-Accountability work feels to me a little like digging a tunnel from both ends; we're trying to "meet in the middle" on the needs created by the exit of NTIA and the mechanisms available to us as identified and analyzed by Sidley and the CCWG.) I'm attempting to draw strictly on operational experience, with IANA and elsewhere-- making sure we know what the routine workflow/oversight looks like so people can do their day-to-day jobs to the highest possible standard, and making sure there's some way to handle exceptions where something needs to be done but current SOP doesn't necessarily provide a proper basis for operational authority and decisions without NTIA.

Can someone remind me of what this DT is actually going to accomplish by Thursday?

It seems to me that we can resolve some issues and perhaps clarify others, but I've been accused of excessive optimism on a regular basis lately. :-)

As a modest proposal:

1. Identify the issues we actually have, starting with the operational questions:
            a. What involvement does NTIA have in the daily business of generating the production root zone?

  *   my understanding of NTIA's day-to-day role, per the workflow discussion in SAC068 (section 3.2), is that certain software waits for authenticated approval from an NTIA employee before a change can be entered into the database as approved for publication in the production root zone.
  *   What else?
            b. What other involvement does NTIA have in the day-to-day work of IANA (routine transactions, SOPs)?

  *   Facilitating resolution of issues with governments such as OFAC requests (SAC069, 2.1.3)
  *   I am not sure there is anything else like this, but let's be sure
            c. What are the other practical effects of NTIA's oversight role?

  *   The other questions I raised seem to appear here: NTIA has had an undocumented (AFAIK) but sometimes significant role in determining when changes in the overall RZM process are justified and providing oversight to make sure they're handled effectively
  *   Exception handling? (When something not covered by SOP comes up, is NTIA involved in resolving it? My impression is no, but we can check.)

2. Identify requirements to hand off to the rest of the CWG/other DTs (transition, authorization, CSC, etc.) and CCWG-Accountability for resolving the issues
            a. Software has to be changed so that the new workflow can be implemented.

  *   IIRC it's been decided we don't need to replace NTIA with another party in the same workflow; we need to eliminate that step. (verify)
  *   We do need to identify whose software is involved (ICANN's?)
            b. NTIA may need to be replaced or some new understanding may need to be reached as far as any other operational role (see 1.b. above)
            c. It seems to me to be a requirement that IANA be able to evolve its services and its ability to deliver them in the absence of NTIA.

  *   Someone needs to be able to approve a final decision to do something like sign the root
  *   Someone needs to be able to approve expenditures to investigate such a possibility, or the impact of implementing policy decisions such as new gTLD expansion on the day-to-day operations of the root zone generation and distribution system
  *   So far, AFAIK this kind of work has been done by ICANN, with an oversight role played by NTIA-- ICANN sponsored the research on DNSSEC deployment constraints, for example, but the RZM partners together made the relevant decisions and a contract revision was required. I see no reason for this to change but it does seem as if this oversight has to be accounted for somewhere-- whether the CSC, some function of the PTI (internal or external), some other basis for new accountability mechanisms such as new budget controls.
  *   NTIA has sometimes been considered to be part of an informal appeals path. I believe that exploring this is a task of the CCWG-Accountability.
            d. Other requirements we might identify

Does this help?

thanks,
Suzanne

-----Original Message-----
From: cwg-dtf-bounces at icann.org<mailto:cwg-dtf-bounces at icann.org> [mailto:cwg-dtf-bounces at icann.org<mailto:dtf-bounces at icann.org>] On
Behalf Of Suzanne Woolf
Sent: Friday, April 10, 2015 5:21 PM
To: Gomes, Chuck
Cc: CWG DT-F
Subject: Re: [DT-F] REVISED: Design Team F kickoff

On Apr 10, 2015, at 2:54 PM, "Gomes, Chuck" <cgomes at verisign.com<mailto:cgomes at verisign.com>> wrote:

I agree that RSSAC involvement on issues such as DNSSEC and IPv6
implementation is needed but I don't think that CSC would have any role
there, at least not as I think DT-C is envisioning the CSC.  If I am correct that
it will not be CSC, then I guess we need to decide who it would be.

Right, apologies if I misunderstood the scope of DT-C or the CSC-- just trying
to make sure the bases are covered.

The concern about authorizing process or technology changes is a general
one, not only having to do with issues that touch on the technical details of
the content of the zone. It's simplified vastly by the assumption that policy is
developed elsewhere, and the concern here is oversight of implementation,
but there's still a need to make sure we're not either dropping pieces of
NTIA's role or creating new constraints inadvertently. (There may be new
constraints we want to enable, but I'm assuming we'd need a clear
rationale.)

Assuming our whole scope is "NTIA as authorizer disappears" and we're
assuming all else remains equal, what attributes/responsibilities of the other
two partners change?

As a related but perhaps less direct question, do we need to look more
specifically at the impact of new accountability mechanisms? Not that we
can do so in detail while they're still under development, but can/should we
suggest some guidelines for evaluating their effects on this core of IANA's
role in the root zone? The budget one is obvious to me, are there others?

I hope these are helpful questions. I may not be not entirely clear on what
questions are in scope.

best,
Suzanne

-----Original Message-----
From: cwg-dtf-bounces at icann.org<mailto:cwg-dtf-bounces at icann.org> [mailto:cwg-dtf-bounces at icann.org<mailto:dtf-bounces at icann.org>] On
Behalf Of Suzanne Woolf

Sent: Friday, April 10, 2015 12:41 PM
To: Alan Greenberg
Cc: CWG DT-F
Subject: Re: [DT-F] REVISED: Design Team F kickoff

On Apr 9, 2015, at 10:31 PM, Alan Greenberg <alan.greenberg at mcgill.ca<mailto:alan.greenberg at mcgill.ca>>
wrote:

Thanks for this Suzanne,

No way would I disagree with you and Chuck about wanting to keep all
useful communications paths open. Nothing that we will likely do in this DT
should impact this, although I think that going forward (post this DT), we
may want to do a bit of documentation. Since changing the Root Zone
Maintainer is both out of our scope and nothing that we would want to do
in parallel with the change to remove NTIA, I think that we can safely say
that it will be business-as-usual regarding the Root operators.

Agreed on this, and agreed on the exception:

One issue that we probably SHOULD be looking at though, is whether we
need to replace whatever role NTIA has played (if any) in the critical
decisions/changes such as DNSSEC or IPv6.

Oh indeed, and this was IMHO the argument in favor of including
representation for RSSAC on the CSC, as additional insight as IANA services
need to be monitored and might need to evolve. I'm not coming from a
position of deep conviction on the question, it just seems to me something
that should be explored, partly because I'm not fully sure of the scope of the
CSC in regards to such a decision process. (IOW my interest isn't in
"representation" per se, it's in making sure that stakeholders who have to
deploy and live with an operational change are able to provide feedback on
planning and implementation.)

There's no documented process of which I am aware for such decisions, so
I don't know exactly what NTIA's role has been. I know they've informally
consulted root server operators, including via their RSSAC liaison.

New constraints on IANA's budget, either its structure or oversight, should
be reviewed to make sure they're not inadvertently taking away the ability
to investigate, plan, implement, or monitor the impacts of such changes--
not just for consulting the root server operators, but more generally.

thanks,
Suzanne
_______________________________________________
cwg-dtf mailing list
cwg-dtf at icann.org<mailto:cwg-dtf at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-dtf

_______________________________________________
cwg-dtf mailing list
cwg-dtf at icann.org<mailto:cwg-dtf at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-dtf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150413/37a4a710/attachment-0001.html>