Re: FW: ISSUE: Inappropriate usage of RFC 2119 key words

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:
> The section of the draft in question says:
> 
>    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 implementors where the method is not required for
> interoperability".

  I welcome suggestions for how implementations can *meaningfully*
interoperate when they have different interpretations for an attribute.

  i.e. one defines an attribute to be "signed 24-bit integer counter,
little endian", and the other doesn't support that data type.

  None of the meanings of the novel integer type (e.g. counter) can be
used by the second implementation.  It can only treat the field as
"string of undistinguished octets".

  Therefore, they cannot be said to inter-operate according to the
definition of the attribute.

  The alternative is to interpret "inter-operate" as "sends / receives
opaque data without agreeing on the format, meaning, or processing of
that data".  If that is our definition of the word, then we can say that
DHCP inter-operates with RADIUS.  And the term loses all meaning.

> Requested change:
> Since the only rationale offered for the prohibition is the spurious one of
> avoiding code changes (something that is certainly implementation-specific),
> the section should be removed altogether.

  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.

  Alan DeKok.

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