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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 01 October 2007 16:23 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 1IcO39-0001xu-8V; Mon, 01 Oct 2007 12:23:15 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcO38-0001xp-RC for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 12:23:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcO38-0001xh-Hb for tcpm@ietf.org; Mon, 01 Oct 2007 12:23:14 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcO37-0005D3-Aw for tcpm@ietf.org; Mon, 01 Oct 2007 12:23:14 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 01 Oct 2007 09:23:12 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l91GNCq1007261; Mon, 1 Oct 2007 09:23:12 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l91GN7vd001413; Mon, 1 Oct 2007 16:23:12 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); Mon, 1 Oct 2007 09:23:11 -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: Mon, 1 Oct 2007 09:23:09 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <20071001124730.32E282AB9B1@lawyers.icir.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcpsecure: how strong to recommend?
Thread-Index: AcgEKXDxD4AUrzV6TGqZmv6DX0P4egAFtEfw
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: <mallman@icir.org>
X-OriginalArrivalTime: 01 Oct 2007 16:23:11.0069 (UTC) FILETIME=[5BE088D0:01C80447]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1650; t=1191255792; x=1192119792; c=relaxed/simple; s=sjdkim3002; 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 ?=20 |Sender:=20; bh=+/GJ8XuR5ISJY6v+0ZNdAB4UVVcYTg1EKG6I2Za7wq8=; b=eGgAoNS/ny4FBzHMENLuj1EC9Okacvog2b0An1+7u4pMK687WtwUnwf7MzaZ6StgSlpLDvji OjH3Xgs22x0hISlsUgG81jIQk5HBCwYdL9+h7giGBCm/3eT2JUOZHEdQ;
Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: tcpm@ietf.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

 
> 
> Hyperbole elided, but still trying to understand ...
> 
> > but
> > saying that "SHOULD doesn't give leeway not to do something", is 
> > something which I would want to dis-agree.
> 
> If tcpsecure is a SHOULD then what would be an invalid reason 
> for me to exclude it from my implementation?

It is difficult to say since the implementer is given the choice whether
or not to include/exclude it. Yes, both SHOULD and MAY provides that
luxury. The only difference is the strength of the advise offered by
both these adjectives which needs to be viewed from a recommendation
perspective. If you think that these are generally good to have then use
SHOULD else these are really optional ones use MAY. The bottomline is
that unless it is tagged as MUST, I believe we have already given the
flexibility, the key is how "strong" we would want to recommend and that
is what we are trying to do and get the consensus. Atleast this *my
understanding*. I expressed my opinion and other have expressed theirs. 

Also, I am trying to understand something here since I wasn't sure how
situations like this have been dealt in the past. Actually, I am trying
to understand the algorithm used to arrive consensus here?. I was
assuming that after the "hums were sought" and the email was sent both
offering 3 choices, now after getting the responses the next step would
be to derive something out of that once we have reached enough responses
or a stipulated time expires if one exists. If we believe there isn't
even a rough consensus after the responses so far, what is the next
step? Curious.

-Anantha 


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