errata logo graphic

Found 2 records.

Status: Verified (1)

RFC5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", October 2009

Source of RFC: opsawg (ops)

Errata ID: 1927

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-10-23
Verifier Name: Dan Romascanu
Date Verified: 2009-10-25

Section 4, 3rd para says:

   The MIB module is organized into a group of scalars and two tables.
   The syslogMsgControl group contains two scalars controlling the
|  maximum size of SYSLOG messages recorded in the tables and also
   controlling whether SNMP notifications are generated for SYSLOG
   messages.

It should say:

   The MIB module is organized into a group of scalars and two tables.
   The syslogMsgControl group contains two scalars controlling the
|  maximum number of SYSLOG messages recorded in the tables and also
   controlling whether SNMP notifications are generated for SYSLOG
   messages.

Notes:

Rationale: possible confusion.

"maximum size of SYSLOG messages recorded" conceptionally would
relate to the SIZE of syslogMsgMsg OCTET STRING instances or the
maximum value for syslogMsgSDParams instances, but the DESCRIPTION
clause for the syslogMsgTableMaxSize OBJECT-TYPE in the MIB module
in Section 7 clarifies that this object indicates the maximum
*number* of entries in the syslogMsgTable and does not describe
some filtering criterion (by size) of the SYSLOG messages recorded.


Status: Held for Document Update (1)

RFC5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", October 2009

Source of RFC: opsawg (ops)

Errata ID: 1928

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2009-10-23
Held for Document Update by: Dan Romascanu

Section 7, pg. 7 says:

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

It should say:

(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


Report New Errata