Re: Rationalizing the RADIUS data model

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

Hi Barney,

> I would strongly protest any move to make arbitrarily-formatted vendor-
> specific attributes retroactively prohibited.  There is absolutely no

I agree.

> justification for any such move.  If you wish to contrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.

Right. This was, more or less, what I proposed.

Let me first say a few words about why I think a new VSA/SDO/Std area
would make sense. Clearly, we have an attribute number and datatype
insufficiency problem, which could be solved this way.

You may then ask, why create yet another VSA space, isn't the current
one already enough? The answer to this is more complicated, but it
has to do with three things:

   o  A well-defined data model is beneficial for everyone.

   o  Making it possible to enforce the new data type & processing rules
      for the area, without making old VSAs illegal or cause
      protocol failures.

   o  Making it possible to easily move vendor- or SDO-originated
      enhancements into the standard space. This may not be obvious,
      people could argue that as a part of such move you can make
      modifications. But, as we have seen, such modifications are
      often painful, and this would continue to hurt standardization
      in the field.

Finally, lets talk about what to do specification & status wise
for the old VSA format, should we adopt something like what I
proposed. I think the options are as follows:

   1. Make it illegal, i.e., MUST NOT use. Equipment that gets
      updated would suddenly stop working when someone sends
      it an old format VSA. We clearly don't want this.

   2. Keep it as it is, no change in behaviour or status.

   3. Make the use of the old format a SHOULD NOT for new attributes.

      Possibly combined with some status change of the old format,
      maybe "historic".

   4. Make the use of the old format a MUST NOT for new attributes.
      This may be too strong as well.

So, I think we want something along the lines of 2 or 3. Personally,
I would go for a "SHOULD NOT".

--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/>