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

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> [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?  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?



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