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

Pete Resnick <> Mon, 23 June 2008 20:39 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 98AA83A688D; Mon, 23 Jun 2008 13:39:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A2D43A688D; Mon, 23 Jun 2008 13:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.3
X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G+HNcSA6T7R4; Mon, 23 Jun 2008 13:39:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D03E3A688B; Mon, 23 Jun 2008 13:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1214253564; x=1245789564; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=Mime-Version:=201.0|X-Sender:=20presnick@smtphost.qualco|Message-Id:=20<p06250101c485b665147 9@[]>|In-Reply-To:=20<20080619024147.9146C3>|References:=20<8832006D4D21836CBE6D>=0D=0A=20<485590E2.>=09<p06250116c47c330c7dd0@[ 42]>=0D=0A=20<>=0D=0A=20<C122F9 1B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM>=0D=0A=20<200806>|User-Agent:=20Eudora =206.2.5b1(Macintosh)|Date:=20Mon,=2023=20Jun=202008=2015 :39:24=20-0500|To:=20Russ=20Housley=20<housley@vigilsec.c om>|From:=20Pete=20Resnick=20<> |Subject:=20Re:=20Appeal=20against=20IESG=20blocking=20DI SCUSS=20on=0D=0A=20draft-klensin-rfc2821bis|Cc:=20bob.hin,, |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=20 =3B=20format=3D"flowed"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5200,2160,5323"=3B=20a=3D"3983789"; bh=30vMi2R8FO0MjBkNyDVzE10hM8Wj5Bl/x8qH8Po9eiw=; b=aSJTmmod2kFepUdsaPRvzLYochjps2HlP56jKfGGYrJ9ef4jRt7YcPza ml6S9AxWgyH713cJdsXTNQT7IQJnuWZ/SfK2q9eYVlcfpDKu9QRZP8Y6I LKyrMJkt9oa2dqxzlt6Hdgo3+PsT7gXpRn/xIyLeyJ8VvIRkVklUVjP5P 0=;
X-IronPort-AV: E=McAfee;i="5200,2160,5323"; a="3983789"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2008 13:39:24 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m5NKdOVS021805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Jun 2008 13:39:24 -0700
Received: from [] ( [] (may be forged)) by (8.14.2/8.14.2/1.0) with ESMTP id m5NKdM87010132; Mon, 23 Jun 2008 13:39:23 -0700
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p06250101c485b6651479@[]>
In-Reply-To: <>
References: <> <> <p06250116c47c330c7dd0@[]> <> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <>
User-Agent: Eudora 6.2.5b1(Macintosh)
Date: Mon, 23 Jun 2008 15:39:24 -0500
To: Russ Housley <>
From: Pete Resnick <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

On 6/18/08 at 10:35 PM -0400, Russ Housley wrote:

>The I-D Checklist (IDnits,, 
>Section 6, says:
>     Addresses used in examples SHOULD preferably use
>     fully qualified domain names instead of literal IP
>     addresses, and preferably use example fqdn's such as
> instead of real-world fqdn's.
>RFC 2119 has a pretty clear definition of "SHOULD".  It says:
>     This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.

Ahem. RFC 2119 is also pretty clear about two other things:

    In many standards track documents several words are used to signify
    the requirements in the specification.  These words are often
    capitalized.  This document defines these words as they should be
    interpreted in IETF documents.

I-D Nits ain't no "standards track document", and it barely qualifies 
as an "IETF document". It's certainly not an IETF consensus document.

But also:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for

Indeed, the real potential for causing harm or failure to 
interoperate in the case of 2821bis would be to change all of the 
examples to "", inadvertently screw it up in some 
interesting way, and cause people to implement incorrectly. In the 
case of a document where almost all of the examples have been left 
alone, and those examples have been in use for 7 years without 
problems, the burden of proof is on you to demonstrate harm if you 
want to put a DISCUSS on the document. If you want to put a COMMENT 
on the document, it is incumbent on the document editors to review 
the decision of 7 years ago and have them explain why that path was 
chosen. But unless there is *demonstrable* harm at this point in the 
life cycle of the document, it's an editorial issue that does not 
warrant a DISCUSS.

(To wit: Wouldn't it have been amusing if John had changed all of the 
examples to fit 2606 names and some AD came along and said, "DISCUSS: 
This document is heading for Draft Standard after 7 years of 
deployment. Even though I can't see an overt problem in the examples 
now used, changing them from perfectly good examples that have 
interoperated for 7 years without problem has the potential for harm. 
Please change them back to their original forms." I'd be far less in 
favor of an appeal against *that* DISCUSS.)

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
IETF mailing list