Proposed Resolution of Issue #318: REJECT

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

Alan DeKok said:

"This issue should be rejected.

  RADIUS specifications define format, meaning, interpretations, and
processing requirements for attributes.  Two implementations that
disagree about an attribute can inter-operate at the RADIUS level by
exchanging RADIUS packets.  They cannot be said have interoperable
implementations of the attribute."

Given that the Design Guidelines document has already been approved for
publication by the IESG, the bar for making changes is extremely high.  

In this case, that bar does not appear to have been reached. 

The assertion is that interoperability issues cannot be created by a 
mismatch of RADIUS data types and therefore that normative language
cannot be used. 

While it is possible for any RADIUS attribute to be expressed as a 
String of octets, configuration of attributes in Hex is both inconvenient
and error prone.  Moreover, if an attribute requires computation of any
kind, then a mismatch in the data type will result the data being 
misinterpreted, with unpredictable results. 

Therefore the text in question would appear to meet the RFC 2119 bar. 

The proposed resolution of Issue 318 is REJECT. 







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