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

Joe Touch <touch@ISI.EDU> Fri, 19 September 2008 20:26 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 167293A687D; Fri, 19 Sep 2008 13:26:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A48F83A685A for <>; Fri, 19 Sep 2008 13:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U5y27qZZ4bkM for <>; Fri, 19 Sep 2008 13:26:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BAEFA3A67D8 for <>; Fri, 19 Sep 2008 13:26:48 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8JKQGX8009004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Sep 2008 13:26:17 -0700 (PDT)
Message-ID: <>
Date: Fri, 19 Sep 2008 13:28:17 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: David Borman <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,,, "Anantha Ramaiah (ananth)" <>, Ted Faber <faber@ISI.EDU>
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

Hash: SHA1

Hi, David,

If we have docs we can point to, we're fine. I had questions from others
on this point; if we have precedent, we're set.


David Borman wrote:
> 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 MUSTs
>> 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 SHOULD.
>> 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
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list