[Seamoby] Section 5.5 Modifications

["James Kempf" <[e-mail]>]

Hi Gary,

>   I get the impression that either everyone has forgotten about proactive
> CT, or does
> not care. Which is too bad, for the boy scouts are right on when they say
> "be prepared".
>

Thanx for reminding me, being an old Boy Scout myself I should have remembered.
:-)

How about if we modify the text I sent out as below? In addition, I think we
need an additional section, which I will post on a separate thread, that
describes the steps needed to standardize a feature context. This text will
include a requirement for update on feature contexts that are not tightly
synchronized with external events.

                jak

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

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.




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