Subject: [mobile-ip] AAA/QOS in MIP and SeaMoby

From: [email-masked]
Date: Thu, 8 Mar 2001 10:44:26 -0600

I know this message will be perceived by some as flame bait.  I don't
want it to be.  Please don't flame me.  I have a very basic question
about the MIP and SeaMoby charters.  Why do things that are clearly
operational and that are client server in nature get included into a
routing or transport WG such as MIP or SeaMoby?

Why can't AAA server specific stuff be done somewhere else like say
a AAA group?  Tying AAA specifically to a particular macromobility
implementation seems like a very bad design approach to me.
It seems like it is being done to placate particular vendors' interests
to me.

The QoS argument holds a bit more water than AAA.  Mixing stuff into
the MIP group seems to defocus the routing aspects and muddy up the
AAA and QoS aspects a bit.  Ultimately, it seems MIP should be
absorbed into IP anyway and that should be the ultimate design goal
i.e. making MIP go away, so hanging ornaments on it is just going
to prolong our agony in making it go away.

In general I don't think the router fabric for the global Internet should be
tied so much to the penchants of 3G vendors or operators.

Thanks,

Phil Neumiller

---

From: Michael Thomas <[email-masked]>
Date: Thu, 8 Mar 2001 15:57:21 -0800 (PST)

Phil,

Even though I've been one of the prime agitators
for paying attention to QoS and network/QoS
admission control, I do not think that SEAMOBY or
MIP should not be a vast catch basin for every
problem remotely related to mobility. In
particular, I have a lot of trepidation in MIP
about the assumption that AAA ought to be the
ultimate answer (or even first choice) for key
distribution problems when things are mobile. This
is a case where the problem should have been
defined, but probably tossed over the wall to CAT
or IPsec or even AAA to see how they could (if at
all) meet the requirements for MIP.

What I do think is useful for SEAMOBY and MIP is
to:

1) Investigate what the actual problems are
   related to enabling AAA and QoS
2) Deal with the problems that are clearly
   within the purview of MIP or SEAMOBY
3) Make our case to the relevant working
   groups if extensions/fixes are needed to
   play well with mobility
4) Start new working groups if the problems
   are outside of anybody's scope but are still
   important.

We need to start somewhere with (1), and I believe
that MIP and SEAMOBY have it in their charters to
figure out what it means. But that doesn't
necessarily mean that once you figure out what
it means that you have to claim ownership of it.

Modularity is our friend, hopefully.

	      Mike