Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

[Jukka MJ Manner <[e-mail]>]

Hi,

your proposal is what I was looking forward to see: a generic architecture 
and protocol and then an example use case with FMIP, for example.

Regards,
Jukka

On Thu, 21 Aug 2003, James Kempf wrote:

> Jukka,
> 
> For CARD, the problem is that if the FMIP prehandover information signaling is
> not specified as the vehicle, CARD must specify a separate protocol that
> performs a substantially identical function. This is in direct violation of RFC
> 1958 Principle 3.2 (and I quote):
> 
>        3.2 If there are several ways of doing the same thing, choose one.
>    If a previous design, in the Internet context or elsewhere, has
>    successfully solved the same problem, choose the same solution unless
>    there is a good technical reason not to.  Duplication of the same
>    protocol functionality should be avoided as far as possible, without
>    of course using this argument to reject improvements.
> 
> Using the FMIP prehandover signaling does not mean that FMIP must be used for
> handover. One could use GPRS or any other protocol for that purpose.
> 
> With respect to CT, its a bit murkier, since the proposal is to directly use the
> FMIP handover signaling (as opposed to the prehandover signaling) as transport
> for the context and for the signaling from the Mobile Node to trigger the
> context transfer.
> One way we could finesse this is to define CT as an extension mechanism, then
> define in an appendix how it would apply to FMIP. This would avoid the problem
> of tying the base design to FMIP, while still ensuring it would work well with
> FMIP.
> 
>             jak
> 
> 
> ----- Original Message -----
> From: "Jukka MJ Manner" <[e-mail]>
> To: "James Kempf" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, March 21, 2003 11:27 AM
> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work
> 
> 
> >
> > Hi,
> >
> > maybe I'm out of line here, but I would really like to see that CARD and
> > CT are not tied directly to (F)MIP. The reason is that there are other
> > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could
> > use SIP to find the initial location of the user (if needed) and then use
> > a local mobility management mechanism to support the mobility within the
> > local domain. You would still need CARD and CT to enable seamless
> > mobility, though.
> >
> > Regards,
> > Jukka
> >
> > On Thu, 21 Aug 2003, James Kempf wrote:
> >
> > > Folks,
> > >
> > > This email is to confirm the concensus at the IETF 56 meeting to proceed
> toward
> > > completing the Seamoby work and closing the Working Group. This email also
> > > advances proposals for a couple of other issues that were not discussed at
> the
> > > meeting but are required to close out Seamoby.
> > >
> > > CARD:
> > >       - Drop draft-ietf-seamoby-card-requirements-02.txt.
> > >       - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather
> than
> > >          Proposed Standard
> > >       - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on
> > >         AR-MN interface. Consult with FMIP draft editor about best way to do
> > > this..
> > >       - Complete protocol on AR-AR interface that will support both learning
> > > based
> > >          and server based approaches.
> > >       - Protocol design complete by IETF 57 in Vienna.
> > >
> > > CT:
> > >
> > >     - Drop draft-ietf-seamoby-ct-reqs-05.txt.
> > >     - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than
> > >        Proposed Standard.
> > >     - Complete protocol design by IETF 57 in Vienna.
> > >
> > > We did not discuss the following issues, here they are with some
> suggestions:
> > > about how to resolve them
> > >
> > >     - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt.
> > >        Since a clear statement of the problem is necessary for formulating
> > >        the research questions, continue to advance this document to
> > >        Informational.
> > >
> > >     - Relationship between CT and FMIP. Since the purpose of
> > >       Seamoby is to support fast handover, focus on a design
> > >       that integrated well with FMIP signaling.
> > >
> > > Discussion?
> > >
> > >             jak
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
> 
> 

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