Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:33:37 -0400

Pat:

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 4:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1';
> [email-masked]'; [email-masked]
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> On Wed, Jul 11, 2001 at 03:00:32PM -0400, Gary Kenward wrote:
> > Pat:
> > 
> >  The oAR does not need to know when the first packet arrival
> > at the newAR may occur. Indeed, for proactive to be effective,
> > the oAR must initiate a ct based upon an event that is only 
> indicates
> > a possible handover.
> > 
> >   Here is the scenario: the MN traffic is passing through, say, AR3.
> > The RF subsystem (aka the link layer, aka L2) "determines" 
> (through L1/l2
> > mechanisms) that AR5, AR19, and AR11 are potential 
> candidates for handover.
> > AR3 receives an event from L2 that instructs it to transfer 
> context to
> > AR5, AR19, AR11. The three "target" ARs in this example are 
> thus ready to
> > receive a handover of the MNs traffic, if it is required to 
> maintain the
> > traffic flow. Note that this approach does not completely 
> prevent the MN
> > from unexpectedly appearing in the coverage domain of a 
> different AR - 
> > that's the nature of wireless, however, it goes a long way 
> to improving
> > the situation.
> > 
> >   Nothing in the above refers to a deadline event. Of course, it is 
> > the objective to have the context in place before it is 
> needed at the
> > new AR. But ct must still work if this deadline is not met, 
> and, because
> > we all know how unpredictably handovers can be, the requirements and
> > design should explicitly address this situation. In other words, in
> > wireless handover, the exception is the rule.
> 
> Good. So far we are in agreement.
> 
> > 
> >   As I have stated, I want to change that text to clarify 
> that ct completion
> > before the first packet arrival is a goal, not a 
> requirement. Or, perhaps,
> > it is a SHOULD, not a MUST.
> 
> Right but using the above example, there is *nothing* the protocol
> can do to ensure this happens. This is network engineering, wireless
> technology capabilities, etc.
> 
> So, this requirement is kind of moot, since we agree that the protocol
> doesn't care, and the packet would be identical regardless of whether
> the CT occurred prior to the arrival of the first packet. I think it 
> still makes sense to discuss timing in the protocol spec, but this is
> informative only.
> 
> Am I simply confused?

Well, I disagree that there is nothing we can do with the protocol
to meet the goal. We seem to circle over the issue of "timing" quite alot,
and no resolution is in site. I think it is fatuous to create a requirements
document for a mobility protocol, particularly on that is supposed to be
contributing to "seamlessness", that does not in some manner the need
certain
time constraints. Stating that ct should be "fast" or "faster" is, IMHO,
like
saying that a politician must be honest. Good in principle, but ambiguous in
fact. 

On this point, I agree with James' latest posting. 

