[DT-F] Design Team F kickoff

[Milton L Mueller]

I have to agree with David that we do not have time or the resident expertise in this group to propose new operational procedures for RZM.
Identifying issues and requirements might be a good fallback position but even there, I don't think we have sufficient time.
David's proposed principles are a nice starting point but are quite generic and I don't see the value of calling for things like "accuracy" - no one will argue for inaccuracy and unless we can propose a framework that we believe improves accuracy, stability, etc. I am not sure of the value of such an exercise.

I suggest that we continue working on this beyond the 4 days and start adjusting our framework to the proposed model that the CWG seems to be converging on.
--MM

From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of David Conrad
Sent: Monday, April 6, 2015 11:48 PM
To: Alan Greenberg
Cc: CWG DT-F
Subject: Re: [DT-F] Design Team F kickoff

Hi,

Given the looming deadline (4 days?!), I remain uncertain there is sufficient time for us to both identify the salient issues and come up with a new architecture for root zone publication, particularly since these would appear to be serial operations.  In addition, I suspect revising the root zone architecture to address the identified issues is probably going to require a bit of thought from a variety of folks not necessarily represented on the the design team (e.g., the root server operators and the IAB to name a couple).  Perhaps a more realistic approach would be to identify the issues/requirements and propose a framework (similar to what the IETF and RIR folks have done in different contexts) under which a new architecture can be devised? (My quarter-baked thought would be to have the CSC form an ad hoc group of technical experts who would propose a revised architecture for subsequent public comment, but will admit I haven't thought much about the process by which stuff like this happens).

In any event and to start off, in terms of principles, I'd offer as a first cut (in alphabetical order):

  *   Accountability: all activities associated with root management must be unambiguously attributable to an authorized actor and that actor must be held responsible for those activities.
  *   Accuracy: all changes must be implemented with no errors.
  *   Auditability: all activities that impact the public that are performed by root management actors must be recorded.
  *   Improvability: root management must be able to evolve to meet the changing Internet.
  *   Predictability: there should be no surprises associated with root management processing.
  *   Security: no unauthorized entity should be able to make a change and only the changes requested are the ones that are implemented.
  *   Simplicity: the root management systems must be as simple as possible ("but no simpler").
  *   Stability: the processes related to root change requests should be consistent over time with any changes well documented and introduced with appropriate lead time.
  *   Standards-based: interactions between actors in root management should be based on open standards; no proprietary mechanisms or interfaces should be used between actors.
  *   Transparency: changes made as part of root management, and the policies upon which they are based, must be visible to interested stakeholders.
  *   Resiliency: it must be possible to quickly recover from a failure in any part of the system (even if the failure remains present).
  *   Robustness: single points of failure must be minimized or mechanisms must be in place to mitigate their impact.
Note that some of these principles may tend to be in opposition to each other (e.g., a simple solution may not be the most secure or robust).

I'm sure I missed some principles...

Regards,
-drc

From: Alan Greenberg <alan.greenberg at mcgill.ca<mailto:alan.greenberg at mcgill.ca>>
Date: Monday, April 6, 2015 at 3:22 PM
To: CWG DT-F <cwg-dtf at icann.org<mailto:cwg-dtf at icann.org>>
Subject: [DT-F] Design Team F kickoff

Although the template for DT-F (Relationship between the NTIA, IANA and the Root Zone Maintainer) has not officially been approved, I see no reason on to start the work, all the more so since the target completion date is just 4 days away. We are likely to miss that deadline, but I would like to keep the slippage as small as possible.

The draft template is attached. The DT members are:

Jaap Akkerhuis

Gary Campbell

Jordan Carter
David Conrad

Alan Greenberg

Milton Mueller

Rudi Vansnick



Bernie Turcotte and Grace Abuhamad will be providing staff support.



David is arguably the person with the deepest knowledge of the subject,

and can hopefully provide some insight into the issues.



As I see it, we have two parts to our task. The first is to identify the

salient issues in a post transition IANA with relation to the Root Zone

Maintainer (RZM), and then to propose an architecture for publication of

the Root Zone.



As a first step, I would suggest that we identify any:

- principles we wish to adhere to (such as transparency, auditability);

- problems (or potential problems) with the current process;

- Current NTIA operational involvement and if/how this needs to be

replaced or compensated for.



Current processes are documented in

<https://www.icann.org/en/system/files/files/sac-067-en.pdf>

https://www.icann.org/en/system/files/files/sac-067-en.pdf, pages

10-22.



Alan


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