Subject: [seamoby] Comments on CT Reqs draft

From: George Tsirtsis <[email-masked]>
Date: Tue, 14 Aug 2001 10:18:59 -0400

All,

Here are some comments on the current CT requirements draft. We quote text
from the draft to make this easier to read and try to suggest alternative
text when possible.

Comment 1
-----------
"4.9 All context information to be transferred MUST be available at the 
   AR performing the transfer, prior to the initiation of the context 
   transfer.
 
   The total context associated with the MN's traffic is composed of 
   various types of feature context. To effect a rapid transfer, the 
   context information has to be readily available when the AR begins 
   the transfer. "
 
This does not make sense as stated. What initiates the gathering of all the
relevant context to be transferred? Or you just mean that all relevant
context is in close proximity to the CT code (i.e.: same box)? By saying the
context MUST be ready when CT is initiated we just defer the potential for
delay, we do not eliminate it...i.e.: one may not initiate CT until it has
gathered all context but the gathering process could take very long time. 
We suggest something like the following:
"CT should not be slowed down by a process or feature inability to make
appropriate context available to CT. CT SHOULD be able to transfer context
as it becomes available. 

Comment 2
----------
"4.10 The context information provided for transfer MUST be reliable.

   The context to be transferred must not only be readily available for
   transfer, but the sending AR must ensure that the information is sound.
   
   The context transfer solution may provide mechanisms to support reliable
   transfer of context, but the effectiveness of context transfer in
enhancing
   handover between ARs would very likely be compromised by attempts to 
   transfer malformed context."

This again makes no sense to the casual reader! How does CT "evaluate" the
soundness of a protocol specific context. Consider that the effectiveness of
context transfer in enhancing handover between ARs would also very likely be
compromised by attempts to ensure that the information is sound. Please
remove this totally unreasonable requirement or explain what you mean. If
people feel strongly about this it should as a minimum be watered down like
this:
"The sender SHOULD make all reasonable efforts to ensure the data is sound
since transfer of invalid data may be more damaging than transfer of no data
at all"

Comment 3
----------
"5.1.1 The context transfer protocol MUST be capable of transferring all 
      of the different types of feature context necessary to support the 
      MN's traffic at a receiving AR."

I would like to propose to clarify this further:
"CT MUST be generic and feature agnostic, i.e.: CT MUST allow new features
to be defined and transported without having to change CT itself."

Comment 4
-----------
"5.4.1 Proactive context transfer MUST be completed before the handover 
      of the Mobile Node's traffic to the receiving AR completes."

Does this make sense after the removal of the proactive/reactive concept
from this doc. Even if it does make sense there is no way to ensure such a
thing. You can only try and have mechanisms so you can recover when things
go wrong. E.g.: there might not be any connectivity between old and new AR.
This is a SHOULD not a MUST.

Comment 5
----------
"5.4.3 A context transfer MUST complete with a minimum number of protocol
      exchanges between the source AR and the rest of the ARs. "

This is a SHOULD..protocol engineering is a trade-off and this is one of the
basic variables (signaling level). The requirements document may decair its
preference to low signaling levels but must not mandate it...At the end of
the day a slightly slower more concrete CT may be better than a faster
flakey CT!

Comment 6
-----------
"5.4.4 The context transfer protocol design MUST minimize the amount of 
      processing required at the sending and receiving Access Routers."

As above..this is a SHOULD not a MUST...Minimization implies the existence
of some optimization function with constraints. Who sets the constraints? If
they are set by each implementor according to their fancy, then all these
protocols can claim compliance with the above. 

Comment 7
-----------
"5.4.5 The Context Transfer protocol MUST meet the timing constraints 
      required by all the feature contexts."

Again, CT SHOULD attempt to comply with timing constrains and have ways to
recover if it does not...nothing is for certain here...Maybe change with
something like this:
"The Context Transfer protocol SHOULD strive to comply with the the timing
constraints imposed by the different feature contexts. The CT protocol MUST
provide ways to recover and allow the handoff to complete normally when the
timing constrains are not met."

