RE: FW: HTTP digest and RADIUS; new version of the Sterman draft

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

Alan DeKok writes...

>   One of the reasons for writing standards in the IETF is so that
> other people don't.  As we've seen in a number of cases, non-IETF
> extensions to RADIUS involve *terrible* protocol design.

[DBN] Agreed. 

>   I'm sure many people will agree that defining sub-types in RADIUS is
> ugly.  But it's significantly less ugly than the choices made by
> non-IETF groups.

[DBN] Hmmm.  That may amount to damnation by means of faint praise.  :-)

>   The single largest reason for defining sub-types is not to make our
> life easier when writing new I-D's for RADIUS.  It's to give other
> people a standard way of extending RADIUS, and thus to make our life
> easier when we have to implement their modifications to the protocol.

[DBN] My personal opinion on this is that the sub-types are not in any
technical way necessary in any of these current proposals.   The
authors, working outside of IETF supervision, have created, implemented,
and in some cases deployed, these extensions using sub-types.  My
further opinion is that much of the argument in favor of sub-types is
seeking to protect existing implementations from IETF WG change control.

There may, in fact, be some merit to a variation of your suggestion.  I
have thought about the notion of SDO-Specific RADIUS Attributes (SSAs).
These would be structured similarly to the VSAs, but with the
requirement of a single layer of sub-attributes, reflecting standard
RADIUS attribute format within the value field of an SSA, promoted to a
MUST.  This would allow SDOs to create RADIUS attributes within their
"vendor ID" space.  In addition, there should be some formal protocol
quality review process, similar to the "MIB Doctors" used to review new
MIBs.  All of this would not help the current debate, however, as
"grouped" sub-types would still be prohibited.  But it might be of great
utility for future discussions.

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