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

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

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>

I am trying to understand the errata and so I might stupid
questions. Since you report two independent defects, it might have
been useful to have two errata posted. I have no clue whether the
errata tracker allows to make such changes now.
 
> Section: 7, pg. 7
> 
> Original Text
> -------------
>  SyslogTimeStamp ::= TEXTUAL-CONVENTION
> !    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d"

What does the '!' mark imply here?

>      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

Again, it is not clear to me what this ! mark tries to convey.

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

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.

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

This is a very good catch - too bad nobody did find this before the
RFC was posted. Your clarification surely makes sense, but the
resulting format is really irritating. I do not know at the moment how
to deal with this. The two options we have:

a) Keep the published DISPLAY-HINT and document that the rendered
   value is really misleading humans (and we usually render for humans
   - so this is really bad)

b) Declare the DISPLAY-HINT as a failure and remove it by hardwiring
   into the DESCRIPTION clause a conversation that uses leading zeros.

I think more discussion is needed.

/js

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