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

["Glen Zorn" <glenzorn@comcast.net>]

>[gwz] You must be a better fortuneteller than I, because I usually find it
>difficult to predict the future uses of a new thing (e.g., whether it would
>be useful someday to add a certain attribute to a group).  I would prefer 
>to
>say that if you _know_ for a fact that the new attribute a) is standalone &
>will never be included in a group and b) it is not possible for it ever to
>take a value that would be longer than 253 octets (i.e., an integer), then
>use the existing standard attribute space, otherwise use the extended 
>space.

Wouldn't the ability to be placed within a group need to be deifned at the 
time that the attribute is defined?  
[gwz] 
[gwz] Why?

If the attribute isn't defined to use 
grouping, why would it be allocated within the extended space?

>[gwz] Apparently you guys know what you're talking about but I sure don't:
>AFAIK, Prrivate Enterprise Numbers have nothing to do with standard RADIUS
>attributes.  Are you suggesting that there should be _two_ new attribute
>formats, one w/a Tag, etc. & the other without?  Why?

If an attribute is one which doesn't satisfy the above criteria (e.g. a 
uint32 or uint64), and therefore doesn't need to be grouped, why should the 
attribute be forced to take on the additional overhead?
[gwz] 
[gwz] What overhead?  We're talking about 8 bits here...



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