Hi.
As we try to raise other things back to the level of principles,
I want to address one that seems to underlie some of the
thinking that has led to what I believe to be too-specific, and
probably misguided, provisions in the draft.
That underlying theme is, more or less, "Suppose ISOC goes
crazy, gets into internal financial problems, and decides to
divert all available funds into core ISOC staff support,
networking on Mars, wild parties, or other non-IETF activities?
How do we prevent that and/or be sure that IETF funds and other
resources are safe from that process?" From talking with some
of the advocates of what became Scenario C, a concern like that
is part of what drove them to want some structure completely
separate from ISOC. And, despite the decision to proceed
toward Scenario O, it appears that the theme keeps recurring, so
maybe we should just take a real look at it. It seems to me
that there are three issues:
(1) Are there safeguards that lower the odds of a
serious problem with ISOC and reduce the risk of
requiring a separation to an acceptable level?
(2) To the extent to which good, and clear, agreements
make good relationships, what style of provisions are
needed?
(3) If we should be thinking about things in terms of
"blowing of explosive bolts", at what points should such
bolts and separation points be installed?
The first of these comes dangerously close to revisiting the
"Scenario O" decision, but, since the issue doesn't seem to want
to go away from I* thinking despite the community's decision,
maybe it is worth opening explicitly. Let me take the three in
turn:
(1) Existing safeguards.
At least in the conversations I have had, two themes have arisen
about the need for safeguards in how ISOC deals with the IAOC
(and IASA more generally). One is tied to the perception that
CRNI has become non-responsive to IETF requests (the validity of
that perception for different areas is a different issue) and
asking what would prevent ISOC from going down a similar path.
The other recalls ISOC's financial problems of a few years ago
and the desire of some of the then-members of the ISOC Board to
shift resources away from the IETF and toward other activities.
ISOC saw that Board behavior as a problem, and instituted some
major structural changes to to prevent recurrences while
continuing to support IETF at requested levels. We've now got
IAB-appointed members of ISOC's Board and, by contrast, have
never had IETF-appointed or approved members of CRNI's Board.
While the IAB-appointed members of ISOC's Board do not
"represent the IETF", IAB would need to turn quite stupid to
appoint people who could not be reasonably assumed to consider
and advocate for things that are as obviously in the IETF's
interest as not diverting IETF-designed funds for other
purposes. If the IAB were to turn that stupid, we have problems
that no text in a BCP is going to solve. And, as I have said
before, my own experience is such that I actually prefer an
organization that has had problems, faced them, and dealt with
them effectively than one that does not yet exist and whose
behavior under stress therefore cannot be predicted. We are
also structuring this arrangement so that it is basically an
IETF support arrangement, rather than a service that ISOC is
carrying out for the IETF at their discretion (which is probably
a reasonable description of the CNRI relationship). The two
situations are very different; trying to build plans that start
from the assumption that they are, or might be, equivalent, just
does not impress me as completely rational.
(2) Agreements.
Let me argue, as others have, for principles here, not
micromanagement specifics. I think Margaret's outline is a
little too abstract, but there is a middle ground between it and
talking about bank accounts. I think Bernard's idea/ analogy
to pre-nuptial agreements is probably exactly right, and I
believe that we need to get competent professional advice on how
one of those should be structured and what needs to be in it ...
not start slipping "bank account" or equivalent provisions into
a BCP based on the financial administration experience of the
IESG and IAB. Even from the standpoint of my limited knowledge
in the area, there is a huge difference between asking for
"separation of funds" and "sound accounting and administrative
practices" or even "escrow arrangements" and getting down to
bank accounts and lengths of times funds can be held. I note
that, in general, prenuptial agreements are arrived at by
parties who like and trust each other, expect and intend to make
the relationship work, and expect to put effort into making it
work. When those relationships don't hold, the parties don't
need prenuptial agreements; they need to not get married.
FWIW, my interpretation of the "Scenario O" decision is that we
have decided to get (a little more) married.
(3) Where to install the explosive bolts
While I fear that I participated in an early version of this
discussion, it has taken on an air of unreality. But, assuming
it is necessary at all, we should look at experience and
contingencies sufficiently to figure out the right places to
place those bolts. In the ISOC case, we've seen them face a
crisis in whether to support the IETF in the light of tight
funding. We have seen them resolve that crisis by (i)
supporting the IETF at requested levels throughout, (ii)
changing their financial arrangements to reduce the level of
risk -- not just through the PIR arrangements but through
arrangements for funding earmarked for IETF purposes, and (iii)
changing their organizational structure to lower future risk.
If we need "bolts" there, let's install them, but let's do so in
terms of Bernard's pre-nuptial analogy and my observation about
marriages above: these are safeguards to prevent
misunderstandings should a relationship that all of us expect to
work out, and intend to work hard to make work out. They should
not be than the sorts of provisions one might want with a party
that is presumed to be either hostile, incompetent, or both.
But let's also look at what our history suggests may be the
higher-risk point. While ISOC has been quite dependable,
despite a few scares, the IETF community has had experience with
its internal leadership mechanisms getting out of touch with the
community. Slightly over a decade ago, we had an IAB that had
gotten sufficiently insular, and had developed enough of a
tendency for its members to talk with each other rather than the
community, that it started substituting its judgment for that of
the community. We ultimately needed to fix that problem by a
fairly major restructuring of how we did things. Whether
accurate or not, if we listen to many of the comments during the
"Problem Statement" process, there is some view in the community
that the IESG has gotten at least as out of touch, and at least
as non-responsive, as the IAB was pre-Kobe. On a particularly
bad day, some of us might even suspect that the ways in which
the IESG and/or IAB have interacted with the community on this
restructuring process, and even claimed "rights" to make the
decisions for us, are an indication that they have gotten even
more seriously out of touch than the Problem Statement process
identified.
So, is the risk zero that the IAD and IAOC will get out of
touch, become non-responsive, and decide it is time to use the
IETF's funds for some really nice parties in warm places? Our
experience is that it is not (even though the "old" IAB was
extremely careful to not tap anything resembling IETF funds for
their legendary wine-consumption dinners). We can't even
predict whether they would invite the IAB and/or IESG to
participate in the parties. Trying to solve imagined possible
problems with ISOC by creating separate IASA bank accounts,
under exclusive IAD and IAOC control, _increases_ the risk of
this sort of abuse running away from us, rather than decreasing
it (while sound accounting practices and accountability actually
helps). I note that we know where to find ISOC: if there were
to be serious abuses that go beyond agreements about principles,
they have assets, they maintain offices, they are accountable to
donors of restricted funds, and so on. We have fewer of
those inherent protections with the IAOC and IAD.
Conclusion and recommendation: If folks are serious about
needing to worry about provisions to "blow the bolts", then
let's see the proposals for the IETF Community's being able to
blow the bolts separating it from the IASC while retaining all
of the relevant assets and controls. To the extent to which the
IAOC is driven from the IESG and IAB, let's see the proposals
for the community blowing the bolts that could separate it from
those bodies if they get out of line and unresponsive on
administrative matters.
If that analysis is done carefully, we might just discover that
having ISOC in the loop is part of the mechanism by which the
community protects itself against potential IAOC/IAD abuses.
Indeed, that possibility was one of the reasons why some of us
favored "Scenario O". Conversely, if the would-be bolt
providers and blowers cannot or will not develop those other
recommendations, but keep pushing the "blow bolts between IASA
and ISOC" one, I think we need to start wondering whether what
we are really seeing is an "ignore the community preference and
transform Scenario O back into Scenario C" plan.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf