Re: [Seamoby] Minutes for Meeting at IETF 53

Behcet Sarikaya <behcet.sarikaya@alcatel.com> Thu, 18 April 2002 16:43 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 MAA14108 for <seamoby-archive@odin.ietf.org>; Thu, 18 Apr 2002 12:43:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14095; Thu, 18 Apr 2002 12:41:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14067 for <seamoby@optimus.ietf.org>; Thu, 18 Apr 2002 12:41:17 -0400 (EDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14030 for <seamoby@ietf.org>; Thu, 18 Apr 2002 12:41:14 -0400 (EDT)
Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IGekV03434 for <seamoby@ietf.org>; Thu, 18 Apr 2002 11:40:46 -0500 (CDT)
Message-ID: <3CBEF725.4070906@alcatel.com>
Date: Thu, 18 Apr 2002 11:41:09 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com> <3CBEEC77.3EDB171@iprg.nokia.com>
Content-Type: multipart/alternative; boundary="------------020200060101070200010202"
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

Hello Charlie,
  Absolutely.
What I was pointing out is looking at the history of Seamoby WG, it is 
keeping to jettison out (as James says) its work items. Maybe Seamoby WG 
is an incubator of new WGs.
So CARD and CT are being incubated and sometime in the future new work 
items are going to come out with  well defined scopes. The discussions 
here could serve this goal and as such they are probably very useful.
  This is how I see it.

Regards,
Charles E. Perkins wrote:

>Hello Behcet,
>
>Behcet Sarikaya wrote:
>
>>Karim et al.,
>>  It seems to me that what Karim is arguing is MIPv4/v6 fast handover
>>drafts do provide a solution to CARD.
>>
>
>That's not what I read, but I'll wait to see what Karim has to say.
>
>>  And he is saying that these are MN centric solutions and bode well
>>with Steve's arguments and the end-to-end arguments in system design
>>first presented by Saltzer, Reed and Clark in as early as 1984.
>>
>
>I heard Steve's presentation.  I asked a question at the microphone
>about whether he believed it precluded network-controlled operation.
>He said it did not, but he wanted to restore mobile nodes to be
>full citizens (paraphrasing, and it's been a few weeks now).
>Subsequent discussion seems to be going to extremes, to the point
>of ignoring obviously reasonable network-constrolled designs for
>which [seamoby] ought to be responsive.
>
>The paper you cite does not preclude such operation.  We can
>view the mobile node as a client which is making use of available
>service.  If the network provides the service, it is free to
>establish parameters by which it provides the service, and if
>it is beneficial to have a mobile node move to another point of
>attachment, I see nothing wrong with notifying the node about
>that, along with a good candidate for an access router.  I don't
>see any reason why the network should be restricted from using
>a CAR discovery protoocol to identify such a candidate.
>
>>  Maybe the question is what business Seamoby has here?
>>
>
>My answer would be that [seamoby] ought to be making protocols
>by which we can expedite smooth handovers.  That's a good piece
>of work, and one for which we can exhibit existence proofs to
>show that it is possible.  I think that so far that there has
>been trouble to get agreement on "general" goals, but that there
>are particular instances where the intended results should be
>obvious.  I believe these particular instances include
>network-controlled and mobile-controlled scenarios.
>
>===================================================================
>
>Somewhere else, it was stated that only the mobile node can
>possibly know all of the CARs.  I would amend this to instead
>say that the mobile node can always know about CARs that are
>not visible to the network.  But, as it turns out, the network
>can always know CARs that are not visible to the mobile node
>also.  So, we have to allow the mobile node to make the choice,
>but we should not prevent the mobile node from following
>network-directives.  Thus, we should develop a model by which
>CAR discovery is allowed to provide input to a network-controlled
>handover scheme, which is nonetheless subject to possible rejection
>by the mobile node.
>
>Regards,
>Charlie P.
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>
--behcet