So, if we do not put some sort of deading goal into the requirements, and
describe
how the protocol is expected to behave to reach that goal, and how it should
behave
if the goal is missed, then what is the point? I could transfer context
using
ftp and a dial up link (don't flame me, I like ftp).

Gary

> 
> PatC
> > 
> > Gary
> > 
> > Note: the ct scheme we are working on is a little different 
> then that
> > described above, but hte principle is the same. I did not 
> want to get into
> > all the details in this email.
> > 
> > > -----Original Message-----
> > > From: Pat Calhoun [mailto:[email-masked]]
> > > Sent: Wednesday, July 11, 2001 10:34 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]';
> > > [email-masked]
> > > Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > > comments) (SHOULD
> > > be , RE: Issue #4)
> > > 
> > > 
> > > If we end up deciding that we want to keep most of the current
> > > text, I will follow the WG's desire, but I do have some
> > > concern with the fact that it currently uses the arrival of
> > > a packet destined for the MN as the main difference between both
> > > modes of operation. My issue here is in source triggers 
> (meaning oAP
> > > initiates CTP), oAP has no way of knowing when the first 
> packet will
> > > be received, and therefore doesn't know whether a proactive or
> > > reactive CTP should be initiated. This is why I am 
> convinced that this
> > > is just informational, and not a protocol thing.
> > > 
> > > PatC
> > > 
> > > On Wed, Jul 11, 2001 at 10:20:20AM -0400, Gary Kenward wrote:
> > > > Madjid:
> > > >  
> > > >    I'm glad you feel this way. I guess this discussion 
> > > began as a result of 
> > > > Issue #4, which proposes an alternate wording.
> > > >  
> > > >     After a few exchanges with Cedric, I reviewed the 
> > > current text, and
> > > > I realized that it indicates that proactive is deadline 
> > > driven, which I
> > > > really
> > > > believe is a bad thing to require.  All I want to ensure is 
> > > that there is a 
> > > > capability with ctp to start a ct sometime before the 
> > > actually traffic
> > > > handover
> > > > is initiated. Why? Because there are many networks that 
> > > provide "warnings"
> > > > that a handover may be imminent (actually, most RF systems 
> > > can be designed
> > > > to do this, and should). How? Well, the actual trigger 
> > > event will change
> > > > depending upon the L2 design, but typically, the mechanism 
> > > starts with the
> > > > base receiver sensing transmission from a mobile, and then 
> > > usually many
> > > > other 
> > > > mechanisms that kick in to identify the mobile at L1/L2.
> > > >  
> > > >    So, I would also like to keep the current text, for the 
> > > same reason. I
> > > > would
> > > > like to remove the deadline, or at least change it so that 
> > > it is clearly a
> > > > desirable
> > > > deadline, but not a requirement (we cannot make it a 
> > > requirement because the
> > > > physics
> > > > of wireless handover make the timing of any forewarning 
> > > event completely un-
> > > > predictable).
> > > >  
> > > >    Maybe I've said this all before, and maybe my view is 
> > > clear to everyone.
> > > > Sorry
> > > > for being repetitive.
> > > >  
> > > > Gary
> > > >  
> > > > 
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1 
> [mailto:[email-masked]]
> > > > Sent: Tuesday, July 10, 2001 6:37 PM
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
> > > > [email-masked]
> > > > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> > > > 
> > > > 
> > > > Gary,
> > > >  
> > > > I don't think we should remove the reactive/ proactive 
> > > definitions out of
> > > > requirement, unless there is a consensus for removing it.
> > > >  
> > > > If we nobody can come up with a better definition than 
> the already
> > > > existing one, either we keep it or declare it as an open issue.
> > > >  
> > > > Personally I liked the definitions that are based on the 
> > > starting event
> > > > such as link establishment better, but I still can live 
> > > with the exiting 
> > > > one (packet arrival) for the time being. Removing the 
> whole thing
> > > > is throwing a lot of good thoughts away.
> > > >  
> > > > A requirement subject to modifications is better than no 
> > > requirement.
> > > >  
> > > > Madjid
> > > >  
> > > >  
> > > > 
> > > > -----Original Message-----
> > > > From: Gary Kenward [mailto:[email-masked]]
> > > > Sent: Tuesday, July 10, 2001 8:53 AM
> > > > To: [email-masked]'; [email-masked]
> > > > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> > > > 
> > > > 
> > > > 
> > > > John: 
> > > > 
> > > >    I have been contemplating removing the 
> "reactive"/"proactive" 
> > > > definitions from the requirements also, but I really do hope we 
> > > > do not lose the concept of starting ct as early as 
> possible. Being 
> > > > proactive with ct has been a fundamental component to 
> ct since the 
> > > > problem statement draft, and, to me, a critical tool 
> for providing 
> > > > seamless service handover. 
> > > > 
> > > >    There are those who, rightfully, have no interest in 
> proactive 
> > > > ct for their networks. If we lose the requirement, it 
> may be very 
> > > > difficult for the wg to proceed with a ctp design that supports 
> > > > this mode. 
> > > > 
> > > >    I'll wait for your issue to be generated. Some of us 
> are also 
> > > > struggling with some alterative wording of the definitions 
> > > > 
> > > > Gary 
> > > > 
> > > > > -----Original Message----- 
> > > > > From: [email-masked] [ mailto:[email-masked]
> > > > <mailto:[email-masked]> ] 
> > > > > Sent: Tuesday, July 10, 2001 1:59 AM 
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked] 
> > > > > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) 
> > > > > 
> > > > > 
> > > > > Hi Gary, 
> > > > > 
> > > > > >  I agree, particularly with your definition of ct 
> (although I'm 
> > > > > > not sure where "reductive mode" came from). 
> > > > > 
> > > > > 
> > > > > Ooops, I meant that I was in "reductive mode" (trying to 
> > > > > simplify & get back to the basics).  
> > > > > 
> > > > > > In thinking through the overall discussion, I am 
> > > realize that the 
> > > > > > big difference between "reactive" and "proactive" is 
> > > how they are 
> > > > > > triggered. "proactive" assumes that there is a trigger 
> > > available 
> > > > > > early on that permits some context transfer in advance 
> > > of an actual 
> > > > > > handover. 
> > > > > 
> > > > > I agree. My thoughts are that the discussion of reactive 
> > > and proactive 
> > > > > (& triggering, etc.) get quite close to protocol 
> design.  I think 
> > > > > that is one reason that the discussion became so heavy on the 
> > > > > the requirements. 
> > > > > 
> > > > > >   I do believe the current wording for proactive is 
> > > wrong. Now that 
> > > > > > I have had time to contemplate the wording, it does not 
> > > define what 
> > > > > > I have always believed proactive ct should be 
> about. I'm hoping 
> > > > > > that if we fix that wording, we can move on to the 
> > > important part 
> > > > > > of designing ctp. 
> > > > > 
> > > > > My suggestion would be to cut-out of the requirements 
> > > document the 
> > > > > discussion about proactive & reactive text.  I will try 
> > > to make an 
> > > > > issue for this later in the day. 
> > > > > 
> > > > > thanks, 
> > > > > John 
> > > > > 
> > > > 
> > > 
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 12:42:35 -0700

