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
<presnick(_at_)qualcomm(_dot_)com> wrote:
On 3/8/03 at 5:22 PM -0500, Margaret Wasserman wrote:
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.
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:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102