[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
>[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
>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
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?
[gwz] What overhead? We're talking about 8 bits here...
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.