[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Technical Errata Reported] RFC5176 (2012)
> 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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.