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

From: "Gary Kenward" <[email-masked]>
Date: Mon, 13 Aug 2001 22:04:29 -0400

Pat:

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: August 13, 2001 19:19
> To: [email-masked]
> Subject: [seamoby] Update on Issues from IETF meeting
> 
> 
> All,
> 
> Although I need to put together the minutes from the London 
> meeting last week,
> I'd like to send out the results from our Issues discussion, 
> and request any
> comments before we move on.
> 
> There are four pending issues:
> 
> Issue 2: This issue has to do with the adoption of the 
> proposed requirement 4.3.
> 
> 	The consensus in the meeting was to adopt the requirement 
> 	with some minor wordsmithing.
> 
> Issue 4: This issue had to do with new terminology for 
> proactive and reactive
> Issue 7: Remove the terminology proactive and reactive
> 
> 	After some intense discussion on the issue, it was 
> decided to remove
> 	proactive and reactive, and instead adopt a very simple 
> requirement
> 	similar to:
> 
> 	"Context Transfer may occur prior to, during or after a 
> handover."

"And in any parallel space-time continuum."

> 
> 	Nearly complete consensus on this approach.
> 

I did not put my hand up. I was too amazed.

> Issue 5: This issue was a request to support multi-phasic CTs
> 
> 	The text proposed at the meeting was:
> 	"4.9 Context information MAY be transferred in phases, 
> allowing for 
> 	time critical state to be sent first, and non-time 
> critical state 
> 	to be sent later.

Similar to the change to proactive and reactive: we do not need
the second phrase (the part starting with "allowing for . . . ").
The second phrase describes one application of multiphase, not
a requirement for it (NB: for proactive, the order is reversed,
so the requirement is actually incorrect as it is worded).

So, yes to:
"4.9 Context information MAY be transferred in phases."

Note that we have a requirement that the context must be labelled.

> 
> 	The cost of building and sending smaller packets is 
> less, as well 
> 	as parsing and processing by the receiver. "

This is editorial, and subject to debate (hmmm, smaller packets are
easier to build and send? Does this means that ATM is more efficient 
;^} )

> 
> 	The consensus at the meeting was to adopt the text, but 
> a comment was
> 	made that how one defines time critical is an issue 
> since anything
> 	could be send in the initial CT message.
> 
>     Each CT profile would need to specify whether it is time-critical.

Why? We need a protocol model to better understand the requirements for
time-critical state transfer (if there are any) and any need for
synchronization.

> 
> If someone has any comments on the above, I'd like to hear 
> them now. As you
> know, decisions aren't made at meetings, and the list is 
> still the preferred
> medium to provide comments. If I hear no objections by 8/21, 
> these changes
> will be included in the next revision of the draft will be 
> send to WG last call.

Comments provided.

> Thanks,

Your welcome.
Gary
> PatC

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 15 Aug 2001 11:30:48 -0400

Cedric:

  If I may: we proposed for options for issue 4 (and issue 7, which
I felt was related). I have attached the powerpoint slides for you. One of 
the options was your revised wording, which unfortunately, did not get
enough 
review before the meeting, and was too long to digest during the meeting.

  The indication in the meeting was that people preferred the wording
Pat email. However, consensus can only be established on the wg email 
list. 

Gary

> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 10:20 AM
> To: Pat Calhoun
> Cc: [email-masked]
> Subject: Re: [seamoby] Update on Issues from IETF meeting
> 
> 
> Pat Calhoun wrote:
> 
> >         proactive and reactive, and instead adopt a very 
> simple requirement
> >         similar to:
> >
> >         "Context Transfer may occur prior to, during or 
> after a handover."
> >
> It is very simple indeed, but I am not sure I understand 
> WHERE is the requirement.
> If I don't require anything, my context transfer actually 
> MUST happen prior to,
> during or after the handover. I can't see when else. By 
> requiring that 'CT MAY occur
> at any time', are you planning for
> disruptions in the time continuum?
> 
> Serioulsy, removing the terminology is not the same as 
> removing the concept.
> 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,
> thanks,
> 
> Cedric.
> 
> 
> 
> >
> >
> >         "4.9 Context information MAY be transferred in 
> phases, allowing for
> >         The consensus at the meeting was to adopt the text, 
> but a comment was
> > medium to provide comments. If I hear no objections by 
> 8/21, these changes

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 15 Aug 2001 12:54:11 -0400

Cedric:

 Given those same laws of physics, how can there be a realistic
requirement stating that CT complete at some specific time, even
relative to handoff (ignoring the fact that we don't have a temporal
definition of handoff either)?

 Stating what is obvious to some is often required in requirements
