Subject: [Seamoby] RE: Section 5.5 Modifications

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 10:37:24 -0500

Well, I am maybe not as good of a boy scout as some others
but, I remember 3 weeks of debate, followed by a period
of  2 months of silence and then a 90 minute discussion in London 
(not to mention the 3$K trip expense :) ) 
that lead to us not making reactive
or proactive CT as a basis for the CT usefulness debate. 
Lets not open that barrel of snakes (certainly bigger than worms) again.

If you want to mention proactive a byproduct, or use case, that is fine.
But I think we should be careful about making a byproduct a primary goal.

Regards,

Madjid 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, July 19, 2002 7:47 PM
To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
Subject: Section 5.5 Modifications

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 17:28:01 -0500

James,

Ok, I guess I am reactive to proactive or reactive CT,
because the baggage that the words have and their relation
to handover and L2 triggers. If I understand your point clearly,
you are refering to the need for transfering different feature
contexts at different points in relation to handover.

I think this is covered by the following
(what lead to this discussion, was actually the difference
in urgency of header compression versus accounting data)
And the MAY and MUSTs were debated heavily too :)

Regards,

Madjid

4.11 Context information MAY be transferred in phases.

   Providing for phased transfers allows the context acquisition 
   and transfer to be prioritized.  

4.12 The context information to be transferred MUST be available at the
     AR performing the transfer, prior to the initiation of a given phase 
     of the context transfer.

   To effect a rapid transfer, the context information has to be readily 
   available when the AR begins a phase of the transfer.

   If the context transfer is comprised of a single phase, then all of the
   context must be available prior to the transfer initiation.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, July 22, 2002 12:08 PM
To: Nakhjiri Madjid-MNAKHJI1; Gary Kenward; [email-masked]
Subject: Re: Section 5.5 Modifications

Madjid,

> But I think we should be careful about making a byproduct a primary goal.

I guess I am not clear what your opinion is on the proposed change. The
intent
of the changes I proposed, including both the modification to Section 5.5
and
the new Section 5.8, was to leave it up to the individual feature context
specifications whether the transfer was done proactively or reactively. The
general context transfer protocol would continue to be neutral in this
regard,
as it was agreed to in London. Is this acceptable to you?

Also, if you feel the wording I've proposed doesn't capture this intent,
please
feel free to propose an alternative.

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 17:28:01 -0500

James,

Regards,

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, July 22, 2002 12:08 PM
To: Nakhjiri Madjid-MNAKHJI1; Gary Kenward; [email-masked]
Subject: Re: Section 5.5 Modifications

Madjid,

            jak