[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-radext-design-00.txt
David B. Nelson wrote:
>> 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"?
Suggested text?
Most new "commands" would be strongly discouraged, I think.
>> 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.
"Don't". Unless, of course, you're packing an existing data structure
as-is. i.e. using RADIUS as a transport.
> 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?
Yes.
> Do we have recommendations for those that want complex attributes
> and don't want to use Extended Attributes?
They should stop trying to create hacks.
> Or is using the Extended
> Attribute format the only recommended option?
If the extended attribute format is insufficient, the strong
recommendation is that you're doing something wrong.
i.e. trying to pack existing complex data structures into RADIUS
attributes. Trying to use RADIUS as an application-aware transport, etc.
I'll send another message with a proposed checklist of what to do, and
what not to do.
Alan DeKok.
--
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/>