Subject: [Seamoby] Fw: Results of CT Requirements Concensus Call

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Aug 2002 13:24:17 -0700

I think the IETF lists were down at the beginning of last week, so this never
went out.

            jak

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 20, 2002 12:59 PM
Subject: Results of CT Requirements Concensus Call

> So it looks as if we have rough concensus around the following two issues:
>
> Issue 1 (Section 5.2): Preference is for Proposal 2, namely to say that the
> protocol must support any transport but does not include a specific default.
>
> Issue 2 (Section 5.5): Preference is for Proposal 1, namely to include
language
> specifying requirements on the feature context specifications with regard to
the
> items that the generic CT protocol doesn't support.
>
> The text for these two is included below. Gary, can you please put this text
> into the document?
>
> The comments came back split on Issue 3. Half the people supported Proposal 2,
> to include a separate section with a paragraph stating that feature contexts
> must be standardized but not in requirements language. The other half
supported
> Proposal 3, which establishes specific requirements on feature context
> standardization.
>
> Given that Proposal 1 for Issue 2 already has a few requirements on feature
> context standardization, I'd like to suggest that we go with Proposal 2 for
> Issue 3, a separate section with a few general statements about what feature
> context standards must support, but not specific requirements.
>
> The text for Proposal 2 of Issue 3 is included below.
>
> Comments?
>
>                     jak
>
> --------------------------------------------
> Issue 1:  Concensus text
> --------------------------------------------
>
>    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.
>
> -------------------------------------------
> Issue 2: Concensus 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.
>
> -------------------------------------
> Issue 3: Proposed Compromise Text
> -------------------------------------
>
>     Section 6: Standardization of Feature Contexts
>
>     The context transfer protocol provides a basic framework in which feature
>     contexts of varying types can be transferred. Recognizing that the
>     particular feature contexts may have very different needs with regard
>     to update, synchronization, and transport, the base context transfer
>     protocol requirements are designed to not constrain how the context
transfer
>     protocol is used for particular feature contexts with respect to these
>     points. In addition, some feature contexts may require additional
processing
>     on the target access router before they can be of use. Individual feature
>     contexts will be standardized by the method of IETF standards action.
>     The standardizationof a feature context should describe how a feature
>     context utilizes the base context transfer protocol; if update,
> synchronization,
>      and additional proccessing are required, and, if so, how they are
achieved;
>      and the transport used for the feature context.
>
>
>
>

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Aug 2002 13:24:17 -0700

jak

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 20, 2002 12:59 PM
Subject: Results of CT Requirements Concensus Call

language
the
supported
transfer
to
TCP
is
contexts
transfer
processing
achieved;