Subject: RE: [seamoby] Yet Another BOF?

From: "Gary Kenward" <[email-masked]>
Date: Thu, 1 Mar 2001 13:42:32 -0500

It's just my perception Scott, but it seems like the response to any
identified requirement is "well, we can make MIP do that"....

Gary

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 4:03 PM
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [seamoby] Yet Another BOF?
> 
> 
> anything that includes the text "That excludes vanilla MIP as 
> a solution"
> does not look like a requirements discusison to me 
> 
> why is it so hard to discuss what the actual requirents are without
> talking about solutions?
> 
> Scott
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 01 Mar 2001 12:09:30 -0800

Hello Gary,

That's an interesting statement.  You might apply it to
other protocols to figure out:

"well, we can make SIP do that"
"well, we can make RADIUS do that"
"well, we can make PPP do that"

Mobile IP is supposed to be pretty simple, all in all,
just a way to associate a routing address to an identifying
address as needed.  Now [seamoby-mm] is presumably going to
make some protocol that enables local routability with
better latency characteristics, in addition to the global
association managed by ("unadorned") Mobile IP.  Or,
perhaps instead of, but I don't see so much why the latter.

But, as the success of IP proves, network-layer addressing
is so powerful that it is easy to imagine ways to fiddle
with it and get a lot of cool results.

Thus, it is easy to understand
"well, we can make Mobile IP do that"...
And I don't think it's necessarily an
unfortunate thing that people are thinking
about such things.  But, on the other hand,
it's important to avoid protocol bloat and
unnecessary requirements.  To me that just
means that good engineering is required.

Regards,
Charlie P.

> Gary Kenward wrote:

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 30 Mar 2001 13:57:27 -0800

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.

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".

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

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.

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

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]

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.

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.

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

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.

Regards,
Charlie P.