to ensure that the obvious isn't lost.

 This is why I prefer to refer to a proactive capability requirement
for ct: CT MUST be able to respond to events that warn of a possible
handoff to an AR, and CT MUST be able to transfer context to prepare
the newAR with the appropriate context for proper forwarding of the
MNs traffic. Ideally, the latter means proactive CT SHOULD be complete
before the arrival of the first packet at the new AR.

 Reactive starts sometime after the handover is initiated, and completes
as soon as it can...

 But then, here we go again...

Gary

> Sent: Wednesday, August 15, 2001 11:22 AM
> To: Pat Calhoun
> Pat,
> thanks for the minutes. It seems it was indeed pretty intense.
> However...
> 
> Pat Calhoun wrote:
> 
> > 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.
> 
> Stating whether or not CT could complete before or after 
> handoff is to me a
> requirement.
> 
> Cedric.
> 
> 
> > 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
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Aug 2001 09:06:57 -0400

Rajeev:

  "to proceed" - sure enough.

  but for the record, CT before handoff is not necessarly
proactive, it's just early...

Gary

> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 10:37 PM
> To: Cedric Westphal
> Cc: Pat Calhoun; [email-masked]
> Cedric at al.,
> I guess the purpose was not to disallow proactive or reactive 
> CT. In fact, having CT to
> occur prior to, during and after handover allows for all the 
> possible cases. In the form
> of a requirement,
> 
> - when the MN arrives at the new AR, it must be possible for 
> the context(s) to be present
> at the new AR
> - when the MN arrives at the new AR, it must be possible to 
> perform CT when context(s)
> is(are) not present in  order to obtain them
> 
> In my opinion, this would be enough to proceed on this 
> without getting into a rathole.
> 
> Regards,
> 
> -Rajeev
> 
> 
> Cedric Westphal wrote:
> 
> > Pat Calhoun wrote:
> >
> > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote:
> > > > Pat,
> > > >
> > > > > > Serioulsy, removing the terminology is not the same 
> as removing the concept.
> > > > >
> > > > 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: George Tsirtsis <[email-masked]>
Date: Thu, 16 Aug 2001 12:01:54 -0400

whatever...

