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

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Aug 2003 10:03:20 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Sun, 23 Mar 2003 06:43:27 +0200

Hi all,

> 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.

I agree.

John

---

From: [email-masked]
Date: Sun, 23 Mar 2003 06:43:27 +0200

Hi all,

I agree.

John

---

From: [email-masked]
Date: Sun, 23 Mar 2003 06:52:54 +0200

James,

> 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.

I thought that consensus was to define the CT protocol, but make
it a bit 'frameworky' and provide an appendix with FMIP applicability.
As FMIP is still a moving target, I think this is the best way to go,
especially as others have expressed interest in CTP for other
handoff  / mobility solutions.

John

---

From: [email-masked]
Date: Mon, 24 Mar 2003 15:11:18 +0200

James,

> I think I would like to see a precise definition of "frameworky".

So would I!  I think by calling something 'frameworky' there is an implication
of something a bit fuzzy involved.

That being said, what I would like to do is get the basic protocol
mechanisms (messages, data types, parameters, etc.) defined and
then have an appendix where we map the protocol to certain mobility
signaling protocols, like FMIP.  This would give an opportunity for
others to 'map' the CTP to their particular needs, in future 
documents.

> As for FMIP applicability, putting it in an appendix to illustrate how the
> protocol would apply to FMIP is a good idea.

agreed.

John