[DT-F] Design Team F kickoff

[David Conrad]

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>
Date:  Monday, April 6, 2015 at 3:22 PM
To:  CWG DT-F <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/7b457131/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150407/7b457131/smime-0001.p7s>