> ftp and a dial up link (don't flame me, I like ftp).

But there isn't really anything you can do in a protocol to meet timing
requirements. This is all an implementation detail. I agree, btw, with
your observations, and don't have a particular issue with having a 
requirement to state this, but we must all agree that it isn't really
a "protocol" issue, but more how one invokes the protocol.

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 16 Jul 2001 00:11:20 -0700

Hey,

Gary and myself have worked on a new proactive/reactive paragraph
to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
same terminology.
Here it is, please comment, thanks,

Cedric.
-------------------------------------------------------------------------

4.4 The context transfer framework MUST support proactive context transfer.

4.5 The context transfer framework MUST support reactive context transfer.

   It is useful to consider two complementary, non exclusive
modes of operation for context transfer:
proactive and reactive.

   The context transfer process is said to be proactive when the required
contexts are requested to be in place at the target AR  prior to the arrival of
MN's packet
at target AR.

   With proactive context transfer, the idea is to make the context available
to an AR before it is needed. This means that the context is
available at the AR before it is required to forward the first
packet arrival in the MN's traffic. Proactive context transfer is
coupled to mobile handover only by the requirement that the context
be in place before the handover of the MN's traffic is complete.

   The context transfer is said to be reactive when it is not proactive.

   The idea is that in a reactive context transfer, no guarantee is made as to
when the context will be in place at newAR. The context transfer process reacts
to the handover, but has no control over or knowledge of the handover to ensure
that it is in places before the arrival of MN's packet at the target AR.
Reactive context transfer is coupled to mobile handover only by the requirement
that some handover event is triggering the reaction. Reactive context transfer
completes as soon as possible, but its completion is independent of the handover
process.

   Depending upon the network configuration, the MN's velocity and the behavior
of the mobility solution, a reactive context transfer may or may not complete
quickly enough for the new forwarding AR to provide a consistent service to
the first packets of the re-directed traffic.

   In many situations there is no forewarning available of a handover
and context transfer must be initiated simply because the
re-direction of the MN's traffic is in progress and the AR needs the
forwarding context immediately. Because of the physical constraints,
these situations can  never be completely avoided. Thus, if context
transfer is to be  performed at all, the fundamental mode of operation
must be reactive.

   The proactive mode of context transfer is an attempt to further
reduce any disruption of the service provided to the MN's traffic by
making the context available to an AR prior to it being needed for
forwarding. This implies that some network event will occur at the IP
level to indicate the potential for a handover, prior to the handover
being initiated (c.f. requirements 4.1 and 4.2). This event would
trigger a proactive context transfer if there is confidence the context
transfer can complete before the arrival of MN's packet at the target AR.
There can be no guarantee that this event will occur or that this confidence
will be acquired, and thus, a reactive context transfer is
always required as a contingency.

   This also means that a context transfer that begins in proactive mode
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete in reactive mode.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

   As the proactive mode of context transfer is an enhancement, there may be
situations where the reactive mode is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
mode, its use is optional.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 16 Jul 2001 10:25:03 +0200

Cedric, Gary

	I find the background explanatory text very good but when you get
into describing the way the protocol will work, I see an assumption
sneaking in which I don't agree to, namely that the protocol will need
to have two _modes_ of operation.  Maybe it will, or maybe we will be
able to define / design the triggers and handling at the destination
in such a way that there really will be only one mode. But I think
it's premature to imply two modes, ... maybe you didn't really mean to?

	Anyway, I've suggested revised text inline, below.

	Best,
		Henrik

> Here it is, please comment, thanks,

.................................................. Thus, if context
transfer is to be performed at all, its fundamental function must be
reactive context transfer.

>    The proactive mode of context transfer is an attempt to further

   The ability to transfer context proactively is an attempt to further
...

> should evolve into a reactive context transfer attempt.

   This also means that a context transfer that begins as a proactive transfer
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete as a reactive transfer.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

> mode, its use is optional.

   As proactive context transfer is an enhancement, there may be
situations where reactive transfer is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
context transfer, this ability may not always be implemented or used.
   <<<The last sentence limps a bit, I think. Maybe you'll find
      a better formulation that doesn't go into Modes. /Henrik>>>

---

From: "Emil Sturniolo" <[email-masked]>
Date: Mon, 16 Jul 2001 11:45:14 -0400

Hi folks,
	I just have one observation. From reading the new text:

"This means that the context is available at the AR before it is
required to forward the first
packet arrival in the MN's traffic. Proactive context transfer is
coupled to mobile handover only by the requirement that the context be
in place before the handover of the MN's traffic is complete."

My interpretation of this is that a "proactive context transfer" must
be totally completed prior to HO. If one considers a multi-phasic
transfer, and only enough context is transfer proactively to allow
packet forwarding, but other ancillary information is subsequently
communicated, I believe from the current definition that the
completion of this transfer is deemed a "reactive process". I am fine
with this distinction,  but I would like to see it be specifically
stated rather then just implied. Alternatively, we could change the
text slightly to account for this case and still allow it to be a
completed within the scope of a proactive transfer. Suggested text:

"This means that enough of the context is available at the AR before
it is required to process any of the MN's traffic. Proactive context
transfer is coupled to mobile handover only by the prerequisite that
elements of the context that enable packet forwarding be in place
before the handover of the MN's traffic is complete."

Comments?

Cordially,
Emil Sturniolo
[email-masked]
www.NetMotionWireless.com
330-723-9099
330-461-0326 - Mobile/Voice Mail
=====================

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 16 Jul 2001 10:46:27 -0700

Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else' is
in place. More on that 'else' later.

The transfer of context must be bound by the context constituents that
are sufficient and necessary for the node to transit over a proactive
transition mode. This implies partial context existence in the new
candidate points of attachement. Partiality must not mean that something
critical for seamlessness is not in place in terms of context at the
CARs. Thus partial context transfer over proactive transition mode(s)
must imply a totality of context necessary to effect seamlessness.
Depending on what is considered as a seamlessness factor in each context
ontology, then the totality and partiality over transfer of a discrete
number of constituents in new CARs is defined accordingly.

I would like to expand the set of transition modes to the CT requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I personally
consider it as equally important since it provides the intermediate step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 17 Jul 2001 00:06:19 -0700

Emil,

>         I just have one observation. From reading the new text:

the quote below is not new text. It already is in the current req. draft.
On the other hand, the multiple phase req. is not at this time. So, I
share
your concern, and I hope that the definition of the support of multiple
phases will
addresss your point.
Regards,

Cedric.

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 17 Jul 2001 01:11:46 -0700

Henrik,

thanks for the comment. One general reply, before more specific ones in line.
You are concerned about something that was present in earlier versions of the
requirement draft, and that did not raise any issues back then. The introduction
sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
'it is useful to consider two modes of operation'. Nobody objected to that. People
discussed at length what those modes were, but never the term _mode_.

So why discuss something that had been accepted? If I hear where you come from,
I'd say there is the new multi-phase req that induces changes (so now there is the
added 'non exclusive', to underline that both modes can work cooperatively in the
same ct if need be). Other cautionary words should be in that multi-phase req.

Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
with this. A mode is a way of doing things (how do you attempt ct?), an ability is
the capacity of doing things (can you achieve this ct?), these are different notions.

A little bit more in-line.

Henrik Levkowetz wrote:

> to have two _modes_ of operation.

For sure, we agree, and I personnaly did not
see or intend the implication that you see. I think the very first sentence
('two complementray, non exclusive modes of operation') is clear enough
to dispell any doubt about getting locked into one _mode_. There's also
a paragraph talking on how proactive evolves into reactive if need be.

> Maybe it will, or maybe we will be

To tell you the truth, maybe we don't understand mode the same way. Let me
give a picturesque, snow-plowing the driveway kinda example:
a car transmission might have a sporty mode and a comfort
mode. Marketing guys in Detroit did the requirement: we must support sporty,
we must support comfort. Do engineers build two different cars? No, it's just
a switch on the dashboard: up, sporty, down, comfort.
My point is, a _mode_ is not a _protocol_.

> reactive context transfer.

I understand what you are trying to do, but saying 'the fundamental function of
ct' replies to the question 'what is ct' (the fundamental function of ct is to
transfer
context), and this addresses the question 'how'.

>    The ability to transfer context proactively is an attempt to further

an ability is not an attempt.

Henrik, I hope that this helped alleviate your concerns,
best regards,

Cedric.

---

From: "Emil Sturniolo" <[email-masked]>
Date: Tue, 17 Jul 2001 06:43:58 -0400

