Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?

Lars Eggert <lars.eggert@nokia.com> Thu, 31 January 2008 15:23 UTC

Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbGf-0001Le-LC; Thu, 31 Jan 2008 10:23:57 -0500
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1JKbGe-0001LH-NV for tsvwg-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 10:23:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbGe-0001L4-DY for tsvwg@ietf.org; Thu, 31 Jan 2008 10:23:56 -0500
Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKbGd-00089Q-UP for tsvwg@ietf.org; Thu, 31 Jan 2008 10:23:56 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0VFN44P025847; Thu, 31 Jan 2008 17:23:49 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 17:23:35 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 17:23:35 +0200
Received: from esdhcp035218.research.nokia.com ([172.21.35.218]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 17:23:35 +0200
Message-Id: <7F09B4B4-AE6B-4748-9E23-195BB0565BA9@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Brian Weis <bew@cisco.com>
In-Reply-To: <D2813B59-D4EA-474C-AC31-FF6B86BF8294@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?
Date: Thu, 31 Jan 2008 17:23:33 +0200
References: <47974BDB.70406@ericsson.com> <CD8D57B6-EB94-4DCE-A42A-02BC5F573A13@nokia.com> <7A1BB0E8-5EFB-4341-918A-F841DB1B57FF@cisco.com> <A268781D-F81A-48B3-8042-1892AC93B749@nokia.com> <E603EB77-B600-4A73-9217-EB797A5D7AAB@cisco.com> <E119D886-0838-4323-ABD7-0C8CCAE5C7A3@nokia.com> <D2813B59-D4EA-474C-AC31-FF6B86BF8294@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 31 Jan 2008 15:23:35.0621 (UTC) FILETIME=[3F23F750:01C8641D]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: ext Magnus Westerlund <magnus.westerlund@ericsson.com>, RJ Atkinson <rja@extremenetworks.com>, tsvwg list IETF <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On 2008-1-29, at 19:25, ext Brian Weis wrote:
> I certainly agree that the action of TSVWG accepting draft-behringer- 
> tsvwg-rsvp-security-groupkeying as a WG document can't dictate any  
> particular action to MSEC. But such a TWVWG document describing a  
> group security model for RSVP does provide MSEC with the basis for  
> considering protocol work that increases the overall level of  
> security when group keys are used.

Agreed. MSEC (or any other WG) is free to take the contents of that  
RFC into account when determining which solution options best fit  
their use case.

> On the other hand, rejecting it sends a message to MSEC that the use  
> of group security isn't particularly valuable for RSVP and so there  
> isn't much point in doing addition protocol work to make the group  
> security model more secure.

Drafts fail to see WG adoption all the time, for all sorts of reasons.  
I don't think that if draft-behringer would fail to see TSVWG adoption  
this conclusion could be drawn from that decision.

For example, a perfectly valid reason to not adopt an Informational- 
RFC-to-be would be for the WG to agree that adoption wouldn't improve  
the document much, and that WG cycles would be better spent elsewhere.  
This is approximately what happened with draft-sarolahti-tsvwg- 
crosslayer, which is a survey not too unlike draft-behringer.

Lars