ietf-smtp
[Top] [All Lists]

Re: More new text for 2821bis

2008-07-09 12:26:01



--On Wednesday, 09 July, 2008 09:33 -0400 Keith Moore
<moore(_at_)network-heretics(_dot_)com> 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


<Prev in Thread] Current Thread [Next in Thread>