Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

David Borman <> Fri, 19 September 2008 20:00 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 852D63A68F1; Fri, 19 Sep 2008 13:00:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCBD93A68F1 for <>; Fri, 19 Sep 2008 13:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pTgF7CvzWMl9 for <>; Fri, 19 Sep 2008 13:00:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 20F993A685F for <>; Fri, 19 Sep 2008 13:00:52 -0700 (PDT)
Received: from (ala-mail03 []) by (8.13.6/8.13.6) with ESMTP id m8JK16tk026877; Fri, 19 Sep 2008 13:01:06 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Sep 2008 13:01:05 -0700
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Sep 2008 13:01:05 -0700
Message-Id: <>
From: David Borman <>
To: Joe Touch <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 19 Sep 2008 15:01:03 -0500
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 19 Sep 2008 20:01:06.0303 (UTC) FILETIME=[738E68F0:01C91A92]
Cc:,,, "Anantha Ramaiah (ananth)" <>, Ted Faber <>
Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Sep 19, 2008, at 2:04 PM, Joe Touch wrote:

>> But even if you do view it as a hierarchy, it is nothing out of the
>> ordinary.  No optional standard is going to be a MUST for who needs  
>> to
>> implement it, but then the rest of the standard itself will have  
>> still
>> have MUSTs in it for how to do the implementation.
> This is the part that others have commented to me on, and the primary
> point of my note. If we can point to an optional standard that has  
> therein, fine. If not, we're blazing new ground.

That's easy, just look at any optional standards track RFC.  Here are  
a few recent RFCs that I just picked at random:

RFC 5001 "DNS Name Server Identifier (NSID) Option"
RFC 5007 "DHCPv6 Leasequery"
RFC 5010 "The Dynamic Host Configuration Protocol Version 4 (DHCPv4)  
Relay Agent Flags Suboption"
RFC 5044 "Marker PDU Aligned Framing for TCP Specification"

None of these are mandatory, so at best they would be SHOULD for the  
overall document, and yet they all have MUSTs in them.  Need I go on?   
The only difference I can see is that these standards don't have  
explicit SHOULD/MAY in their applicability sections.

>> The only thing that
>> might be unique here is that the applicability statement has an  
>> explicit
>> SHOULD/MAY in it; they could be changed to should/may and I don't  
>> think
>> anything would be lost, but I also think it is fine as it is.
> It would definitely be lost; the doc would then have only MUSTs for
> certain items, which are not MUSTs if the overall document is a  
> This is the punchline; i.e., if we feel that we can't make document- 
> wide
> recommendations at different levels than individual items, then the
> document-wide concern needs to be reflected in the level of individual
> items, and then I would claim that the current MUSTs should be  
> converted
> to SHOULDs. (I don't see other impacts).

Again, the SHOULD/MAY in the applicability section is about who can  
benefit from tcpsecure, and has nothing to do with how to implement  
tcpsecure.  The other MUST/SHOULD/MAYs in tcpsecure are about how to  
implement tcpsecure.

It's "you SHOULD/MAY implement this, but if you do, you MUST do it  
this way".  That's just normal standards stuff.

			-David Borman

tcpm mailing list