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@qualcomm.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@qualcomm.com> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102