|
Glen Zorn said: > It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits, attributes using signed integer data types or > unsigned integer types of other sizes will require code changes, and > SHOULD be avoided. > > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes; indeed, this appears to be a > classic case of the use of RFC 2119 keywords to "try to impose a particular > method on implementers where the method is not required for > interoperability". The issue being described here is not one between RADIUS clients and servers that implement the attribute, but rather between a RADIUS client that implements the attribute and a RADIUS server that does not support the attribute or the new type. If instead of using an unsigned 32 bit integer, an 8, 16 or 24 bit integer is used or a signed integer, then existing RADIUS servers will not be able to support the newly defined data type without a code change. While existing RADIUS servers could send the newly defined types as a String, this would force network administrators to enter the attributes in hex form. This would be likely to cause errors in configuration, particularly in the case of signed integers. However, an issue has been raised about whether RADIUS does in fact support 64-bit integers, or whether the data types used in previous attributes were either special types (e.g. Interface ID) or 64-bit octet strings. If WG consensus is that RADIUS does not today support 64-bit integers, the choices would be as follows: 1. Recommend the addition of the 64-bit integer data type to implementations; 2. Remove the reference to 64-bit integers in the above paragraph. |