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 mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf