Re: #720 and #725 - Appeals and IAD autonomy

[John C Klensin]

--On Wednesday, 22 December, 2004 21:51 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:

> John,
> 
> I've probably seen enough versions of enough issues that I'm
> more than a little spaced out.. but I think your proposal
> looks very much like the in-draft version of the appeals
> procedure, with three differences:
> 
> - Not limited to procedure, and not limited to the IAOC
> - Abandoning the "chain" model of "if you don't like one
> decision, try again" that the current appeal structure has
> - Not using the word "appeal"
> 
> I like all of those properties, and it should be a small twist
> of language (starting from the text in the draft, not the most
> recent suggestion) to make it come out that way.
> But I'm not sure I'm reading your words correctly, so better
> double-check

A fascinating question, actually.   I think you are reading my
words correctly and that, by happy coincidence, the words that
are now in the draft are fairly easily adapted.

But the principles are more important than the words, and I
think this is a profound change in principles.  It is, I think,
a significant change to say "if you expect the IAOC model to
succeed,

* the IETF has got to keep its hands off the day-to-day
decisions, even when they seem wrong

* the IESG and IAB need to be prohibited structurally
from micromanaging, or managing at all, beyond the
degree that the IAOC wants to permit.  They supply
input, they make requests, but decisions rest on the
IAOC side of the wall and stay there, with the only
_real_ recourse being to fire the IAOC

and then to figure out a way to implement those principles.

 john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[Harald Tveit Alvestrand]

--On torsdag, desember 23, 2004 04:14:58 -0500 John C Klensin 
<[EMAIL PROTECTED]> wrote:


--On Wednesday, 22 December, 2004 21:51 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:
John,
I've probably seen enough versions of enough issues that I'm
more than a little spaced out.. but I think your proposal
looks very much like the in-draft version of the appeals
procedure, with three differences:
- Not limited to procedure, and not limited to the IAOC
- Abandoning the "chain" model of "if you don't like one
decision, try again" that the current appeal structure has
- Not using the word "appeal"
I like all of those properties, and it should be a small twist
of language (starting from the text in the draft, not the most
recent suggestion) to make it come out that way.
But I'm not sure I'm reading your words correctly, so better
double-check
A fascinating question, actually.   I think you are reading my
words correctly and that, by happy coincidence, the words that
are now in the draft are fairly easily adapted.
But the principles are more important than the words, and I
think this is a profound change in principles.  It is, I think,
a significant change to say "if you expect the IAOC model to
succeed,
* the IETF has got to keep its hands off the day-to-day
decisions, even when they seem wrong

* the IESG and IAB need to be prohibited structurally
from micromanaging, or managing at all, beyond the
degree that the IAOC wants to permit.  They supply
input, they make requests, but decisions rest on the
IAOC side of the wall and stay there, with the only
_real_ recourse being to fire the IAOC
and then to figure out a way to implement those principles.
Actually, I think we have agreement on those principles, and have mostly 
been struggling with how to express them.

Appeals procedures (under whatever name) are procedures that should exist 
so that if someone thinks something's gone really wrong, it's possible to 
get it noticed and talked about - and, if it's necessary, corrected.

Trying to manage anything by routine appeals is totally broken.
Harald


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue: #748: Section 5.4 - Quarterly deposits inappropriate

[Brian E Carpenter]

Joel,
Money has this tricky property of being fungible, which is what allows
governments, funding agencies, and even corporate finance people,
to play such games. But on the other hand, what do you expect ISOC to
do in a year when, for whatever reason, its general income is significantly
down and designated donations for the IETF are significantly up? Given that
we are entering a relationship of trust, I think there has to be flexbility
to deal with unforeseeable circumstances such as those.
   Brian
Joel M. Halpern wrote:
The concern (and I think it is minor but not insignificant) is not with 
incompatibility.
It is that as currently written, in the case of more IETF earmarked 
donation than expected, it is equally consistent with the text that either
1) ISOC maintains their level of general contribution to IETF activities
or
2) ISOC reduces their level of general contribution to IETF activities, 
because the money is coming from elsewhere.

We clearly want 1.
Governments lover to do 2.  That is the game they play with "lottery 
money is only usable for schools" and similar nonsense.

Yours,
Joel
At 10:25 AM 12/22/2004, Brian E Carpenter wrote:
Joel,
Joel M. Halpern wrote:
I think that there is a different side of this.
Suppose that a budget was worked out (as below), with a plan for a 
certain expected coverage from ISOC general funds, meeting fees, and 
directed donations.
Lets presume the budget includes the plan for building the reserves.
If meeting fees run high, presumably the IAOC and ISOC will negotiate 
about how much of that goes into extra IETF reserves, how much goes 
for previously unbudgeted but desired IETF activities, and how much 
goes to reduce ISOC general fund contribution.
What I wonder about is the case where earmarked donations run higher 
than budgeted.  If ISOC is allowed to reduce its support from general 
funds for the IETF based on that increased earmarked donation, then 
it tends to undermine the value of the earmarked donation.
It seems to me that two conclusions follow from this:
1) The budget ought to be built around some assumption (based on 
experience) of earmarked donation.
2) But extra earmarked donation should go to either IETF reserves or 
other IETF specific activities that were not in the budget.

I'm not clear that anything in the -02 text with the minor proposed
changes to get rid of "quarterly" is incompatible with this.
   Brian
Yours,
Joel
At 08:51 AM 12/22/2004, Margaret Wasserman wrote:
Hi Bert,
At 11:13 PM +0100 12/21/04, Wijnen, Bert (Bert) wrote:
May be I need to explain my (personal) thinking.

This is good, because your personal thinking does not match my 
personal thinking and perhaps that is why we have been having 
trouble coming to wording that seems right to both of us.

In my view, just as an example, if we have this budget:
Revenues:expenses  $5M
- meeting fees   $ 2M
- earmarked donations:   $ 2M
- ISOC budget$ 1M
and at the end of the year it turnes out that we adhered to th $5M 
spending
and that the meeting fees and earmarked donations are say $ 5M, then I
would hope we can set aside $1 M for reserve funds for possible future
shortfalls and/or disasters.
I'd hope that ISOC would still be willing to allocate $ 1M for IETF
(at least untill we have our defined reserve fund established).

With the same budget numbers, I would, personally, think about it 
like this:

ISOC has agreed to cover a $5M budget.  The IASA is only 
anticipating $2M in meeting revenue.  This means that ISOC needs to 
raise funds (in one form or another) to cover $3M worth of expenses.

If meeting fees and/or designated donations do cover the full $5M, 
the budget is covered.  If these revenue sources do not cover the 
full $5M, ISOC will need to cover the remaining expenses from 
non-IASA-specific funds.

I think that you are making a mistake when you consider the 
"earmarked donations" and the "ISOC budget" to be two separate 
revenue streams.
ISOC will have fund raising programs, and _all_ of the donations 
that ISOC collects from those programs are ISOC revenue.  Some of 
that revenue may be earmarked to specific projects (IASA is only one 
of many projects that people may choose to fund) and/or collected 
via project-specific fund raising efforts, but all of this revenue 
and all related expenses are included in the ISOC budget.

I don't know whether or not IETF meeting fees will be included in 
the ISOC budget.  That will depend on whether we view meeting fees 
and expenses as IASA budget items, or whether the meetings are run 
in such a way that only the surplus from the meetings shows up on 
the ISOC/IASA books.

In fact I would rather see a budget:
revenues: expenses
- meeting fees   $ 2M allocate to reserve fund $.5M
- earmarked donations:   $ 2M normal expenses $4.5M
- ISOC budget$ 1M
And then if meeting fees turn out to generate an extra 1M without 
ex

Re: IASA BCP Conflict of Interest Clause?

[Brian E Carpenter]

[EMAIL PROTECTED] wrote:
I think this is sufficient as well.
a.
On 22 dec 2004, at 15.22, Harald Tveit Alvestrand wrote:
"The IAOC will establish and publish rules to handle conflict of 
interest situations".

Yes, I think so. Profiting from a conflict of interest is pretty
much illegal anyway, so I don't really see why the BCP needs to spell
it out - the IAOC needs such rules for its own protection anyway.
The ISOC Board went through this process a few years ago and I would
expect that the rules for the IAOC would be very similar.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #723: Section 3 - Requirements for Outsourced Activities [w as: BCP-02: Requirements for Outsourced Activities]

[Wijnen, Bert (Bert)]

Kurtis comments on text suggested by Bernard:
> On 2004-12-09, at 17.02, Bernard Aboba wrote:
> 
> > Suggest this be rewritten to:
> >
> > "The IAOC is accountable for the structure of the IASA and thus decides
> > which functions are to be outsourced. All outsourcing must be via
> > well-defined contracts or equivalent instruments.  Both outsourced and
> > in-house functions must be clearly specified and documented with
> > well-defined deliverables, service level agreements, and transparent
> > accounting for the cost of such functions."
> 
> I think this is overkill. It is up to the IAD/IAOC to decide how to 
> account for costs of outsourced contracts, so I would put a period 
> after "service level agreements".
> 
I have seen support for Bernard's statement (on email I believe by Margaret)
and I like Bernard's text myself as well.
I have not seen anyone agree with Kurtis yet. So for now I am believing
we seem to have more agreement on the complete text suggested by
Bernard. 

I have updated the text (in my edit buffer) accordingly. 
Speak up if you disagree.

Bert
> - - kurtis -

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Discussion: #723 details on outsourcing

[Harald Tveit Alvestrand]

Ticket #723 is a thread coming from the paragraph that says:
   All outsourcing must
   be via well-defined contracts or equivalent instruments.  If any
   functions are performed in-house, they must be clearly specified and
   documented with well-defined deliverables, service level agreements,
   and transparent accounting for the cost of such functions.
The two topics raised in that thread are whether the requirements need to 
be placed on both in-house and outsourced services, and whether the 
requirement for transparent accounting was overkill.

In the discussion that led to this paragraph, the point was made that a 
contract for a service usually documents deliverables, SLAs and so on, 
while it's been observed that if one does a function inhouse (whether it's 
telephone service, accounts-keeping or a full document publishing 
function), one may see that the function is either not accounted for at all 
or it is lumped into a general lump sum such as "overhead". Then it's hard 
to be transparent, since it's not documented what was done, whether it 
fulfilled requirements, or what it cost.

My worry is more in the direction of "state principles, not mechanisms" - 
that the requirement here is specifying too much about how to do these 
things, rather than why it should be a certain way.

So while my first instinct is to suggest that this is "no change needed", 
I'm instead sending this out with "discussion".

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

No change needed? #723 - Outsourcing as a principle

[Harald Tveit Alvestrand]

Ticket #733 questions whether it's right to state a principle that things 
should be outsourced:

In principle, IETF administrative functions should be outsourced.
I would remove this sentence. We later say that it is the IAOC's
job to decide what is outsourced and what isn't, and I am more
comfortable with that than with stating this as a general
principle.
No discussion recorded.
Remembering the discussions that led us here, I think we had consensus on a 
strong principle of outsourcing - this is based on two beliefs:

- That some functions are performed more effectively and efficiently by 
people who do "that sort of thing" for others
- That building a large team that performs functions "in-house" will lead 
to a greater temptation to consider "how to make work for our staff" rather 
than "what's best for the IETF" (this has happened to other organizations).

I believe that these are valid reasons to keep the mention of the 
outsourcing principle in section 3, so I suggest we close #723 with "no 
changes needed".

Another tack would be to edit the text to mention the beliefs above 
explicitly - but I think that's a level of detail in justification that we 
have not done for other principles.

OK?
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

End of tickets - heading for vacation

[Harald Tveit Alvestrand]

Note to the IETF list...
Bert and I have now sent out notes on all the open tickets that are not 
closely related to finances, except 739 and 728.

I've asked the editors to prepare a -03 I-D that can be published before 
the holidays, incorporating the changes that seem agreed upon (which are 
most of those tickets). Henrik will then be able to close the tickets.

Today's the day I'm taking off for Christmas holidays, so I won't be able 
to paint a coherent financial picture for covering the financial tickets 
(745, 732, 721, 737, 722, 748, 749, 750) before the holidays - meaning that 
we still have issues to resolve for after the holidays. Whether the changes 
that happen because of that are "significant" or not remains to be seen.

I have not yet seen a change that I think is large enough to warrant a Last 
Call reset - it may yet happen, and if others, after having seen the -03 
version, think the Last Call needs to be reset because of those changes, 
please say so on that list.

But - for the moment, I'll just wish you all a happy holiday season!
   Harald Alvestrand
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Discussion: #723 details on outsourcing

[Brian E Carpenter]

Harald Tveit Alvestrand wrote:
Ticket #723 is a thread coming from the paragraph that says:
   All outsourcing must
   be via well-defined contracts or equivalent instruments.  If any
   functions are performed in-house, they must be clearly specified and
   documented with well-defined deliverables, service level agreements,
   and transparent accounting for the cost of such functions.

The two topics raised in that thread are whether the requirements need 
to be placed on both in-house and outsourced services, and whether the 
requirement for transparent accounting was overkill.

In the discussion that led to this paragraph, the point was made that a 
contract for a service usually documents deliverables, SLAs and so on, 
while it's been observed that if one does a function inhouse (whether 
it's telephone service, accounts-keeping or a full document publishing 
function), one may see that the function is either not accounted for at 
all or it is lumped into a general lump sum such as "overhead". Then 
it's hard to be transparent, since it's not documented what was done, 
whether it fulfilled requirements, or what it cost.

My worry is more in the direction of "state principles, not mechanisms" 
- that the requirement here is specifying too much about how to do these 
things, rather than why it should be a certain way.

So while my first instinct is to suggest that this is "no change 
needed", I'm instead sending this out with "discussion".
Well, I go for "no change" as in Bert's note on the same ticket.
It's all too easy to fall in the trap of hiding hard-to-classify
expenses under "general," and it's a mistake that comes back to
hurt you later. "Transparent accounting" is a principle worth stating.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #727: Section 2.2, 4, & 7 - Miscellaneous & editorial [was : Last Call Comments on draft-ietf-iasa-bcp-02.txt]

[Wijnen, Bert (Bert)]

Responding to the items/topics that have been recorded as issue 727

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Margaret Wasserman
> Sent: Saturday, December 11, 2004 20:54
> To: ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: Last Call Comments on draft-ietf-iasa-bcp-02.txt
> 
> 
.. snip ..

> This document
> does not affect the ISOC-IETF working relationship as it relates to
> standards development or the communication of technical advice
> relevant to the policy and educational goals of ISOC.
> 
> >>  I'd cite RFCs 2026 and 2048 as references here.
> 

Mmm... 2026 seems fine.
Not sure about 2048. That is about MIME stuff !!??
So which one do you mean? Probably 2031?

My current edit buffer now says:

 This document
 does not affect the ISOC-IETF working relationship as it relates to
 standards development [RFC2026, RFC2031] or the communication of
 technical advice relevant to the policy and educational goals of ISOC.
>

.. snip 
 
> 2.5  Effective Date for Commencement of IASA
> 
> The procedures in this document shall become operational immediately
> after this document has been approved by the process defined in BCP 9
> [RFC2026] and has been affirmed by a Resolution of agreement by the
> ISOC Board of Trustees.
> 
> >>  Just a minor wording suggestion...  Unless "Resolution of agreement"
> >>  is some type of legal phrase, I'd make the following change:
> >>
> >>  s/Resolution of agreement by/resolution of/
> >>
> >>  The ISOC Board has some wording that we use for these cases.  We
> >>  will accept the document and agree to carry out our
> >>  responsibilities, as described therein.  We don't use the words
> >>  "Reolution of agreement" to describe that, though.
> 

I have made this change for now.
But it may change completely pending the outcome of Issue 739, or so I think.
>

.. snip 

> The IAOC may also choose to invite liaisons from other groups, but is
> not required to do so; the IAOC decides whether or not to have a
> liaison to any particular group.  Any such liaisons are non-voting.
> Responsibility for selecting the individual filling a particular
> liaison role with the body from which the IAOC has requested the
> liaison.
> 
> >>  This last sentence isn't a sentence.  Perhaps:
> >>
> >>  s/role with/role lies with/ ?
> 
done

> Appointed members of the IAOC serve two year terms.  IAOC terms
> normally end at the first IETF meeting of a year, just as as IAB and
> IESG terms do.
> 
> The members of the IAOC shall select one of its appointed voting
> members to serve as the chair of the IAOC, with all of the duties and
> responsibilities normally associated with such a position.
> 
> >>  I'd remove everything after the comma.  There is no clear concept
> >>  of what duties and responsibilities would normally be associated
> >>  with such a position, and you have specific responsibilities and
> >>  limits listed later.
> 
No change made. It had quite some discussion during rev 01.
And we then seemed to have agreed (to me at least) on taking
the text from the IAB doc (RFC2850, sect 3.1) and not fiddle
with the words (as had been done earlier).
So after that earlier discussion on the text, I do not see this
as just an editorial change.

> 
.. snip 

>All
>contracts executed by ISOC on behalf of IASA shall either include
>a clause allowing termination or transfer by ISOC with six months
>notice, or shall be transferable to another corporation in the
>event that the IASA transitions away from ISOC.
> 
> >>  s/or transfer//  (it is redundant with the second half of 
> >>  this sentence).
> 

done

>Any accrued
>funds, any IETF-specific intellectual property rights, and any
>IETF-specific data and tools shall also transition to the new
>entity.
> 
> >>  By "accrued funds", you presumably mean funds that are currently
> >>  held in the IASA accounts.  So, why not just say so?
> 
> 
Mmm... I am sort of with you.
AT the other hand, I see continued discussion about "ISOC should not
credit xxx to IASA accounts".

So I am not sure your suggestion is just editorial. If we keep all the 
current text about crediting money to IASA accounts, then it is editorial.
But given the ongoing discussion, I have not (yet) made the change.

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #723: Section 3 - Requirements for Outsourced Activities

[Scott Bradner]

accounting transparency is mentioned in a number of places already
it seems overly redundent to mention it here yet again - but its not 
a big deal to me

Scott

-
Kurtis comments on text suggested by Bernard:
> On 2004-12-09, at 17.02, Bernard Aboba wrote:
> 
> > Suggest this be rewritten to:
> >
> > "The IAOC is accountable for the structure of the IASA and thus decides
> > which functions are to be outsourced. All outsourcing must be via
> > well-defined contracts or equivalent instruments.  Both outsourced and
> > in-house functions must be clearly specified and documented with
> > well-defined deliverables, service level agreements, and transparent
> > accounting for the cost of such functions."
> 
> I think this is overkill. It is up to the IAD/IAOC to decide how to 
> account for costs of outsourced contracts, so I would put a period 
> after "service level agreements".
> 
I have seen support for Bernard's statement (on email I believe by Margaret)
and I like Bernard's text myself as well.
I have not seen anyone agree with Kurtis yet. So for now I am believing
we seem to have more agreement on the complete text suggested by
Bernard. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: No change needed? #723 - Outsourcing as a principle

[Scott Bradner]

Harald concludes:
> I believe that these are valid reasons to keep the mention of the 
> outsourcing principle in section 3, so I suggest we close #723 with "no 
> changes needed".

I agree

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

We can close: Issue #728: Section ?? - Openness requirements

[Wijnen, Bert (Bert)]

This issue has been split (I think) in sub-issues 714, 715, 716, 
717 and 718.

So I propose that we can close issue 728.

Or am I missing something?

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

#732: Section 5 - Fund raising cost allocated to IASA?

[Wijnen, Bert (Bert)]

Inline

