Subject: A charter for the IESG

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 07 Mar 2003 16:10:55 +0100

Hello,

in December, I published an internet-draft called 
"draft-iesg-charter-00.txt", containing a proposed text for an IESG charter.
A revised version (-01) was published in January based on comments.

A version with some further clarifications is created, but not published 
before the cutoff - it's available at
http://www.alvestrand.no/ietf/chair/iesg-charter.txt

Some discussion has taken place on the POISED list 
([email-masked]), but the point has been made that for such a 
potentially important document, the IETF list may actually be a more 
appropriate venue for discussion. Hence this note.

This IESG charter attempts to capture what the IESG has believed that it 
has been asked to do by the IETF community. Most of the document is simply 
collecting references to sections of other IETF BCP documents, and 
attempting to form a coherent picture of what the IESG is supposed to be 
doing. I do not believe that it shows the IESG to be much different from 
what the community currently believes it is.

What I hope to do with this document is:

- Discuss it on this mailing list and on the POISED mailing list as the 
community finds appropriate

- Discuss it privately in San Francisco with those who are concerned, and 
in the plenary if there are questions raised from the community

- Send out a revised version some time after San Francisco

- Issue a four-week Last Call for BCP on the document once discussion has 
stabilized

- Approve it for BCP before the Vienna IETF

At the Vienna IETF, the "problem" working group is scheduled to make a 
consensus call on the process for *changing* the IETF process. While the 
shape of the result is still unknowable, I believe it's likely that among 
the outputs of such a process will be a greatly changed IESG charter.

But until then, I believe there is value in publishing this document.

What does the community think?

                 Harald Alvestrand

---

From: Joe Baptista <[email-masked]>
Date: Fri, 7 Mar 2003 12:06:10 -0500 (EST)

why don't you have an irc meeting so we can all publically give our
comments on this.

regards
joe baptista

Joe Baptista - only at www.baptista.god

  Free Tibet http://free.tibet/

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Mar 2003 12:07:54 -0500

> doing. 

I think it is useful to document current practice and the justification for
that practice.

I do not think it's a good idea to call it a charter, at least not at this
stage, because the work of documenting current practice needs to be kept
separate from the work of documenting desirable practice.  Many people
understand the word 'charter' as a grant of rights/privileges/
responsibilities/etc. and that's not the same thing as documenting current
practice.  If the document claims to grant rights to IESG, and people don't
like those rights, people will want to change the document, and that
interferes with the work of documenting current practice.

It's fine to request that the document that describes current practice be
labelled BCP; this is very much in line with the purpose of BCP.  But if there
is pushback from the community that says this document is not desirable
practice, the document should be published as Informational and clearly
labelled as documenting current practice - NOT claiming that it is a charter.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 7 Mar 2003 12:39:01 -0500

On Friday, Mar 7, 2003, at 12:07 America/Montreal, Keith Moore wrote:
> separate from the work of documenting desirable practice.

It is not clear to me that the current www.ietf.org version of this I-D
only "document(s) existing practice and the justification of that 
practice".
Since the document appears to be broader and since it does in fact 
define
the roles/responsibilities of the IESG, calling it an IESG Charter is 
both
appropriate and clear.  The existing IAB Charter RFC is a very close 
analogue
to this new I-D, for example.

Keith Moore disagrees with at least part of my words above; I'll not 
respond
to any of his followups on this narrow point of document title.

And again, I'm glad to see *something* concrete get written down and put
out for community review.  I think it would be in everyone's best 
interest
for everyone to at least read through the I-D before it goes to RFC.
That way, if any concerns exist with the I-D, those concerns can be 
resolved.

Ran

---

From: Bob Hinden <[email-masked]>
Date: Fri, 07 Mar 2003 09:51:57 -0800

Harald,

>- Approve it for BCP before the Vienna IETF

I don't think it is appropriate for the IESG to approve it's own 
charter.  We don't let working groups approve their own charters.  Like the 
working group charter process, there needs to be an independent group 
running the process, getting IETF community input, and approving it.

Possible choices for groups to drive this process are the IAB or the ISOC 
Board of Trustees.  A process where the IAB approves the charter with 
review and comments from the ISOC BoT would also work.

This issue needs to be discussed and agreed by the IETF community.

Bob

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 08 Mar 2003 17:22:54 -0500

Some comments on the process...

I have specific comments on the document, but I will send them
separately.

>what the community currently believes it is.

