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

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

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