> -Original Message-
> Date: Sat, 11 Dec 2004 14:53:32 -0500
> To: ietf@ietf.org
> From: Margaret Wasserman <[EMAIL PROTECTED]>
> Subject: Last Call Comments on draft-ietf-iasa-bcp-02.txt
> 
> ...
> 
> > behalf of the IASA at the direction of the IAOC. The IAD is likely
> > to draw on financial, legal and administrative support furnished by
> > ISOC support staff or consultants. Costs for ISOC support staff and
> > consultants are allocated based on actual expenses or on some other
> > allocation model determined by consultation between the IAOC and
> > ISOC.
> 
> This paragraph triggers a concern, but not one that should be dealt
> with in this section. We talk here about ISOC support staff costs
> being allocated to IASA, but I don't think we ever talk about fund
> raising costs being allocated to IASA. Do you think that we need
> to say something about that? Or should fund raising costs remain
> outside of the IASA budget and be deducted before funds are
> credited to the IASA accounts?

We have text that states:

ISOC shall create and maintain appropriate
structures and programs to coordinate donations
intended to support the work of the IETF, and
these will include mechanisms for both in-kind and
direct contributions to the work supported by
IASA.  

I am OK with leaving it at that and assume that ISOC will charge
fund-raising costs to the appropriate cost center.

Compare it to
   Meeting revenues are an important source of funds
   for IETF functions.  The IAD, in consultation with
   the IAOC, sets the meeting fees as part of the
   budgeting process.
   All meeting revenues shall be credited to the
   appropriate IASA accounts.

We do not specify how "costs for collecting the meeting fees (credit card
fees, bank fees, what have you)" are accounted for either.

In short: do we need all that detail.

As Harald explained in a posting this morning, the reason why we did the
specifics on the text you quote above is that it is too easy to "hide"
internal staff cost under G&A without detail.

So my proposal is: no change needed

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #747 and #734: Section 3.1 - Change "account" to "accounts"

[Wijnen, Bert (Bert)]

Issue 734 and 747 seem to be about the same thing.

Editors have accepeted that s/account/accounts/
and that change has been made in my editing buffer.

So I think both tickets can change to "Document updated".

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #735 - wording changed [was RE: No change needed? #735 "rig hts in data"]

[Wijnen, Bert (Bert)]

> 
> I don't think that there is a substantive issue here, just an 
> editorial one.  What about just reusing Jorge's text, like this:
> 
> >Margaret said (quoting the draft):
> >
> >>>  The IAD is responsible for ensuring that all contracts give the IASA
> >>>  and the IETF all rights in data needed to satisfy the principle of
> >>>  data access.
> 
Margaret suggested this changed text:

> The IAD is responsible for ensuring that all contracts give IASA and 
> the IETF the perpetual rigth to use, display, distribute, reproduce, 
> modify and create derivatives of all data created in support of IETF 
> activities.
> 

The above text change seems fine to me and states the same as what we
want to say (in my view) and is less "twisted" (I agree).

So I have made the (in my view editorial) change in my edit buffer.

Bert
> It is not much longer than the original, and I don't have to twist my 
> brain around to realize what it is trying to say.
> 
> >I can't think of a way to untwist the sentence more while making it 
> >say the same thing - suggest that we don't make any change.
> 
> Does my suggestions above help?
> 
> Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #732: Section 5 - Fund raising cost allocated to IASA?

[Scott Bradner]

clearly fund raising expenses must be accounted for but, imo, 
there is nothing special about fund raising expenses - there will
also be other overhead costs that will have to be seen as being in the
IASA budget (Bert mentions credit card fees, there is also office space,
legal support for contract negotiation, etc, etc) - I do not see 
a particular need to call out fund raising expenses in a special way.

Bert proposes:
> So my proposal is: no change needed

I agree

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #737: Section 5.3 - Designated Donations [was RE: IASA BCP -02 Designated Donations - section 5.3]

[Wijnen, Bert (Bert)]

Inline 

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Leslie
> Daigle
> Sent: Thursday, December 16, 2004 22:29
> To: Brian E Carpenter
> Cc: ietf@ietf.org; Lynn St.Amour
> Subject: Re: IASA BCP -02 Designated Donations - section 5.3
> 
> 
> 
> Let me try a slightly different cut on the discussion.
> 
> 1/ I believe the IETF is trying to address the fact we would like
> to be able to accept support in chunks that are greater than
> individual meeting fees, and less than $100kUS.  IMHO,
> it's not that the IETF needs to be able to accept donations
> in *any* size between those, but I have heard people say that
> they know the person in their company who could write a cheque
> for $40k, if it will pecifically support the IETF, but there's no
> way they can get $100k through their budget.
> 
My feeling is that we all agree on the above. I have not seen anyone speak
up against the principle above.

The current text actually does capture that:

ISOC shall create and maintain appropriate
structures and programs to coordinate donations
intended to support the work of the IETF, and
these will include mechanisms for both in-kind and
direct contributions to the work supported by
IASA.  Since ISOC will be the sole entity through
whom donations may be made to the work of the
IETF, ISOC shall ensure that those programs are not
unduly restrictive.  For the benefit of
individuals, smaller organizations and countries
with developing economies, ISOC shall maintain
programs that allow for designated donations to
the IETF.

Lynn wants the last sentence removed. 
I can sort of see that, because it is a detail and it only explains
(I think) why we want the programs to not be "unduly restrcitive".
What the last sentence may alllude to is that we are thinking about
very small size of contributions (I could see individuals wanting to
donate like a few tens of dollars a year). And so that is detail, and 
that indeed needs to be worked out and to be evaluated against possible
cost for doing so (as explained somewhat by Lynn).

It is probably OK to remove:

 For the benefit of
individuals, smaller organizations and countries
with developing economies, ISOC shall maintain
programs that allow for designated donations to
the IETF.

and the text above

The ISOC shall create and maintain...

covers two items:

- ISOC will continue (maintain) the current IETF donor program
- ISOC will create (or update) the program to make the program
  not unduly restrictive.

So are we OK on that?

> 2/ I believe we've also heard the IETF say that it wants to be able
> to clearly identify its collected assets (and, as the flipside,
> is willing to pay for all of its expenses).  This is driven
> by a lot of factors, but I think the an important one is
> that the IETF believes it can and should be financially viable.
> Taking the bad along with the good, we want to be in an
> environment where we can prove that out empirically.
> 

I personally am not sure I want to "prove" that we (IETF) can and
should be financially viable. But I DO want transparency, and as
part of thta, I do want to see which donations were tagged
and intended for IETF and how they have been allocated/credited
to IETF. So my concern has been addressed with the text on
transparency.

Lynn also stated that we currently see a 90/10 rule in ISOC in that
80% of the donations are under $10K and they bring in some 10% of
the all donations (If I understood here posting correctly).
If that is the case, then a lower bound of $10K might be fine
for explicit tagging.

Now ... I have in my mind that the lower limit for tagging is
currently $100K. So that seems to be an issue. But if donatins 
above $10k are only 20% of the (number of) donations, and make up
90% of the money, then allowing tagging of that seems fine.
And for me, that seems captured in the 

   "... to make the program not unduly restrictive."

text.

> 3/ We've heard clear explanations that attracting and managing
> corporate donations is not a simple task.  Specifically,
> that there are reasons that it's not a simple matter to
> drop the level of donation necessary for designating
> donations.
> 
> 
> I don't believe the BCP needs to have specific text about
> *how* "1/" and "2/" are achieved.  The current text is
> about "how", and perhaps that's why it does not reconcile
> with "3/".
> 
I agree with 1 and 2 (except for focus on proving a finacial
independent IETF). I am not sure we really have documented
the "how". I thin

Re: #720 and #725 - Appeals and IAD autonomy

[John C Klensin]

--On Thursday, 23 December, 2004 10:22 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:
 
>>> John,
>>> 
>>>...
>>> I like all of those properties, and it should be a small
>>> twist of language (starting from the text in the draft, not
>>> the most recent suggestion) to make it come out that way.
>>> But I'm not sure I'm reading your words correctly, so better
>>> double-check
>> 
>> A fascinating question, actually.   I think you are reading my
>> words correctly and that, by happy coincidence, the words that
>> are now in the draft are fairly easily adapted.
>> 
>> But the principles are more important than the words, and I
>> think this is a profound change in principles.  It is, I
>> think, a significant change to say "if you expect the IAOC
>> model to succeed,
>> 
>>  * the IETF has got to keep its hands off the day-to-day
>>  decisions, even when they seem wrong
>>  
>>  * the IESG and IAB need to be prohibited structurally
>>  from micromanaging, or managing at all, beyond the
>>  degree that the IAOC wants to permit.  They supply
>>  input, they make requests, but decisions rest on the
>>  IAOC side of the wall and stay there, with the only
>>  _real_ recourse being to fire the IAOC
>> 
>> and then to figure out a way to implement those principles.
> 
> Actually, I think we have agreement on those principles, and
> have mostly been struggling with how to express them.
> 
> Appeals procedures (under whatever name) are procedures that
> should exist so that if someone thinks something's gone really
> wrong, it's possible to get it noticed and talked about - and,
> if it's necessary, corrected.
> 
> Trying to manage anything by routine appeals is totally broken.

Well, perhaps we are close enough that it doesn't make sense to
have further discussion without text, and text in context, but...

I think the "something's gone really wrong" and "...corrected"
part of the above _might_ miss the point I'm trying to make.  

(1) If you have an appeal procedure, any appeal
procedure at all, then it is up to the judgment of the
individual members of the community whether a decision
is "really wrong".   I don't need to worry about denial
of service attacks here, just about people acting in
good faith and with the best of intentions.  Remember we
have had debates on the IETF list about the variety of
pastries to be available during meeting coffee breaks as
well as the theory for selecting meeting sites.   I may
be too concerned about this, but I think those debates
could easily have led to appeals about meeting locations
when people concluded that the decisions being made were
against the expressed consensus  desires of the
community (or against plain good sense).   Such appeals
have been prevented by the assumption that the IETF
membership has no ultimate control over _individual_
secretariat or Chair meeting siting decisions and that
contracts are already signed by the time meeting sites
are announced.   That has protected us from procedural
entanglements that could easily make meeting scheduling
impossible.  But, with the presumed requirements on the
admin structure for openness, that particular protection
disappears.

(2) If there is an mechanism, any mechanism at all, for
the IESG and IAB to second-guess administrative entity
decisions, I think it can be guaranteed, given the sorts
of personalities we put on those bodies, that the
mechanism will sooner or later be used and that, once
used, there will be a tendency for its use to become
routine.  We appoint people with strong opinions and
with a tendency to want to manage, sometimes
micromanage, anything for which they feel responsible
and to do so aggressively.  If kept under control and in
perspective, those tendencies can be very useful.  But I
think any person who has listened to a few IESG
telechats, any WG Chair or Editor who has tried to get a
document through the system in recent years, anyone who
has worked for the Secretariat, and many others can
easily identify incidents that they would consider out
of control or without adequate perspective.

(3) Part of the problem here is that, on the technical
standards side, part of the job of the IESG is to ensure
that the collection of standards the IETF emits are
essentially consistent, that we don't have a standard in
one area that makes a standard in another area
impossible to implement.  Sometimes we don't get that
quite right and it requires some sorting-out.  But it
works most of the time, and works precisely because that
is a real IESG responsibility which th

Issue #740: Section 2.2 & 5.6 - IASA BCP -02 Reserves [was RE: I ASA BCP -02 Reserves - section 2.2 /7 and 5.6]

[Wijnen, Bert (Bert)]

Lynn,
Inline

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Lynn St.Amour
> Sent: Monday, December 13, 2004 01:45
> To: ietf@ietf.org
> Subject: IASA BCP -02 Reserves - section 2.2 /7 and 5.6
> 
> 
> Bert, Rob,
> 
> please find below comments on "reserves".  Thanks again for 
> all your efforts.
> 
> 
> >Section 2.2
> >
> >7.   The IASA shall
> 
> work with ISOC to (?)
> 

Mmm... it seems to me that the IASA should establish a target.
Having said that, I could live with the addition.

I agree that IASA and ISOC together need to work on a plan to 
actually build the reserve. That is actually stated later on in the 
sentence.

> >establish a target for a reserve  fund to cover normal operating 
> >expenses and  meeting expenses in accordance with prudent  planning, 
> >and ISOC shall work with the IASA  to build up and maintain the
> 
> s/reserve./reserve as part of ISOC's overall reserve strategy and 
> provisioning./
> 
> The changes above are to reflect the last known agreement (at least 
> from ISOC's perspective it was the last known :-) .  Some additional 
> comments below.
> 

Lynn, since this is a "principle", I would rather see harald declare
consensus on it first. I think you are right, in that we do have
similar text in sect 5.6 but I am still not sure it is just an
editorial change that I can just make.

Harald?

> >5.6 Operating Reserve
> >
> >  As an initial guideline and in normal operating circumstances, the 
> >IASA should  have an operating reserve for its activities 
> >sufficient to cover 6-months of non-meeting  operational expenses, 
> >plus twice the recent  average for meeting contract guarantees. 
> >However, the IASA shall establish a target for a  reserve fund to 
> >cover normal operating expenses  and meeting expenses in accordance 
> >with prudent  planning.  Rather than having the IASA attempt to 
> >build that  reserve in its separate accounts,
> 
> I don't believe this sentence reads properly given we're following a 
> divisional accounting model (more appropriately called a cost center 
> model?) as the accounts will not be held physically separate. 

Not physical, I understand that.
But Sect 5.1 starts off to talk about "separate set of accounts".
And so this text in sect 5.6 just tries to be consistent with that.

W.r.t. the "divisional" vs "cost center" coounting
We got the text on "Divisional Accounting" and on "sepearet set of
accounts" from Glenn Ricart, so what should it be. If we do make a
change we need to make it consistent over the whole doc.
Probably best to keep that for working out when we sit down with the
accountants?

> Perhaps delete that part and begin the sentence with: "the IASA looks 
> to ISOC to build " ?
> 
??

> >the IASA looks to  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.  Such reserves do not appear instantaneously; the  goal is 
> >to reach this level of reserves within 3  years after the creation 
> >of the IASA. Such funds  shall be held in reserve for use by IASA 
> >for use  in the event of IETF meeting cancellation or other 
> >unexpected fiscal emergencies. These reserves shall  only be spent 
> >on IETF support functions.
> 
> The penultimate sentence above seems to be redundant, and in any case 
> the last two sentences are not in agreement with the earlier ones 
> that say it may be held as a line of credit, etc. nor with the notion 
> that the IASA would not be holding a separate reserve (2.2 - 7 seems 
> to imply the same thing?).   Finally, access to these reserves would 
> expect to follow normal IAOC and ISOC approval processes for any 
> budget overruns and would not automatically be available for use by 
> IASA in the event of meeting cancellations or other emergencies. 
> Maybe replace the last two sentences with some variation of "Access 
> to these reserves would expect to follow normal IAOC and ISOC 
> approval processes for any budget overruns."
> 

I believe that the current text was quite extensively discussed in the 
past. I am not sure I can just go ahaead and make changes based on
one person bringing it up. So I'd like to see more support on the list
first. 

Bert
> Best regards,
> Lynn
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Issue: #748: Section 5.4 - Quarterly deposits inappropriate

[Wijnen, Bert (Bert)]

So I have made (for now) this change.

OLD:
   5.4  Other ISOC Support
 
Other ISOC support shall be based on the budget process as specified
in Section 6.  ISOC shall credit the appropriate IASA accounts at
least quarterly.
 
NEW:
 
   5.4  Other ISOC Support
 
Other ISOC support shall be based on the budget process as specified
in Section 6.  ISOC shall periodically credit additional funds to the
IASA accounts to cover anticipated expenditures for that period
within the yearly budget.

I understand that the discussion has not finished, but at least the
"quarterly creditring" has been addressed.

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #755: Section 5.6 - Building a surplus [was RE: Building a surplus]

[Wijnen, Bert (Bert)]

I think we need more discussion on this.

But let me add that Lynn had also made suggestions
as discussed in issue 740.

Maybe we should merge the 2 issues into one?

Bert

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Fred Baker
> Sent: Thursday, December 23, 2004 06:52
> To: ietf@ietf.org
> Subject: Building a surplus
> 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Based on the discussion on the list including Christian's 
> note that said:
> 
> The current platinum sponsors of ISOC are Afilias Limited, APNIC,
> ARIN,
> Microsoft, RIPE NCC, and the Swedish International Development
> Cooperation Agency (SIDA). Most of these sponsors, including
> Microsoft,
> designate their funds for "standard activities". These standard
> activities are typically IETF related, but they are not 
> necessarily
> managed through "the IETF". The current list includes: RFC Editor,
> scholarship funding for needy IETF participants to attend 
> meetings,
> activities of the IAB, IESG, IRTF, special workshops of the IETF,
> travel
> for IETF related activities, "errors and omissions" 
> insurance coverage
> for IESG, IAB, and Working Group Chairs, communications 
> charges for
> conference calls of the IAB, IESG, and IRTF.
> 
> Forcing a particular bank account structure does not 
> appear helpful.
> What is helpful, on the other hand, is a yearly report 
> explaining how
> the contributions are actually used. Even large companies like
> Microsoft
> don't like signing $100,000 checks without knowing how 
> the money will
> be
> spent.
> 
> I'd like to suggest that section 5.6 be changed to read:
> 
> As an initial guideline and in normal operating circumstances, the
> IASA
> should be able to count on an operating reserve for its activities
> sufficient to cover 6-months of non-meeting operational 
> expenses, plus
> twice the recent average for meeting contract guarantees. 
>  Rather than
> having the IASA attempt to build that reserve in separate 
> accounts,
> the
> IASA looks to 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. 
> Such
> reserves do not appear instantaneously; the goal is to reach this
> level
> of reserves within 3 years after the creation of the 
> IASA.  Such funds
> shall be available for use by IASA for use in the event of IETF
> meeting
> cancellation or other unexpected fiscal emergencies.
> 
> Under current conditions it is highly unlikely that an IETF-specific 
> surplus will be developed anytime soon, so I do not think its 
> necessary to
> spend too much time planning for what to do with one (which I think is
> what 
> Leslie was saying).
> 
> In round numbers, the expected budget for the IETF-related 
> activities next
> year is $4.1 million US (that includes $1.4 million for 
> running meetings 
> and $2.7 million for all other expenses including the IAD, 
> secretariat 
> costs, insurance, RFC Editor, IESG & IAB support etc).  If 
> the attendance 
> at the meetings and the meeting fees stay the same, the meetings will
> bring 
> in about $2 million.  That leaves about $2.1 million for the 
> ISOC to pick 
> up. This is about half a million more support than the ISOC 
> budgeted this 
> year, and a bit over double ISOC's 2003 figure.
> 
> Clearly, any donations to the ISOC like the ones that 
> Christian mentions, 
> that specify that the donations are to be used to support "standard 
> activities" would have to only be used to support standard 
> activities. But
> it is likely to be a while before such designated donations 
> could exceed 
> the IASA costs that the ISOC will be responsible to cover.
> 
> 
>Regards,
>  Fred Baker
> 
> /=
> /
>   | Fred Baker |1121 Via Del Rey  
> |
>   | Chairman, ISOC BoT |Santa Barbara, 
> California |
>   ++93117 USA 
> |
>   | Nothing will ever be attempted,| phone: +1-408-526-4257   
> |
>   | if all possible objections must| fax:   +1-413-473-2403   
> |
>   | be first overcome. | mobile:+1-805-637-0529   
> |
>   | Dr. Johnson, Rasselas, 1759|  
> |
> /=
> /
> 
> -BEGIN PGP SIGNATURE-
> Version: PGP 8.0.3
> 
> iQA/AwUBQcpgUG4xHWxyLJtDEQLMEgCgju6Dt1YLmcDEGwpYWN2Ki3wl4B8An1dn
> 0vSraJ2dVBR1WaWUGOHS8x7N
> =YYYa
> -END PGP SIGNATURE-
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

__

RE: Issue: #749: Section 6 - Budget process

[Wijnen, Bert (Bert)]

As a result of the discussion I have updated the text
and it currently looks as follows in my edit buffer:



While the IASA sets a budget for the IETF's
administrative needs, its budget process clearly needs
to be closely coordinated with ISOC's.
The specific timeline shall be established each year
by IASA and ISOC.
As an example, a general annual timeline for budgeting is:



The IAD presents a budget proposal
(prepared in consultation with ISOC staff)
for the following fiscal year, with 3 year
projections, to the IAOC.


<< more text as in rev 02 >>


The dates described above are examples and subject
to change.  They will most likely be modified each
year based on the dates of the second and third IETF
meetings of that year.  They also need to be
synchronised with the ISOC budgeting process.


I think that closes the issue.

Bert
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, December 22, 2004 14:05
> To: ietf@ietf.org
> Subject: Re: Issue: #749: Section 6 - Budget process
> 
> 
> 
> I think John's formulation is right
> > It seems to me that, realistically, the total IASA budget
> > consists of two parts:
> > 
> >   * Whatever the IAOC chooses to try to spend out of
> >   IETF-designated cash on hand, e.g., meeting fees as well
> >   as any targeted funds.
> >   
> >   * Everything else, which the IAOC would like ISOC to
> >   come up with out of other funds or raise.
> > 
> > Rather than dancing around that issue, why not make it explicit
> > that the request to ISOC gets submitted in two parts.  For the
> > first, the ISOC would need really good reasons to say "no", with
> > the assumption going in that there are no such reasons (but I
> > don't think the BCP should overconstrain things).  For the
> > second, the IAOC is expected to ask nicely with the
> > understanding that there might be some negotiation.  
> 
> my worry centers on the 2nd part - I think it would be real 
> bad all around 
> for the IAD to ask for the world (in ISOC funds) in public then have
> the ISOC board say thte the money is not there - that brings on a
> confrontation that could have easily been avoided if the original 
> budget were worked out with the ISOC 'in the loop'
> 
> but that said - I can live with the what is in the document since 
> principle 3 covers the situation
> 
> Scott
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #754: Section ?? - Conflict of Interest Clause [ was RE: I ASA BCP Conflict of Interest Clause? ]

[Wijnen, Bert (Bert)]

So I have add (in my editing buffer) 


The IAOC shall establish and publish rules to
handle conflict of interest situations.


In the context it looks as folllows:


The IAOC decides further details about its
decision-making rules.
These rules will be made public.


The IAOC shall establish and publish rules to
handle conflict of interest situations.


All IAOC decisions are minuted.
Minutes are published regularly.


I think that closes the issue.
Bert
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Brian E Carpenter
> Sent: Thursday, December 23, 2004 10:59
> To: [EMAIL PROTECTED]
> Cc: Harald Tveit Alvestrand; ietf@ietf.org
> Subject: Re: IASA BCP Conflict of Interest Clause?
> 
> 
> [EMAIL PROTECTED] wrote:
> > 
> > I think this is sufficient as well.
> > 
> > a.
> > 
> > On 22 dec 2004, at 15.22, Harald Tveit Alvestrand wrote:
> > 
> >> "The IAOC will establish and publish rules to handle conflict of 
> >> interest situations".
> > 
> 
> Yes, I think so. Profiting from a conflict of interest is pretty
> much illegal anyway, so I don't really see why the BCP needs to spell
> it out - the IAOC needs such rules for its own protection anyway.
> The ISOC Board went through this process a few years ago and I would
> expect that the rules for the IAOC would be very similar.
> 
>  Brian
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Issue #721: Section 5.1 - Financial statements and Audits [was RE : BCP-02: Financial statements and Audits]

[Wijnen, Bert (Bert)]

I have seen some discussion on this but I have not seen a consensus
call by Harald. In fact I think Harald said that most of the
issues on finances and reserves still need more discussion.

SO I have not made a change yet.

I know we DO want something about GAAP in the document,
that seems pretty clear.

Bert

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Bernard Aboba
> Sent: Thursday, December 09, 2004 16:59
> To: ietf@ietf.org
> Subject: BCP-02: Financial statements and Audits
> 
> 
> Section 5.1
> 
> "For bookkeeping purposes, funds managed by IASA should be 
> accounted for
> in a separate set of accounts which can be rolled-up 
> periodically to the
> equivalent of a balance sheet and a profit and loss statement for IASA
> alone after taking into account the effect of common items paid for or
> received by ISOC as a whole."
> 
> I think we want to specify what financial statements are 
> produced in more
> detail, and how an audit may be triggered.
> 
> Suggest this be changed to:
> 
> "For accounting purposes, funds managed by IASA should be 
> accounted for in
> a separate set of accounts, in order to allow the general of separate
> financial statements for IASA, after taking into account the 
> allocation of
> common items paid for or received by ISOC.  The allocation of 
> these common
> items shall be agreed upon between the ISOC and the IAOC as 
> part of the
> budget process.
> 
> Financial statements to be produced for IASA include (but are 
> not limited
> to) an Income (Profit/Loss) Statement, Balance Sheet and 
> Statement of Cash
> Flows, in accordance with Generally Accepted Accounting 
> Pinciples (GAAP).
> Should the IAOC not be satisified with these financial statements, the
> IAOC shall have the right to request that the ISOC conduct an audit."
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Issue: #749: Section 6 - Budget process

[Scott Bradner]

Bert sez:
   As a result of the discussion I have updated the text
   and it currently looks as follows in my edit buffer:



While the IASA sets a budget for the IETF's
administrative needs, its budget process clearly needs
to be closely coordinated with ISOC's.
The specific timeline shall be established each year
by IASA and ISOC.
As an example, a general annual timeline for budgeting is:



The IAD presents a budget proposal
(prepared in consultation with ISOC staff)
for the following fiscal year, with 3 year
projections, to the IAOC.


<< more text as in rev 02 >>


The dates described above are examples and subject
to change.  They will most likely be modified each
year based on the dates of the second and third IETF
meetings of that year.  They also need to be
synchronised with the ISOC budgeting process.


   I think that closes the issue.

it does for me - tnx

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #740: Section 2.2 & 5.6 - IASA BCP -02 Reserves

[Scott Bradner]

Bert quotes lynn and then says
> > Maybe replace the last two sentences with some variation of "Access 
> > to these reserves would expect to follow normal IAOC and ISOC 
> > approval processes for any budget overruns."
> > 
> 
> I believe that the current text was quite extensively discussed in the 
> past. I am not sure I can just go ahaead and make changes based on
> one person bringing it up. So I'd like to see more support on the list
> first. 

I support Lynn's suggestion

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: No change needed? #723 - Outsourcing as a principle

[John C Klensin]

--On Thursday, 23 December, 2004 11:30 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:

> Ticket #733 questions whether it's right to state a principle
> that things should be outsourced:
> 
>>> In principle, IETF administrative functions should be
>>> outsourced.
>> 
>> I would remove this sentence. We later say that it is the
>> IAOC's job to decide what is outsourced and what isn't, and I
>> am more comfortable with that than with stating this as a
>> general principle.
> 
> No discussion recorded.
> 
> Remembering the discussions that led us here, I think we had
> consensus on a strong principle of outsourcing - this is based
> on two beliefs:
> 
> - That some functions are performed more effectively and
> efficiently by people who do "that sort of thing" for others
> - That building a large team that performs functions
> "in-house" will lead to a greater temptation to consider "how
> to make work for our staff" rather than "what's best for the
> IETF" (this has happened to other organizations).

Mumble.   Just so there  is not "no discussion", both of these
beliefs are questionable.  

The first could also be an argument for hiring someone who "does
that sort of thing" if there were enough of that sort of thing
to be done to justify a long-ish term appointment.  And there is
a case to be made that managing a collection of contractors,
especially contractor organizations, is more difficult,
time-consuming, and expensive, than managing employees.

The second is a position I've taken, and one in which I firmly
believe, but I'm not sure that "...functions should be
outsourced" is quite the right way to capture it.  It would be
closer to say that any decision to create an in-house position
should be strongly justified to and by the IAOC, that in-house
positions other than the IAD should be, to the extent possible,
zero-based on an annual basis, and that in-house staff should be
kept as lean as possible, but no leaner.

> I believe that these are valid reasons to keep the mention of
> the outsourcing principle in section 3, so I suggest we close
> #723 with "no changes needed".

I think that, if you really want to capture the intended
principle, the relevant text would be modified to read something
like...

In principle, IETF administrative functions should be
outsourced. Decisions to perform specific functions
"in-house" should be explicitly justified by the IAOC
and restricted to the minimum staff required, with these
decisions and staffing reviewed by the IAOC on a regular
basis and against a "zero base" assumption.

Anything less is likely to be construed as making it a violation
of principle to make decisions that we may need to make.  For
example, as discussed on other threads, there may be very strong
arguments, at least in the longer term, for making the IETF
Executive Director and/or IESG Secretary an employee.
> 
> Another tack would be to edit the text to mention the beliefs
> above explicitly - but I think that's a level of detail in
> justification that we have not done for other principles.

Agreed.
   john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[Carl Malamud]

Hi John -

Your note seems like an outlier.  In particular, it takes a really
*strong* stance on protecting people from each other because
people *will* act badly.  For example, the way I read your
note, the IESG will micromanage and the IASA/IAD will order
bagels flown in daily from New York.  Appeals will be a daily
happening and people will hire lawyers instead of working it out.

I think you're trying to solve many corner cases.  I don't
think we need to solve them right now.  As Dave Farber would
say, maybe we should burn those bagels when we get to them?

Seriously: this BCP seems, imo, pretty much cooked.  There may
be flaws and holes that people forgot, but this would be alot
easier to nail down if we had some operational experience in
the new framework and then solve problems that are real.
There are lots of checks in balances in place, there are going
to be lots of new people who have to get up to speed, and
the community is watching.  

I know you don't want to revise the BCP every 10 minutes for the
next 10 years, but if we had to ammend it once or even twice,
this would not be a big tragedy.

My personal advice: let's stop negotiating, call this BCP cooked, 
and move on to other fires.

Carl
(speaking as a "private citizen" again ... my contract with
ISOC has run it's course)


> 
> --On Thursday, 23 December, 2004 10:22 +0100 Harald Tveit
> Alvestrand <[EMAIL PROTECTED]> wrote:
>  
> >>> John,
> >>> 
> >>>...
> >>> I like all of those properties, and it should be a small
> >>> twist of language (starting from the text in the draft, not
> >>> the most recent suggestion) to make it come out that way.
> >>> But I'm not sure I'm reading your words correctly, so better
> >>> double-check
> >> 
> >> A fascinating question, actually.   I think you are reading my
> >> words correctly and that, by happy coincidence, the words that
> >> are now in the draft are fairly easily adapted.
> >> 
> >> But the principles are more important than the words, and I
> >> think this is a profound change in principles.  It is, I
> >> think, a significant change to say "if you expect the IAOC
> >> model to succeed,
> >> 
> >>* the IETF has got to keep its hands off the day-to-day
> >>decisions, even when they seem wrong
> >>
> >>* the IESG and IAB need to be prohibited structurally
> >>from micromanaging, or managing at all, beyond the
> >>degree that the IAOC wants to permit.  They supply
> >>input, they make requests, but decisions rest on the
> >>IAOC side of the wall and stay there, with the only
> >>_real_ recourse being to fire the IAOC
> >> 
> >> and then to figure out a way to implement those principles.
> > 
> > Actually, I think we have agreement on those principles, and
> > have mostly been struggling with how to express them.
> > 
> > Appeals procedures (under whatever name) are procedures that
> > should exist so that if someone thinks something's gone really
> > wrong, it's possible to get it noticed and talked about - and,
> > if it's necessary, corrected.
> > 
> > Trying to manage anything by routine appeals is totally broken.
> 
> Well, perhaps we are close enough that it doesn't make sense to
> have further discussion without text, and text in context, but...
> 
> I think the "something's gone really wrong" and "...corrected"
> part of the above _might_ miss the point I'm trying to make.  
> 
>   (1) If you have an appeal procedure, any appeal
>   procedure at all, then it is up to the judgment of the
>   individual members of the community whether a decision
>   is "really wrong".   I don't need to worry about denial
>   of service attacks here, just about people acting in
>   good faith and with the best of intentions.  Remember we
>   have had debates on the IETF list about the variety of
>   pastries to be available during meeting coffee breaks as
>   well as the theory for selecting meeting sites.   I may
>   be too concerned about this, but I think those debates
>   could easily have led to appeals about meeting locations
>   when people concluded that the decisions being made were
>   against the expressed consensus  desires of the
>   community (or against plain good sense).   Such appeals
>   have been prevented by the assumption that the IETF
>   membership has no ultimate control over _individual_
>   secretariat or Chair meeting siting decisions and that
>   contracts are already signed by the time meeting sites
>   are announced.   That has protected us from procedural
>   entanglements that could easily make meeting scheduling
>   impossible.  But, with the presumed requirements on the
>   admin structure for openness, that particular protection
>   disappears.
>   
>   (2) If there is an mechanism, any mechanism at all, for
>   the IESG and IAB to second-guess administrative entity
>   decisions, I think it can be guaranteed, given the sort

Re: No change needed? #723 - Outsourcing as a principle

[Scott Bradner]

I like John's formulation & reason

In principle, IETF administrative functions should be
outsourced. Decisions to perform specific functions
"in-house" should be explicitly justified by the IAOC
and restricted to the minimum staff required, with these
decisions and staffing reviewed by the IAOC on a regular
basis and against a "zero base" assumption.

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Consensus? #718 Transparency - reports on decisions

[Sam Hartman]

> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes:

Harald> I suggest resolving this by adding the following text to
Harald> section 3.4 "IAOC decision making", after the first
Harald> paragraph:

Harald>   All IAOC decisions are minuted. Minutes are published
Harald> regularly.
I like the intent but don't like the word minuted.  How about all IAOC
decisions are recorded in the minutes of the IAOC.  These minutes are
published regularly.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[John C Klensin]

--On Thursday, 23 December, 2004 09:42 -0800 Carl Malamud
<[EMAIL PROTECTED]> wrote:

> Hi John -
> 
> Your note seems like an outlier.  In particular, it takes a
> really *strong* stance on protecting people from each other
> because people *will* act badly.  For example, the way I read
> your note, the IESG will micromanage and the IASA/IAD will
> order bagels flown in daily from New York.  Appeals will be a
> daily happening and people will hire lawyers instead of
> working it out.

No, my concern is that 

(i) the IESG, or the IESG's leadership, is likely to micromanage
because it has tended to micromanage, or try to do so, many of
the things it has touched in the last several years -- the
secretariat, the content of various documents down to the
editorial level, the RFC Editor, and so on (some of that has
gotten better in recent months or years, but that isn't the
point).  Even you have made the claim that they (for some
instance of "they") have tried to micromanage you in terms of
the contents of your various reports and recommendations.  And
the discussion of why the IETF and IAB Chairs had to be on the
IAOC had, to me, a strong ring of "so we can make sure that
administrative entity does exactly what we want", which is close
to an operational definition of intended micromanagement.   So
that one isn't a corner case, it is a simple extrapolation from
behavior that has been observed in the community (and commented
upon in the Problem Statement work, which makes it feel like I'm
not alone in those impressions).

(ii) If I'm worried about bagels (I'm really not), I'm not
worried about the IAD/IASA making that decision: I expect those
people to be firmly in contact with fiscal realities and
priorities.  If they are not, we will have far worse problems
than the bagel supply.  But I'm concerned about even the
possibility of bagels-by-appeal, or
bagels-by-IESG/IAB-overriding IAD decisions, even while
realizing that particular example is (deliberately) unlikely.

And, as I said, the issue I'm raising is a key management and
management-relationships principle.  Whether one agrees with it
or not, characterizing it as a corner case seems to me like a
stretch.

>...
> Seriously: this BCP seems, imo, pretty much cooked.  There may
> be flaws and holes that people forgot, but this would be a lot
> easier to nail down if we had some operational experience in
> the new framework and then solve problems that are real.
> There are lots of checks in balances in place, there are going
> to be lots of new people who have to get up to speed, and
> the community is watching.  

The observation that what I was suggesting was close to what was
there now and would require only a few wording changes came from
Harald and not from me.   I was just trying to be sure we all
had the same understanding of what those wording changes would
be intended to mean if we mean them.

> I know you don't want to revise the BCP every 10 minutes for
> the next 10 years, but if we had to ammend it once or even
> twice, this would not be a big tragedy.

No.  But I've heard that the draft IAD job description was
floated by a couple of HR/ search experts (I believe at least
one of those reports has not been forwarded to the transition
team because there was no indication that the advice was wanted)
and that the comments involved phrases like "incompetent
description" and "no one sane would take a job defined that
way".   These are not small issues: they go to the very core of
the likely ability of the IAD and IAOC to function.  To
paraphrase an out-of-context quote from a different discussion,
I don't want to see Harald become the next-to-last Chair of the
IETF because of this process.   Put differently, I'd like to be
sure that principles are well enough articulated, and details
left to where they can be worked out, that we get a chance to
revise the BCP without completely killing the IETF in the
process.

> My personal advice: let's stop negotiating, call this BCP
> cooked,  and move on to other fires.

And my personal advice is to make sure that we get the
principles right and that we do so, as needed, based on
competent review and advice.  I also recommend that we look at
past behaviors and assume that they extrapolate cleanly into
future behaviors unless reasons or conditions can be identified
that make such extrapolation inappropriate.  I further recommend
that it is far more useful to look at those extrapolations and
what they mean about both principles and implementation than it
is to spend a lot of energy on scenarios that are really
unlikely, such as how things would be handled, in detail, if
IETF income from meeting fees significantly exceeded all
expenses in a given year.

You may have noted that I've said virtually nothing, on or
off-list, about editorial matters that don't impact principles
except sometimes to suggest that excess detail be removed.  That
is not an accident.  It is consistent, I think, with your desire
to get this co

Issue #745: Section 3.1 - ISOC involvment in budget

[Wijnen, Bert (Bert)]

Scoot, I believe that we have also resolved that issue
implicitly by resolving issue749. Do you agree?

Bert

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #745: Section 3.1 - ISOC involvment in budget

[Scott Bradner]

> Scoot, I believe that we have also resolved that issue
> implicitly by resolving issue749. Do you agree?

not being someone who memorizes issue numbers I had to look these up
but I think you are correct

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #755: Section 5.6 - Building a surplus [was RE: Building a surplus]

[Fred Baker]

At 04:56 PM 12/23/04 +0100, Wijnen, Bert (Bert) wrote:
Maybe we should merge the 2 issues into one?
sure 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

The Font top-level MIME type registration I-D

[Dave Singer]

This was posted a while back and hasn't received much comment.  I 
suspect that it is not so much the quality of the writing as the fact 
that many haven't noticed it...

It proposes registering a top-level font/ MIME type for font formats. 
Note that it is font formats, just like image formats, that we 
propose registering;  I understand that in the past there has been 
some confusion that it might be fonts themselves (e.g. font/courier) 
that would be registered.  That would be like having image/mona-lisa 
or audio/beethoven5th, of course. Rather, we propose font/opentype 
(for example).

This was modelled on another recent top-level MIME type definition.
All comments are gratefully received, of course.
Best of the season to you all.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[Carl Malamud]

Hi  John -

> (i) the IESG, or the IESG's leadership, is likely to micromanage
> because it has tended to micromanage, or try to do so, many of
> the things it has touched in the last several years -- the
> secretariat, the content of various documents down to the
> editorial level, the RFC Editor, and so on (some of that has
> gotten better in recent months or years, but that isn't the
> point).  Even you have made the claim that they (for some
> instance of "they") have tried to micromanage you in terms of
> the contents of your various reports and recommendations.  And
> the discussion of why the IETF and IAB Chairs had to be on the
> IAOC had, to me, a strong ring of "so we can make sure that
> administrative entity does exactly what we want", which is close
> to an operational definition of intended micromanagement.   So
> that one isn't a corner case, it is a simple extrapolation from
> behavior that has been observed in the community (and commented
> upon in the Problem Statement work, which makes it feel like I'm
> not alone in those impressions).
> 

Hmmm  I don't see how worrying this particular BCP to death is
going to change any of that.  You're talking some pretty 
fundmamental doom-and-gloom stuff.  If things are that broken,
could any BCP fix them?

> (ii) If I'm worried about bagels (I'm really not), I'm not
> worried about the IAD/IASA making that decision: I expect those
> people to be firmly in contact with fiscal realities and
> priorities.  If they are not, we will have far worse problems
> than the bagel supply.  But I'm concerned about even the
> possibility of bagels-by-appeal, or
> bagels-by-IESG/IAB-overriding IAD decisions, even while
> realizing that particular example is (deliberately) unlikely.
> 
> And, as I said, the issue I'm raising is a key management and
> management-relationships principle.  Whether one agrees with it
> or not, characterizing it as a corner case seems to me like a
> stretch.
> 

Hmmm again ... maybe it is just the holiday spirit, or the
six months of intensive community work that has gone into
the document, but it just seems to me that bagels-by-appeal,
or any of the other bagel-related scenarios, are corner
cases.



> No.  But I've heard that the draft IAD job description was
> floated by a couple of HR/ search experts (I believe at least
> one of those reports has not been forwarded to the transition
> team because there was no indication that the advice was wanted)
> and that the comments involved phrases like "incompetent
> description" and "no one sane would take a job defined that
> way".   These are not small issues: they go to the very core of
> the likely ability of the IAD and IAOC to function.  To
> paraphrase an out-of-context quote from a different discussion,
> I don't want to see Harald become the next-to-last Chair of the
> IETF because of this process.   Put differently, I'd like to be
> sure that principles are well enough articulated, and details
> left to where they can be worked out, that we get a chance to
> revise the BCP without completely killing the IETF in the
> process.

Well, I wrote portions of that description, so I definitely
resemble that remark.  ;)  I think you're overblowing this
IAD position by asking for things like executive searches.
Feel free to furnish new text to the committee ... 

