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

"Anantha Ramaiah \(ananth\)" <ananth@cisco.com> Tue, 25 September 2007 17:30 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEFC-00031x-3K; Tue, 25 Sep 2007 13:30:46 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEFA-0002xV-VR for tcpm@ietf.org; Tue, 25 Sep 2007 13:30:45 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaEFA-0006cL-J0 for tcpm@ietf.org; Tue, 25 Sep 2007 13:30:44 -0400
X-IronPort-AV: E=Sophos;i="4.20,296,1186383600"; d="scan'208";a="401681906"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2007 10:30:44 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8PHUh0g000648; Tue, 25 Sep 2007 10:30:43 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PHUdin027011; Tue, 25 Sep 2007 17:30:39 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 10:30:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] tcpsecure: how strong to recommend?
Date: Tue, 25 Sep 2007 10:30:31 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5804051BC4@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <299A2E1C-3704-4F76-B8A3-A3A2C98BA28E@windriver.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcpsecure: how strong to recommend?
Thread-Index: Acf/c7HLhgfFOADJR9ezx8bJmv2JuwAIsArg
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: David Borman <david.borman@windriver.com>, Pekka Savola <pekkas@netcore.fi>
X-OriginalArrivalTime: 25 Sep 2007 17:30:39.0565 (UTC) FILETIME=[CA7D7FD0:01C7FF99]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1637; t=1190741444; x=1191605444; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20<ananth@cisco.com> |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=+/g663aMnVAiy/wOLdzP7aLwAR+u88GYTQ2njhhRQF0=; b=ZR9FMA/Cxoq8MFA3FfF8JnWvhrReTEGCb368wkjHFkJoWQc5QleROMY9zg5HPWgbNnxnEKFW x9DlcR2YsMHaW2u8OKySA7Q3gAXlCIc/56K/xbXJjN7TYbMesi06dTJB;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: tcpm@ietf.org, Fernando Gont <fernando@gont.com.ar>, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Some comments inline... 

> -----Original Message-----
> From: David Borman [mailto:david.borman@windriver.com] 
> Sent: Tuesday, September 25, 2007 5:55 AM
> To: Pekka Savola
> Cc: tcpm@ietf.org; Fernando Gont; mallman@icir.org
> Subject: Re: [tcpm] tcpsecure: how strong to recommend?
> 
> I voted (3) at the meeting.  My vote is with the 
> understanding that the whole tcpsecure document is *not* 
> becoming part of the base TCP specification, but is an 

How does a document become part of the base specification (793 for
eg;-)? Does a document which clarfies some things left/out or corrects
errors like (1122 for eg;-) become part of the base specs?

> optional addition that implementors may choose whether or not 
> to implement.  If they do choose to implement it, then within 
> that context my vote is for two SHOULDs and a MAY.

My understanding is the strength of a proposal is determined by the
language used (SHOULD/MUST/MAY etc.,) and that covers everything
including guiding an implementor to implement the proposal or not. For
eg:- a TCP stack need not implement TCP secure mitigations at all but
MUST implement slow start for example. 

If someone determines (I assume they know what they are doing in most
instances ;-) that proposals recommended in a particular RFC is needed
either in part/full then they would put resources to get that
accomplished in their stack. Isn't the "standard" way ?

Or are you saying "base specfication" is something akin to what the
roadmap document is talking about under the section "basic
functionality"?

Confused,
-Anantha

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm