Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928)

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Alfred Hnes" <ah at TR-Sys.de>
> To: <j.schoenwaelder at jacobs-university.de>; <opsawg at ietf.org>
> Cc: <ah at WOTAN.TR-Sys.de>
> Sent: Wednesday, October 28, 2009 9:27 AM
> Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928)
...
> The first part of that section -- almost all on p.21 -- mainly
> deals with the 'fully specified' SMI data types, where syntax and
> sematics are so narrow the DISPLAY-HINT is not needed and hence
> not permitted, and the presentation of those subcases of the
> INTEGER data type that do not have narrow semantics specified
> in the SMI.
> 
> The second part of the section extends from the bottom of p.21
> to the end of the section and deals with OCTET STRING conversions.
> Bullet (3) on p.22 discusses the display format characters in the
> DISPLAY-HINT string for OCTET-STRING objects, and refers to
> numeric format conversions; the only detailed rule given is:
> 
>                                                     If the octet
>    length part is greater than one, and the display format part refers
>    to a numeric format, then network-byte ordering (big-endian
>    encoding) is used interpreting the octets in the value.
> 
> That's why I always had concluded that the description of numeric
> conversions on page 21 was included here by reference, for all other
> relevant (yet herein unspecified) details, in particular the phrase
> quoted above, starting with "For all types, ...".
> This contains the assumption that the n-octet integer values to be
> converted were signed integers.

That was not the intent when the text was developed.  It is also worth
keeping in mind that since its inception DISPLAY-HINT has been recognized
as being a very limited facility.  That's one of the reasons why it is
so totally optional.

> As it has turned out, this interpretation is not shared universally,
> with the alternate assumption being that these n-octet integers
> must always be regarded as unsigned.

This is my recollection of the intent when the text was written.

> Most instances I recall ever having seen are uncritical because the
> valid range for the integer values is restricted by application
> semantics to the extent that the MSB is always 0, thus admitting
> both interpretations without any impact on their use.
> 
> (Ironically, related trouble has recurred in other places in the
> IETF, where specifications had not been explicit enough to state
> precisely whether particular protocol fields carry signed or
> unsigned integer values, and later protocol additions had to work
> around deployed implementations assuming either.)

In general, it's safest to assume that bit fields are unsigned unless
explicitly stated otherwise, the behaviour of some C compilers
notwithstanding.

> Apparently, the best solution would be to file a clarification
> for Section 3.1 of RFC 2579, as an Errata note, as well, in order
> to disambiguate the interpretation.  When this is done, collateral
> issues can be identified and resolved.

Agreed.
 
Randy