Re: [tcpm] exegesis of 'Updates' -- was: ... reviewof draft-ietf-tcpm-tcpsecure[-10]

Joe Touch <touch@ISI.EDU> Tue, 30 September 2008 23:42 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4D328C19E; Tue, 30 Sep 2008 16:42:17 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB0F3A6B31; Tue, 30 Sep 2008 16:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVnCF+PoCEdN; Tue, 30 Sep 2008 16:42:16 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 430DF3A68DA; Tue, 30 Sep 2008 16:42:16 -0700 (PDT)
Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m8UNgB17003712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Sep 2008 16:42:13 -0700 (PDT)
Message-ID: <48E2B952.6080109@isi.edu>
Date: Tue, 30 Sep 2008 16:42:10 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <200809302002.WAA09122@TR-Sys.de> <48E2A86E.5050602@isi.edu> <0C53DCFB700D144284A584F54711EC5805DF4D6F@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5805DF4D6F@xmb-sjc-21c.amer.cisco.com>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@tr-sys.de>, tcpm@ietf.org, iesg@iesg.org
Subject: Re: [tcpm] exegesis of 'Updates' -- was: ... reviewof draft-ietf-tcpm-tcpsecure[-10]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Anantha Ramaiah (ananth) wrote:
...
> As a result, we're here considering reasons not to put 
> Updates in the header, to avoid too strongly implying that 
> all TCPs everywhere need to be augmented with an 
> IPR-encumbered poor substitute for true security.
>--- 
> IPR issue was raised when the document was initially presented 3+
> years ago!. Scott Bradner made a presentation to clarify the IPR intent
> and after that this, the IPR issue was never considered as a hindrance
> for the draft to move forward. 

That is proven incorrect by your next sentence.

> Agreed that the IPR issue might have had
> some influence w.r.t the verbiage on the strength of mitigations. Lars
> Eggert suggested an applicability statement to be added, we added the
> same. Not sure why you are bringing this up now, the IPR issue was
> beaten to death long time back.

It is relevant to the issue of Updates, just as it was during the
MUST/SHOULD/MAY discussions.

> Again, my current understanding (which is inline with Alfred) is
> about "if a draft changes the TCP RFC 793 rules in some way, then it
> is considered as an update and we should mark it accordingly upfront
> for easy reference purposes" Also, update doesn't mean that "all
> TCP's everywhere need to be augumented with the changes". An
> implementer would read the mitigations, AS and the strength of
> recommended mitigations and would make his/her own choice!

Others have shown cases where modifications with more ubiquitous utility
do not carry the Updates tag. There is no evidence this mod is more
deserving of that tag.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjiuVIACgkQE5f5cImnZrtfDgCfX5bTX25wVirTbOC34+pVjrfm
djgAoIXI3OFh2rmsgDJgVMEDcYpH4rXB
=isFm
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm