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

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Sep 2002 11:34:27 -0700

I've heard no objections to on my proposed resolution of Issue 3, so I'm
assuming it is fine with everyone.

Based on that, I will send email to Gary about the changes and we can hopefully
finally proceed to starting the protocol design.

            jak

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 26, 2002 1:24 PM
Subject: [Seamoby] Fw: Results of CT Requirements Concensus Call

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

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Sep 2002 11:34:27 -0700

jak

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 26, 2002 1:24 PM
Subject: [Seamoby] Fw: Results of CT Requirements Concensus Call

2,
transport.
support
feature
require
router
it,
information,
router
been
feature
feature