RE: RADEXT charter for comment...

["Nelson, David" <dnelson@enterasys.com>]

Barney Wolff writes...

> Yes, but how does changing the sub-Type field from 1 byte to 14 bits
and
> adding a couple of flags not require a code change?  Am I missing
> something obvious?

I think that you are right, Barney.  Adding these features would impact
the parsing code, somewhere, somehow.

I'd like to suggest an alternate way to introduce the Mandatory bit
feature in a RADIUS extension.  We could define a new attribute, called
the Mandatory attribute.  This attribute could be used to "flag" the
other attributes in a RADIUS datagram that are considered mandatory.
This could be done in one of two ways.  The Mandatory attribute could
share a common Tag with the attributes considered mandatory, or it could
include in the data portion of the attribute a list of all the attribute
type codes considered mandatory.

I think this approach was briefly considered in the early pre AAA WG
days, when proposals for extending and "fixing" RADIUS were first being
debated.  While this approach is far less elegant than the Mandatory
bit, it had the advantage of not changing the attribute AVP header
format.

Of course, any logic to implement the mandatory nature of any attribute
will require new code in RADIUS implementations, since this is a
policy-level behavioral issue.  I don't think there is any way to add
this feature to a NAS solely in a data dictionary driven fashion, at
least without some initial code changes to provide that support.  But
that is true of any new attribute with new semantics, at least in RADIUS
client implementations, so there is fine line to this "no code changes"
debate.  I think we could say "no code changes to the attribute parser",
and that would support the requirement to preserve existing data
dictionary driven implementations.

Adding support for new semantics, for example an attribute specifying
some QoS parameter, is obviously going to require new code somewhere in
the NAS.  Whether you consider that "enforcement" code part of the
RADIUS implementation is probably a matter of your particular design
decisions and code modularity structure.

-- Dave


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