ietf-smtp
[Top] [All Lists]

Re: More new text for 2821bis

2008-07-09 06:20:03



--On Wednesday, 09 July, 2008 08:04 -0400 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:

Adding an IESG note to a standards-track RFC is longstanding
practice as a way for IESG members to "hold their noses" and
feel better about approving a document which they dislike.
Less frequently, it could also be used as a way to document
irreconcilable differences between the document
author/editor/wg and IESG while still letting the document
move forward.  But mostly I think it was a way for IESG
members to "feel better" about approving a document when there
was something they didn't like and they were under pressure
(usually from other IESG members) to approve it anyway.

I think they started using it around the time I was on IESG
(1996-2000) - at least it seemed to become increasingly common
during that time).  I don't know if the practice is documented
anywhere - it was (IIRC) an informal agreement between IESG
and the RFC Editor.

Such notes have been useful when there were important
technical considerations that a WG refused to address.  But
IMHO they have also frequently been used for fairly petty
concerns, as in this case.

Keith,

Now I'm going to make an editorial comment...

Certainly I know the history.  To a greater or lesser degree,
most of us do.   Certainly it is just good sense, and therefore
entirely appropriate, for the IESG to use a note to record a
comment about technical controversy or weak consensus.   For
example, I would consider a note on a document that said:

        "Consensus in the community for publishing this document
        as a Proposed Standard was extremely weak, with many
        people questioning ... or preferring ...".  The IESG
        concluded that it should be published on the Standards
        Track anyway because... Readers are encouraged to note
        that, while many IETF Standards Track documents are
        implemented and deployed at Proposed Standard, the
        definition of that maturity level does not require a
        complete and tested specification and to check even more
        carefully than usual for revised documents and
        accumulated experience after publication."

entirely appropriate, even if it is very strong (assuming it
reflected the actual situation). 

While there were clearly issues that clouded the decisions, and
the decisions themselves may or may not have been correct, the
SPF case that Frank cites in his message about the notes on RFC
4408 (etc.), very definitely reflected a case in which there was
ongoing controversy and no clear consensus in the community.
The IESG also took the action that is clearly permitted to them
in such cases, which was to publish documents as Experimental or
Informational rather than on the Standards Track

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.

sigh

regards,
     john

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