[DT-F] Design Team F kickoff

[Jordan Carter]

Hi folks,

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

> Milton,
>
> There is no possibility that IANA or ICANN will assume the RZM function in
> the near term. NTIA has deliberately reserved that from the transition and
> it is politically sensitive in Washington.
>
>
> While I agree there is no possibility ICANN will assume the RZM function
> (I don't think is remotely feasible politically, but that might just be
> me), I thought NTIA made it clear that the RZM function was a part of a
> parallel transition:
>
>
> http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ
>
> *"Q. What impact does this announcement have on the cooperative agreement
> with Verisign?*
>
> A. Aspects of the IANA functions contract are inextricably intertwined
> with the VeriSign cooperative agreement (i.e., authoritative root zone file
> management), which would require that NTIA coordinate a related and
> parallel transition in these responsibilities."
>
>
And yet nobody has heard anything here...


>  If there is movement of the IANA department into a legally separate
> affiliate with a board that is independent of ICANN, the thought of PT-IANA
> assuming the RZM functions is not so scary.
>
> Sorry, you lost me.  If I understand Jordan's concern, the worry is about
> concentrating operational control in a single entity.  I understand and
> personally agree with that concern.  But what would it matter if the single
> entity is ICANN or "a legally separate affiliate with a board that is
> independent of ICANN"?  In either case, wouldn't a single entity have
> complete power/responsibility for generating the root zone?
>
>
Yes, and that is what my concern was addressing. I understand why it might
be seen as less scary... but, see next:

> It might be good to catalogue the benefits and drawbacks of separating the
> RZM from the IANA function as part of the output of this group. If we
> understand and articulate better the purpose of the separation, our
> proposed framework might be better able to understand the requirements.
>
> Agreed.  From my perspective, the primary benefit of separating functional
> components is to facilitate "two person rule" controls, making it much
> harder for either accidental or malicious changes to be made to the root
> zone (such changes would require collusion of two independent parties).
> The primary downside is increased complexity with all that implies to cost,
> security, stability, etc.
>
> What that functional decomposition should be is likely a topic for a
> different set of people and a whole lot more time.
>

Well, the status quo is three parties. Aren't we tasked with describing
these relationships and making proposal recommendations that respond to
that reality?

Going from three parties to two doesn't count as increased complexity -
it's increased simplicity. Since no-one in the short run is proposing to
integrate root zone management with the IANA functions operator, I think we
can confidently state the likely outcome in this respect is simpler than
the status quo...

Jordan


-- 
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/1ac3b312/attachment.html>