RE: Glen's proposal for Attribute Extension

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

Nelson, David <> scribbled on Friday, August 25, 2006 7:44 AM:

> Bernard Aboba writes...
> 
>> One of the motivations for this proposal was that it could be
>> implemented with no change to code on existing RADIUS servers,
>> because a single octet extended type was used, making it compatible
>> with the VSA format suggested in RFC 2865.
> 
> I think we need to explore the "no code change" assertion.  If we are
> limiting the discussion of changes to the RADIUS attribute parser
> code that looks at command code and attribute ID, then it's true that
> no changes, are required.  However, once the parser determines that
> its type 26, a second level of parsing is required.  The vendor OUI
> needs to be recognized as well as any vendor types.  Assuming (and
> this may be a big assumption) that your data dictionary driven
> implementation allows you to enroll new vendor OUIs and associate
> them with a list of vendor types, it may be possible to implement
> this suggestion without any code changes.         
> 
> I think that once you add the tag, some code changes likely to be
> required.  We are only discussing servers here.  I think we all agree
> that NASes and policy-enforcing proxies need to have code changes to
> encompass the semantics of the new attributes. 

OK. probably "minimal code changes" would be more accurate than "no code
changes".  However, the strength of the proposal remains, I think, in
that the features already exist in both clients and servers, just in
different combinations.
   
> 
>> Given that, why would the attribute type need to be changed?
> 
> One additional reason that I would like to see the VSA ID not used is
> that RFC 2865 permits free-format VSAs, notwithstanding the
> recommendation to re-use the basic TLV format.  

???  We are still talking about computers here, right?  If so, to the
best of my knowledge computers don't deal well with "free-form" ;-).
The formats of VSAs must be well defined, even if not standard.

> We need to retain
> that freedom for VSAs.  I would like to curtail that freedom for the
> Extended RADIUS Attributes, and mandate use of the basic TLV format,
> along with use of basic RADIUS data types.  

OK.
   
> 
> I think it's clear from the analysis in the Design Guidelines draft
> that the data models for VSA and standard attribute spaces have
> diverged.  I thought it was a goal of the WG to bring them back
> together for the extended attributes.  I don't think it would be very
> clear that the format restrictions apply only to VSAs with a
> particular OUI value.  

Well, I think that it would be as clear as we wanted to make it.  If we
publish an RFC that has "MUST" surrounding the formats, that seems
pretty clear to me.

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