IETF Logo Mail Archive

RE: NOT RECOMMENDED (was: Re: [TLS] Last Call:draft-ietf-tls-renegotiation)

"Dan Wing" <dwing@cisco.com> Wed, 02 December 2009 04:04 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA463A67DB for <ietf@core3.amsl.com>; Tue, 1 Dec 2009 20:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.313
X-Spam-Level:
X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opTsgXW+7MAF for <ietf@core3.amsl.com>; Tue, 1 Dec 2009 20:04:46 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CC92C3A67AE for <ietf@ietf.org>; Tue, 1 Dec 2009 20:04:46 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAHZ2FUurRN+K/2dsb2JhbACKN5pmmhOYJIQxBA
X-IronPort-AV: E=Sophos;i="4.47,326,1257120000"; d="scan'208";a="56347280"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2009 04:04:39 +0000
Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB244dMC004985; Wed, 2 Dec 2009 04:04:39 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Peter Saint-Andre' <stpeter@stpeter.im>, mrex@sap.com
References: <200912020249.nB22nvQ0007879@fs4113.wdf.sap.corp> <4B15D988.5030209@stpeter.im>
Subject: RE: NOT RECOMMENDED (was: Re: [TLS] Last Call:draft-ietf-tls-renegotiation)
Date: Tue, 01 Dec 2009 20:04:39 -0800
Message-ID: <003501ca7304$91afa030$c3f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <4B15D988.5030209@stpeter.im>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-index: Acpy/Hcp7LRoyJnDR0i6i2+fssB3CQAB94QA
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2009 04:04:47 -0000

 

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of Peter Saint-Andre
> Sent: Tuesday, December 01, 2009 7:06 PM
> To: mrex@sap.com
> Cc: ietf@ietf.org
> Subject: NOT RECOMMENDED (was: Re: [TLS] Last 
> Call:draft-ietf-tls-renegotiation)
> 
> On 12/1/09 7:49 PM, Martin Rex wrote:
> > Stephen Farrell wrote:
> >> 7. 6.2 says: "If servers wish to <<avoid attack>> they MUST
> >> NOT <<do stuff>>" Isn't that equivalent to servers SHOULD
> >> NOT? I think a SHOULD NOT is better. (And that's the form
> >> used in section 7.)
> > 
> > 
> > This might be confusion with ISO terminology.
> > 
> >    MUST       ==  SHALL
> >    MUST NOT   ==  SHALL NOT
> >    SHOULD     ==  RECOMMENDED
> >    SHOULD NOT ==  NOT RECOMMENDED
> > 
> > 
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
> "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in this
> >    document are to be interpreted as described in RFC 2119 
> [RFC2119].
> 
> It's always puzzled me why the boilerplate quoted above does 
> not include
> the phrase "NOT RECOMMENDED", given that RFC 2119 mentions it a mere
> five paragraphs later:
> 
>    4. SHOULD NOT  This phrase, or the phrase "NOT 
> RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
> 
> Is this a spec bug in RFC 2119?

Probably.

According to
http://www.rfc-editor.org/errata_search.php?rfc=2119
it was reported as Errata ID 499 by Anders Langmyr on 2006-01-09.

-d


> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
>

v2.46.0 | Report a Bug | By Email | System Status