Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Russ Housley <[e-mail]>]

Ted:

First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis, I 
do not find the argument about continuity very questionable.  This 
document does include some clarification and lessons learned, and it 
includes much more too.

RFC 2821 Outline for Sections 1 and 2:

    1.     Introduction
    2.     The SMTP Model
    2.1    Basic Structure
    2.2    The Extension Model
    2.2.1  Background
    2.2.2  Definition and Registration of Extensions
    2.3    Terminology
    2.3.1  Mail Objects
    2.3.2  Senders and Receivers
    2.3.3  Mail Agents and Message Stores
    2.3.4  Host
    2.3.5  Domain
    2.3.6  Buffer and State Table
    2.3.7  Lines
    2.3.8  Originator, Delivery, Relay, and Gateway Systems
    2.3.9  Message Content and Mail Data
    2.3.10 Mailbox and Address
    2.3.11 Reply
    2.4    General Syntax Principles and Transaction Model

draft-klensin-rfc2821bis-10 Outline for Sections 1 and 2:

    1      Introduction
    1.1    Context and Notes for this Draft
    1.2    Mailing List
    1.3    Transport of electronic mail
    1.4    History and context for this document
    2      The SMTP Model
    2.1    Basic Structure
    2.2    The Extension Model
    2.2.1  Background
    2.2.2  Definition and Registration of Extensions
    2.2.3  Special Issues with Extensions
    2.3    Terminology
    2.3.1  Mail Objects
    2.3.2  Senders and Receivers
    2.3.3  Mail Agents and Message Stores
    2.3.4  Host
    2.3.5  Domain Names
    2.3.6  Buffer and State Table
    2.3.7  Commands and Replies
    2.3.8  Lines
    2.3.9  Message Content and Mail Data
    2.3.10 Originator, Delivery, Relay, and Gateway Systems
    2.3.11 Mailbox and Address
    2.4.   General Syntax Principles and Transaction Model

Note: Sections 1.1 and 1.2 are to be deleted prior to publication of 
the document as an RFC.

I am not saying that any of the changes are inappropriate, but that 
it is hard to claim that the changes are minimal.

Second, from my perspective, the dialogue about this document did not 
happen as you suggest.

The issue was first raised in the SecDir Review during IETF Last 
Call.  The text from that SecDir Review was included in my note on 
this thread in response to Dave Crocker.  When I highlighted this 
paragraph, the document PROTO shepherd pointed out that the 
"isif.usc.edu" and "[e-mail]" were left in the document as a 
tribute to Jon.  No one has objected to this.  This lead to a 
discussion of the domain names in the rest of the document.

At least three ADs believe that the examples should be changed, and 
they have comments in the Data Tracker that clearly indicate this 
position.  Others feel that the examples out to be changed, but do 
not consider it important enough to delay the document.

We are no having a debate to determine the community consensus on 
this topic.  In addition to the people that are speaking publicly on 
this thread, I am receiving a fair number of private messages.  Some 
are supportive of the appeal position and others are not.  Judging 
community consensus in such a situation is somewhat difficult.  I 
have suggested to the IESG a way to determine the community consensus 
in this case, and I am waiting to hear if other ADs think it is a 
good idea or not.

Russ

At 02:33 PM 6/19/2008, Ted Hardie wrote:
>At 10:50 AM -0700 6/19/08, Russ Housley wrote:
> >
> >That seems to be the crux of the appeal.  Does every possible thing
> >upon which an AD can raise a DISCUSS position need to align with a
> >written rule?  Don't we select leaders because we have some
> >confidence in their judgement?
> >
> >Russ
>
>Russ,
>         This is casting the problem in ways that continue to miss
>the point.  Of course we expect individual Area Directors to exercise
>judgement, and we expect the IESG as a body to do the same.
>
>         But we also expect them to exercise due care in listening
>to the folks actually doing the work, and not over-rule them when they
>clearly have considered the issues.  In this case, John's appeal makes
>clear that the folks writing the document considered the issue
>and made a decision to value continuity.  A DISCUSS position
>to reconfirm that in light of an Area Director's concerns would
>be valid (and probably welcome); once confirmed though, it
>should get dropped.  Otherwise, it over-rules a community decision
>with the individual technical judgement of the Area Director.
>
>         There are very few cases where that is okay.  It applies when
>there is a documented, larger community consensus that the WG or
>submission group decision ignores (a working group decision that
>congestion control wasn't important would get pushback on this
>front, for example).  It applies when the Area Director can demonstrate
>harm to the Internet as a result of the decision; the "can demonstrate"
>there, though, is to the *community* not just to himself or the IESG.
>It applies when the Area Director can demonstrate that the proposal
>simply *does not work* to the satisfaction of the larger community, no
>matter what the proposers believe.
>
>         Most DISCUSS don't need to meet any of those tests because
>the WGs or proposers agree that the issues need to be addressed, so
>there is no over-ride present.  That's good, because over-riding the
>considered technical judgement of the folks doing the work doesn't
>just generate appeals, it drives folks away.  The extent to which
>the current IESG is sliding back into substituting its technical
>judgement for the WGs' is a worrying trend that I've already pointed
>out.  This appeal may seem to be on a small point in a single
>document, but the issue is quite fundamental.  The IETF can drive
>itself into irrelevance very quickly by appearing to be driven by
>ex cathedra pronouncements; even the Pope has done that only
>once since his infallibility was declared doctrine.  Doing so constantly
>over things where the AD's opinion is not backed by community
>consensus is currently getting you an appeal.  The next step could
>well be reformation.
>
>         I hope the IESG considers John's appeal in this light
>and responds promptly to the issues he has raised.
>
>                                 Ted Hardie
>
>

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf