[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADIUS Design Guidelines
"Bernard Aboba" <Bernard_Aboba@hotmail.com> wrote:
> "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."
>
> Question: what would you define as "existing formats"?
For the most part, attribute contents currently defined in the
RFC's.
> For example, the following compound attributes are described in
> RFC 2865, 2868, 2869 and 3162. Note the similarity between
> RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix.
Yup. There is existing code to deal with those attributes, so
adding more attributes of the same "format" isn't a major change to
RADIUS.
Where those attributes require per-attribute special handling
(e.g. CHAP-Password), we should discourage new attributes of the same
format. But even for those cases, I think most of the existing "odd"
formats are so special purpose that no one will be defining new
standards based on them.
To iterate over the attributes you quoted:
> Section 5.3 CHAP-Password
I think the WG will reject any attempt to define new authentication
methods based on CHAP.
> Attributes utilizing a one-octet tag field:
Defining more tagged integers or strings will involve nothing more
than dictionary updates for most implementations.
> Section 5.5 ARAP-Features
I don't even know if anyone is using this. I do know many RADIUS
servers don't even support it, and the format is mostly an array of
values, which we could support through a slightly more complex data
model.
> 2.3 Framed-IPv6-Prefix
Many implementations have IPv6 prefixes as a data type, so adding
more isn't much of a problem.
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/>