[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on RADIUS Extended attributes
I know that a couple of people stated that preference on the list recently,
but without any technical justification.
I think there may have been some concern about compatibility with existing
RADIUS servers, since the format proposed in the Lior & Li draft utilized a
larger Extended-Type field (32 bits) than was suggested for the VSA format
in RFC 2865.
Is it really necessary to do more than double the number of standard
attributes? That is what the >VSA approach would do, without requiring
code changes...
I think the implicit assumption here is that the VSA approach (Vendor-Id of
0) would utilize the VSA format described in RFC 2865 (single octet Type
field). However, the Lior & Li proposal was for a larger Extended-Type
space, and I presume that this would require code changes.
In combination with the tagging scheme (or something very similar) you
mentioned in a recent >message, the "VSA Zero" approach solves this
problem, as well.
RFC 2865 states that more than one vendor-specific attribute can be included
within a RADIUS attribute of Type 26. However, I don't think it describes
how vendor-specific attributes can be split across RADIUS attributes of Type
26. One way to address this is via a tagging scheme. I think the question
is whether we'd want to *require* tags in each Extended attribute, or not.
--
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/>