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

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Jul 2001 14:11:33 -0400

Cedric:
 
   I suspect that we are actually close to agreement, just 10 degrees out of
phase.

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 11:21 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
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).  

Sounds very kinky. I actually didn't say anything such thing in my last
posting, or at least, 
I didn't intend to. I was trying to convince you that there wasn't a need
for another mode
(perhaps I misunderstand what you meant by proposing "soft" ct).

Thanks for reminding me. My French is atrocious. My country may be
bi-lingual, 
but I'm definitely semi-lingual.

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  

Again, you interpret proactive and reactive  with a specific connotation.
I don't. So be it, but do we really need to define a new "soft" mode for ct?
Since I see this little kiddie accounted for in the current modes, and you
don't, something needs clarification. 

 Aside from not liking the term "soft", the reason I'm leery of new modes is
because it adds one more variable in an already contentious scenario. At
this
point, I would prefer to scrap these modes and instead describe the
preferred/
required characteristics of the ct process - e.g. it SHOULD start as early,
if possible,
so that the essential context is available at the newAR when the first
packet arrives,
*but* that some context may still be transferred after the forwarding
begins, *and* 
in some networks there may be no warning and ct can only be performed after
handover
begins/finishes.

Something like that, with a hell of a lot of word smithing.

ain't gonna happen, but I'll take up your offer and try to work it in  

Actually, between these email exchanges the earth shifted on it's axis,
and it turns out I will be there. I'm looking forward to it, as I'm sure
that
90% of the discussions over this issue are an artefact of using email rather
then face to face discussions. I'll bring my flame retardant long johns just
in
case.

the wording.  

Words are great.

Cheers, 

Cedric.   

Tally ho! Now, getting back to this thing in LA with "pro" and "rea" . . .  
Gary 

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: "Gary Kenward" <[email-masked]>
Date: Wed, 11 Jul 2001 10:28:34 -0400

Hello. This confusion is of my doing.
Originally I was not planning to attend, and conveyed this to Cedric.

In short, a different meeting.

Gary

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 7:54 PM
> To: Cedric Westphal
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'
> Subject: Re: [seamoby] RE: Need for support of neither pro 
> nor reactive
> ct. was: Re: [se amoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> > Meeting in
> > London
> Do you mean that a meeting will not solve the issue, or that 
> you cannot
> make the meeting?
> 
> PatC
>