Comment 8
-----------
"5.6.2 The context transfer protocol MUST include methods for exchanging
      information with the handover process.

   Both context transfer and handover require information on the
   AR candidates for handover. The context transfer entities may, in the  
   process of establishing and supporting context transfer, acquire  
   information that would be useful to the handover process in  
   determining the new forwarding path: for example, the outcome of an
   admission control decision at a receiving AR."

The text here is very nebulus, so as a minimum a concrete example should be
given.  "For example, if during the CT process one newAR appears to be able
to support the MN's QoS requirements better than the other, then CT SHOULD
be able to make this information known the handoff process."

Regards

George Tsirtsis
Michaela Vandermeer
Alan O'Neill

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 14 Aug 2001 15:08:36 -0400

George:

  Most of these comments seem to be editorial. As you seem
to have figured out the intended meaning in most cases, I suggest
that they do make sense to the casual reader. The intent here cannot
be to define bullet proof requirements (such a document could easily
consume 100s of pages).

  More comments below:

Gary

> -----Original Message-----
> From: George Tsirtsis [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2001 10:19 AM
> To: [email-masked]
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: [seamoby] Comments on CT Reqs draft
> 
> 
> All,
> 

Your suggestion is syntactically incorrect, and thus harder to understand.
The intent is as you surmised: to require that the context be at the AR,
and not elsewhere when the transfer is to be initiated. There are many
finer points that could be made, but with markedly diminishing importance.

> Comment 2

The requirement says nothing about CT evaluating the soundness
of the context. The requirement actual says the opposite: that
the context must itself be reliable, for ct will do nothing to 
compensate for unreliable context. 

> remove this totally unreasonable requirement or explain what 

It is not unreasonable. It is an absolute requirement, and there
was general agreement (please refer to the archives for the complete
discussion). 

> since transfer of invalid data may be more damaging than 

This is an entirely different requirement. Your version is trying to
"future proof" ct. 5.1.1 is concerned with the current features available
at an AR. Future proof statements such as the one above are, IMHO,
motherhood,
as everything has to agree, and yet there is no way of ensuring that a 
solution is future proof.

> Comment 4

I agree. But if you read the minutes of the last IETF meeting, this
statement will be changed - probably deleted, as "proactive" and "reactive"
are being removed from the draft.

> Comment 5

In truth, this is a non-requirement. "minimum" is one of those ambiguous
words, that cannot be measured without a reference with the requirement
does not specify. 

In essence, given that the reliability requirements for ct are met (which
are tbd), then all this requirement says is that there shouldn't be any
"excess" exchanges. Again, there is no measure to determine what exchanges
might be "excess". 

Probably the only real application of this requirement is if we end up
comparing two protocols that are identical in every way but one has more
exchanges. Might happen.

At this point, this requirement is unlikely to be deleted, and it has
no impact as it is stated.

> Comment 6

The language could be improved, but the requirement is accurate:
the protocol MUST not introduce excess processing. You are right,
the "minimization" requirement has no basis for determining compliance.

> Comment 7

Sorry, but if a protocol meets the requirements, whether through
a clean design or through "recovery", then it meets this requirement.
"strive" is an anthropomorphic term that doesn't belong in a requirement.
Also, you have specified two requirements in place of one. 

The requirement remains a MUST. The fact is that everyone one of the
requirements is likely to fail under some conditions, and the protocol
is going to have to have some reasonable recovery mechanisms. It would
take years for us to gain consensus on all the necessary recovery
mechanisms.

> Comment 8

Why? Here is a good example where the meaning of the requirement was
in fact clear to you. Are you pre-supposing that other readers have less
of a grasp of English, or a lower IQ? As the prime audience for this 
document is actually the people who participated in the writing, it 
would seem reasonable that they would derive the same meaning as you did.

> Alan O'Neill

Cheerio,
Gary

---

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

George:

> Sent: Tuesday, August 14, 2001 6:47 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
> Subject: RE: [seamoby] Comments on CT Reqs draft
> 
> 
> 
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2001 8:09 PM
> To: 'George Tsirtsis'; [email-masked]
> Subject: RE: [seamoby] Comments on CT Reqs draft
> 
> 
> George: 
> GT> Sure and that is not my intent. Throughout your comments 
> I see that you
> are resisting almost all change and I assume this is because 
> of fear of
> opening another endless discussion, which is also not my 
> intent. My only
> intent is to have a small number of very clear requirements 
> that I can work
> with and develop a protocol that I can also implement.

I will not resist changes that improve the possibility that we
will create a good ct solution. But, as I said, the majority of
changes seem to be aimed at clarifying text when the text was 
generally clear. Past experience has shown that word smithing
the requirements are not simple changes.
 
> GT> Gary it does not make sense. My point here is that the requirement
> relates to timing considerations which are covered by other 
> requirements in
> this spec...weather the context is in or out of the AR it is 
> a mute point
> and a protocol should not be held accountable for not doing 
> it this way.

Actually, Kulwinder answered this better then I did. The issue is
not timing, it is scope and ordering.

> GT> I totaly agree with what you state above (which I wish it 
> was the real
> text) but the spec says and I repeat "... The context to be 
> transferred must
> not only be readily available for transfer, but the sending 
> AR must ensure
> that the information is sound." it then also says..."...the 
> effectiveness of
> context transfer in  enhancing handover between ARs would 
> very likely be
> compromised by attempts to  transfer malformed context". If 
> the requirement
> is only about reliability of transfer then that is what it 
> should state.

None of the quotes you provide refer to "CT evaluating the soundness 
of context". The way this requirement is written is that it 
requires on the implementer of an AR to ensure that the context provided 
to CT is reliable. The only thing "wrong" with this, if there is
anything wrong, is that it appears to state the obvious. However,
it also states clearly that ct will not fix corrupted context.

I just don't see how you come to your conclusion.

> GT> No, the requirement is that the CT protocol MUST support reliable
> transfer which is fine...it is not about the AR checking the 
> soundness of
> the context...the text is confusing.

NO. This is not a requirement for reliable transfer. That particular
issue was a subject of great debate and has been deferred - c.f. section
5.2. 

The text says nothing about reliable transfer. It simply says that if
the context is corrupted to begin with, it will be delivered to the
receiving
AR corrupted.

> GT> I do not agree. A number of protocols satisfy the above
> requirement..e.g.: diameter. But if you thing that my suggestion is
> describing a different requirement then it is clear that I did not
> understand 5.1.1. Please illuminate.

The intent of 5.1.1 is that the ct solution should work for all the
*known* features required to support a forwarding service. As it is,
this is an ambitious statement, for we, as a wg, may or may not know 
all of these known features. What we do believe are feature contexts
to transfer are HC, AAA, encryption, QoS, and perhaps policy. Our
knowledge of the ct issues and benefits for these features is very limited,
and will remain so until we start attempting to define ct solutions.\

That's all 5.1.1 states. It does not state that the ct solution should
handle all future feature contexts. Like I stated, IMHO, you can include
this requirement, but it's kind of like saying "I will invest only in
stocks that increase in value" - a good principle, but very hard to 
act upon.

> GT> That is what I asked first ... and yes I was in the 
> meeting which only
> talked about 4.4 and 4.5, hence the question...glad you agree.
> 
> 
> > 
> > Comment 5 
> > ---------- 
> GT> Why not? You say that this is not really a 
> requirement...yet it is a
> MUST in the requirements document.

*shrug* I'm just the editor.

> GT> So, again what is the point of mute requirements? get 
> them out of the
> way and we will have a much better document.

Again, *shrug*. The phrase "mostly harmless" comes to mind.

We have had extensive discussions in the working group over these
requirements, and a consensus was determined. We have to live with
this consensus, otherwise no progress will be made. If there was a real
problem (e.g. logical fallacy or misconception), then it would be worth
opening an issue. But I don't believe it's worth revisiting the debate
over whether the use of words like "fast", "smooth", "faster", "minimal",
etc. are useful in requirements. As you know, if this was a rigorous
requirements
document (e.g. a DoD requirements document), such words would not be
permitted.

> GT> The point is that on one hand there is no way for any 
> protocol to ensure
> that timing requirements are met while on the other hand you miss the
> obvious requirement of failsafe. BTW, I did not request 
> consensus on the
> recovery mechanisms just the requirement for the protocol not 
> to fail the
> handoff when it self fails. Then again I would be happy if 
> you changed that
> MUST to SHOULD since no one can satisfy the MUST.

These are requirements. Even in rigorous requirements excercises it is
fully acceptable to outline the desired goals ("MUST"), while realizing
there are exceptional conditions where these "MUST"s will be violated.
Again, it's an issue that I believe is a result of the lack of rigor
in this particular requirements specification process (and, no, I'm not
suggesting more rigor).

Personally, I'm happy with MUST.

> Why? 
> GT> Because I give you a valid example that you actually 
> agree with instead
> the mumble jumble of the current one but never mind...this is 
> not important
> so forget about it.
> 
> Here is a good example where the meaning of the requirement was 
> of a grasp of English, or a lower IQ? 
> 
> GT> I am not even going to respond to this...you must be very 
> tired since I
> do not think you really want to be offensive. I just regret that I am
> causing you pain...
> 
> As the prime audience for this 
> GT> Gary, a general point. I can understand if I make a point and you
> disagree...in which case we have to discuss further. I do 
> not, however,
> understand when you agree with me and yet say "....oh no, we 
> can not change
> the doc now...too late", unless of course the rest of the 
> group feels the
> same way.

Ok. The process is that you submit an issue to the wg list for each 
change that you would have identified. Then we discuss each issue
for one or two months, and Pat tries to gauge a consensus. If there
is no clear consensus on the list, then Pat will ask for an email humm.

My views on your issues have nothing to do with this process. You are
fully welcome to submit the issues. 

My opinion, however, is that, yes, we certainly have not created a perfect
document, and many of the requirements could be worded better, could have
better explanatory text, and, there are definitely many requirements
missing.
But, in my view, it is not worth the pain and effort to continue polishing
up descriptions that have been actively reviewed and discussed for 3 months
now.

This is just my view, and no I'm not tired, I just want to move on to the
protocol design sometime this millenium.

> 
> - Comments 4, 5, 6 we agree on and unless there are others 
> that disagree we
> should change 
> - Comment 2 I think we agree on but not sure yet
> - Comment 1, 3, 7 we do not seam to agree on
> - Comment 8 is not important 

We (you and I) don't form a consensus. Unless I'm mistaken, the process
outlined above is still in place. If you feel strongly about these
9 issues, then you should submit them (he says reluctantly).

Sorry for seeming obnoxious. 

Gary

> George

---

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

*snip*

> 
> For example, we have ruled out the transfer of PDP context, 
> and BTS context.
> 

We have? I thought we had only decided that such L2 context would
have to be transferred opaquely (which would imply the timing
requirements/reliability/security requirements for the transfer
might be difficult to pin down, but so be it).

Gary

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 15 Aug 2001 13:01:02 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 4:19 PM
To: 'George Tsirtsis'; [email-masked]
Cc: Alan O'Neill; Michaela Vanderveen
Subject: RE: [seamoby] Comments on CT Reqs draft

...*big snip*...

GT> Why do we need to discuss this for 1 or 2 months? I sent an e-mail to
see what the WG feels about issues that concerned me while reading this
draft. If someone things that my points are invalid then lets hear it...you
have agreed with some and disagreed with others...lets hear a few more
opinions and then make a decision. I do not know why it has to be harder
than this.

> - Comment 8 is not important 
We (you and I) don't form a consensus. 
Unless I'm mistaken, the process 
outlined above is still in place. If you feel strongly about these 
9 issues, then you should submit them (he says reluctantly). 

GT> How did this process degenerate to such level of paperwork?...It does
not have to be this way you know. I would very much like to know what
everyone else things. Myself and Gary here seam to agree on comments 4,5 and
6...anyone disagree? .....and yes if you want me to submit the issues as
required by this peculiar local process I will do so but I would rather know
what the WG things first.

Thanks
George

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 15 Aug 2001 13:10:46 -0400

> Sent: Wednesday, August 15, 2001 1:01 PM

I was being fasicious. Of course, we have been discussing proactive/reactive
for nearly six months now. 

Good luck.

Gary