Re: Rationalizing the RADIUS data model

[Jari Arkko <jari.arkko@piuha.net>]

Nelson, David wrote:

> That is the $64,000 question.  In rationalizing the data models, one
> assumes we mean that the same data models will be usable for VSA, SSA,
> and potentially IETF-Extended-Attributes (IEA??).  Whether the set of
> "universal" data format rules (the rationalized data model) is as
> loosely defined, and as subject to liberal interpretation by
> implementers, as the current rules for VSAs will be the crux of the
> discussion on this subject, I rather suspect.

Yes.

> One possible approach is the definition of a unified data model that is
> more flexible than the current standard data types defined in RFC 2865,
> but less flexible than the current VSA rules.  VSAs could still use the
> original, loose VSA data model, but if there is an expectation that a
> VSA might be promoted to an SSA or standard attribute, the developer
> would be constrained to use the new universal data model.

I may not have anything better to suggest, but I would
note that there are still two problems with the above:

o  People's predictions of the fate of their small
   extensions are often bad; a lot of stuff that got
   developed as a private extension is still with us
   today.

o  Long-term, a model where the vendor-specific mechanisms
   are "better" (at least in perception or ease) than
   standard mechanisms does not encourage standardization.
   This could lead to important extensions defined by
   dominant vendors and industry consortiums.

But lets talk about the specifics. What, exactly, is the
current problem? Clearly, we have been impacted by the
small attribute space. This can be solved. What else?
Limited set of basic data types, lack of IPv6 address
for instance. This can be solved too, and I think we
can find consensus on these issues.

Structured data within an octet string, subfields in text
strings, subattributes? There's probably more to discuss
there. Personally, I think text strings will always have
some form of subfields. I would rather not have structured
data as "records", but subattributes might be doable,
particularly if they could be mapped to grouped AVPs
in Diameter. The rest could then be labeled as an
octet string; is there a reason why this type of a
model could not be adopted as _the_ model, for all
attributes?

--Jari

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>