RFC 5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", October 2009Source of RFC: opsawg (ops)
Errata ID: 1928
Status: Held for Document Update
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
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
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: