IESG transparency

RJ Atkinson rja@extremenetworks.com
Wed, 13 Nov 2002 12:55:56 -0500


On Wednesday, Nov 13, 2002, at 03:04 America/Montreal, Harald Tveit 
Alvestrand wrote:
> --On tirsdag, november 12, 2002 18:57:13 -0500 RJ Atkinson 
> <rja@extremenetworks.com> wrote:
>> On Tuesday, Nov 12, 2002, at 02:56 America/Montreal, Harald Tveit
>> Alvestrand wrote:
>>> the reason I asked is that *somewhere*, there has to be stated an
>>> overarching purpose for the organization, which is the driver for the
>>> actual content of the IESG charter.
>>
>> I could be confused, but I think the purpose of the IESG is "to manage
>> the day to day processes, Areas, and Working Groups of the IETF".
>
> manage them to what purpose?
> you can't make a value judgment on whether the IESG is doing well or 
> badly without looking at how its performance impacts the 
> organization's ability to reach its goals.
> And that requires a consensus on those goals.

The IETF creates Internet standards.
So the IESG manages WGs for the purpose of creating Internet Standards.

I really don't think we need to make this much more complicated than 
that.
We can make things gratuitously complex, but some of us would prefer not
to do that.

>>> If we put that into the IESG charter, we have to change it if we 
>>> change
>>> substantially the way the IESG works.
>>>
>>> If it is on the outside, it may be more stable.
>>
>> Having an IETF charter is not a substitute for having an IESG charter.
>> One of the reasons folks want an IESG charter is to have the IESG's
>> powers delineated (even if that is done broadly).  Right now there is
>> not a common, shared understanding of what powers the IESG has.
>
> RFC 2026 and 1603 are reasonably explicit in a lot of places.

Yes, but do NOT speak to the scope of the IESG's powers.  The IESG
in practice does lots of things (e.g. ADs in practice are creating
separate and different policies on mailing list management for WGs
in their areas) that aren't discussed in either of those RFCs.

> PS - the reason I'm pushing back on this now (apart from the fact
> that I haven't done my homework and drafted those charters since 
> Yokohama)
> is that I'd like to keep focus on the problems/issues, not the 
> solutions -
> the problem you identified is "there is not a common, shared 
> understanding
> of what powers the IESG has", and writing an IESG charter is a 
> possible solution
> to that.

Please provide an example of another scalable solution to that problem.
If there is no documentation on the IESG's scope and charter and limits,
creating documentation seems like the only possible answer.  Now maybe
that would be a web page rather than RFC (implementation detail), but
RFC-2026 and custom implies that it would need to be an RFC that went 
through
a BCP-like Last Call.

> Other problems might be:
>
> - the IESG has too much power (specifics)
> - the IESG has too little power (specifics)
> - the IESG doesn't wield the power it has brutally enough (specifics)
> - the IESG wields the power it has too brutally (specifics)
>
> If those are the basic problems, writing a charter describing the 
> status quo ante won't solve them (but might make them come more 
> closely into focus).

Writing an I-D would certainly be a good starting place.  And I think
the IESG are the best ones to draft an initial I-D.

Maybe a reasonable goal could be to have an I-D online with a 
strawman/draft
proposal from the IESG for an IESG charter before the I-D cutoff for the
Spring 2003 IETF ?

IESG reluctance to do just this over the past ~5 years is absolutely a 
big
part of why the community perceives the IESG as lacking transparency.

And if IESG wanted to propose an IETF charter I-D along the way, which 
you seem
to think is a precondition, I don't think that making such a proposal 
would garner
a lot complaints from the community.

Regards,

Ran