[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Scope of applicability for CUI
At 11:16 AM 12/22/2004, Avi Lior wrote:
>...
>I think you don't understand how class works.
>The fundemental piece that you are missing is that the only entity that can
>draw any meaning out of the "Class" attribute is the entity that issued the
>"Class" attribute. This is well documented in 2865.
Since David has tutored me in subtleties of the Class attribute, I suspect he understands it better than most. I am still trying to catch up..
My reading of its specification in RFC 2865 (quoted in entirety below) is that the accounting server is expected to be able to extract meaning from the Class attribute sent to the NAS by the authentication server. Isn't it common practice for these to be different servers?
John
5.25. Class
Description
This Attribute is available to be sent by the server to the client
in an Access-Accept and SHOULD be sent unmodified by the client to
the accounting server as part of the Accounting-Request packet if
accounting is supported. The client MUST NOT interpret the
attribute locally.
A summary of the Class Attribute format is shown below. The fields
are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
25 for Class.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
--
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/>