Subject: RE: [AAA-WG]: Extensibility model and IANA considerations

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Apr 2001 00:08:08 -0700

Bernard Aboba [mailto:[email-masked]] writes:

> >This discussion, though cogent, seems irrelevant.  Pat's
> assertion was that
> >the AVPs should be included (as optional) in the base because they were
> >needed by >1 extensions.  My argument is that they should not, for one
> >reason that they are _not_ optional for either of the extensions in
> >question.  It seems to me that the extensions would need to either modify
> >the base to state that the AVPs are mandatory or establish that
> while they
> >are technically optional, they are (non-explicitly) mandatory in their
> >contexts (wink, wink, nod, nod ;-).
>
> I think it makes sense to include AVPs in the base protocol that are
> used in more than one extension. However, as you point out, if they
> are mandatory in more than one extension, then they cannot be made
> optional in the base spec. If an AVP does not have the same status
> for all extensions, it seems to me that the base spec would
> need to specify the extensions for which the 'M' bit can be set.

But now (assuming that we do not, at this time, have knowledge of every
Diameter extension that will ever exist) we're back to updating the base
every time a new extension needs the 'M' bit set on an otherwise optional
AVP.

>
> >Yes, but more to the point of this discussion, what about AVPs that are
> >mandatory for some extensions (say, MIP & NASREQ) but optional (or even
> >superfluous) for others?
>
> I would propose that the base spec include a table specifying for each
> AVP and extension whether the 'M' bit may be set or not. Each new
> extension could also include such a table.

Ditto.

>
> >From a protocol POV, I'll admit that there is probably not a
> great reason.
> >However, fromm a specification POV, independently defined
> messages increase
> >the cohesion of the documents, while decreasing the coupling
> between them.
> >To use RFC 2867 as an example, in order to implement it a person needs to
> >understand RFCs 2865-2869, inclusive.  I would have _vastly_ preferred to
> >have defined the compulsory tunneling attributes independent of the base
> >RADIUS stuff, but the paucity of the RADIUS namespace prevented that.
>
> How did the paucity of attributes influence the design? In order to
> handle compulsory tunneling accounting, new accounting messages *were*
> defined, so this had some of the character of an "extension". Can you
> talk about the advantages and disadvantages of this approach?
>
> One thing that has occurred to me about RADIUS is that with new access
> types like VPN, the combination of NAS-Port-Type and the message in
> effect define an "extension": the semantics of the AVPs may change
> as a result. For example, if NAS-Port-Type = 802.11, there is no
> point sending a number of attributes that might make sense if
> NAS-Port-Type = Virtual.
>
> The nice thing about this is that these "extensions" can in effect
> be created without the need for any code changes, assuming that the
> RADIUS implementation has an extensible dictionary and supports
> conditional behavior. (For an example of conditional behavior in
> the ISC DHCP server, see Droms & Lemon's "DHCP Handbook").
>
> So if possible, I'd rather not move to a model in which DIAMETER
> server code updates are needed to support "extensions" that could
> have been implemented as dictionary additions under RADIUS. This
> seems like a step backward.
>
> >To put it another way, I would like to be able to take 2
> >documents and implement both the base protocol and _any_ given Diameter
> >extension, w/o needing to chase through a pile of essentially unrelated
> >stuff searching for the definition of the _one_ AVP I need from it.
>
> Well, I would say that it is ok to describe an AVP or messages in two
> places, if that would help, as long as the definition is the same. But
> creating new messages or AVPs that do the same thing as the old ones
> seems like a bad idea, because it requires unnecessary code changes.

I thought that we had decided that an extension by definition defines one or
more new messages.  Adding new AVPs (e.g., MIP-Acct-Octets-In and
NAS-Acct-Octets-In) instead of reusing a generic Acct-Octets-In AVP only
requires dictionary changes, no?

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 08:26:44 -0700 (PDT)

> this would seem to be the multiplicative intersection of two 'features',
> the base plus extensions approach, and mandatory extensions.

This is a non-issue. The new extension section in the base makes this much
clearer, and all that was required what non-protocol clarification text.

PatC

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Apr 2001 08:22:53 -0700

randy

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 7 Apr 2001 11:36:54 -0700

>the base plus extensions approach, and mandatory extensions.

This is the nightmare scenario. Let's not go there if at all possible.