[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-radext-design-00.txt
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.)
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.