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

John C Klensin <> Tue, 17 June 2008 19:31 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 0B67E3A6A04; Tue, 17 Jun 2008 12:31:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBB013A6A35 for <>; Tue, 17 Jun 2008 12:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9ni3Vj2PbHf for <>; Tue, 17 Jun 2008 12:31:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 218F83A6981 for <>; Tue, 17 Jun 2008 12:31:23 -0700 (PDT)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1K8gu3-000EYQ-Kf; Tue, 17 Jun 2008 15:31:40 -0400
Date: Tue, 17 Jun 2008 15:31:35 -0400
From: John C Klensin <>
To: Simon Josefsson <>, Brian Dickson <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Message-ID: <>
In-Reply-To: <>
References: <> <> <p06250116c47c330c7dd0@[]> <> <g36r20$bgq$> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Frank Ellermann <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

--On Tuesday, 17 June, 2008 11:30 +0200 Simon Josefsson
<> wrote:

> Brian Dickson <> writes:
>> Here's my suggestion:
>> List 2606 in the informative references, and footnote the
>> examples used  to indicate
>> that they are "grandfathered" non-2606 examples.
>> So, in text that previously read "", it might
>> read  " [*]",
>> with the references section having "[*] Note - non-RFC2606
>> examples  used. Please read RFC2606."
>> Something along those lines, should hopefully be enough to
>> keep both  sides happy, and resolve the DISCUSS,
>> and hopefully both set a suitable precedent *and* make moot
>> the appeal.
> I think this sounds like a good compromise, and it does
> improve the document quality IMHO.  John, would this be an
> acceptable addition to the document?


I've responded to Brian off-list and continue in my
determination to not engage in a debate about the appeal itself:
under the procedures as I read them and as they have been
applied in the past, the IESG will decide however it decides.
However, unless they make it one by composing a statement or
appeal response and issuing a Last Call on it (I believe they
have the right to do that, but certainly not any obligation, and
it would be unprecedented), the appeal itself is neither a
community popularity contest nor a consensus call.  Remember
that 2026 does not even require that appeals be made public when
they are submitted.

Without endorsing them (the authors speak for themselves and
have written clearly), you might want to re-read any of several
recent notes and the appeal text: the core issue that motivated
the appeal was not whether or not these examples were to be

Changing the examples (or not) has _never_ been the core
question.  If it were, I would have included a discussion of
compromise positions and counter-suggestions that had already
been offered.  Even with such a discussion, the appeal text
would have been much shorter. The core issue has to do with how
the IESG manages document reviews, whether the community likes
late surprises that could easily be avoided, how rules are
formulated and applied in the IETF, how AD judgments relate to
consensus in the IETF Community or applicable subgroups, and so

As to Brian's suggestion, please consider the following, derived
from RFC3501 and hypothesize that, at some point, an RFC 2606bis
might be created (and go through the consensus process to BCP)
that offers special reserved names for newsgroups or mailing
lists as well as domain names (many of the arguments offered for
using only reserved domain names, including "rude to the
owners", would probably apply to newsgroups and other sorts of
network entities as well) and that included a form of Brian's
suggestion as normative.

RFC3501 now includes:

>    Example:    C: A002 LSUB "#news." "comp.mail.*"
>                S: * LSUB () "." #news.comp.mail.mime
>                S: * LSUB () "." #news.comp.mail.misc
>                S: A002 OK LSUB completed

Now, suppose, per Brian's suggestion, that were changed to 

   Example:    C: A002 LSUB "#news." "comp.mail.*" *
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed

   Example:    C: A002 LSUB "#news." "comp.mail.*" [Foobar]
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed

   Example:    C: A002 LSUB "#news." "comp.mail.*"   [1]
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed

any of which would be consistent with what I interpret as the
spirit of Brian's suggestion, with the "*", "[Foobar]", or "[1]"
being anchors for a reference or footnote.

Now _that_, folks, is confusing, since a reasonable reader might
have trouble figuring out whether the footnote/reference anchor
was part of the IMAP syntax and example or not.   It would be so
confusing that I'd argue that it involved a substantive issue,
rather than an editorial/stylistic one as Brian Carpenter
suggests sometimes occurs.  I'd expect people to notice it
during Last Call and complain, and I'd think an AD would be
entirely justified in asking hard questions and forcing

Whether the examples in 2821bis are like that case simply
because they fail to use 2606 names is something that you should
judge for yourselves.  But, because of possibilities that the
examples above illustrate, be careful what you wish for.


IETF mailing list