RE: [Seamoby] CAR Discovery Requirements

"Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com> Fri, 11 January 2002 15:51 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 KAA18670 for <seamoby-archive@odin.ietf.org>; Fri, 11 Jan 2002 10:51:08 -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 KAA03095; Fri, 11 Jan 2002 10:35:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03067 for <seamoby@optimus.ietf.org>; Fri, 11 Jan 2002 10:35:14 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18095 for <seamoby@ietf.org>; Fri, 11 Jan 2002 10:35:11 -0500 (EST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0BFagQ02982 for <seamoby@ietf.org>; Fri, 11 Jan 2002 09:36:42 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58614f5eb9ac12f2570d5@davir04nok.americas.nokia.com>; Fri, 11 Jan 2002 09:35:13 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Jan 2002 09:35:13 -0600
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 11 Jan 2002 10:35:12 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB01246008D55A@bsebe001.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGanFLk1ChfKgaMEdapbwBQi2kYTQAF3gxg
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Hesham Soliman (ERA)'" <hesham.soliman@era.ericsson.se>, ext Phillip Neumiller <PNeumiller@meshnetworks.com>, Govind Krishnamurthi <govs23@hotmail.com>, seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" <Govind.Krishnamurthi@nokia.com>
X-OriginalArrivalTime: 11 Jan 2002 15:35:13.0506 (UTC) FILETIME=[8FC78420:01C19AB5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA03068
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: 8bit

Hi Hesham,

It's not quite clear to me what you propose. Do you want requirement 9,
i.e., the independence from the mobility mgt., to be removed or to be
changed
to a SHOULD requirement?
The said requirement 9 exactly states that the final solution should
be able to be used with ANY mobility mgt. protocol. It does not ignore
that CAR is used in the context of mobility.

My concern regarding Phil's comment was that he mentioned specific
methods to be mandatory in the final solution. I don't think it's a 
good idea to define specific methods as requirements since they
restrict the solution space. That was simply my comment. 

Regards,



Dirk
> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 7:34 AM
> To: Trossen Dirk (NRC/Boston); ext Phillip Neumiller; Govind
> Krishnamurthi; seamoby@ietf.org
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
>   > > 
>   > > 2).  It MUST provide a query (client server) and/or a post 
>   > > (publish and
>   > >      subscribe) method to allow other mobility protocols like 
>   > > those being
>   > >      worked on in the MIP and MANET WGs to cooperate with 
>   > > this protocol.
>   > 
>   > Requirement 9 of the current list already states the 
>   > independence of any
>   > mobility management protocol. Why do you want to enforce specific
>   > methods that have to be provided to ensure (from your 
> point of view)
>   > said independence? 
>   > In conclusion, I think said requirement 9 is sufficient 
>   > since it leave
>   > more freedom for the actual solution.
> 
> => I think it's important to be realistic, there is a 
> difference between designing it _for_ MIP and MANET, 
> and designing it to allow usage _with_ MIP and MANET. 
> The latter is a minimum requirement IMO. Ignoring that
> there are mobility protocols that should be used 
> with the final solution, when the entire problem 
> is mostly relevant to mobile devices, doesn't seem
> realistic to me.
> 
> So I agree with Phil's comment.
> 
> Hesham
>   > 
>   > Regards,
>   > 
>   > 
>   > 
>   > 
>   > Dirk
>   > 
>   > _______________________________________________
>   > Seamoby mailing list
>   > Seamoby@ietf.org
>   > https://www1.ietf.org/mailman/listinfo/seamoby
>   > 
> 

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