As to the end of the IETF, mumble.  That seems a bit much.

> 
> > My personal advice: let's stop negotiating, call this BCP
> > cooked,  and move on to other fires.
> 
> And my personal advice is to make sure that we get the
> principles right and that we do so, as needed, based on
> competent review and advice.  I also recommend that we look at
> past behaviors and assume that they extrapolate cleanly into
> future behaviors unless reasons or conditions can be identified
> that make such extrapolation inappropriate.  I further recommend
> that it is far more useful to look at those extrapolations and
> what they mean about both principles and implementation than it
> is to spend a lot of energy on scenarios that are really
> unlikely, such as how things would be handled, in detail, if
> IETF income from meeting fees significantly exceeded all
> expenses in a given year.
> 
> You may have noted that I've said virtually nothing, on or
> off-list, about editorial matters that don't impact principles
> except sometimes to suggest that excess detail be removed.  That
> is not an accident.  It is consistent, I think, with your desire
> to get this cooked and out but without pushing important issues
> under the proverbial rug in the process.
> 
> YMMD, of course, and likely does.

It does.  I've seen a remarkable degree of consensus, a few
tweaks on a few things, but no huge disagreement that the
principles are wrong.  It may not be a great document, the
framework may not be ideal, but I think y'all should move on
and get back to some real work.  :)  

