RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"

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

Alan DeKok writes...
 
>   Yes, though this document simply re-uses the existing standards
> track type defined in 3162.

There are several examples of new data formats, generally speaking
complex or compound data types, that appear in RADIUS RFCs, both
Standards Track and Informational, that were published after the close
of the RADIUS WG and before the chartering of the RADEXT WG.  I have no
idea how much review and comment each of these documents received by the
IESG and the IETF at large.  Certainly, there was no attribute design
guideline at the time, and probably no designated expert to review
proposed attributes.

It is important to document these practices in the RADIUS Attribute
Design Guidelines draft.  We need to recognize their existence, and
therefore their validity.  I also believe that we want to strongly
discourage further use of "novel" attribute formats, in any new work.

It is important that the RADIUS Attribute Design Guidelines draft,
coupled with the RADIUS Extended Attribute draft, cover all of the needs
for attribute data modeling.  If an important data type is missing, or
cannot be created as derived a data type in a straightforward fashion,
then that shortcoming needs to be addressed in the these two documents.

I would stop short of saying that any "novel" attribute formats that
have been published in any given RADIUS RFC since the closing of the
RADIUS WG should be considered suitable for new design.

>   I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward.  The
> practice should be discouraged, but not forbidden.

Well, as a BCP, the RADIUS Attribute Design Guidelines cannot actually
*forbid* anything, but I think the discouragement for creating (or
re-using) "novel" formats not included in RFC 2865, the RADIUS Attribute
Design Guidelines or the RADIUS Extended Attribute documents should be
very strong indeed.  The desire is to prevent a fragmentation of the
RADIUS attribute data model, such as it is, into some form of Tower of
Babel, at least going forward. 

>   Therefore, I have no objections to this format, or this document.

Given that we are attempting to quickly address an issue with existing
usages (a la RFC 3162) it may be acceptable to re-use that attribute
format in this draft.  I would not support a general grandfathering of
all such attribute formats for new work, including many of the existing
RADEXT WG work items.


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