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

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

So that there is no misunderstanding...

I don't think having a new ICMP message is necessary. That's what I meant by the
"one protocol" statement in RFC 1958. If there is a protocol, such as FMIP
PrxyRtAdv/SolPrxyRtAdv, that performs a particular function, then don't invent
another one. For learning-based information distribution, SolRtAdv would work as
well.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[e-mail]>
To: "James Kempf" <[e-mail]>; <[e-mail]>
Sent: Monday, March 24, 2003 12:34 PM
Subject: 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" <[e-mail]>
> To: "Eunsoo Shim" <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> > To: "James Kempf" <[e-mail]>; <[e-mail]>
> > 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" <[e-mail]>
> > > > To: "James Kempf" <[e-mail]>; <[e-mail]>
> > > > 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
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

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