-----Original Message-----
From: Theo Pagtzis [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 5:00 PM
To: George Tsirtsis
Cc: Pat Calhoun; [email-masked]; Cedric Westphal; Henrik Levkowetz
Subject: Re: [seamoby] Update on Issues from IETF meeting

Hi George, 

With all due respect I am in favour of the suggestion below. It provides
better notion of time and behaviour simultaneously for a CT protocol. 

However, I have one question: 

is it possible that it can happen proactively (before) AND reactively
(after) at the same time? 
Aren't these time event a bit mutually exclusive or at best OR-inclusive? 

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean
logic, reasons clearly for that... 

GT>Actually no... Some context may need to be transfered early and some
late...e.g.: security keys (early) and header compression state (late) 

I disagree with the no, but I agree that it may be _some_ cases where the
context is transfered, part of it early..(proactively) _and_ part of it
(late). 

if 

A means 'late' 
B means 'early' 

A  AND B means that both late and early have to happen _always_       (std
boolean predicates) 
A  OR  B means that either late OR early OR both can happen 

I see A  OR  B as being much more open than A AND B 

In other words A  OR  B captures the case you have described and does
suggest a change of the AND conjunct. to an OR inclusive disjunct.. 

Theo 

UCL/ Mobile Systems 

George

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Aug 2001 16:56:09 -0400

That was my point Pat.

Thanks.

> Sent: Thursday, August 16, 2001 1:19 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; Theo Pagtzis; [email-masked]; 
> Cedric Westphal;
> Henrik Levkowetz
> 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
> On Thu, Aug 16, 2001 at 01:15:11PM -0400, Gary Kenward wrote:
> > But what is "handoff"?
> > 
> > > Sent: Thursday, August 16, 2001 10:25 AM
> > > To: Theo Pagtzis
> > > Cc: [email-masked]; Cedric Westphal; Henrik Levkowetz
> > > 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&so
> rt_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:
> > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > > > ...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'.
> > > > > > > > > to design the crane, and not design a crane and 
> > > see if the containers fit.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > > Cedric.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > PatC
> > > > 
> > > 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Aug 2001 17:43:29 -0400

Consensus can not be determined at a wg meeting. We have to 
go through this on the email list.

And so, yes, let's get on with it.

Before/after or proactive/reactive - pick a pair and let's move
on. I prefer the latter: I know what they mean, I know what they don't
mean, and most important, I know how they can be used. 

BUT, I will not oppose the former, because I don't believe we
will every resolve the discussion until we see real protocol proposals.
And, I totally expect a future debate over the meanings of "before" and
"after", but so be it.

Gary

> Sent: Thursday, August 16, 2001 5:23 PM
> To: Henrik Levkowetz
> > James Kempf wrote:
> > > Folks,
> > > At the risk of sounding hysterical, can we PLEASE come to 
> some concensus
> > > on this and move on? We seem to be stuck in an infinite 
> loop trying
> > > to number the angels that dance on the point of a pin. I thought
> > > we had concensus at the meeting.
> >
> >         Yes. So did I. Let's get on with it!
> >
> >         Regards,
> >                 Henrik
> >
> 
> I was there. There it was (consensus). Here I am re-iterating 
> it again (don't
> exactly know why!).
> Let's move on!
> 
> Regards,
> 
> -Rajeev
> 
> 
> 
> >
> > >
> > > Requirements are meant to be general guidelines for development
> > > of the protocol, and to exclude obviously inappropriate features.
> > > If people can't agree on a narrow scope, then let's define the
> > > requirement as broadly as possible and let the protocol designers
> > > decide what's appropriate for the particular feature they want
> > > to transfer. It sounds to me like that's going to be the case
> > > anyway
> > >
> > > Sorry.
> > >
> > >               jak
> > >
> > > >Delivered-To: [email-masked]
> > > >From: [email-masked]
> > > >To: [email-masked], [email-masked]
> > > >Cc: [email-masked], [email-masked], 
> [email-masked],
> > > [email-masked]
> > > >Subject: RE: [seamoby] Update on Issues from IETF meeting
> > > >Date: Thu, 16 Aug 2001 20:23:59 +0300
> > > >
> > > >Hi all,
> > > >
> > > >I think that CT could happen under the following conditions:
> > > >    1) Before handoff
> > > >    2) During handoff
> > > >    3) After handoff
> > > >
> > > >Futher more, I see it as feasible that:
> > > >    1) All context (for a particular CTP instance) could 
> be sent in a single
> > > >packet (subject to MTU)
> > > >    2) Context (for a particular CTP instance) could be 
> sent seperately
> > > >
> > > >I think that it depends on the situation, implementation 
> and requirements
> > > >for the particular context being transfered.
> > > >
> > > >I request that the CT requirements allow for this.
> > > >
> > > >thanks,
> > > >John
> > >
> > >
> 
>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 16 Aug 2001 18:50:15 -0400

I believe that Scott was pointing out the inability of this group to produce
"actual" requirements. During earlier e-mails I identified at least 3 of the
so called requirements that are not really requirements and yet they are
MUSTs in this requirements document. I have yet to receive an e-mail to say
the contrary...

If the group does not care then lets move on...with the so called
"requirements document" which actually does not contain real requirements...

George
P.S.: I hope this group also appreciates that the criticism is not
necessarily towards the people involved but towards this relatively new IETF
process that IMO is fundamentally flawed. i.e.: the requirement to produce
"requirements" documents before protocols. I hope the ADs are listening in!

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 11:15 PM
To: James Kempf
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [seamoby] Update on Issues from IETF meeting

James and Scott,

I do not agree that we should convert the Requirements draft to a Guidelines
draft. May be I am missing something, but, I think a Guidelines draft
_could_
follow once we have a solution, which itself follows the Requirements.

Can we move on with the consensus that was reached in London and not open
the can
on Requirements vs Guidelines ?

Thanks,

-Rajeev

James Kempf wrote:

> Scott,
>
> >
> >I guess I cannot agree that requirements are meant to be general
guidelines
> >as James suggests.  They are meant to be more than that...certainly MUST
> >requirements.
> >
>
> What I heard in email this morning from, I believe, Gary is that
> the exact timing of transfer will depend on the feature context
> being transferred. Consequently, I do not think it is possible
> to get a more precise set of requirements for the general timing problem
> than what JohnL proposed at IETF 51 and what, I thought, the
> WG had agreed to as concensus.
>
> Any further attempt to be precise would necessarily compromise
> the generality of the requirement and involve investigating
> specific feature context requirements.
>
> >Perhaps, as a way out of this rathole, we could simply change the draft
> >title from
> >
> >General Requirements for a Context Transfer Framework
> >to
> >General *Guidelines* for a Context Transfer Framework
> >
> >As a requirements doc, the draft has problems.
> >As a guidelines doc, it's OK.
> >
> >I know the group was in requirements mode, but it seems to have produced
a
> >guidelines draft.  We could just acknowledge that and propose some
protocols.
>
> Fine, I have no problems with that. IMHO, much of the problem the group
> is having in achieving precision on requirements may be due to the
> fact that everybody has a different set of feature contexts they
> are thinking of, and so they come at the problem of specifying
> requirements for the general problem from that perspective. Agreeing
> to one particular set of precise requirements would in some
> cases involve choosing the requirements for one or a group of
> feature contexts and preclude those of another feature context having
> different and, in come cases, opposing requirements, hence, the
> debate continues to circle. I've not been deeply involved in the
discussion,
> only observing, but this is sort of what I've been seeing.
>
>                 jak

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 17 Aug 2001 03:49:22 -0400

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, August 17, 2001 12:16 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] Update on Issues from IETF meeting

