[DT-F] Design Team F kickoff

[David Conrad]

Jordan,

You appear to be assuming the multiple functions performed by both the "IANA
Function Operator" and the "Root Zone Maintainer" roles are
fixed/unchangeable. Post-transition, there would appear to be nothing that
requires this to be the case and I've argued elsewhere (e.g.,
http://mm.icann.org/pipermail/cwg-stewardship/2015-January/001458.html) that
if resistance to insider threats is a goal, the current NTIA-mandated
partitioning of functionality is not optimal.

Perhaps a better approach would be to identify what you are trying to
disallow/protect against by imposing that restriction? What problem are you
trying to solve?

Regards,
-drc

From:  Jordan Carter <jordan at internetnz.net.nz>
Date:  Tuesday, April 7, 2015 at 3:41 PM
To:  David Conrad <david.conrad at icann.org>
Cc:  Milton L Mueller <mueller at syr.edu>, CWG DT-F <cwg-dtf at icann.org>
Subject:  Re: [DT-F] Design Team F kickoff

> There's one thing that might be an elephant in this room or might not - which
> is the possibility or otherwise of the RZM being ICANN/IANA.
> 
> Without having discussed it with those who are actively working on these
> things, I think a line of business restriction on ICANN or IANA from ever
> doing that job themselves should be part of the transition plan.
> 
> Is it possible to link through to any content that could give us guidance on
> the *output* we need to deliver from this DT? Or is that the framework we need
> now to build (agreeing that doing so in 4 days isn't doable)?
> 
> cheers
> Jordan
> 
> 
> On 8 April 2015 at 10:05, David Conrad <david.conrad at icann.org> wrote:
>> Milton,
>> 
>>> 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 had thought the idea behind the framework was that it would come up with
>> the mechanisms by which the root management system could  evolve, including
>> such areas as accuracy, stability, etc., instead of having us come up with
>> that evolution (in 3 days and counting).  This isn't suggesting that anyone
>> would argue for inaccuracy, rather it is suggesting that it would be good to
>> have a process by which the existing system can be improved.
>> 
>> My understanding of the call for principles was to make sure we were all on
>> the same page with regards to what we wanted to address in terms of the
>> characteristics of the post-NTIA root management system.  I don't have a
>> strong opinion on that matter, but figured it might be helpful.
>> 
>>> 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.
>> 
>> A step before that would be to actually have a framework, no?
>> 
>> Regards,
>> -drc
>> 
>> 
>> _______________________________________________
>> cwg-dtf mailing list
>> cwg-dtf at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-dtf
>> 
> 
> 
> 
> -- 
> Jordan Carter
> 
> Chief Executive 
> InternetNZ
> 
> 04 495 2118 (office) | +64 21 442 649 (mob)
> jordan at internetnz.net.nz
> Skype: jordancarter
> 
> A better world through a better Internet
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150408/7979a1a2/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/20150408/7979a1a2/smime-0001.p7s>