Subject: [seamoby] CT Requirements Issue 7

From: [email-masked]
Date: Fri, 13 Jul 2001 09:04:28 +0300

Hi all,

I sent this yesterday, but it didn't seem to make the list - let me try
again.

====

Description of issue 

Section 4.4 & 4.5 are potentially limiting.

Submitter name: John Loughney
Submitter email address: [email-masked]
Date first submitted: July 12, 2001 
Comment type: T

Priority: S

Section: Insert_Section_Number_Here 

Rationale/Explanation of issue: 

Currently 4.4 and 4.5 imply that there are two modes of operation.  It is
not so cut & dry.  As seen by the discussion on the list, there are many
differing requirements that may not be satisfied by discussion these modes.
Length description of problem 

Currently, by defining proactive & reactive, the work group may start to
think in terms of these 2 modes of operation.  I don't think that CT is so
black & white.  

Requested change: 

Remove proactive & reactive from the document.  These could be used as
examples in the document, if needed.

Disclaimer: I am not saying that proactive, reactive, active, etc. are not
needed - what I am saying is that by defining requirements for more basic
building blocks, we can then use those building blocks to create aggregate
behavior that looks like proactive, reactive, etc.

Proposal 

Focus on the features & functions of reactive & proactive modes rather.  For
example, everyone will agree that certain context may have a higher priority
(may take precidence over, may be more time sensitive, etc.) than others.
Some context may go stale.  Some context may need to be acknowledged.  

By stating the types of functionality that are needed, the requirements will
allow a more rich protocol.

=============================================

Example (solution space):  

We define these features - this is not the complete set:
(priority, time-to-live, ack-needed, synchonized with ho)

So, I would define the transfer of header compression state
as context transfer that has a high priority, a certain time-to-live, 
ack-needed.

High priority would mean that the AR would send it ASAP.

TTL would indicate that the context would go stale.

Ack-needed would indicate to the mobile node that if the
new AR does not yet have the header compression state, 
then it shouldn't send compressed headers, but attempt to
re-initialize the compressor at the new AR.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 17:02:15 -0700

I did see this yesterday, and added it to the issues list. Monday morning
I will update the list with the latest status.

PatC