George,

>"requirements" documents before protocols. I hope the ADs are listening in!

Actually, I disagree with this assessment. I do not think that it is
possible to design a protocol without first agreeing what it should
do, which is what requirements are.

GT> Is that so? I thought the Internet was built this way. Some time ago
IETF believed in "running code". Anyway, as you said this discussion is not
for this list...I will not push this any further, just move on.

George

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 17 Aug 2001 11:59:14 -0400

Scott was part of the review team that created the 8 "comments" that I sent
a few days ago to this list.

-----Original Message-----
From: Theo Pagtzis [mailto:[email-masked]]
Sent: Friday, August 17, 2001 10:27 AM
To: M. Scott Corson
Cc: James Kempf; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [seamoby] Update on Issues from IETF meeting

Hello Scott,

Rather than commenting what the document should be named as, we would
appreciate
if you could point out the specifics that you feel -as a
member of the constituency- that are leaning  towards what you term as
'guidelines' as opposed to what the rest of the Seamoby constituency calls
'requirements'. This would help us all understand what are your inferences
from
reading the document that the group is bringing together.

To dismiss a whole effort as being guidelines rather than requirements is
rather
deconstructing since we cannot see what are the points from the document you
are
not in agreement with and most important _why_ !

Would you like to elaborate on specific points you do not agree with in this
document? If not I fear that it will not be fruitful at all to pursue this
angle
any further.

Regs

Theo

UCL/ Mobile Systems

guidelines
> I know the group was in requirements mode, but it seems to have produced a
protocols.
>
> -Scott
>
> At 10:41 AM 8/16/01 -0700, James Kempf wrote:
> >Folks,
> >
> >>Cc: [email-masked], [email-masked], [email-masked],
> >[email-masked]
> >>    1) All context (for a particular CTP instance) could be sent in a
single
> >>packet (subject to MTU)
> >>    2) Context (for a particular CTP instance) could be sent seperately
> >>
> >>I think that it depends on the situation, implementation and
requirements

---

From: James Kempf <[email-masked]>
Date: Fri, 17 Aug 2001 08:15:44 -0700 (PDT)

>
>Meanwhile, let's get this thing out so we can work on protocols.
>

Precisely!

>> I think we need to accept the document with edits as
>> defined in the London meeting and move on. Whether it is called
>> guidelines or requirements is irrelevent, because it is not going
>> to get any more specific until we start looking at particular feature
>> contexts that need to be transferred, IMHO.
>
>It is very relevant to the ADs.
>

Well then, let's just put whatever name they want on it. :-)

The point is that the content reflects the concensus of the WG on
*general* (stress here) requirments for context transfer. The
preciseness of the general requirements can only be determined to the
extent that there is no conflict between the requriements for transfer
of specific feature contexts. Where there is a conflict, the general
requirements must, of necessity, reflect a compromise, and so
will be less specific. It's impossible to make the requirement
more specific without excluding one or the other case in conflict.

My impression, particularly with regard to the timing issue, is that
this is exactly what is happening. Some specific feature contexts
(like QoS) could be transferred earlier, some (like header compression)
must be transferred later. Trying to be more specific than JohnL.'s
wording proposed in London and later on the list is going to
exclude one or the other. Hence, the burden of making the timing
requirement more specific ("no more than xxx milliseconds latency
prior to L3 handover..", etc) should fall on the individual feature
context requrirements document, not on the general requirements document.

Am I missing something?

		jak

---

From: [email-masked]
Date: Sat, 18 Aug 2001 10:16:20 +0300

Hi Pat,

> Well, we are trying to get consensus on your first point, but
> the other issue that seems to have consensus is to allow for 
> CT to occur in multiple phases.

I know ... I was just trying to restate my points in a different
format, so people wouldn't be arguing about 'and' / 'or' and so
on ...

John