[DT-F] Design Team F kickoff

[Jordan Carter]

Thanks David.

The problem is the concentration of power/responsibility in what is
currently a three-party process but which will soon be a two-party one (if
the authorisation function is not replaced) with a single monolithic entity
doing all this.

Milton's points also are relevant. If we can't articulate a view as to the
benefits of separation then there'd be no case in integrating them...

cheers
Jordan

On 8 April 2015 at 12:18, David Conrad <david.conrad at icann.org> wrote:

> 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 *
>
>


-- 
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/85a8afd8/attachment.html>