Subject: One last word on operational reserves

From: Fred Baker <[email-masked]>
Date: Wed, 19 Jan 2005 07:46:00 -0800

The ISOC board has been following the development of the Structure of the 
IETF Administrative Support Activity (IASA) Internet Draft and some of the 
board members have been participating in the discussion.  The board feels 
that this draft is something that the board can readily agree to support 
and agree that the ISOC will accept the responsibilities of ISOC as 
described in the document.

That said, there may be some disagreement over the meaning of section 5.6 
that should be cleared up before the document is ratified by the IESG and 
some people may have some unrealistic expectations of generating a running 
financial surplus (which we will discuss in a separate message since it 
does not impact the text of the draft)

The second paragraph of Section 5.6 reads (in the -04 version of the draft)
    The IASA expects ISOC to build and provide that operational reserve,
    through whatever mechanisms ISOC deems appropriate: line of credit,
    financial reserves, meeting cancellation insurance, and so forth.  In
    the long term, financial reserves are preferable; it should be a goal
    for ISOC to reach this level of reserves within 3 years after the
    creation of the IASA.

This paragraph could refer to an IETF (IASA)-specific operational reserve 
or to the overall ISOC operational reserve.  The ISOC plans to build up an 
operational reserve to protect all of the ISOC's activities, including the 
IETF-related ones.  The board thinks that this is the appropriate way to 
proceed.  Rob Austein suggested that maybe this paragraph should be removed 
(see http://www1.ietf.org/mail-archive/web/ietf/current/msg33748.html). 
Either removing the paragraph or revising it to make it clear that it is 
referring to the overall ISOC operational reserve would remove the 
potential for misunderstanding. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 19 Jan 2005 17:12:14 +0100

--On onsdag, januar 19, 2005 07:46:00 -0800 Fred Baker <[email-masked]> 
wrote:

> or to the overall ISOC operational reserve.  The ISOC plans to build up
> an operational reserve to protect all of the ISOC's activities, including
> the IETF-related ones.  The board thinks that this is the appropriate way
> to proceed.  Rob Austein suggested that maybe this paragraph should be
> removed (see
> http://www1.ietf.org/mail-archive/web/ietf/current/msg33748.html). Either
> removing the paragraph or revising it to make it clear that it is

Fred,

thanks for the encouraging words!

I *think* this is a "not a problem" thing.... I believe the intent is that 
IETF can say "we think we need 6 months reserve for our stuff", and ISOC 
can say "that's no problem - we have general reserves that are larger than 
your 6 months + the reasonable risk on other stuff".

I think IASA should have the right to know if ISOC's reserves are smaller 
than the ones mentioned here, or if ISOC is at significant risk of having 
to eat through its reserves on other things - but I see this wording as 
saying "we need to be reasonably sure that the money is there if we really 
need it", not "you need to do something special just for us".

I wouldn't have that much issue with removing everything after "The IASA 
expects ISOC to build and provide that operational reserve" - I think that 
needs to remain, because an alternative reading of the previous paragraph 
without that context would be "IASA expects to build up that reserve out of 
its own budget", which is a course of action I believe we have considered 
and rejected.

But let's see what other people say....

                     Harald

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Jan 2005 09:33:21 -0800

At 5:12 PM +0100 1/19/05, Harald Tveit Alvestrand wrote:
>
>I *think* this is a "not a problem" thing.... I believe the intent 
>is that IETF can say "we think we need 6 months reserve for our 
>stuff", and ISOC can say "that's no problem - we have general 
>reserves that are larger than your 6 months + the reasonable risk on 
>other stuff".

I agree that however it is ISOC can say "that's not a problem" is sufficient,
whether insurance, operational reserves, etc.  But I believe we need to
be very careful on saying that general reserves are equivalent to the
operational reserve we've requested.  I believe we are asking the ISOC
to ensure that they have this level of protection pretty much no matter
what happens to its other programs, and I believe that we need to be
very frank that this is what we're asking for.  If ISOC says "we can ensure
the following level of reserve, which covers 6 months of IETF activity assuming
all else is at least marginal and 3 months if every other program 
goes belly up",
then we need to know that's what they're saying.

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.
And if we need to change those requests to be a reasonable partner to ISOC,
okay.  But that clarity could save a lot of pain later on, and I think it is
important.  The smallest amount of hand-waiving here and now can result in
lots of wind later on.
		regards,
			Ted Hardie

---

From: Steve Crocker <[email-masked]>
Date: Wed, 19 Jan 2005 13:04:33 -0500

I'm glad we're drilling down into this level of specificity.  I sit on 
the ISOC board and also on the IASA Transition Team, so I'm reading this 
with both my ISOC hat and a "proto-IAOC" hat on.  (But I'm speaking just 
for myself, not others on the board or the transition team.)

We can try to tighten the words down, and it may be a good thing to do 
so, but I think there's already a fairly strong primary line of defense 
that will come into operation.  ISOC provides pretty strong visibility 
into its finances and will continue to do so.  It will establish, as a 
matter of practice, the necessary reserves, and it will label and manage 
those reserves in a fashion that makes it clear that there is enough 
money for IASA's operational needs.  And in the event there's a threat 
it cannot do so, it will raise the appropriate alarms fairly early.  But 
my saying so is not enough to create the level of comfort Ted and others 
are asking for.

Moving over to the IASA side of the operation, the IAOC will be strongly 
focused on making sure there's enough money available to run the 
operation.  This is where I think the primary line of defense is.  It 
will be the IAOC that is watching to make sure there is enough money, 
and if there isn't, or even if there isn't adequate visibility and 
assurance, the IAOC will raise the alarm on behalf of the IETF.  If it 
doesn't, it's failed one of its primary missions.  The mere creation of 
the IAOC is, in my mind, a strong implementation of the level of 
protection being asked for here.

As I said above, I'm not opposed to having words in the BCP that make 
all of this clear, but I think it's, at best, only added protection in a 
  scheme that already embodies a reasonably satisfactory level of 
protection.

Steve

Ted Hardie wrote:
>> I *think* this is a "not a problem" thing.... I believe the intent is 
>> that IETF can say "we think we need 6 months reserve for our stuff", 
>> and ISOC can say "that's no problem - we have general reserves that 
>> are larger than your 6 months + the reasonable risk on other stuff".
> 
> 
> all else is at least marginal and 3 months if every other program goes 
> belly up",

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 Jan 2005 10:52:20 -0800

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jan 2005 23:16:14 -0500

On Wednesday, January 19, 2005 10:52:20 -0800 Fred Baker <[email-masked]> 
wrote:

> 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.

I _think_ the intent is that the published BCP will represent a formal 
agreement between ISOC and the IETF, but of course the work-in-progress 
internet-draft does not.  Given this, I think it's appropriate any time we 
add to text for people comment on "what we're asking ISOC to do".  By 
proposing adding a requirement to a document we expect will represent 
agreement between ISOC and the IETF, we _are_ asking ISOC to do something.

Hopefully by the time the IESG sends the document to the ISOC board, we 
have indeed progressed from "the IETF is asking" to "ISOC and the IETF 
agree", and the vote of the ISOC board is just a formality.  IMHO, if this 
is not the case, we've screwed up.

> 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.
>

I think a slight variation on Harald's proposal should suffice:

>     through whatever mechanisms ISOC deems appropriate.

Harald stopped after "reserve"; I think the next clause is important to 
make it clear that we don't expect ISOC to keep a special cash pool just 
for IASA.

> 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.

This sounds like a very good idea.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Jan 2005 10:04:33 +0100

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 <[email-masked]> wrote:

> 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".
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Jan 2005 15:07:27 -0500

--On Wednesday, 19 January, 2005 23:16 -0500 Jeffrey Hutzelman
<[email-masked]> wrote:

> I _think_ the intent is that the published BCP will represent
> a formal agreement between ISOC and the IETF, but of course
> the work-in-progress internet-draft does not.  Given this, I
> think it's appropriate any time we add to text for people
> comment on "what we're asking ISOC to do".  By proposing
> adding a requirement to a document we expect will represent
>...

Jeffrey,

I think we need to be a little careful with any assumptions
about changes between that "work in progress" I-D and the
"published RFC".  According to the I-D tracker, bcp-04 was in
the IESG's queue for _approval action_ at today's teleconf (I
haven't checked today to see if there has been an update but it
would normally take a bit of time to appear even had there been
an action).  The reason for getting it into the queue is
described in the tracker and makes that listing basically a
placeholder -- it is a bit of a procedural ruse, but, at least
IMO, nothing serious.  It creates an opportunity for abuse, but
I do not expect that it will be abused.  But the important point
is that the queue entry is about -04, not about -05 nor some
"ready to be published" formal agreement text.   Once something
is approved by the IESG and sent off to the RFC Editor, what
gets published is the document as sent modulo boilerplate,
editorial, and formatting changes.

The various schedules that have floated around don't contain a
step for "rewrite the agreement into the form of a formal
agreement and then Last Call it again".  The Last Call would,
IMO, be needed given a complete rewrite so that the community
could verify that the intent had not changed.  If you (or
others) think such a rewrite is important, then you had best
start advocating that position and seeing if you can get support
behind it.   Otherwise, I think that, more or less what you see
today in -04 is what you are going to get.  My assumption is
that the IESG will, in fact, not take action on -04 plus an
unimplemented list of changes but that -05 will be posted and
the community will have at least some chance to review it before
action is taken (I hope that is correct and would be,
personally, pretty upset if something were approved and sent to
the RFC Editor that the community hadn't reviewed).  However,
again, I'd be astonished if -05 differed in general style or
presentation from -04... at least unless the community makes it
very clear, and soon, that it will insist on that sort of
rewrite.  I think that, so far, you are the first person who has
asked for it.

   john

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Jan 2005 16:22:36 -0500

> editorial, and formatting changes.

Exactly true.

> behind it.

I think you must be reading something into my message that wasn't there.
I don't believe any such rewrite is necessary.  I _do_ believe we had 
better make sure that by the time the IESG approves the document, its 
_contents_ will be agreeable to the ISOC board.  Only at that point will 
this document be the agreement between ISOC and the IETF, rather than 
merely an expression of what the IETF is asking ISOC to agree to.

It is _that_ point I was trying to make in response to Fred's comment about 
whether this document is "the agreement" or "the IETF's request" -- it is 
both, depending on at what time you ask.