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

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Aug 2001 13:15:11 -0400

But what is "handoff"?

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, August 16, 2001 10:25 AM
> To: Theo Pagtzis
> Cc: [email-masked]; Cedric Westphal; Henrik Levkowetz
> Subject: Re: [seamoby] Update on Issues from IETF meeting
> 
> 
> Theo,
> 
> My problem wasn't the terms active,proactive,reactive, but 
> the rather long text
> accompanying the terms, which caused nothing but confusion 
> and would open up
> cans of worms. I find John's proposal to be short and to the point.
> 
> If you think that something along the lines of:
> 
> "Context Transfer MAY occur before (proactive), during 
> (active) and after (reactive)
> a handoff."
> 
> would be more acceptable since it keeps the terminology in 
> place, I wouldn't be
> against it, and would welcome comments.
> 
> PatC
> On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote:
> > Ced/All,
> > 
> >    First just to comment that having done some work for the 
> design of a proactive mobility
> > framework, I can only see that
> > at the end of the day the terminology will boil down to 
> whatever people's taste sees fit as a term
> > compliant with the timing intrinsincs of context transfer.
> > 
> > However, I would like to argue in favor of the terms 
> active, proactive and reactive, not because I
> > have writen a draft about proactive mobility but because I 
> have substantial reasons to believe that
> > the terms are generic enough to encompass the entire time 
> continuum of _any_  event (not just
> > context transfer)
> > 
> > As I said in the seamoby meeting the meaning of active 
> (during), reactive (after) and proactive
> > (before) depends first on the reader and really has got a 
> fractal nature with respect to the
> > magnitude of
> > application of the notions since they really do not apply 
> just to a mode of operation as people
> > _erroneously_  consider. Much like a fractal they apply to 
> a set of modes, or to an ontology of set
> > of modes, or to a set of ontologies of sets of modes, 
> etc...ad infinitum
> > 
> > Just to exhibit the futility of the discussion on the 
> matter and the fact that at the end of the
> > day it is more who influences whom (everybody company hats 
> on) rather what the terminology really
> > reflects I will only cite the meaning of the terms 
> PROACTIVE and REACTIVE from what else, the one
> > and only source of objectivity which if we do not respect 
> we might as well throw dictionaries away,
> > deny authority of linguists, and identify a tech 
> terminology anarchy where only the strongest
> > (hello hats) survives
> > 
> > I am not going to comment on what the oxford dictionary 
> says because I expect people to be able to
> > identify the etymology of the terms as supplied by the 
> experts of linguistics, in the light of
> > objectivity:
> > 
> > 
> http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q
ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_
id=Iz5i-> rrbDl0-705
> > 
> > Let us now visit the etymology of the word REACTIVE
> > 
> > 
> http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q
ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha
> > 
> > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4
> > 
> > Last but not least the word Active
> > 
> > http://dictionary.oed.com/cgi/entry/00002214
> > 
> > I stress the multiplicity of meaning but stick to notions 
> of  1.a, 3.b, 4.a, 5.
> > 
> > People managed to stick to the terms the label 'mode'.... 
> WHY  did this happen? ..because it serves
> > them better for the purposes of dissmissing the terms or is 
> it because they have a narrow view of
> > the world, or is it maybe because they do not really 
> consider the real meaning of the terms? I
> > wonder...
> > 
> > A CT protocol MUST support at least one of these if it is 
> expected to work in this time dimension
> > 
> > As such to me the above means that:
> > 
> > 'a CT protocol MUST support a minimum of at least one time 
> class of event servicing with respect to
> > mobility, that is active,reactive or proactive event 
> servicing for the purposes of mobility aware
> > context transfer'
> > 
> > What are the events? I don't care (and why should I) it may 
> be a handoff, it may the connection, it
> > may be foobar.
> > 
> > The above mean to me that the terms above describe 
> accurately a 'requirement' with respect to the
> > time period that context transfer comes in effect with 
> respect to an EVENT. The terms are elegant
> > and comprehensive as long as people know what they mean. 
> Oxford English Dictionary attests to
> > that...
> > 
> > In that light the above terms do not need replacement 
> really since they do describe accurately what
> > they are supposed to. As such I personally provide a reason 
> that what Cedric suggested augmenting
> > the set of requirements with, is valid. It just becomes a 
> matter of taste whether people want to
> > name it something else, like 'during, before, after' which 
> is more informal.
> > 
> > That is not to say that I oppose to the validity of 
> 'during,before,after'. It is to say that we
> > have been fighting over synonyms really at a time when we already
> > identified the right words.
> > 
> > I would personaly like to stick to 
> active,reactive,proactive for the reasons presented above. If
> > people feel that the 'during,before,after' works better in 
> their head then fair enough, but we just
> > embark in yet another game of renaming things..
> > 
> > Regs.
> > 
> > Theo
> > 
> > UCL/ Mobile Systems
> > 
> > 
> > 
> > 
> > Cedric Westphal wrote:
> > 
> > > "A CT protocol SHALL support context transfer which can occur
> > > before, during or after handover"
> > > this is not the same as 'CT MAY occur prior to, during, 
> after', and
> > > that makes sense to me.
> > >
> > > Henrik Levkowetz wrote:
> > >
> > > > Cedric,
> > > >
> > > >         Stating that a protocol SHALL support context 
> transfer which
> > > > can occur before, during or after handover blatantly 
> eliminates your
> > > > example which does it ONLY 2 days after handoff.
> > > >
> > > >         Henrik
> > > >
> > > > >
> > > > > Henrik,
> > > > >
> > > > > Henrik Levkowetz wrote:
> > > > >
> > > > > > Cedric,
> > > > > >
> > > > > >         Johns proposal and wording was the first 
> that cut trough
> > > > > > the fog at the meeting, and met with overwhelming 
> agreement because
> > > > > > it stated very simply what seems to have been many 
> people's concern
> > > > > > -- i.e. that a CT protocol _not_ be so limited that 
> it could not handle
> > > > > > any of the conceivable timing scenarios implied.
> > > > > >
> > > > > >         As such, it may be obvious, but it is also 
> VERY MUCH a
> > > > > > requirement, and may sort out unsuitable protocol 
> proposals which may
> > > > > > not have the flexibility required.
> > > > >
> > > > > I disagree with this, but this flexibility is exactly 
> the point I'm bringing up.
> > > > > The proposed requirement is so much a requirement 
> that I'd like to see ONE ctp that does NOT
> > > > >
> > > > > meet it. I am sorry, but a ctp that ONLY sends 
> context 2 days after a handoff
> > > > > does satisfy the requirement, since it 'may occur 
> prior to, during or after', so why
> > > > > not pick after? Talk about sorting out unsuitable protocols...
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Cedric.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >         Do you actually have anything against it, 
> apart from it being
> > > > > > obvious? I for one am very happy to have this 
> requirement plainly and
> > > > > > simply stated.
> > > > > >
> > > > > >         Regards,
> > > > > >                 Henrik
> > > > > >
> > > > > > Cedric Westphal wrote:
> > > > > > >
> > > > > > > Pat Calhoun wrote:
> > > > > > >
> > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, 
> Cedric Westphal wrote:
> > > > > > > > > Pat,
> > > > > > > > >
> > > > > > > > > thanks for the minutes. It seems it was 
> indeed pretty intense.
> > > > > > > > > However...
> > > > > > > > >
> > > > > > > > > Pat Calhoun wrote:
> > > > > > > > >
> > > > > > > > > > > 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,
> > > > > > > > >
> > > > > > > > > ...what I state is that saying 'CT may happen 
> prior to, during or after handoff'
> > > > > > > > > is not a requirement, it is just stating the 
> obvious. CT must happen prior to,
> > > > > > > > > during or after handoff, not because you 
> require it, but because basic laws of
> > > > > > > > > physics.
> > > > > > > >
> > > > > > > > And most people felt that the pro/re text also 
> didn't reflect any requirements.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Stating whether or not CT could complete 
> before or after handoff is to me a
> > > > > > > > > requirement.
> > > > > > > >
> > > > > > > > So how would you propose changing the text so 
> it reads as an actualy requirement?
> > > > > > >
> > > > > > > Together with Gary, we did propose some text. I 
> did not see much objection on the list
> > > > > > >
> > > > > > > about the wording, except some worries about the 
> use of the word 'mode'.
> > > > > > > Also, I like John's proposal in Issue 7,
> > > > > > > which if I understand it well, is to look at the 
> requirements from the context point
> > > > > > > of view, and not from the protocol point of view. 
> Basically, looking at the container
> > > > > > > first
> > > > > > > to design the crane, and not design a crane and 
> see if the containers fit.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Cedric.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > PatC
> > 
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 16 Aug 2001 10:18:51 -0700

Since the MIP WG doesn't have a problem with this term, I don't see
why we need to open that can of worms. 

Do we want to move on, or spend more cycles arguing terminology and push
our milestones out further?

PatC