Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis Tue, 17 June 2008 12:26 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id C736528C176; Tue, 17 Jun 2008 05:26:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9394A28C0FC for <>; Tue, 17 Jun 2008 05:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VtPmiMI96Kae for <>; Tue, 17 Jun 2008 05:26:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5DE3928C0DE for <>; Tue, 17 Jun 2008 05:25:59 -0700 (PDT)
Received: from ( []) by (8.13.7 TEAMON/8.13.7) with ESMTP id m5HCQh6l009143 for <>; Tue, 17 Jun 2008 12:26:43 GMT
Received: from (localhost.localdomain []) by (8.13.4 TEAMON/8.13.4) with ESMTP id m5HCQc8l022468 for <>; Tue, 17 Jun 2008 12:26:38 GMT
X-rim-org-msg-ref-id: 1638512914
Message-ID: <>
X-Priority: Normal
References: <><> <p06250116c47c330c7dd0@[]><> <g36r20$bgq$><><>
In-Reply-To: <>
Sensitivity: Normal
Importance: Normal
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Date: Tue, 17 Jun 2008 12:26:30 +0000
MIME-Version: 1.0
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

Sounds like a lot of work to me. In the era of xml2rfc, that could be error-prone as well. For the particular issue, having a notice in the Conventions section might do (it may be there already...). However, it doesn't address the fundamental issue raised by the appeal. 

I don't think the IETF wants to go the path of U.N.-sponsored treaty organization SDO's [if you have no clue what I am referring to, just ask Tom Taylor or Rich Shockey who would love to earn beers for telling about their experiences].  The goal is not just to negotiate a "settlement", but to fix the problem. We are engineers, after alll. 

Moreover, I do not think the "problem" is an individual, where the fix is "fixing" the individual. I would encourage everyone to re-read John's original post. The fundamental problem of not knowing what is critical and what isn't needs to be made clear, and via the IETF's accepted processes.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Simon Josefsson <>

Date: Tue, 17 Jun 2008 11:30:05 
To:Brian Dickson <>
Cc:Frank Ellermann <>om>,
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

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?

IETF mailing list
IETF mailing list