Cedric,
	Shame on me!. I read the draft some time ago and I didn't compare the
text. I was just going by the note you had posted.  Furthermore, I
didn't want to restart the debate about proactive versus reactive. As
for the multi-phasic issues, ultimately I was just trying to suggest
some text that might allow for the better description of this
functionality with respect to the definition. On the other hand,  if
the original text is deemed more appropriate by the WG, I wanted  to
insure that the distinction I pointed out was clearly identified and
not left up to interpretation. Looking forward to meeting you in
London.

Cordially,
Emil Sturniolo

-----Original Message-----
From:	Cedric Westphal [mailto:[email-masked]]
Sent:	Tuesday, July 17, 2001 3:06 AM
To:	Emil Sturniolo; [email-masked]
Subject:	Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

Emil,

>         I just have one observation. From reading the new text:

the quote below is not new text. It already is in the current req.
draft.
On the other hand, the multiple phase req. is not at this time. So, I
share
your concern, and I hope that the definition of the support of
multiple
phases will
addresss your point.
Regards,

Cedric.

---

From: "Emil Sturniolo" <[email-masked]>
Date: Tue, 17 Jul 2001 07:32:28 -0400

Theo,
	Maybe I am missing something here, but I think we are somewhat in
agreement. I too believe that the "proactiveness"  by which CT was
initiated does not (can not?)  directly correlate to its completion,
although I might have stated that in a circuitous fashion.  What is
important to me is that somehow we describe in the document that
enough elements of the context (your totality of context necessary to
effect seamlessness )  be communicated to the nAR to facilitate
seamless HO prior to having it process/propagate any of the MN's
traffic. However we go about describing this functionality, using 2,3
or n modes as you suggest, makes little difference to me. On the other
hand, if the WG at large deems that this behavior falls into one of
the already defined categories, I would like to insure that the
definition clearly points this out so it is not left to interpretation
(such as mine). Thanks for the response.

Cordially,
Emil Sturniolo

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
On Behalf Of Theo Pagtzis
Sent:	Monday, July 16, 2001 1:46 PM
To:	Emil Sturniolo
Cc:	Cedric Westphal; Pat Calhoun; Gary Kenward; seamoby
Subject:	Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context
is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else'
is
in place. More on that 'else' later.

candidate points of attachement. Partiality must not mean that
something
Depending on what is considered as a seamlessness factor in each
context

I would like to expand the set of transition modes to the CT
requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I
personally
consider it as equally important since it provides the intermediate
step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition
mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems

> coupled to mobile handover only by the requirement that the context
be

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 17 Jul 2001 13:59:12 +0200

Cedric,

	Your are quite right in that mode may be used more generally, as it was in the
introduction sentence. This is not what I object to.  It is the much more specific
usage and examples at the end of the text which I object to, as they actually seem
to require two separate, different, modes of operation. 

	I'm not in any way particular about the specific wording I proposed, any wording
that does not enforce two modes would be Ok; I simply submitted text as the decent
thing to do when proposing a change. If you don't like it, different words could
be just as fine.

	However, if you don't mean to require that the protocol has two separate, 
different modes, I believe that the text will have to change somewhat. I understand
the way you wish to use mode, but the current text does not clearly read in that 
manner -- quite the contrary, actually, which is why I commented in the first place.

	Regards,
		Henrik