Re: [Seamoby] Minutes for Meeting at IETF 53

["James Kempf" <[e-mail]>]

CARD and CT are in the charter and will stay there. There are just the
right number of people and a good technical discussion going. These are
precursors for a successful technical solution in IETF, though success
is at this point by no means guaranteed.

            jak


----- Original Message -----
From: "Behcet Sarikaya" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 18, 2002 9:41 AM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53


> 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
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> --behcet
>


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby