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

Lars Eggert <lars.eggert@nokia.com> Thu, 31 January 2008 15:15 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 1JKb8w-0006j1-Uw; Thu, 31 Jan 2008 10:15:58 -0500
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1JKb8v-0006iC-4c for tsvwg-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 10:15:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb8u-0006i3-Pf for tsvwg@ietf.org; Thu, 31 Jan 2008 10:15:56 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKb8u-00067q-9R for tsvwg@ietf.org; Thu, 31 Jan 2008 10:15:56 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0VFEpA7015564; Thu, 31 Jan 2008 17:15:15 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 17:14:51 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 17:14:50 +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:14:50 +0200
Message-Id: <CBE2B8DB-E26C-46B1-9928-BE001F97BACA@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Francois Le Faucheur IMAP <flefauch@cisco.com>
In-Reply-To: <32462932-4901-4426-92CA-EA11DC37350C@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:14:48 +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> <668A8CDF-038D-490A-93A2-B5B71B186ADC@cisco.com> <EA366CF1-8D57-4DAC-8743-E9870F1E71F1@nokia.com> <D110EE81-74ED-407A-A781-E7A08C80EB51@cisco.com> <C5FC511D-BC4A-42F0-BFB1-7230CAC79B6A@nokia.com> <32462932-4901-4426-92CA-EA11DC37350C@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 31 Jan 2008 15:14:50.0949 (UTC) FILETIME=[06695F50:01C8641C]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
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-30, at 20:32, ext Francois Le Faucheur IMAP wrote:
> It is not that you are saying that TSVWG should not influence MSEC,  
> but rather you are pointing out that as per IETF procedures,  
> publishing an Informational Track document (even as WG document)  
> does not have the official weight to influence MSEC (and therefore  
> should not be understood/expected to do so).
> Is this right?

Yes. An informational RFC that surveys the solution space does just  
that.

If it comes with a TSVWG consensus behind it, it establishes that  
TSVWG is of the opinion that the characterization of the solution  
space in the RFC is correct (rather than just representing the  
authors' opinion, as an individual submission with the RFC Editor  
would.)

MSEC or some other WG is free to refer to that RFC to help them decide  
which option in the solution space is most applicable to their  
particular use case, of course. But an Informational RFC can't  
recommend one solution as the TSVWG-preferred approach, especially if  
that approach isn't an Internet standard.

Lars