Re: [tcpm] tcpsecure: how strong to recommend?

Joe Touch <touch@ISI.EDU> Mon, 01 October 2007 23:14 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IcUSx-0000oV-Bv; Mon, 01 Oct 2007 19:14:19 -0400
Received: from tcpm by with local (Exim 4.43) id 1IcUSw-0000j4-7q for; Mon, 01 Oct 2007 19:14:18 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IcUSv-0000f4-TG for; Mon, 01 Oct 2007 19:14:17 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IcUSr-0008Kv-Ey for; Mon, 01 Oct 2007 19:14:13 -0400
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id l91NDjx4025456; Mon, 1 Oct 2007 16:13:45 -0700 (PDT)
Message-ID: <>
Date: Mon, 01 Oct 2007 16:13:42 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: "Mitesh Dalal (mdalal)" <>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.3
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: "Edward A. Gardner" <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0522330498=="

Mitesh Dalal (mdalal) wrote:
> well said Edward! I concur with your take on this and was alluding to
> the same ideas that you mentioned below. To highlight your comment
> again:
>> In particular 
>> there is confusion between discussing whether implementing 
>> tcpsecure itself is mandatory / recommended / optional vs. 
>> whether some feature of tcpsecure is mandatory / recommended 
>> / optional, given that tcpsecure itself is implemented.
> I think it does captures the debate we are having here. My
> opinion is that if we view these changes as Updates to RFC793, then
> they may be perceived as mandatory changes and again open discussions
> around IPR, MAY/SHOULD/MUST language and so on. However if we have
> a  banner statement stating that implementing these changes are
> recommended/optional and enumerate situations in which they are 
> helpful this should alleviate a lot of opposing view.  And
> once we have this statement and if a tcp implementation does decide
> to have this feature then it MUST be this way for the feature to work
> correctly.\

I think we agree that there are two levels of language needed:

1) for the entire system
	for which I think MAY is appropriate,
	and the conditions when useful would be beneficial to note

2) for the components, once you decide to implement
	MUST/MAY/SHOULDs as needed there. there seem like there are
	a few MAYs for various parts, MUSTs for others;
	it's not all MUSTs, but I don't think there will be
	deep discussions about this


tcpm mailing list