Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt

[Christian Vogt <christian.vogt@nomadiclab.com>]

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/>