RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

John,

You must have snoozed at the point of the lesson.

"Acounting Server" that is in the same adminsirative domain as the issuer of
the Class.

The Accounting Server could be the RADIUS Server or not.  But because it is
in the same realm it therefore it knows what is in the Class.

I don't know about common practice -- but I don't think that is germain to
how class works.

Does that help?

Avi

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com] 
> Sent: Wednesday, December 22, 2004 1:45 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: 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/>