RE: Potential work items

["Nelson, David" <dnelson@enterasys.com>]

Mike Bean writes...

> We have code in our RADIUS server that parses many structured RADIUS
> attribute types, some RFC, most VSA.

VSAs are fine... for what VSAs were intended for.  I have worked on
RADIUS Servers that parsed VSAs, too.  

> I understand that this group does not want to add new attribute types
to
> the RADIUS standard; however, since 3GPP2 standards have been adopted
and
> require RADIUS support for sub-type values, it may be helpful to write
an
> informational RFC that describes the use of sub-types in a RADIUS
> attribute.

IMHO, it is unfortunate if 3GPP2 has standardized use of RADIUS
attributes that substantially "bend" the well-accepted RADIUS
architecture.  Having done so, the debate is over how to "promote" these
VSAs into some form of standards or multi-vendor status.  Like it or
not, the standard RADIUS attribute space is "flat".

> Perhaps IS-835 and IS-878 can be changed to flatten these sub-type
> attributes into separate attributes.

That would probably be my preference, but I haven't seen the documents
you reference.

> My concern is it may be too late...

Too late because the implementers have shipped product and don't want to
go back and re-implement, in an effort to move into an IETF
standards-based arena?  I've heard the argument that the closure of the
IETF RADIUS WG created an "open season" for other SDOs to revise the
RADIUS architecture, but I just don't buy it.

> ...providing additional information on how sub-type attributes are
used
> can only help developers.

Help developers to continue to "make the same mistakes"?  Sorry for what
might be perceived as a cheap shot, but IMHO use of sub-types in non-VSA
attributes is a mistake. 

> I suspect most vendors supporting 3GPP2 in their
> RADIUS server have already written code to support at least the
display of
> sub-type attributes.  My two cents.

I suppose you are correct.  Is this a case of the de-facto standard
forcing the hand of the de-jure standard development?

Thanks for your contribution to the discussion.  I don't know how this
will come out, but having more concrete data helps.

-- Dave



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