RE: [RADIUS FIXES] Authorize Only / RADIUS layering criteria

[<Pasi.Eronen@nokia.com>]

Emile van Bergen wrote:
> 
> Let's take the example of Class for simplicity, supposing for a
> moment that it isn't already defined. The generic opaque
> attribute that SHOULD be echoed by the NAS would be defined by
> a RADIUS extension RFC, and be available for use in any
> application that requires an attribute with those external
> semantics. The upgrade from SHOULD to MUST would require an
> upgrade to the core RADIUS RFC.
> 
> The RADIUS extension RFC defining Class could suggest its use
> as a billing item reference or similar uses. However, it should
> not enumerate or limit future applications, or put constraints
> on its value, when not required for its basic definition ('an
> attribute whose contents are copied from access accept to
> subsequent accounting request').

I disagree about this, to some degree at least. If we have two
different "applications" that use an attribute for two quite
distinct purposes, IMHO they should define two separate
attributes.

The current approach of reusing the same attribute number for
different purposes is there basically only because getting a new
attribute number has been difficult (and using a "vendor-specific" 
number has a stigma attached to it, although many attributes with 
"vendor-specific" numbers are not really specific to any vendor 
but instead widely used...)

Class is actually a good example here: It is defined as an
attribute that MUST NOT be interpreted by the client (implying
that the server can put anything it wants there). But people are
anyway using it to carry things that the client _does_ somehow
interprete (e.g., some semi-permanent identifier for the
subscriber in roaming cases). Thus, the server can't anymore
follow the original "put whatever I want there"; the contents 
has to be in line with what the client's expectations. 

(And in this case, there is progress towards defining a separate
attribute, Chargeable-User-Identity...)

Best regards,
Pasi

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