RE: Guidelines Document Discussion

["Avi Lior" <avi@bridgewatersystems.com>]

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Monday, April 09, 2007 2:55 PM
To: Avi Lior; aland@nitros9.org
Cc: radiusext@ops.ietf.org
Subject: RE: Guidelines Document Discussion

>[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO 
>will always need to create their own VSAs.  We are starting to see 
>convergences in the Wireless/Wireline networks and it would be nice if 
>SDOs attributes would interoperate or at least it should be easy to 
>translate between SDOs.

This seems like it might be an achievable goal.  The RFC 2865
recommended VSA format has caused some problems because of its
limitations (8-bit type
space) and lack of treatment as opaque octets (the Diameter/RADIUS 
translation problem in RFC 4005).   If we address the limitations, and
make 
it clear that following the recommendation is not required and cannot be
assumed by implementations, then this can work.

[avi] Good.

>If I have an enumeration (of TRUE or FALSE) using a 32-bit value is 
>wasteful in view of the size limitation of both attributes and packet 
>size.

Are you saying that the VSA space should allow one octet or two octet
data types?

[Avi] Why not?  Certainly in structured types this is very useful.  In
the past when working in SDO space I had lots of questions as to why are
we using a 32-bit value for an enumeration of true or false.

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