RE: [Seamoby] Minutes for Meeting at IETF 53

"Glenn Morrow"<gmorrow@nortelnetworks.com> Tue, 23 April 2002 18:45 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 OAA01644 for <seamoby-archive@odin.ietf.org>; Tue, 23 Apr 2002 14:45:24 -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 OAA20646; Tue, 23 Apr 2002 14:24:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20618 for <seamoby@ns.ietf.org>; Tue, 23 Apr 2002 14:24:34 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00455 for <seamoby@ietf.org>; Tue, 23 Apr 2002 14:24:30 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NINiB27543; Tue, 23 Apr 2002 13:23:44 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYXSP>; Tue, 23 Apr 2002 13:23:38 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E034DB901@zrc2c012.us.nortel.com>
From: Glenn Morrow <gmorrow@nortelnetworks.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
Date: Tue, 23 Apr 2002 13:23:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAF3.FC6A4520"
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

Very very well said - let's move on to the analysis and agreement of a
standard from a set of candidate solutions to this problem space, please.

> 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
>