Subject: Re: Choice of Data Model SMI vs XML vs. UML

From: David Spence <[email-masked]>
Date: Tue, 09 Jan 2001 19:49:14 -0500

Erik Guttman wrote:
>... 
> Why can't we standarize DIAMETER (its current informal spec) and later
> model it with SMIng?  If we find errors in the spec, we can cycle
> it in the standards process.  I think this would be a useful endeavor.
> Once SMIng notation is standardized, we could begin this process of
> rewriting the DIAMETER specification with the goal of improving it.
>...

Question:  What if the SMIng model were more restrictive than the original
DIAMETER standard?  In other words, what if the SMIng model prohibited
message contents that the pre-SMIng DIAMETER standard allowed (but were
either nonsensical or at least ambiguous) -- like including the
Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message? 
It would be good to avoid having to make incompatible changes like that.

Would it make any sense to standardize part of DIAMETER now, like the base
protocol and Mobile IP extensions, without data modeling, but delay
standardizing the NASREQ extensions until the NASREQ data elements can be
modeled?  I'm thinking that with NASREQ, we have less time pressure (because
of the existence of RADIUS), and so the successor to RADIUS should provide
the best platform for future expansion that we can.  It may be argued that
the NASREQ application is simple enough that data modeling is unnecessary,
but I fear that won't always be the case.  You ought to be able to encompass
more services in the future, such as DSL, broadband, and LAN access. 
Without data modeling, things are going to get really messy.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Jan 2001 20:17:06 -0800

> Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message?

In this case, the model would be broken. AFAIK, it is neither nonsensical
nor ambiguous to include both the Framed-IPX-Network and
Framed-AppleTalk-Network AVPs in the same message, since PPP can carry both
(and IP, too!) simultaneously.

> It would be good to avoid having to make incompatible changes like that.

Since the history of SNMP is one of incompatible changes, I fail to see why
anything should change now ;-)

> of the existence of RADIUS),

The reason for the inception of this effort (some 4 years ago) was the
inadequacy of RADIUS.  I can't see how the situation has improved.

> and so the successor to RADIUS should provide

In the future?  RADIUS (or bizarre, usually proprietary, variants thereof)
is being used for these things (and more) right now.

> Without data modeling, things are going to get really messy.

They already have, some time ago.  We _do not_ need to spend another three
years blathering about silver bullets.

---

From: David Spence <[email-masked]>
Date: Wed, 10 Jan 2001 12:56:43 -0500

> is being used for these things (and more) right now.

Precisely!  But not in a standard way.  And while it isn't in our charter to
standardize those things now, we are creating the framework within which
future standardization will proceed.  The point was that the supposed
simplicity of RADIUS cannot be used as an argument that data modeling is not
necessary. 

> years blathering about silver bullets.

Agreed.