Subject: RE: [seamoby] RE: Need for support of neither pro nor reactive ct . was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 9 Jul 2001 12:41:18 -0500

Why isn't the meeting in London gonna happen? 
I hope the mention of Utah is just the marriage "joke", I don't want to see the requirement
work  drag on to Utah, unless we are ready to pack to another projects!!!

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 10:21 AM
To: Gary Kenward
Cc: 'seamoby'
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing

Gary, 

here again you tell me I want to scrap the proactive/reactive terms. How 
many times do I have to tell you I like the definitions, I love proactive CT, 
I love reactive CT, I want to marry them in Utah and have a nice menage 
a trois (plus c'est LA meme chose, by the way). 
What's missing it the little kiddie of proactive and reactive, but you are 
right, there is no point continuing this discussion this way. Meeting in London 
ain't gonna happen, but I'll take up your offer and try to work it in 
the wording. 
Cheers, 

Cedric. 

Gary Kenward wrote: 

 Cedric:  All of us our busy. It is regrettable that you wasted your timeexplaining something which did not need explaining. You are missingmy point, which is, to be blunt, that proactive/reactive does coverthe case you are so concerned about, at least as far as I am concerned.If you bother to check through the archives you will see that I havestated this many times, in many ways.  'nuff said. I now agree with Pat. This will take at least a meeting atIETF 51 to work out; at least. I may or may not be there. My onlycaution is that exchanging one set of terms for another will likelynot resolve the real issue, just bury it until someone comes up withmore detail to argue. I have no great love for the terms "proactive"and "reactive", but I am fully convinced that choosing new terminologywill set us back to January of this year, when Seamoby had the discussionof "soft" versus "hard", "make-before-break" versus "break-before-make".  As I tried to indicate in my previous posting, if you believe your case needsemphasis, then let's work it into the wording of the current draft. Until someclearly superior terminology arises, let's work with what we have. GaryPlus ca change, plus c'est le même chose. 

-----Original Message----- 
From: Cedric Westphal [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, July 04, 2001 3:24 AM 
To: Kenward, Gary [WDLN2:AN10:EXCH] 
Cc: 'seamoby' 
Subject: Need for support of neither pro nor reactive ct. was: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing 
 
Gary: 

I read your reply, and I have the feeling that you are trying to convince me that 
proactive and reactive cts are indeed required. I think you are missing my point. 
First, for the record: I an convinced both proactive and reactive ct are required, 
and the definition proposed in this issue #4 are satisfying in this respect. They 
are necessary. Agreed. They are not sufficient. 
I am not going to comment point by point, I don't have time for this, but sum up: 
-in a previous mail, you said Rajeev's definitions (that you attributed to Pat) were 
good for you. 
-they are good definition for proactive and reactive. They do not consider a mixed situation, 
initiated prior to arrival and completed after. 
-the draft mentions the support of only proactive or reactive. The draft as well prohibits 
a mixed situation. A proactive ct that completes after whatever event is a failed proactive ct. 
It is a proactive that turns into a reactive (or should a fresh reactive ct be initiated if the proactive 
ct does not completes before the event, not so clear in the draft). There was not much 
point to comment before hand, since, as you say, the draft is ambiguous, and could be read any way. 
But since the clarification issue has been raised, we should address its consequences. 

Please consider the situation where MN at some point in the future  will go from oldAR to 
some identified newAR. I have this context that I want to transfer. However, it is of no critical value 
to the MN at newAR. I have the choice of: (a) proactive: I start transfering now, and pray it 
is established at newAR before (draft quote: 'it is required to forward the first packet arrival 
in the MN's traffic', new definition quote: 'the arrival of MN's packet at target AR). (b) reactive: 
I wait (new definition quote: 'subsequent to the arrival of MN's packet at target AR) until 
(draft mentions: 'initiation of a handover or soon after initiation'). 
Please explain to me why, since I have no critical deadline, I should still make a choice between 
(a) or (b), that is, to simplify (a) ensure that all my context is transfered before handoff, or 
(b) wait until I handoff to transfer. Where is (c): I take a leisurely transfer around the handoff, 
I start before, but take it easy, dude, whenever I get there is when I get there. 
You might see this as a terminology issue, (what do you call (c) since it is not proactive nor reactive). 
I think it is more a requirement issue. If the requirement draft specifies (a) and (b), does not 
mention any other possibility, explains that if (a) fails, then use (b) as the only choice of combined/ 
mixed/soft ct, then it seems to imply that it excludes (c). 
I agree with (a) MUST be supported, (b) MUST be supported, tell me why (c) SHOULD NOT 
be supported as a requirement? 
Thanks, 

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 16:56:42 -0700

> work  drag on to Utah, unless we are ready to pack to another projects!!!

Have no fear... I don't have plans to keep this going on forever. We
also have an interim on our milestones, and I plan to use it should
we need it.

PatC