Subject: RE: [seamoby]Rant: Update on Issues from IETF meeting

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 20 Aug 2001 11:24:03 -0500

Pat, thank for the minutes, although, the spelling of my
name migrated from Madjid (Majid is ok too) towards Majeev (I guess I should
blame myself for agreeing with Rajeev too much :).

Ok, and now the rant:

For whatever it is worth, I am for removing the terminology
like reactive and proactive or whatever other word. I can not fathom
 that words like during and after causes allergic reactions (no offense).

As Gary mentioned, we did discuss these terms for several months on Ct list,
we discussed them on Seamoby list for a month, we became quite to have a 90
minute
discussion in London and we convinced each other (those of us who were
there),
now we want list consensus, why are we singing the same tones again? 
A simple consensus (yes or no) should be fine.

We agreed to leave very important requirements such as timing and reliablity
for later.
So why are we fighting about some terminology, that may or may not affect
many peoples implementations? Are we escaping the reality???

I bet revisiting the requirements after 6 months of protocol (or even
framework) work
would be much more useful.

I would rather discuss the CT profile issue (the thread that was killed).

My single squashed Nickel,
Madjid

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 9:14 AM
To: Cedric Westphal
Cc: Pat Calhoun; [email-masked]
Subject: Re: [seamoby] Update on Issues from IETF meeting

> Serioulsy, removing the terminology is not the same as removing the
concept.

As far as I can tell, proactive vs. reactive was essentially stating when CT
would occur. This, as you state, is not a requirement, and therefore adding
something as simple as what proposed seems to do the same thing with the
least
amount of friction.

> It looks to me like the baby was thrown away with the bath water. You
mention some
> 'intense discussion', could you elaborate to enlighten those who were not
present,

Here are the rough minutes for this particular discussion:

<minutes>
Issues 4 & 7
-------------

4 - Proactive v.s. Reactive.

7 - Remove pro and re from doc. 

Theo: Why remove? 
Two modes are too limited, may be more than two
modes, putting in reqs will limit to two modes.

Theo: two classes of sets of modes, other distincitions 
necessary. 

Charlie: Don't know yet, revisit issue later. Move
on better understood reqs. Table it.

John Longherty: Talk about protocol modes, examples
rather than modes. Useful to discuss in terms of
examples of how a protocol may work, but not
normative. 

Allison: Design space to consider, potental to 
classify. Don't put in as requirement. 

Majiv: Misunderstanding. Timing req. originally
there, to define timing req need to dig deeper,
need to define in relation to handover, not
supposed to be modes. Solution covers both,
but solutions don't have to cover modes.
Remove if expected to be a mode.

Gary: Mode is the problem, not proactive and reactive.
Mode is the issue, capability is more deescriptive.
Protocol operate on two kinds of capabilities.
Not bit in header, happens in different time relative
to handoff. 

Hemant: Do we need to define temporal characteristics?
Depends on when trigger was sent.

Theo: Shift from mode to timing. Timing in which
you act. CT tends to revolve around time 
restriction. Dismiss timing, then revisit.

Rajeev: Mode -> capabilities won't solve.
MN attaches to new router, is context there or not?
Pro - there, Re - not there. Too much confusion,
put in appendix. 

three options

1) Use word capabilities
2) Remove
3) Move to appendix.

Need to consider revise or keep current text.

Rajeev: Proposed text. If context there when MN
attaches to new router, pro. If there after, re.

Majeev: Timing requirements in req. doc? Will
it delay handover? May want to define pro and
re, if not, triggers may be needed. Confusing
based on starting event and ending event.

Rajeev: Presentation, is a distinction. 

Majeev: Does there need to be a timing
requirement?

Henrik: Cedric's text makes me least happy.
Way it says it is difficult, don't know
discussion says that you implement two
modes. Other than that, OK. 

Gary: Timing requirement is in current doc,
section 5, req for pro and re, current
reqs are wrong, specifies a too tight
timing req, needs to be fixed.
No happy with delegating to appendix, important
part of CT and for seamlessness.

Pat: Advisory.

Gary: No, it must be a requrimenet, proactive,
there when packets arrive at new AR.
Lose and be back in same debate.

????: QoS guy, how would a router react
if first packet had a code point and
the QoS was not there? Would drop.
So there is a timing req. 

Pat: Some
environments where you don't have 
handoff notification, in others,
can.

???: Some networks have it.

Rajeev: Always try to get context transfereed
prior to handover. Not removing possibility 
of moving context. When you invoke CT. 

Henrik: Important to have capability to do flexibly,
as early and late. Shouldn't be an appendix.

Gopal: Can push or pull context, pro or re depends
on timing. 

John Logherty: Local API issue.

Gary: Makes a difference. Multiphasic, only time
is just at time that handover is happening. Later,
state isn't there for packet to be forwarded. 
Other phases, might want to transfer. Static,
won't change. Value in concepts, landscape for
people to work on solutions.

Rajeev: Proactive mode, previous router initiates.
Reactive, new router initiates. Both routers should
be able to initiate. Proactive in either direction.
Is context on new router?

Pat: options

1) leave as is.
2) use word capabilities.
3) remove text from doc -5 
4) remove text to appendix -5 
5) state that CT before, during, or after
handover. - many.

5) wins.
</minutes>

Thanks,

PatC