RE: [Technical Errata Reported] RFC5176 (2012)

["Dave Nelson" <d.b.nelson@comcast.net>]

> yes.  But the danger here is that the NAS may not understand the
> attributes that are offering the alternate (limiting) service and
> would interpret the response as a full access-accept.

If the provisioning is via Service-Type, then NASes MUST treat provisioning
of an unrecognized / unsupported service as if the message were an
Access-Reject.  That's clearly stated and has been around long enough that
any NAS failing to enforce this behavior is *badly* broken.

> For this situation to work correctly the sender of the Access-Accept
> would have to know whether or not the Receiver has to means to
> recognize the response correctly.

For subsidiary attributes that further modify the Service-Type attribute,
this is true. There are recommendations that NASes ought to have a local
policy regarding treatment of such attributes, but there is no absolute
guarantee.  Service-Type is the only RADIUS attribute that is implicitly
"mandatory" in all implementations.

> This could be provided by a capability exchange for example.

I always thought that would be useful and the WG never seemed to agree. 



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