[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
a) Asking early is much better than carrying out endless
discussions based on ambiguous grounds! So there are
no 'stupid' questions!
b) AFIACT, the responsible AD can do almost anything he likes ...
>> 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?
I always use change bars ("|") in the leftmost column to mark
lines to be changed (OLD) or changed (NEW); this style now recurs
so frequently in RFC Errata as well that I do not want to explain
it again and again. However, in *this* case, where I had to
present a rather long quotation to give the necessary context for
the rationale, I wanted to draw the attention to other lines that
the suggestions in the Errata Note do _not_ attempt to change,
and thus the exclamation mark ("!") seemed to be an intuitive tag
for lines containing important related details an to which I wanted
to refer specifically in the Errata's 'Notes'.
>> 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.
"Pay attention to this line. It strongly matters for this Errata Note!"
>> 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. ...
The text in RFC 2579 for numerical translations is convoluted indeed,
but I believe it is unambiguous.
It starts out with "For INTEGER types ..." and continues with:
"For all types, ..." as quoted above.
> ... 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.
You may be right; I'll take a closer look at that; maybe more Errata?
>> (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. ...
Two observations here (let's stay on the learning curve!):
- It's always tempting to (only) give 'simple' examples.
This might be taken as evidence that reviewers perhaps should
challenge authors to provide less simple examples as well.
- Playing with an early prototype implementation might have
revealed the issue. Now that we have a PS, playing with
upcoming implementations will give us a chance to improve
the PS in a future update at Draft Standard level.
That's what the Standards Track envisions anyway, isn't it?
> ... 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.
+1
Since I did not have the cycles available to step in earlier in syslog,
I wanted to start this discussion in a manner that becomes visible
to prospective readers of the RFC, hence the Errata path taken.
This emerging thread should be the right place for the discussion,
and the conclusions drawn eventually should be used to update the
Errata note in the most useful manner.
> /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/>
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah at TR-Sys.de |
+------------------------+--------------------------------------------+