I think you need to be very clear about what this document is trying
to accomplish.  Are you trying to:

         #1 Document what the IESG believes its current role, authority
                 and responsibilities are?
         #2 Document community consensus regarding the role, authority and
                 responsibilities that the community has granted to the IESG?

Some of the discussions on the problem-statement list indicates that
there may be a gap between these two things.

If you are trying to do #1, then the process you have identified sounds
fine.  However, I would consider this to be an informational communication
from the IESG to the community, so I think it should be published as an
Info RFC, not a BCP.  Also, the document should state that it is a
communication from the IESG to the community, and does not represent a
community mandate.

If you are trying to do #2, then revision control needs to belong to the
community.  You may choose to serve as the editor of this document, but
you would need to update it, as necessary, to reflect community consensus.
I also think that this would take longer than you have outlined, and it
might not make sense to do this in parallel with the problem-statement
effort.

>But until then, I believe there is value in publishing this document.

I think that there could be considerable value in publishing a document
that explains what the IESG believes its charter to be (#1 above).  Among
other things, this could serve as a useful baseline for any changes that
the community decides to make as a result of the problem-statement effort.
But, I would prefer to see such a document published as an Info RFC, with
wording that would discourage misinterpretation of the document as a
community mandate.

Margaret

---

From: Pete Resnick <[email-masked]>
Date: Sat, 8 Mar 2003 19:20:49 -0800

>wording that would discourage misinterpretation of the document as a

I agree wholeheartedly with Margaret, with regard to both the value 
of such a document and the form it should take. I believe it would be 
incredibly useful to the problem-statement group, especially since it 
has been said that some of the items in the problem-statement draft 
do not reflect the reality of how the IESG operates. It would be good 
to actually see how the IESG views its operations. I also think that 
an Informational RFC is exactly what is called for; a BCP would 
require IETF consensus and would inappropriately compete with the 
problem-statement work.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Mar 2003 09:02:36 +0100

Pete,

since I'm more fond of being right than of being consistent...... I want to 
try to argue for the INFO case....

some more thoughts on the BCP vs INFO issue.

Short argument:

- IF the community thinks that process BCPs should in general be followed
- IF the community agrees that changing BCPs is a slow process
- IF the community thinks that the process components described in the IESG 
charter need to be changed on shorter notice than the release cycle for BCP
- THEN the IESG charter should be an INFO document

More background:

As Keith Moore said on the problem-statement list -

> IETF has two common practices that almost always produce poor results:
>
> 1. trying to solve a problem before it is understood
> 2. trying to document existing practice and desirable practice
>     at the same time
>
> please, let's not make either of these mistakes with the IESG charter

The problem-statement effort will likely result in changes in the IETF 
structure. Including the role of the IESG - I would be very disappointed if 
it did not!
So the current IESG charter will not have much direct effect on what the 
IETF process is after that process has completed.

We then have 3 cases I can think of, for the period between now and the end 
of the problem-statement effort:

- The community thinks that the current charter is fine, and wants to 
constrain the IESG to continue to behave accordingly until the new process 
comes along: It needs to be BCP, because that's the only thing that 
constrains.

- The community thinks that the process needs to be changed in ways that 
are inconsistent with the charter as written, but that it's OK to discuss 
the changes for a long time before making them: BCP works fine, because we 
can reissue the BCP when we need to change the process.

- The community thinks that process needs to be changed, and on short 
notice, in ways that are inconsistent with the charter as written, but 
consistent with the older BCPs (2026 and friends): INFO is the right 
answer, because this allows the IESG to do what it thinks is right without 
being constrained by the charter text, while preserving the theory that 
BCPs ought to be followed.

(There's a fourth case - that the community thinks that BCPs are just 
advisory documents that can be ignored at will. I don't think that's a path 
we want to start down.... but in that case, the distinction does not 
matter...)

                      Harald

--On lørdag, mars 08, 2003 19:20:49 -0800 Pete Resnick 
<[email-masked]> wrote:

>> the community decides to make as a result of the problem-statement
>> effort. But, I would prefer to see such a document published as an Info
>> RFC, with wording that would discourage misinterpretation of the
>> document as a community mandate.
>
> I agree wholeheartedly with Margaret, with regard to both the value of
> such a document and the form it should take. I believe it would be
> incredibly useful to the problem-statement group, especially since it has
> been said that some of the items in the problem-statement draft do not
> reflect the reality of how the IESG operates. It would be good to
> actually see how the IESG views its operations. I also think that an
> Informational RFC is exactly what is called for; a BCP would require IETF
> consensus and would inappropriately compete with the problem-statement
> work.
>
> pr
> --