[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928)
Hi -
I don't see how RFC 2579 supports the reading that bytes of an
octet string should be interpreted as negative numbers. It certainly
was never the intent, and none of the definitions in RFC 2579
would support that reading.
If anything is to be changed here, it is the text in RFC 2579 clause 3.1 (3).
The simple clarification is that these octets are unsigned. I'm not aware
of any TCs for which this would do the wrong thing, but we should review
what's out there. The tougher problem is what to do about the leading zeroes -
DISPLAY-HINT is clearly broken there with respect to the needs of a human-
friendly DateAndTime.
Perhaps the good news is that since DISPLAY-HINTS really have no normative
force, implementations can just ignore them and do the Right Thing. :-) * 0.5
Randy
----- Original Message -----
> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "RFC Errata System" <rfc-editor at rfc-editor.org>
> Cc: <ah at TR-Sys.de>; <akarmaka at cisco.com>; <opsawg at ietf.org>
> Sent: Wednesday, October 28, 2009 4:00 AM
> Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928)
>
> 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/>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG at ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg