Subject: [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 09:26:59 -0400

Cedric:
 
  All of us our busy. It is regrettable that you wasted your time
explaining something which did not need explaining. You are missing
my point, which is, to be blunt, that proactive/reactive does cover
the 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 have
stated this many times, in many ways.
 
  'nuff said. I now agree with Pat. This will take at least a meeting at
IETF 51 to work out; at least. I may or may not be there. My only
caution is that exchanging one set of terms for another will likely
not resolve the real issue, just bury it until someone comes up with
more detail to argue. I have no great love for the terms "proactive"
and "reactive", but I am fully convinced that choosing new terminology
will set us back to January of this year, when Seamoby had the discussion
of "soft" versus "hard", "make-before-break" versus "break-before-make".
 
  As I tried to indicate in my previous posting, if you believe your case
needs
emphasis, then let's work it into the wording of the current draft. Until
some
clearly superior terminology arises, let's work with what we have.
 
Gary
Plus ca change, plus c'est le même chose.

-----Original Message-----
From: Cedric Westphal [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: Cedric Westphal <[email-masked]>
Date: Wed, 04 Jul 2001 08:20:56 -0700

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.
>
>      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
>      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,
>      -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
>      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/
>      I agree with (a) MUST be supported, (b) MUST be supported,
>      tell me why (c) SHOULD NOT

---

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

> clearly superior terminology arises, let's work with what we have.

Well, I hope that we don't end up just exchanging terminology. I is
obvious from the discussions on the list that this is a difficult issue
to resolve in the list, so I am glad that you agree that a face to face
is the best way.

I do want to enforce the fact that whatever we discuss at the meeting,
we still need concensus on the list. 

PatC

---

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

> Meeting in

Do you mean that a meeting will not solve the issue, or that you cannot
make the meeting?

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 11 Jul 2001 00:21:24 -0700

Pat,

I don't think I'll be able to be in London. A meeting can only help the
issues forward. As far as I am concerned, my only way to provide any
input is the mailing list.

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 07:09:26 -0700

> input is the mailing list.
Ah, well as I stated earlier, we don't make decisions in IETF meetings. The
list will be used to discuss what we agreed upon at the meeting, and we can then
take it from there, and I'll have to determine consensus.

Thanks,

PatC