Fred,
we went into the topic of whether a separate MoU was required at the beginning of December (thread with subject "Adminrest: IASA BCP: Separability", subthread started by brian Carpenter on December 2), and concluded that no other document should be necessary.
A few cycles ago, while we were still waiting for ISOC's next round of feedback, some of the debate was phrased in terms of "specify what the IETF wants the IASA to do" - assuming that ISOC would state whether or not it could fulfil those requirements. I believe that ISOC has now done so, without raising any issues that require "major surgery", and that the BCP is a sound basis for going forward with setting up this activity within ISOC. (If not - better get those comments in now!)
WRT the BCP's legal status - I don't think it can be an agreement per se - if IETF is considered legally part of ISOC, such an agreement is a part agreeing with a whole, which doesn't seem to make sense. What it can be treated like is the output of a planning process, which ISOC can then commit to implement - and in this case, a planning process that has provisions for how the resulting plan should be changed (BCP update), which we would also expect ISOC to agree to.
As I said then - I get rather nervous when I get presented with scenarios where I would sign agreements with ISOC on behalf of the IETF, when the only legal cover I have for this not being my personal responsibility is that I'm part of ISOC.
No disagreement on the need to revise RFC 2031 - but I think that's a job for my successor to undertake.
Harald
--On 19. januar 2005 10:52 -0800 Fred Baker <fred@xxxxxxxxx> wrote:
At 09:33 AM 01/19/05 -0800, Ted Hardie wrote:Again, I don't have any concerns about how these issues are met, but I want us to be very, very clear on what we are asking for from ISOC.
I think also that we need to be very sure that we know what the BCP is. What your words above - and other comments you have made in this forum - make it sound like is "the BCP is the IETF's request to ISOC". What I have heard from others is that "the BCP is the IETF's commitment to ISOC". Here I would gently demur, pointing out that there is actually no commitment made by IETF towards ISOC in the BCP; rather, IETF is identifying here what it expects *ISOC* to do for *it* (set up the IASA, hire and pay the IAD, manage budgets, fund-raise, deliver accounting information, and so on). When we hear requests for ISOC to pass a resolution (or something more) "to support the BCP", I understand it to be "the agreement between IETF and ISOC".
Those are very different things.
If the BCP is the IETF's request to ISOC, then the agreement between IETF and ISOC is a different document, and the ISOC Board should pass a resolution supporting *that* document. If the BCP is the agreement between ISOC and IETF, and IETF expects ISOC to pass a resolution supporting it, then what we are discussing here is what ISOC and IETF will actually do, not what one side is requesting of the other.
What ISOC will actually do is ensure that it has the ability to perform all of its functions when the chips are down. One of those functions is the IASA.
How would you like to document that?
By the way, before we are done, I believe that the IETF and ISOC should update our MOU. The current MOU is RFC 2031, and is badly out of date even with respect to current commitments ISOC has made to the IETF. The updated MOU should, I believe, not only describe the expectations that IETF has of ISOC, but the expectations that ISOC has of the IETF, in terms of supporting its educational and public policy activities through counsel, position papers like RFC 1984, and personnel.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf