Re: [v6tc] v6tc - is there life

Alain Durand <Alain.Durand@Sun.COM> Thu, 18 November 2004 19:56 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27391; Thu, 18 Nov 2004 14:56:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsQl-0001rf-1l; Thu, 18 Nov 2004 14:58:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsHp-00089v-NW; Thu, 18 Nov 2004 14:49:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsBQ-0006qJ-ID for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 14:43:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25602 for <v6tc@ietf.org>; Thu, 18 Nov 2004 14:43:06 -0500 (EST)
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsE5-0001X8-P7 for v6tc@ietf.org; Thu, 18 Nov 2004 14:45:55 -0500
Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAIJh6Vu015039 for <v6tc@ietf.org>; Thu, 18 Nov 2004 12:43:06 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7E00EAV43TJN@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 18 Nov 2004 12:43:06 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7E00EKD43QVV@mail.sun.net> for v6tc@ietf.org; Thu, 18 Nov 2004 12:43:05 -0700 (MST)
Date: Thu, 18 Nov 2004 11:42:59 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: [v6tc] v6tc - is there life
In-reply-to: <1100805436.4434.96.camel@essrv103nok15564.ntc.nokia.com>
To: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
Message-id: <0D192C02-399A-11D9-B9DD-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> <Pine.LNX.4.61.0411162232140.23785@netcore.fi> <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> <E0EA934C-38BF-11D9-9D63-00039376A6AA@sun.com> <1100805436.4434.96.camel@essrv103nok15564.ntc.nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7BIT
Cc: v6tc@ietf.org
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7BIT

On Nov 18, 2004, at 11:17 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> Anyways, I think somebody said that in requirements work it's
> (generally) better to look at the intersection of the requirements and
> not the union of the requirements. This may somewhat apply here as 
> well.

Agree.

>>
>>> Then we just do a quick analysis on the mailing list of the protocols
>>> vs. the requirements and choose the one that seems to be the best fit
>>> as
>>> a *baseline* document.
>>
>> There is no such thing as a "quick analysis on the mailing list", you
>> know that.
>
> Alain, maybe I stated too strongly my wish to do the analysis 
> relatively
> quickly and painlessly. I don't want to start another two year project
> of scenarios and analysis.

Agree 100%. I'm talking about a few months to understand the spectrum 
of solution better.
Let me briefly show some of the trade-off to analyze, and I really do 
not want
to start a thread now on each of them, but just show that those will be 
issues to address
in the very near future.
	- Could we live with UDP encapsulation always on?
	- Do we need mutual authentication? How strong should this be?
	  Should some of this authentication mechanism "follow-on" atfer the 
tunnel set-up phase
	  as finished?
	- Should we embed some kind of signaling in the tunnel?

	- Alain.


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