RE: I-D ACTION:draft-ietf-radext-design-00.txt

["David B. Nelson" <dnelson@elbrysnetworks.com>]

I think this version is a step forward.  Thanks!  A couple of nits:

> Network Working Group                                     G. Weber
> INTERNET-DRAFT                                       Cisco Systems
> Category: Standards Track                         Alan DeKok (ed.)
>                                                         FreeRADIUS

Please note that this document is not Standards Track, it is intended as a
BCP (Best Current Practices).

>   The advice in this document applies to attributes used to encode
>   data.  RADIUS protocol changes, or specification of attributes that
>   can be used to provide new RADIUS commands (such as Service-Type) are
>   out of scope.

I think some further explanation of how values of the Service-Type
attribute, in particular, could be used to effectively create commands may
be in order.  More specifically, could we provide some guidance as to when
one has crossed the line into defining a "command" within an "attribute"?

> 2.1.3.  Complex Attribute Usage

This section explains why packing complex attributes into conventional
attributes (e.g. into sub-fields of a string data type) is disadvantageous.
It gives no advice to those who really want to do this, however.  What is
the "party line" here?  I know we have features in the Extended RADIUS
Attributes draft to address this.  Do we want to reference that document
here?   Do we have recommendations for those that want complex attributes
and don't want to use Extended Attributes?  Or is using the Extended
Attribute format the only recommended option?



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