Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2

From: "James Kempf" <[email-masked]>
Date: Mon, 12 Aug 2002 16:21:54 -0700

The following are proposals for Section 5.2. Please indicate which proposal you
AGREE with (if any), and which proposals you DISAGREE with. Please *only*
indicate AGREE with only one proposal.

-----------
Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the
requirements.
-----------

-----------
Proposal 2: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified so that it is
               independent of the underlying transport.

            Recognizing that the transport characteristics for context transfer
            will depend on the particular application, it should be possible to
            transfer context directly on top of reliable transports, such as TCP
            or SCTP, unreliable transports, such as UDP, or as an option or
            extension on another protocol, such as handover signaling.

-----------

-----------
Proposal 3: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified to utilize a reliable
               transport protocol as a default, unreliable transport MAY also be
               optionally allowed.

               Recognizing that context transfer may be crucial for successful
               handover, the context transfer protocol must specify operation
              on a default reliable transport. The context transfer protocol may
              optionally allow transfer on unreliable transport.

    5.2.2  The context transfer protocol MUST run directly on top of a transport
              protocol. Context transfer within another application layer
              protocol MUST NOT be allowed.

              In order to preserve the unity of context transport across all
              feature applications, context transfer must run directly on top of
             a transport protocol. Running context transfer as an option on
             another application layer protocol is prohibited.
-----------

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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 19:27:09 -0700

Hello Jim,

I agree with Proposal 2.   But I am also very favorable towards
Proposal 1, which by the rules I cannot "also" agree with.
In any case, I disagree with Proposal 3.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 19:27:09 -0700

Hello Jim,

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Aug 2002 09:07:01 -0500

FYI, 802.11f defines the context transfer among APs over wired network 
using TCP.
It should also be noted that this spec is still a draft.
If there are compelling reasons for lifting the reliability at the 
expense of speed and flexibility, I would also go for it.

Regards

-- 
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Aug 2002 09:07:01 -0500

Regards

-- 
Behcet

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 13 Aug 2002 11:35:48 -0700

Agree with proposal 2
Disagree with 3.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 13 Aug 2002 11:35:48 -0700

Agree with proposal 2
Disagree with 3.

-Rajeev