Subject: [seamoby] RE: draft-hamid-seamoby-ct-reqs-00.txt

From: "Gary Kenward" <[email-masked]>
Date: Mon, 2 Apr 2001 10:46:04 -0400

Charlie:

  Thanks for the comments. Very much appreciated (and many are not
far off of some of the internal debates we have been having).

   I have some questions concerning your suggestions, for you or anyone
else who may wish to answer.

   BTW: there is a 01 version of the document. We did confuse the situation
a tad but submitting both during the IETF meeting. The 01 version hopefully
reads a somewhat better, and may even address some of your points.
http://search.ietf.org/internet-drafts/draft-hamid-seamoby-ct-reqs-01.txt

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 4:57 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: [email-masked]
> Subject: draft-hamid-seamoby-ct-reqs-00.txt
> 
> 
> 
> Hello folks,
> 
> All in all, the requirements draft seems to be a very worthwhile
> effort, from which good solutions are likely to be developed.  Thanks!
> 
> Here are some comments.
> 
> 1. Security needs discussion.  Unsecured context transfers are
>    to be avoided.  I see that the word "integrity" appears in
>    section 4.2, but somehow I didn't think that the entire discussion
>    about security was intended to be distilled into that single word.

Absolutely. We explicitly wanted to be cautious about getting too
deep into this discussion with our draft, as neither of us are active
in the security discussions, which we know to be very dynamic. 

Hopefully, someone will help us with the text.

> 
> 2. Supporting one-to-many context transfers might be useful.
>    It might also be complicated.  It almost certainly is not so
>    crucial that its lack would break the protocol.  Thus, I would
>    rate it no more than a "SHOULD", instead of a "MUST".

Understood, although I would say we should wait and see what
the solution looks like. We are not talking about general multicasting
here. I suspect that one-to-one context transfer could actually be
more complex in a real wireless scenario due to the ambiguity of
the handover "direction" at any given moment.

> 
> 3. Conversely, reactive context transfer will sometimes be the
>    only available option.  Thus, it has to be a MUST, not a SHOULD.

Agreed. I had thought we had made that change in the -01 version.
It will be in the -02 version.

> 
> 4. Terms like "micro-flow" and "integrity" need to be defined in the
>    terminology section -- or, perhaps better, replaced by more
>    specific or more common terms in the body of the text.  
> Specifically
>    regarding "micro-flow" as you have used it, a protocol would need
>    some identification mechanism.  This mechanism needs elaboration
>    in the requirements draft, I think -- it is important.

Microflow seems to be a far more controversial term then I would have
expected. We were using the definition in the problem statement, namely,
the 5-tuple definition. 

Actually, the refers to RFC2475 and RFC2207 (the latter is referenced to 
cover the scenario where the IP packets are encrypted). Is this acceptable?
I really would not want to generate a new definition of microflow if one
already exists.

> 
> 5. Discussions about interworking with "the micro-mobility mechanism"
>    are probably better deleted for now, although I agree with 
> the spirit
>    of that suggestion.

Would it be more acceptable to change "the micro-mobility mechanism"
to the "mobility mechanisms"?

> 
> 6. 100% reliability is impossible(*).  Furthermore, even high 
> reliability
>    may be undesirable as a requirement.  High reliability means
>    retransmissions, backoff algorithms, algorithmic complexity,
>    and longer time delays in case of errors.  All of these are
>    opposed to the goal of context transfer as a way to get timely
>    service without protracted renegotiations.  Maybe, in fact, it
>    should be the case that [seamoby] should explicitly declare that
>    highly reliable context transfer is "out of scope"!  I imagine
>    that more than a single retransmission won't be worthwhile.
>    [proof of (*): consider network partition or nuclear war]

No proof needed. Reliability is always a process of exponentially 
diminishing returns. 

We certainly did not mean to imply re-transmission, etc. Rather we
would like to leave the level of "transport reliability" to the network
engineers. 

And, as you indicate, data integrity is the real issue: it is likely more
harmful to deliver erroneous context then it is to fail to deliver the
information at all.

We will rework the text.

> 
> 7. I'd suggest adding the context transfer problem statement design
>    team members to the acknowledgements.  There was certainly a lot of
>    discussion on the mailing list from those folks, so I reckon they
>    did a lot of work shaping the form of this draft.  Intuitively,
>    the design team seems to have made a stronger contribution than
>    those who were explicitly mentioned, but I wasn't there so 
> I clearly
>    cannot say with any certainty.

Actually, this is not really correct, most of the concepts were developed
long before the creation of the design team. Having said this, this was a 
personal submission, and the contributors from the design team will 
be added to the authors list of the wg draft (we are deciding today if 
this draft forms the basis for the dt requirements draft).

> 
> 8. At the end of section 4.1, the last sentence refers to the number
>    of messages being less.  Less than what?  The sentence before is
>    missing a word after "simply".
> 
> 9. At the top of page 5, the word "appropriate" should probably be
>    "desired", because appropriateness would need a lot more 
> definition.

And desired does not?

> 
> 
> 
> Editorial:
> 
> "captured"         -->  "described"
> "sustain"          -->  "preserve"
> "rest of the ARs"  -->  "target ARs" (maybe worthwhile to put 
> in terminology)
> "ensure"           -->  "mean"    (in the paragraph preceding 
> the bullet item
>                                    about supporting reactive 
> context transfer

We'll have to look over the context of these changes.  For example,
I know the denotation of "sustain", and it fits perfectly; "preserve"
could be involve archiving the information.

> 
> In the sentence containing "cardinality between" -- perhaps
> you meant "correspondence between the number of".  There are
> some misspelled words, missing articles, missing parentheses,
> and syntax errors that need proofreading, which if need be I
> can type in later.  The text of the draft is too close both to
> the header and to the footers.

Thanks. You might want to look at the -01 draft before you do more
typing. Again, sorry for the confusion. Your comments will be useful
in producing the next revision. It is a work in progress.

Tally ho,
Gary

> Regards,
> Charlie P.