Re: Response to appeal [...]

"Frank Ellermann" <> Mon, 07 July 2008 20:39 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 7E2F93A6B1C; Mon, 7 Jul 2008 13:39:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5ABA3A6B03 for <>; Mon, 7 Jul 2008 13:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.858
X-Spam-Status: No, score=-3.858 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EucjZwXEbAgG for <>; Mon, 7 Jul 2008 13:39:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 68A583A68D5 for <>; Mon, 7 Jul 2008 13:39:13 -0700 (PDT)
Received: from list by with local (Exim 4.43) id 1KFxUU-0002xb-41 for; Mon, 07 Jul 2008 20:39:18 +0000
Received: from ([]) by with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Mon, 07 Jul 2008 20:39:18 +0000
Received: from hmdmhdfmhdjmzdtjmzdtzktdkztdjz by with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Mon, 07 Jul 2008 20:39:18 +0000
From: "Frank Ellermann" <>
Subject: Re: Response to appeal [...]
Date: Mon, 7 Jul 2008 22:41:38 +0200
Organization: <>
Lines: 79
Message-ID: <g4tutc$pbb$>
References: <>
Mime-Version: 1.0
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Frank Ellermann <>
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

IESG Secretary wrote:

> This is a response to that appeal.
> The IESG came to consensus that the use of non-example domain
> names should not prevent publication of RFC2821bis, even though
> the IESG finds this practice can cause harm.

Good enough, hopefully the discussed examples are updated before
publication.  Not because they directly cause harm, but because
thousands of 2821bis readers might read no other RFC (assuming
that 2821bis is advanced to STD unmodified).

> Community input is needed with respect to the application of
> this policy to revision of specifications.

Fixing known errata and nits, as well as clarifying or removing
unused or non-interoperable features, is IMO the whole point of
the maturity levels (in practice - in theory it means that we
might soon see more than two implementations based on 2821bis
instead of RFC 821, but that is obviously hilarious).

If you consider the relevant IDnits as an "2606 implementation"
it is IMHO fine -- everybody here knows that "recommended" and 
"required" are no synonyms.

> it is normal, and indeed encouraged, to establish a dialog 
> between the holder of the DISCUSS, the document shepherd (see
> RFC 4858), the authors, the working group, and the sponsoring
> AD.

There is apparently a bug in RFC 4858, it asks the shepherd to
judge the WG consensus.  But the shepherd is not necessarily a
co-Chair or AD (see 3.e in 4858).  Judging consensus is a task
that cannot be delegated, the shepherd is no scapegoat.

When you clarify those DISCUSS rules please make sure that it
always means what the name says, a DISCUSS must not degenerate
into a veto, only 1/3 or more ABSTAINs are a veto.

Or in the opposite direction, if "discuss-discuss" is actually
a "pseudo-DEFER" something with the DEFER rules is wrong.  

> One of the items that was felt important in improving this 
> process was that the role of the shepherds should be more
> central than it currently is.

Non-WG shepherds or non-Chair WG-shepherds are IMO volunteers
for various non-critical tasks of sponsoring ADs or WG Chairs.
But judging consensus is critical, it is one reason why there
are WGs and an IESG at all.

> The IESG Statement "DISCUSS Criteria in IESG Review" is 
> consistent in spirit with this request, noting that stylistic
> issues and pedantic corrections are not appropriate for a

I'm not exactly sure why stylistic issues cannot be discussed.
As long as what happens really is a discussion, i.e. authors
are free to say thanks for the feedback and do what they like.

clearer difference.  With rules that a DISCUSS automatically
turns into NO OBJECTION after a time out, while an OBJECTION
automatically turns into an ABSTAIN after a generous time out.

> the IESG does not agree that the interests of the IETF and
> Internet community are always served by prohibiting changes
> when documents advance.

Good.  I'm not aware that the appeal proposed something else.

> The IESG continues to welcome feedback from the community on
> its procedures.

Nobody seriously wanted to replace RECOMMENDED by REQUIRED in
2606bis, as far as I can judge it from the feedback (thanks). 


Ietf mailing list