RE: [Seamoby] CAR Discovery Requirements

"Govind Krishnamurthi" <govs23@hotmail.com> Mon, 14 January 2002 18:31 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 NAA11341 for <seamoby-archive@odin.ietf.org>; Mon, 14 Jan 2002 13:31:06 -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 NAA18306; Mon, 14 Jan 2002 13:12:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18278 for <seamoby@optimus.ietf.org>; Mon, 14 Jan 2002 13:12:42 -0500 (EST)
Received: from hotmail.com (f100.law9.hotmail.com [64.4.9.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10436 for <seamoby@ietf.org>; Mon, 14 Jan 2002 13:12:39 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jan 2002 10:12:11 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 14 Jan 2002 18:12:10 GMT
X-Originating-IP: [63.78.179.4]
From: Govind Krishnamurthi <govs23@hotmail.com>
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 13:12:10 -0500
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
Message-ID: <F1008Ut65BVEpVRqOdt00002202@hotmail.com>
X-OriginalArrivalTime: 14 Jan 2002 18:12:11.0194 (UTC) FILETIME=[FC65E9A0:01C19D26]
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

Hesham,
Where does the current set of requirements preclude any sort of mobile node 
involvement. I think
whether an MN is involved or not is implementation specific.. and
not a requirements issue. I don't think the requirements for CAR discovery 
change whether a MN is involved or not. Also letting the MN or AR decide 
where actually to handover is out of scope of CAR discovery.
Just letting the MN also hear does not complete CAR discovery.. CARs 
comprise of GAARS + their capabilities.. What you say is just GAARs.

-Govind.
> >...
>   > >6. Protocol applicability ? SHOULD (?)
>   > >(show of hands indicated that this item should be changed
>   > to a MUST)
>   > >support inter-domain as well as Intra-domain scope
>   >
>   > Inter-domain discovery of access routers (which seems
>   > implied by what
>   > might otherwise seem an innocuous protocol design feature)
>   > is problematic.
>   >
>   > It would require resolving which users are subscribers of
>   > which domains,
>   > or complex inter-domain roaming and billing reciprocity.
>
>=> This is exactly why I urge you (this wg) to clearly
>explain which protocol you are talking about. AR - AR or
>AR MN ???
>Clearly AR - MN lis an obvious way to discover all routers
>that the MN can hear. Inter/intra domain issues are
>not relevant.
>
>So please make it clear which part of the protocol
>you're referring to. We should not always assume
>that we're discussing the AR - AR case.
>
>   > While it seems reasonable to avoid locking mobile stations
>   > into a single
>   > domain, the policy interactions of requiring
>   > multiple-domain discovery
>   > would make the task much more difficult at the start.
>
>=> Certainly. But there is an easy way of doing that:
>Let the MN decide.
>
>Hesham
>
>   > _______________________________________________
>   > 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




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


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