Subject: RE: on the point of mobility & multihoming

From: <[email-masked]>
Date: Thu, 4 Mar 2004 14:28:30 +0200

Dave,

> jlnc> So a requirement that a multi6 solution must not break
> jlnc> mobility (MIPv6?) would be sufficient?
> 
> as for my own perspective, no, this would not be enough.
> 
> the infrastructure approach that is the basis for mipv6 has some
> serious deployment and use challenges.
> 
> more directly, it looks quite reasonable to use a single, rather
> small, set of mechanisms and solve substantial portions of both
> problem spaces.
> 
> it is by no means sure that this will actually work.  the problem is
> that the possibility that it _will_) work is not very much part of the
> discussion, yet it should be.  the potential benefits of a common
> mechanism are too large to ignore.

I still worry about feature-creep in Multi6.  Should a multi6 be
a floor polish & a desert topping?  

John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2004 21:37:04 +0900

[ post by non-subscriber.  with the massive amount of spam, it is easy to
miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

john,

jlnc> Dave,

jlnc> I still worry about feature-creep in Multi6.  Should a multi6 be
jlnc> a floor polish & a desert topping?

only if you want to lick the floor.

but seriously, you cannot imagine how much I share your concern for
feature creep.

what i've discovered in this topic is an equal fear of the potential
to have too much redundant, and possibly conflicting, mechanism,
because related problems were not solved with common mechanism.

but, yes, the mantra of: timely, simple, useful
is paramount.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2004 22:33:34 +0900

John;
 
> a floor polish & a desert topping?

That happened with IPv6 by collective half-wisdoms.

It often occurs when chairs waste time on discussions of
abstract nonsenses.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Mar 2004 10:17:01 +0100

It's to avoid featurism that RFC 3582 describes "goals" not "requirements"
and that Eliot's draft describes "things to think about." When we have a
complete architectural analysis, I hope we will be able to extract from
that what are the necessary and sufficient components of a solution,
and stop there.

   Brian