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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Christian Vogt <mailto:christian.vogt@nomadiclab.com> allegedly
scribbled on Thursday, July 12, 2007 1:45 AM:

> Bernard Aboba wrote:
>> Given the potential widespread impact of attribute extension, the
>> RADEXT WG Chairs are requesting that the RADEXT WG and all other
>> affected WGs please review the following document:
>>
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-e
>> xtension-01.txt
> 
> Bernard and authors,
> 
> I reviewed draft-lior-radius-attribute-type-extension-01.  This
> document should become a WG document IMO.  I have three comments,
> though:  
> 
> (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.

> (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
> should be handled separately from the technical requirements -- and
> maybe in a completely different document as it could/should also
> affect the current extension type code space.     
> 
> (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.
  
> 
> Editorial remarks:
> 
> Section 2, 5th paragraph: s/NUST/MUST/

Done.

> 
> Section 5, 3rd example:  The value of the 3rd Extended Type field
> should be 27 rather than 25. 

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.

> 
> Kind regards,
> - 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/>