[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt
Glen:
>> (1) I was wondering why a RADIUS extended attribute needs its own
>> length field.
>
> Because, like standard VSAs, more than one extended sub-attribute can
> be packed into a single attribute. We probably need to point this
> out specifically & include an example.
Yes, making that clear would be good. Readers might wonder otherwise.
>> (2) The 3rd requirement listed in section 2, which states that
>> inappropriate use of extension type codes by vendors should be
>> eliminated, seems to be an administrative/policy issue.
>
> Except that it doesn't say that. What it says is that the extended
> attribute scheme must be unaffected by this poaching of the standard
> attribute type space; our proposal achieves that by making the new
> extended type space a part of the existing VSA space instead of
> taking one of the (supposedly) unassigned numbers from the standard
> type space.
Maybe this design decision should be clarified in the document a bit as
well.
>> (3) The Length field of a RADIUS extended attribute is specified
>> as
>>> = 4 according to section 4. I would recommend to relax this to
>>>> =
>> 3, since the relaxation would allow for attributes without a value
>> -- such as indications that are communicated by only the presence
>> of an attribute, not a particular attribute value.
>
> This would violate RFC 2865.
OK.
[...]
> No, the third attribute is a continuation of the second; they are
> both strings, which have arbitrarily been assigned the extended type
> of 25 (there are 2 attributes because the string won't fit in one).
> The example could use a bit of clarification, though.
Yes, thanks.
- Christian
--
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/>