--On Wednesday, 09 July, 2008 09:33 -0400 Keith Moore
<[EMAIL PROTECTED]> wrote:
>
>> But, unless it contains significant and important information,
>> this stuff clutters up documents and, when there _is_
>> consensus about the technical specification and publication,
>> can constitute the IESG saying "regardless of the community
>> consensus, we, the all-seeing and all-knowing IESG, know
>> better and are going to take advantage of our privileged
>> position to state our opinion of the document --not in a
>> dissenting RFC (which the IESG claims an absolute right to
>> publish if they feel like it), or in an IESG statement, but
>> by changing the Standards Track RFC itself. There may be
>> situations where even that is appropriate, but the question
>> is what the limits are on this mechanism being used, largely
>> invisibly (unless, as Frank notes, the author notices on
>> AUTH48 and protests), and how far things can descend, to use
>> your words, toward "fairly petty concerns", on the IESG's own
>> authority.
>
> well, yeah.
>
> Though as the entire purpose of the note is, in some sense, to
> let the IESG move on and get documents published when there
> remains disagreement between the document author/editor/wg and
> IESG, a process that required agreement on those notes would
> seem to defeat their purpose. And without such notes,
> presumably more documents would be delayed. So I am having a
> bit of trouble coming up with a process remedy that works
> better than what we have now.
Three things occur to me. Neither is a solution, but I believe
that they would be helpful:
(1) Unless there is a technical issue that affects the protocol
itself (not the form of the specification), IESG Statements and
notes on Protocol Action notices should be favored over IESG
modifications to, or disclaimers on, actual Standards Track RFC
text.
(2) As was discussed in other contexts, any assertion of
substantive harm needs to be backed up by clear evidence and/or
community consensus. If neither is possible, the third
provision becomes even more important.
(3) Any time the IESG decides it is important to put one of
these statements into RFC text without clear and demonstrated
community (not just IESG consensus), all of the IESG members
supporting that move should be required to identify themselves
explicitly in the Protocol Action Notice or some other location
that is visible to the community and the Nomcom. The Nomcom is
the communities main way or judging, and protecting itself
against, behavior that might be considered petty or otherwise
inappropriate. ADs should be required to identify themselves
and take responsibility for their decisions, not to hide behind
"the IESG finds".
john
