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

[RFC Errata System <[e-mail]>]

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 <[e-mail]>

Section: 7, pg. 7

Original Text
-------------
 SyslogTimeStamp ::= TEXTUAL-CONVENTION
!    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d"
     STATUS       current
     DESCRIPTION
        "A date-time specification.  This type is similar to the
         DateAndTime type defined in the SNMPv2-TC, except the
         subsecond granulation is microseconds instead of
         deciseconds and a zero-length string can be used
         to indicate a missing value.

         field  octets  contents                  range
         -----  ------  --------                  -----
|          1      1-2   year*                     0..65536
           2       3    month                     1..12
           3       4    day                       1..31
           4       5    hour                      0..23
           5       6    minutes                   0..59
           6       7    seconds                   0..60
                        (use 60 for leap-second)
!          7     8-10   microseconds*             0..999999
           8      11    direction from UTC        '+' / '-'
           9      12    hours from UTC*           0..13
          10      13    minutes from UTC          0..59

         * Notes:
         - the value of year is in network-byte order
|        - the value of microseconds is in network-byte order
         - daylight saving time in New Zealand is +13

         For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
         displayed as:

                         1992-5-26,13:30:15.0,-4:0

         Note that if only local time is known, then timezone
         information (fields 11-13) is not present."
     SYNTAX      OCTET STRING (SIZE (0 | 10 | 13))


Corrected Text
--------------
(a)  upper part of the table:

         field  octets  contents                  range
         -----  ------  --------                  -----
|          1      1-2   year*                     0..32767
           ...

(b)  "*Notes:" part:

<< see Notes below -- one possibility to address the issue is
   amending the text as follows; verifiers might do better >> 

         * Notes:
         - the value of year is in network-byte order
|        - the value of microseconds is in network-byte order;
|          users of network management applications following
|          the DISPLAY-HINT specified above should be aware of
|          the unusual appearance of the apparent 'fractional part'
|          displayed: RFC 2579 requires the leading zeros to be
|          omitted; thus a time component diaplayed as '13:30:15.50'
|          does not indicate 50 centiseconds, but 50 microseconds
|          past the full second!
         - daylight saving time in New Zealand is +13


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.

(b)
 
WARNING:

According to Section 3.1 of RFC 2579, the components of the
DISPLAY-HINTS string describe the *independent* formatting of
substrings of the OCTET STRING (in this case).
Thus, the display instructions for the conceptional 'seconds'
part of the OCTET STRING, "1d.3d", actually describes the
independent formatting of a 1-octet and a 3-octet substring
(in network byte order) as decimal integers without leading
zeros, separated by a literal period ('.') -- a "display
separator character" in RFC 2579 terms --, and not the
human-friendly formatting of a single fixed-point fractional
number; there is no concept of a decimal fraction representation
in this notation.
So the presentation format will be very different from common 
practice for human beings. See the example below.
The "fixed-point with decimal sign" representation from
RFC 2579 is only available for INTEGER values, for cases with
scaled values, where the conceptual integer and fractional part
are stored as a single integer in units of the specified
fractional part; it is not applicable to display formats for
OCTET STRING objects.

Elaborating on a slight variant of the example from the RFC, ...
   Tuesday May 26, 1992 at 1:30:15.008 PM EDT
(8 milliseconds past the full 15 seconds), the 'seconds' part
would be represented as 15 seconds 8000 microseconds in four
octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with
the other components, would be rendered as:
    1992-5-26,13:30:15.8000,-4:0

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5676 (draft-ietf-opsawg-syslog-msg-mib-06)
--------------------------------------
Title               : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
Publication Date    : October 2009
Author(s)           : J. Schoenwaelder, A. Clemm, A. Karmakar
Category            : PROPOSED STANDARD
Source              : Operations and Management Area Working Group
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG