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

"James Kempf" <kempf@docomolabs-usa.com> Mon, 24 March 2003 17:23 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069 for <seamoby-archive@odin.ietf.org>; Mon, 24 Mar 2003 12:23:49 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OHhiS18574 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 12:43:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHhiO18571 for <seamoby-web-archive@optimus.ietf.org>; Mon, 24 Mar 2003 12:43:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26055 for <seamoby-web-archive@ietf.org>; Mon, 24 Mar 2003 12:23:17 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHg2O18477; Mon, 24 Mar 2003 12:42:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHemO18404 for <seamoby@optimus.ietf.org>; Mon, 24 Mar 2003 12:40:48 -0500
Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25952 for <seamoby@ietf.org>; Mon, 24 Mar 2003 12:20:22 -0500 (EST)
Message-ID: <003901c36a5b$ba176750$036015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Eunsoo Shim <eunsoo@nec-labs.com>, seamoby@ietf.org
References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo>
Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work
Date: Sun, 24 Aug 2003 09:21:08 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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