Regards,

Carl

___
Ietf mailing list

Re: #720 and #725 - Appeals and IAD autonomy

[John C Klensin]

--On Thursday, 23 December, 2004 13:31 -0800 Carl Malamud
<[EMAIL PROTECTED]> wrote:

> Hi  John -
> 
>> (i) the IESG, or the IESG's leadership, is likely to
>> micromanage because it has tended to micromanage, or try to
>> do so, many of the things it has touched in the last several
>> years -- the secretariat, the content of various documents
>> down to the editorial level, the RFC Editor, and so on (some
>> of that has gotten better in recent months or years, but that
>>...
> Hmmm  I don't see how worrying this particular BCP to
> death is going to change any of that.  You're talking some
> pretty  fundmamental doom-and-gloom stuff.  If things are that
> broken, could any BCP fix them?

Well, that is one of the reasons why several members of the
community have tried to comment, several times, that the Admin
Reorg effort is addressing problems that are either irrelevant
or not on the critical path.   And I have observed that all of
them, after having been ignored, have simply dropped out of the
discussion.  I suspect, but can't prove, that "in disgust"
belongs at the end of that sentence.

I'd also observe that I don't think you have tried to get a
technical or standards track document through the system in the
last year or two.

>> (ii) If I'm worried about bagels (I'm really not), I'm not
>> worried about the IAD/IASA making that decision: I expect
>> those people to be firmly in contact with fiscal realities and
>> priorities.  If they are not, we will have far worse problems
>> than the bagel supply.  But I'm concerned about even the
>> possibility of bagels-by-appeal, or
>> bagels-by-IESG/IAB-overriding IAD decisions, even while
>> realizing that particular example is (deliberately) unlikely.
>> 
>> And, as I said, the issue I'm raising is a key management and
>> management-relationships principle.  Whether one agrees with
>> it or not, characterizing it as a corner case seems to me
>> like a stretch.
> 
> Hmmm again ... maybe it is just the holiday spirit, or the
> six months of intensive community work that has gone into
> the document, but it just seems to me that bagels-by-appeal,
> or any of the other bagel-related scenarios, are corner
> cases.

The bagels aren't just corner cases, they are a
deliberately-silly example (which I think I've said).  But the
question of how much the IESG and IAB should be able to
intervene in the operations of the IASA is not.

> 
> 
>> No.  But I've heard that the draft IAD job description was
>> floated by a couple of HR/ search experts (I believe at least
>> one of those reports has not been forwarded to the transition
>> team because there was no indication that the advice was
>>...
> Well, I wrote portions of that description, so I definitely
> resemble that remark.  ;)  I think you're overblowing this
> IAD position by asking for things like executive searches.
> Feel free to furnish new text to the committee ... 

I actually never asked for an executive search.  I asked for
review of the description by someone competent in that area and
for the transition team to consider whether an executive search
was appropriate.  My personal hypothesis, as I said on the list,
was that it probably would not be useful and worth the costs.
But I thought the question was important to ask, and am
concerned about the symptoms of its not being asked, of the
description not being reviewed by professionals, etc.

As far as whether I'm overblowing the position, I don't know,
because I still can't figure out from the draft just what the
expectations are of how much authority that person has and what
he or she is expected to do.   If we are talking about an
overblown administrative assistant (or executive assistant to
the IETF Chair), then thinking seriously about searches is
unnecessary.  But I keep seeing phrases that imply managing a
fairly large operation consisting of multiple subcontractors,
shaping a reasonably large budget, and making a large number of
decisions that could, if gotten wrong, impact the IETF's ability
to function.  If _those_ are the expectations, then I think we
really want some executive-level talent in the job and that
hiring someone junior who happens to know some of the IETF
Leadership (not the only alternative, but one extreme
possibility) would be a bit mistake.

> As to the end of the IETF, mumble.  That seems a bit much.

Well, my impression -- it is just an impression, but I am still
trying to get technical work done in this community and keep
hearing from others in the same boat-- is that this process is
sucking a lot of the energy and life out of the community.  I
suggest that very few of the people who are following all of the
BCP and issues traffic are functionally doing anything else in
the IETF.  If those impressions are correct, it brings us to the
question of how long we can pull energy into administrative
planning and similar structural/ organizational issues before it
is fatal... whether fatal to energy, fatal to the notion that
work

Re: The Font top-level MIME type registration I-D

[John C Klensin]

Dave,

The third paragraph of your introduction starts --but only
starts-- to answer the obvious questions of "why not use
application/ ?" and "why do you need a top-level type?"
Assuming we accept your explanation for the first, it seems to
me that the second is still a little dicey. You've defined two
subtypes and I can think of a handful, but only a handful, of
others.   Unless there will be far more subtype registrations
than that suggests, creating a top-level type doesn't feel
right.   

So, let me ask you, and anyone else who is inclined to think
about this, a question: are there other things than fonts which
could use a top-level type and whose needs are similar (as
described in your introduction)?  Is there a more general
problem that we can solve here?  Is  the XML- precedent useful
in any way?

best,
   john



--On Thursday, 23 December, 2004 13:53 -0800 Dave Singer
<[EMAIL PROTECTED]> wrote:

>  .txt>
> 
> This was posted a while back and hasn't received much comment.
> I suspect that it is not so much the quality of the writing as
> the fact that many haven't noticed it...
> 
> It proposes registering a top-level font/ MIME type for font
> formats. Note that it is font formats, just like image
> formats, that we propose registering;  I understand that in
> the past there has been some confusion that it might be fonts
> themselves (e.g. font/courier) that would be registered.  That
> would be like having image/mona-lisa or audio/beethoven5th, of
> course. Rather, we propose font/opentype (for example).
> 
> This was modelled on another recent top-level MIME type
> definition.
> 
> All comments are gratefully received, of course.
> 
> Best of the season to you all.





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Font top-level MIME type registration I-D

[John C Klensin]

Dave,

The third paragraph of your introduction starts --but only
starts-- to answer the obvious questions of "why not use
application/ ?" and "why do you need a top-level type?"
Assuming we accept your explanation for the first, it seems to
me that the second is still a little dicey. You've defined two
subtypes and I can think of a handful, but only a handful, of
others.   Unless there will be far more subtype registrations
than that suggests, creating a top-level type doesn't feel
right.   

So, let me ask you, and anyone else who is inclined to think
about this, a question: are there other things than fonts which
could use a top-level type and whose needs are similar (as
described in your introduction)?  Is there a more general
problem that we can solve here?  Is  the XML- precedent useful
in any way?

best,
   john



--On Thursday, 23 December, 2004 13:53 -0800 Dave Singer
<[EMAIL PROTECTED]> wrote:

>  .txt>
> 
> This was posted a while back and hasn't received much comment.
> I suspect that it is not so much the quality of the writing as
> the fact that many haven't noticed it...
> 
> It proposes registering a top-level font/ MIME type for font
> formats. Note that it is font formats, just like image
> formats, that we propose registering;  I understand that in
> the past there has been some confusion that it might be fonts
> themselves (e.g. font/courier) that would be registered.  That
> would be like having image/mona-lisa or audio/beethoven5th, of
> course. Rather, we propose font/opentype (for example).
> 
> This was modelled on another recent top-level MIME type
> definition.
> 
> All comments are gratefully received, of course.
> 
> Best of the season to you all.





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Issue #755: Section 5.6 - Building a surplus [was RE: Building a surplus]

[Henrik Levkowetz]

on 2004-12-23 9:02 pm Fred Baker said the following:
> At 04:56 PM 12/23/04 +0100, Wijnen, Bert (Bert) wrote:
>>Maybe we should merge the 2 issues into one?
> 
> sure 

I've merged issue #755 with issue #740 in the issue tracker.

Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[Sam Hartman]

> "John" == John C Klensin <[EMAIL PROTECTED]> writes:

John> --On Thursday, 23 December, 2004 09:42 -0800 Carl Malamud
John> <[EMAIL PROTECTED]> wrote:

>> Hi John -
>> 
>> Your note seems like an outlier.  In particular, it takes a
>> really *strong* stance on protecting people from each other
>> because people *will* act badly.  For example, the way I read
>> your note, the IESG will micromanage and the IASA/IAD will
>> order bagels flown in daily from New York.  Appeals will be a
>> daily happening and people will hire lawyers instead of working
>> it out.

John> No, my concern is that

John> (i) the IESG, or the IESG's leadership, is likely to
John> micromanage because it has tended to micromanage, or try to
John> do so, many of the things it has touched in the last several
John> years -- the secretariat, the content of various documents
John> down to the editorial level, the RFC Editor, and so on (some
John> of that has gotten better in recent months or years, but
John> that isn't the point).  Even you have made the claim that
John> they (for some instance of "they") have tried to micromanage
John> you in terms of the contents of your various reports and
John> recommendations.  And the discussion of why the IETF and IAB
John> Chairs had to be on the IAOC had, to me, a strong ring of
John> "so we can make sure that administrative entity does exactly
John> what we want", which is close to an operational definition
John> of intended micromanagement.  So that one isn't a corner
John> case, it is a simple extrapolation from behavior that has
John> been observed in the community (and commented upon in the
John> Problem Statement work, which makes it feel like I'm not
John> alone in those impressions).

Micro-management is not the same as management.  I actually think the
IESG and IAB have done a good job of stepping in, applying management
and solving some real problems over the years.  I realize that I'm now
part of the IESG and thus part of the organization that you believe is
doing too much micro-management.  However I haven't been involved in
many of the past decisions and so I think that this response is at
least mostly untainted by my involvement in the IESG.p


So, I do see the IESG and IAB continuing to try and set priorities for
the parts of the secretariat that influence the standards process.
Clearly these priorities will need to be evaluated in the entire
budget context by the IASA just as they are now evaluated by Fortec.


I'm not sure what specific issues you believe are micro-management.
However I contend that this BCP is not the right forum for these
concerns to be addressed.  If you have concerns about how the IAB and
IESG are conducting themselves, there are several approaches you could
take.  First, you can provide input to the IESG and IAB about how they
have handled specific issues and how they are handling issues before
them.  In cases where you believe it is necessary to do so, you can
even appeal decisions.  You can also provide feedback to the nomcom if
you believe that a different set of qualifications or outlook is
required for IESG and IAB members.



--Sam, speaking only for myself

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[John Leslie]

John C Klensin <[EMAIL PROTECTED]> wrote:
> --On Thursday, 23 December, 2004 13:31 -0800 Carl Malamud
> <[EMAIL PROTECTED]> wrote:
>> [John Klensin wrote:]
>> 
>>> (i) the IESG, or the IESG's leadership, is likely to
>>> micromanage because it has tended to micromanage, or try to
>>> do so, many of the things it has touched in the last several
>>> years...

   John Klensin, I think, is in a position to know whether this is
so. I haven't seen evidence that he's wrong...

>> Hmmm  I don't see how worrying this particular BCP to
>> death is going to change any of that.  You're talking some
>> pretty  fundmamental doom-and-gloom stuff.  If things are that
>> broken, could any BCP fix them?

   Well, we've had at least partial success on previous tries...

   But that's really not the point. We should ask, will _this_ BCP
tend to make that situation better or worse?

> Well, that is one of the reasons why several members of the
> community have tried to comment, several times, that the Admin
> Reorg effort is addressing problems that are either irrelevant
> or not on the critical path. 

   Indeed. The lack of agreement what _is_ the critical path has
made this process difficult.

> And I have observed that all of them, after having been ignored,
> have simply dropped out of the discussion. 

   This is not the way consensus is supposed to work: that things
get dragged out until only like-minded people are still around.
Consensus is supposed to consider issues raised by even very small
minorities, and try to satisfy all reasonable persons that their
concerns are addressed.

>>> ... But I'm concerned about even the possibility of
>>> bagels-by-appeal, or bagels-by-IESG/IAB-overriding IAD decisions,
>>> even while realizing that particular example is (deliberately)
>>> unlikely.

   This example is sufficiently unlikely that one is tempted to
dismiss it, and miss the baby being thrown out with the bathwater.

   I'm not so much worried about IESG actually _appealing_ the
decision on where to get bagels as I am about language which seems
to encourage anyone who doesn't like the bagels to _ask_ the IESG
to appeal it. Inevitable, somebody will claim to have heard that
 didn't like the bagels, at which
point it will be hard for any Chair to avoid wasting time talking
about bagels. :^(

   The whole idea here, I thought, was to set up a support structure
which would just work -- so that it could be "invisible" to the IESG
and never need to be discussed by that group. (The problem, I thought,
was that shortcomings of the current Secretariat were entirely too
visible; and the IESG was spinning its wheels discussing them.)

>>> And, as I said, the issue I'm raising is a key management and
>>> management-relationships principle.  Whether one agrees with
>>> it or not, characterizing it as a corner case seems to me
>>> like a stretch.

   Let's review what John Klensin asked for:
" 
"  * the IETF has got to keep its hands off the day-to-day 
"decisions, even when they seem wrong
"  
"  * the IESG and IAB need to be prohibited structurally
"from micromanaging, or managing at all, beyond the
"degree that the IAOC wants to permit.  They supply
"input, they make requests, but decisions rest on the
"IAOC side of the wall and stay there, with the only
"_real_ recourse being to fire the IAOC

   This doesn't sound like a "corner case" to me.

>>> You may have noted that I've said virtually nothing, on or
>>> off-list, about editorial matters that don't impact principles
>>> except sometimes to suggest that excess detail be removed.
>>> That is not an accident.  It is consistent, I think, with
>>> your desire to get this cooked and out but without pushing
>>> important issues under the proverbial rug in the process.
>>> 
>>> YMMD, of course, and likely does.
>> 
>> It does.  I've seen a remarkable degree of consensus, a few
>> tweaks on a few things, but no huge disagreement that the
>> principles are wrong.  It may not be a great document, the
>> framework may not be ideal, but I think y'all should move on
>> and get back to some real work.  :)  

   I respect Carl's belief... but I respect John Klensin's worry
more.

> And I think that a large fraction of that "remarkable degree of
> consensus" is consensus by exhaustion of most of the community.
> I've even heard from several IAB and IESG members that they have
> been exhausted by the process and can't deal with it any more.

   They shouldn't have to!

   If what we design doesn't make their job easier, and reduce
the non-Internet things they need to worry about, this whole
process will be a terrible mistake.

   I have a great deal of respect for Harald. He's done a very
good job of managing a very difficult process. The process is an
exhausting one -- we're trying to replace a totally unique process
which _used_to_ work well for us with a slightly less unique
process which none of us have experience with.

   Beliefs run strong. Legitimate con

Re: #720 and #725 - Appeals and IAD autonomy

[avri]

On 23 dec 2004, at 20.07, John Leslie wrote:
I'm not so much worried about IESG actually _appealing_ the
decision on where to get bagels as I am about language which seems
to encourage anyone who doesn't like the bagels to _ask_ the IESG
to appeal it.
I don't understand why it is that the IESG would make the appeals (I 
know this was the suggestion).  I think that appeals should continue to 
work as they do now.  First you appeal to the one who made the decision 
you don't like, then you escalate it.  So if I want to appeal the IAD's 
decision, i go to the IAD.  If I am not satisfied with the answer i go 
to the IAOC and then up the food chain (staying with the bagel motif) 
from there.

a.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[Spencer Dawkins]

Hi John -
Your note seems like an outlier.  In particular, it takes a really
*strong* stance on protecting people from each other because
people *will* act badly.  For example, the way I read your
note, the IESG will micromanage and the IASA/IAD will order
bagels flown in daily from New York.  Appeals will be a daily
happening and people will hire lawyers instead of working it out.
John's note took a stronger stand than I would have taken, but I 
happen to agree with most of his points - especially that IASA/IAD 
effectiveness should be evaluated in large slices. Maybe annually, 
certainly not decision-by-decision.

In my second marriage, I have learned that in a partnership vital to 
both parties, I don't get to pick the parts I like and demand that the 
other parts change. It's a package deal. If the package works, great, 
but trying to turn a package that doesn't work into one that does, 
part by part, just isn't worth the aggravation and agony.

Spencer 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf