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

[Alfred Hönes <ah at TR-Sys.de>]

In the message archived at
  http://www.IETF.ORG/mail-archive/web/opsawg/current/msg00848.html,
Juergen Schoenwaelder wrote:

> On Fri, Oct 23, 2009 at 09:39:48PM +0200, RFC Errata System wrote:
>
>> The following errata report has been submitted for RFC5676,
>> "Definitions of Managed Objects for Mapping SYSLOG Messages to
>>  Simple Network Management Protocol (SNMP) Notifications".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Alfred Hoenes <ah at TR-Sys.de>
>
> ... [snip]
>
>> Section: 7, pg. 7
>>
>> Original Text
>> -------------
>>  SyslogTimeStamp ::= TEXTUAL-CONVENTION
>> !    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d"
>
> ... [snip] ...
>
>> Notes
>> -----
>> (a)
>>
>> Section 3.1 of RFC 2579 (on page 21) states, regarding numerical
>> conversion descriptor components in DISPLAY-HINTS:
>>
>>                [...]  For all types, when rendering a value, leading
>>    zeros are omitted, and for negative values, a minus sign is rendered
>>    immediately before the digits.  [...]
>>
>> Arguably, this means that substrings of OCTET STRING type are
>> interpreted as *signed* values (in network byte order).
>> Therefore, the range restriction for the 'year' part specified
>> informally in the DESCRIPTION clause does not make proper sense;
>> an upper bound of 65536 is nonsensical anyway since a 2-octet
>> substring cannot assme 65537 different values; to avoid issues
>> with different interpretation of RFC 2579, the 'safe' range
>> 0..32767 is recommended -- this should not be a serious restriction
>> in practice.
>
> Hm. The text you quote is the definition of 'd' for INTEGER typed
> DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET
> STRING types DISPLAY-HINTs, it is not really clear what RFC 2579
> intended. If your interpretation is right that numbers are signed,
> then we have similar problems in other documents, e.g. RFC 2579's
> definition of DateAndTime.

Returning to RFC 2579 and reconsidering the context,
a few observations should be made before progressing:

Unlike purists argue for RADIUS and DHCP, the SMI has peacefully
lived with the concept of structured data carried in OCTET STRING
objects, whithout seeing a need to formally define a new SMI data
type for each such, say, 'application layer data type'.
(Intrinsically that already has been inherited from X.208 / X.680.)

Therefore, it might be wise to precisely distinguish SMI layer
aspects from 'application layer' aspects considered out of scope
for the SMI, but keeping in mind that the latter preferably should
make use of general, standard SMI mechanisms as far as possible.


The data structures and types superimposed on OCTET STRINGs
via TEXTUAL-CONVENTIONs and defined otherwise in MIB module
specifications are essentially at the application layer, not
a matter of interest at the SMI layer.
Therefore, I see no conceptual problem of specifying signed or
unsigned integer values conceptually mapped into OCTET STRINGs
(or BCD data, 5-bit Baudot codes, or 7-bit SMS characters, packed
into OCTET STRINGs, or integer parts of seconds and fractional
parts of seconds mapped separately, whatever you need, btw!).
All that needs to be done at MIB module specification time is
providing unambiguous coding rules for interoperability
(e.g., "3-octet unsigned integer in network byte order").

So far, I believe, we do not have any problem now.


The second topic scratched at in the Errata Note deals with
the application of the SMI (RFC 2579) DISPLAY-HINT mechanism
to such 'application level' data types.

The precise specification of that generic mechanism is in the
domain of the SMI, as is the interpretation of the standard.
However, the DISPLAY-HINT mechanism needs to make some assumptions
on the binary patterns that shall be presented to humans; this
is easy for the 'fully specified' SMI data types, but it is much
less straightforward for structured data superimposed on OCTET
STRINGs, and arguably RFC 2579 has underspecified this aspect --
otherwise it would not be possible to give rise to different
interpretations, as it turns out now.

The other question indeed is the applicability of the mechanism
to a specific application, the restrictions to be adhered to in
order to make proper use of the mechanism for an 'application
data type', e.g. how to design such data types in a 'DISPLAY-HINT
friendly' manner.
Since this subject cannot be dealt with properly without a solid
foundation, we should first tackle the perceived ambiguity in
RFC 2579 before discussing the SMI user (application) layer details.
Therefore, I suggest to defer the discussion of the latter.


Thus, let's focus on Section 3.1 of RFC 2579 (p.21/22).

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.
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.
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.)

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.

Before performing any action, it would perhaps be useful to harvest
existing IETF and Vendor MIB modules for instances of data structures
superimposed on OCTET strings and observe the kind of integer values
(signed/unsigned) in these structures:
    a)  in general
(irrelevant for the issue at hand, hence for information only);
and (significant for the issue):
    b)  when the DISPLAY-HINT mechanism is also used for the
        respective objects.

I have neither enough spare time nor the (non-IETF) example material
at hand to perform this harvesting and therefore would like to
solicit input from vendors.


> ... [snip] ...
>
> I think more discussion is needed.
>
> /js


Yes, I tried to start it hereby.   :-)

>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+