RE: [RADIUS FIXES] Authorize Only / RADIUS layering

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

So, let me take a moment to address RADIUS layering in a pro-active
fashion.

It is certainly appropriate to have layering of one application upon the
services provided by another.  We need to address this general
architectural concept within the constraints of RADIUS as it exists, and
the charter of the RADEXT WG.

RADEXT is not chartered to make major or substantial architectural
changes to RADIUS.  For example, introducing layering akin to the base /
application layering in Diameter is certainly out of scope.

It would, generally speaking, be appropriate for RADEXT to consider
standardization of new attributes for the provisioning of existing,
well-defined services that exist on the NAS.  Traditionally, these
attributes have used the data types defined in RFC 2865 and have been
transparent to the RADIUS protocol engines, in both clients and servers.
The vast majority of existing RADIUS attributes is acted upon by
application layer software outside the scope of the RADIUS protocol
engine, and its associated support and management components. So
layering does already exist, to this extent.

The specific practice that I'm suggesting is undesirable is the
definition of new RADIUS attributes, and their basic semantic
descriptions, in RFCs defining the applications, rather than in
[companion] RADIUS extensions RFCs.  That does not mean that the I-Ds
for such RADIUS extensions need to be work items for the RADEXT WG.
They could be work items for other IETF WGs (or conceptually even other
SDOs), with concurrent review and WG Last Calls in RADEXT and the other
WG(s).   In any event, the collection of IETF standard attributes
(anything other than VSAs) should be treated as a consistent body of
work, and be considered as elements of the RADIUS protocol.

RADIUS does not have a formal language that would allow the independent
publication of data objects, much as we have MIBs for SNMP and PIBs for
COPS.



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