Re: [Seamoby] CAR Discovery Requirements

"Trossen Dirk \(NRC/Boston\)" <dirk.trossen@nokia.com> Wed, 13 March 2002 19:32 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16188 for <seamoby-archive@odin.ietf.org>; Wed, 13 Mar 2002 14:32:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06657; Wed, 13 Mar 2002 14:14:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06627 for <seamoby@ns.ietf.org>; Wed, 13 Mar 2002 14:14:14 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15531 for <seamoby@ietf.org>; Wed, 13 Mar 2002 14:14:10 -0500 (EST)
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DJDW309659 for <seamoby@ietf.org>; Wed, 13 Mar 2002 21:13:32 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T599df33600ac158f25076@esvir05nok.ntc.nokia.com>; Wed, 13 Mar 2002 21:14:11 +0200
Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 21:14:10 +0200
Received: from Beethoven (nokdaa00583.americas.nokia.com [172.18.5.83]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA00622; Wed, 13 Mar 2002 14:10:29 -0500 (EST)
Message-ID: <008701c1cac3$3c336840$6401a8c0@Beethoven>
From: "Trossen Dirk (NRC/Boston)" <dirk.trossen@nokia.com>
To: ext James Kempf <kempf@docomolabs-usa.com>, seamoby@ietf.org
References: <DC504E9C3384054C8506D3E6BB012460382FEB@bsebe001.NOE.Nokia.com> <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Wed, 13 Mar 2002 14:13:56 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 13 Mar 2002 19:14:10.0992 (UTC) FILETIME=[41878B00:01C1CAC3]
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi James,

> And, in fact, this brings up another issue. The current requirements are
> completely lacking *any* mention of security. But I will address that in
> another note so as not to confuse the threads.

They at least mention the secure transfer of capability information.
However,
I'm looking forward to seeing requirements or additions to requirements,
folding in security aspects.


> I have no objection to including this requirement as long as:
>
>     - The language makes clear that the requirement is not to force the
> same protocol to perform CAR discovery and to communicate MN
> preferences.

Agree, sorry for any inappropriate wording that didn't make this clear
enough.
From my perpective, CAR discovery has been seen as a problem that needs
certain
aspects to be addressed. Expressing MN's requirements is one of them to
determine the CARs. A solution for the CAR discovery problem is comprised
of different parts that fulfil as a whole the requirements we're currently
talking about. Parts of
the solution could be defined as a new protocol, for other parts we could
and should
use existing infrastructure. This was implicitly in my mind for ALL
requirements,
e.g., for the transfer of capability information. That's why I didn't put it
specifically
in the one we're currently discussing.
To expedite the process, what would an appropriate wording to make this
clear?
Or would it be more useful to have a general statement in the introduction
of the
requirements, that this is the case for ALL requirements, following the line
of
argumentation I tried to outline in the previous paragraph?

>
>     - The distinction between routing security/AAA requirements for CAR
> discovery and MN security/AAA requirements for MN preferences is
> maintained.

I see this more as security aspects in general. Could you provide
requirement(s)
for this aspect (actually your above sentence is pretty much one, isn't it)?

Regards,



Dirk


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