Subtypes

[Nagi <Nagi_Reddy.Jonnala@alcatel.be>]

Chnaged the subject line from:  RE: FW: HTTP digest and RADIUS; new version
of the Sterman draft


> So are you saying that it's OK to treat a sub-class of RADIUS standard
> attributes as if they were VSAs, in that only RADIUS product from
> certain vendors who choose to support this functionality need to be able
> to parse the attributes?

It is OK to treat a sub-class of stabdard attributes as if they are not
relevant for this implementation. There are plenty of standard attributes
and one can't expect each and every implementation to support all of them.
Take for example, a Radius client implementation which doesn't understand
EAP messages. Let us say for instance, a malfunctioned Radius server
sending a EAP message to the non-EAP compliant Radius client as part of
Access-Accept. What do we expect from a Radius client?

- Just ignore the attribute and continue with the access-accept.
- Since it doesn't understand a standard attribute, it has to treat it as a
access-reject.

Ofcourse I vote for the first.


> I think an attribute is either of limited scope of application (a VSA),
> or it is of general applicability and all
> RADIUS implementations SHOULD understand it.

If it is not relevant for the implementation, it may ignore.

regards
Nagi.





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