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

James,

Right.The design team proposed that the specification allows two options:
piggybacking as ICMP options and stand-alone messages.
I think this is a good approach that can satisfy many things.

Eunsoo

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>; <seamoby@ietf.org>
Sent: Sunday, August 24, 2003 8:21 AM
Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

> Defining the CARD messages as generalized ICMP options for RFC 2461 and
> associated extentions is acceptable. I presume this is what you mean by
> "piggybacking".
>
>             jak
>
> ----- Original Message -----
> From: "Eunsoo Shim" <eunsoo@nec-labs.com>
> To: "James Kempf" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Sunday, March 23, 2003 8:37 AM
> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby
Work
>
>
> > It was agreed to make the CARD messages piggyback-able in the past.
> > Then the CARD messages could be transported even on top of other
messages
> > than FMIP messages.
> > Also we don't have to worry about how FMIP will turn out in the future.
Or
> > the FMIP designers don't have to worry about the semantics change
required
> > by the CARD protocol.
> > Piggybacking wouldn't be better than tight-coupling with FMIP?
> >
> > Eunsoo
> >
> > > Extending the semantics is the proposal. Or, alternatively, delivering
the
> > > learning-based information via a RS.
> > >
> > > If it turns out not to be a good match, then an additional message
could
> > be
> > > added for the learning based approach.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Eunsoo Shim" <eunsoo@nec-labs.com>
> > > To: "James Kempf" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> > > Sent: Saturday, March 22, 2003 1:13 PM
> > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby
> > Work
> > >
> > >
> > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR
information
> > > > after discovery.
> > > > In Dycard, the discovery requires messages between MN and AR for
> > delivering
> > > > the IP address of the previous AR to the current AR. This is beyond
the
> > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages.
> > > > I wonder whether the proposal is to extend the semantics of FMIP
> > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages
between
> > AR
> > > > and MN for CARD.
> > > >
> > > > Eunsoo
> > > >
> > > >
> > > > > 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
> > > > > Seamoby@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby