Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 2 Jul 2001 13:12:31 -0500

I suggest we leave this as an open issue, until we meet in IETF.

Madjid 

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, June 29, 2001 10:28 AM
To: 'seamoby'
Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
Sensitivity: Confidential

In the interest of moving the requirements forward, I support the change in
the
definitions of "reactive" and "proactive' proposed by Pat:

Reactive CT: The context transfer process which takes place subsequent 
to arrival of a MN's packet at the target AR 

Proactive CT: The context transfer process in which the required contexts 
are in place at the target AR  prior to the arrival of MN's packet at target
AR. 

Since these are "definitions" and not requirements, I assume that there is
room
for change as we delve into the design process.

For what it's worth . . .

Gary

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 03 Jul 2001 00:54:34 -0700

Sorry to breach the truce, but here are some comments:

> are in place at the target AR  prior to the arrival of MN's packet at target

reactive sounds good to me, but not proactive. There is a consensus for support
for several phases in CT. So it seems that the term 'required' needs to be
clarified.
In the CT phases discussion, the talk is about priority. Some contexts are more
important than other. Which is true, but mostly some contexts are more time
sensitive
than other. Some accounting contexts, which some operator would argue is _very_
important, can arrive later, after the arrival of MN's packet at new AR. This
requirement denies this possibility.

Solutions: 1) define a static context (configuration state) and a dynamic
context (accounting
state). Static context is what has to be transfered before the arrival of MN's
packet
at target AR. Replace 'required' in your definition by 'static', or 'config'.
Dynamic is what
can be transfered later to fill in the blanks. I have some text on this if you
want.

-or-

2) one of the issues with proactive/reactive is that it connotes a
serialization. pro/before, re/after.
There seems to be somewhat of a consensus as to before what and after what
(having the
newAR default router, or having the newAR receiving packets from the MN).
For instance in this proposal, the whole transfer has to be performed _before_
(prior in the
text) the arrival of MN's packet at newAR. Other proposals: pre-handoff,
post-handoff, same
thing. Charlie's proposal: reactive, predictive, also same thing.
On the other hand, CT can be initiated before/after, and completed before/after.
So, if you take
away the initiated after/completed before, you still need at least THREE terms.
There is also a consensus on reactive: initiated after/completed after. The
issue is with proactive,
which means before, and has to cover the CT completed *after* case, which is
somewhat
counter-intuitive.
So here is yet another proposal, which borrows the handoff terminology, and is
in everybody's
dictionnary:
hard CT = reactive CT
soft CT = a CT in which the transfer is initiated before the arrival of MN's
packet at the target
AR. (no mention of completion, covers the initiated before, completed before or
after case).
proactive CT= the definition up this mail (covers the initiated before/completed
before case).

Cheers,

Cedric.