Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5

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

The following are proposals for Section 5.5. 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: Replace Section 5.5 with the following text:

    5.5 Context Update and Synchronization

    5.5.1 The base context transfer protocol SHOULD NOT provide direct support
              for synchronization with outside events, since synchronization is
              not a requirement for all or even most feature contexts.

    5.5.2 The base context transfer protocol MUST allow individual feature
             context specifications to define their own synchronization with
             external events.

    5.5.3 The base context transfer protocol SHOULD NOT provide support for
             updating context after it is transfered, since individual feature
             contexts will differ in their need for update.

    5.5.4 The base context transfer protocol MUST allow individual feature
             context specifications to define their own update procedures if
             required.

        Most feature contexts will not require synchronization, however
        there are a few that may. Header compression, for example, may require
        that the header compressor on the old access router cease and the
        compressor on the new router start in synchrony with hand over of
        routing to the new router; otherwise, the compressor on the new router
        will not be properly synchronized. Since most contexts don't need
        synchronization support, the general CT solution need not support it,
        but it should not provide a hinderance to those feature contexts
        that do.

       Feature contexts will differ in whether or not they require update.
       A feature context such as QoS parameters for the service level
       agreement with a user may not involve dynamically changing information,
       but it may change during or after context transfer. Such feature contexts
       may benefit from allowing the context to change after the transfer is
       completed. Other feature contexts, such as header compression, may be
       tightly synchronized with external events and changes on the old router
       need to be discarded since the new router's state may already have been
       modified.

----------

Proposal 2: Replace Section 5.5 with the following text:

    5.5 Context Update and Synchronization

    5.5.1 The base context transfer protocol MUST NOT provide direct support
              for synchronization with outside events, since synchronization is
              not a requirement for all or even most feature contexts.

    5.5.2 The base context transfer protocol MUST NOT provide support for
             updating context after it is transfered, since individual feature
             contexts will differ in their need for update.

             Since the base context transfer protocol must accommodate a wide
             range of potential feature contexts, the base protocol design must
             not contain any specification concerning update and
             synchronization.

---------------

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Aug 2002 10:17:36 -0500

Agree with 1,
Disagree with 2,

Regards,

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, August 12, 2002 6:22 PM
To: [email-masked]
Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5

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

----------

    5.5.1 The base context transfer protocol SHOULD NOT provide direct
support
              for synchronization with outside events, since synchronization
is
              not a requirement for all or even most feature contexts.

    5.5.3 The base context transfer protocol SHOULD NOT provide support for
             updating context after it is transfered, since individual
feature
             contexts will differ in their need for update.

        Most feature contexts will not require synchronization, however
        there are a few that may. Header compression, for example, may
require
        that the header compressor on the old access router cease and the
        compressor on the new router start in synchrony with hand over of
        routing to the new router; otherwise, the compressor on the new
router
        will not be properly synchronized. Since most contexts don't need
        synchronization support, the general CT solution need not support
it,
        but it should not provide a hinderance to those feature contexts
        that do.

       Feature contexts will differ in whether or not they require update.
       A feature context such as QoS parameters for the service level
       agreement with a user may not involve dynamically changing
information,
       but it may change during or after context transfer. Such feature
contexts
       may benefit from allowing the context to change after the transfer is
       completed. Other feature contexts, such as header compression, may be
       tightly synchronized with external events and changes on the old
router
       need to be discarded since the new router's state may already have
been
       modified.

----------

    5.5.1 The base context transfer protocol MUST NOT provide direct support
              for synchronization with outside events, since synchronization
is
              not a requirement for all or even most feature contexts.

    5.5.2 The base context transfer protocol MUST NOT provide support for
             updating context after it is transfered, since individual
feature
             contexts will differ in their need for update.

             Since the base context transfer protocol must accommodate a
wide
             range of potential feature contexts, the base protocol design
must
             not contain any specification concerning update and
             synchronization.

---------------

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Aug 2002 10:17:36 -0500

Agree with 1,
Disagree with 2,

Regards,

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, August 12, 2002 6:22 PM
To: [email-masked]
Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5

----------

----------

---------------

---

From: "Hamid Syed" <[email-masked]>
Date: Tue, 13 Aug 2002 16:10:32 -0400

Agree with proposal 1, Disagree with 2.

-Hamid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, August 12, 2002 7:22 PM
To: [email-masked]
Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5

----------

----------

---------------

---

From: "Hamid Syed" <[email-masked]>
Date: Tue, 13 Aug 2002 16:10:32 -0400

-Hamid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, August 12, 2002 7:22 PM
To: [email-masked]
Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5

----------

----------

---------------