Re: [Ianaplan] CWG draft and its impact on the IETF

[Bernard Aboba <[e-mail]>]

Brian said:

"(This of course shows why the PTI is a pointless idea, but that isn't our
discussion here.)"

[BA] +1 to that!

Unless there is an intent to institute fees, PTI would appear to be a
subsidiary with no revenue and all costs.  Those costs would probably be
higher than the present arrangement, due to the fees required to form the
subsidiary, as well as the costs of operating the subsidiary (e.g.
additional accounting, legal, personnel, etc. expenses) So given that PTI
is going to cost someone (ICANN or the communities or both) something, it
needs to provide some definite benefit to compensate.  However, from what I
can see, there is none.

Typically wholly owned subsidiaries of a non-profit are created in
situations where the subsidiary is expected to generate a profit, not a
loss.  Since the subsidiary is wholly owned by ICANN, the financial results
can be consolidated, but consistently money-losing entities have a way of
garnering extra scrutiny from taxing authorities (and from the executives
and board members of the parent company).


On Mon, May 11, 2015 at 1:26 PM, Brian E Carpenter <
[e-mail]> wrote:

> I think it's simple enough. If the proposed PTI is a wholly owned
> subsidiary of ICANN, the overarching IETF agreement still needs to be
> with ICANN. Obviously operational additions such as the SOW and SLA
> could be with the subsidiary.
>
> (This of course shows why the PTI is a pointless idea, but that isn't
> our discussion here.)
>
> Regards
>    Brian
>
> On 12/05/2015 06:42, Eliot Lear wrote:
> > Hi everyone,
> >
> > I'm writing this with an eye toward a conversation that perhaps the IAB
> > and IAOC might find useful, as they consider various activities relating
> > to the IANA transition.
> >
> > Over the last week or so, I read through the CWG proposal for the naming
> > component of the IANA functions transition proposal.  That proposal can
> > be found at [1].  I'm posting some comments here strictly as relates to
> > the IETF relationship with ICANN, and not the rest of it, since that
> > discussion should occur elsewhere.
> >
> > The basis of the naming community's proposal is to create a new entity
> > to take on the IANA functions, known as Post-Transition IANA (PTI)[2].
> > That entity would be a wholly owned subsidiary of ICANN, but have its
> > own management structure, including a customer service component, known
> > as the Customer Standing Committee.  All current IANA functions would be
> > transferred to the PTI under this proposal.  A multistakeholder IANA
> > Function Review  (IFR) process is created as well.  In a sense, the
> > proposal is vaguely reminiscent of our own arrangements.  In particular
> > it seems that the names community also wants to a customer relationship
> > with the IANA Functions Operator (IFO) and to have the choice to change
> > providers, should that ever become necessary.  There's a bunch of
> > mechanism proposed to reduce the likelihood of a change, including
> > escalation, a separation review, etc., but at the end of the day the
> > choice would be the naming community's, just as the IAB has had the
> > choice to continue the protocol parameters arrangement.
> >
> > How does this affect the IETF?
> >
> > First, if all functions are meant to be transferred to the PTI, it seems
> > that the IAB would have to agree to an assignment, per the terms of
> > RFC-2860.[2]  Second, since for the first time the naming community
> > would have a choice in whether they wish to change IFO, we have to ask
> > the question, “What if they did?”  What would happen to the PTI?  What,
> > in particular, are the funding implications?  It has always been
> > possible for ICANN or the IAB to terminate the arrangement.  If that
> > happened, however, the IAB and IAOC would have to work with ISOC to
> > determine a funding source for a new IFO for protocol parameters.
> >
> > It's worth noting that NRO Executive Council has stated that they wish
> > to retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB
> > could do the same, but then it seems to me that the value of the PTI
> > itself is diminished.  And so that brings us back to the cardinal
> > question: what's right for the Internet?  Here I understand that
> > different people will have varying views.
> >
> > Having the burden of funding shift to another source can itself be a
> > source of instability.  The CWG proposal contains the FY15 budget costs
> > for the IANA function.  That total is $6.3 million[6], but includes
> > indirect and shared costs as well.  What isn't in those costs is an
> > allocation across functions.  At the very least we should have that
> > information.  Preferably we should have those costs separately funded,
> > to the extent possible.  This would provide the naming community all the
> > freedom they want, and us all the freedom we want, without budgetary
> risk.
> >
> > Having written that last line, I feel the need to once again point out
> > what we said in our response, that we are satisfied with the performance
> > of ICANN as IFO, and have been for quite some time, and that all of this
> > is still contingency planning.[5]
> >
> > And so questions:
> >
> >   * Under this new arrangement, does it make sense to continue the
> >     relationship with ICANN as it stood before or does it make sense to
> >     go directly to PTI?
> >   * If the arrangement is with PTI, should we seek a budgetary
> >     separation, and what would be the complexities of that?
> >
> > I think there may be other questions for the CWG proposal, but to me
> > these are the big questions.
> >
> > Eliot
> > [1]
> >
> https://www.icann.org/en/system/files/files/cwg-stewardship-draft-proposal-with-annexes-22apr15-en.pdf
> > [2] See III.A bullet 1.
> > [3] RFC 2860
> > [4] Message from Axel Pawlik to [e-mail] on 10 May 2015,
> > "Numbers community proposal contact points with CWG’s Draft IANA".
> > [5] draft-ietf-ianaplan-icg-response.
> > [6] See Annex P of the CWG draft.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Ianaplan mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ianaplan
> >
>
> _______________________________________________
> Ianaplan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ianaplan
>