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

From: RFC Errata System <[email-masked]>
Date: Fri, 23 Oct 2009 12:39:48 -0700 (PDT)

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 <[email-masked]>

Section: 7, pg. 7

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

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.

(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

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5676 (draft-ietf-opsawg-syslog-msg-mib-06)
--------------------------------------
Title               : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
Publication Date    : October 2009
Author(s)           : J. Schoenwaelder, A. Clemm, A. Karmakar
Category            : PROPOSED STANDARD
Source              : Operations and Management Area Working Group
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Oct 2009 12:00:44 +0100

> "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications".

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

What does the '!' mark imply here?

>          field  octets  contents                  range

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

>          For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be

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.

> the other components, would be rendered as:

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Oct 2009 12:37:20 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder 

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

It's always better to enter errata at a granularity where a single
resolution makes sense. I think that the submitter can edit to reduce
the text to one item, and then submit a second item. Or alternatively I
can reject the current erratum (#1928) and Alfred can submit two (or
more) errata instead. 

Dan

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Oct 2009 12:48:02 +0100 (MEZ)

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

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

> 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!"

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

You may be right; I'll take a closer look at that; maybe more Errata?

> 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

+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

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:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Oct 2009 16:54:23 +0100

> "For all types, ..." as quoted above.

See, it depends how you parse the text. One can read it as the initial
"for INTEGER types" phrase qualifies the whole paragraph for INTEGER
types. I have to look at code I wrote many years ago to see what my
implementation does. Knowing what implementations do would certainly
help.

/js

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 28 Oct 2009 17:27:22 +0100 (MEZ)

In the message archived at
  http://www.IETF.ORG/mail-archive/web/opsawg/current/msg00848.html,
Juergen Schoenwaelder wrote:

>> "Definitions of Managed Objects for Mapping SYSLOG Messages to
>>  Simple Network Management Protocol (SNMP) Notifications".
>>
> ... [snip]
> ... [snip] ...

Returning to RFC 2579 and reconsidering the context,
a few observations should be made before progressing:

Unlike purists argue for RADIUS and DHCP, the SMI has peacefully
lived with the concept of structured data carried in OCTET STRING
objects, whithout seeing a need to formally define a new SMI data
type for each such, say, 'application layer data type'.
(Intrinsically that already has been inherited from X.208 / X.680.)

Therefore, it might be wise to precisely distinguish SMI layer
aspects from 'application layer' aspects considered out of scope
for the SMI, but keeping in mind that the latter preferably should
make use of general, standard SMI mechanisms as far as possible.

The data structures and types superimposed on OCTET STRINGs
via TEXTUAL-CONVENTIONs and defined otherwise in MIB module
specifications are essentially at the application layer, not
a matter of interest at the SMI layer.
Therefore, I see no conceptual problem of specifying signed or
unsigned integer values conceptually mapped into OCTET STRINGs
(or BCD data, 5-bit Baudot codes, or 7-bit SMS characters, packed
into OCTET STRINGs, or integer parts of seconds and fractional
parts of seconds mapped separately, whatever you need, btw!).
All that needs to be done at MIB module specification time is
providing unambiguous coding rules for interoperability
(e.g., "3-octet unsigned integer in network byte order").

So far, I believe, we do not have any problem now.

The second topic scratched at in the Errata Note deals with
the application of the SMI (RFC 2579) DISPLAY-HINT mechanism
to such 'application level' data types.

The precise specification of that generic mechanism is in the
domain of the SMI, as is the interpretation of the standard.
However, the DISPLAY-HINT mechanism needs to make some assumptions
on the binary patterns that shall be presented to humans; this
is easy for the 'fully specified' SMI data types, but it is much
less straightforward for structured data superimposed on OCTET
STRINGs, and arguably RFC 2579 has underspecified this aspect --
otherwise it would not be possible to give rise to different
interpretations, as it turns out now.

The other question indeed is the applicability of the mechanism
to a specific application, the restrictions to be adhered to in
order to make proper use of the mechanism for an 'application
data type', e.g. how to design such data types in a 'DISPLAY-HINT
friendly' manner.
Since this subject cannot be dealt with properly without a solid
foundation, we should first tackle the perceived ambiguity in
RFC 2579 before discussing the SMI user (application) layer details.
Therefore, I suggest to defer the discussion of the latter.

Thus, let's focus on Section 3.1 of RFC 2579 (p.21/22).

The first part of that section -- almost all on p.21 -- mainly
deals with the 'fully specified' SMI data types, where syntax and
sematics are so narrow the DISPLAY-HINT is not needed and hence
not permitted, and the presentation of those subcases of the
INTEGER data type that do not have narrow semantics specified
in the SMI.

The second part of the section extends from the bottom of p.21
to the end of the section and deals with OCTET STRING conversions.
Bullet (3) on p.22 discusses the display format characters in the
DISPLAY-HINT string for OCTET-STRING objects, and refers to
numeric format conversions; the only detailed rule given is:

                                                    If the octet
   length part is greater than one, and the display format part refers
   to a numeric format, then network-byte ordering (big-endian
   encoding) is used interpreting the octets in the value.

That's why I always had concluded that the description of numeric
conversions on page 21 was included here by reference, for all other
relevant (yet herein unspecified) details, in particular the phrase
quoted above, starting with "For all types, ...".
This contains the assumption that the n-octet integer values to be
converted were signed integers.
As it has turned out, this interpretation is not shared universally,
with the alternate assumption being that these n-octet integers
must always be regarded as unsigned.
Most instances I recall ever having seen are uncritical because the
valid range for the integer values is restricted by application
semantics to the extent that the MSB is always 0, thus admitting
both interpretations without any impact on their use.

(Ironically, related trouble has recurred in other places in the
IETF, where specifications had not been explicit enough to state
precisely whether particular protocol fields carry signed or
unsigned integer values, and later protocol additions had to work
around deployed implementations assuming either.)

Apparently, the best solution would be to file a clarification
for Section 3.1 of RFC 2579, as an Errata note, as well, in order
to disambiguate the interpretation.  When this is done, collateral
issues can be identified and resolved.

Before performing any action, it would perhaps be useful to harvest
existing IETF and Vendor MIB modules for instances of data structures
superimposed on OCTET strings and observe the kind of integer values
(signed/unsigned) in these structures:
    a)  in general
(irrelevant for the issue at hand, hence for information only);
and (significant for the issue):
    b)  when the DISPLAY-HINT mechanism is also used for the
        respective objects.

I have neither enough spare time nor the (non-IETF) example material
at hand to perform this harvesting and therefore would like to
solicit input from vendors.

> ... [snip] ...

Yes, I tried to start it hereby.   :-)

Kind regards,
  Alfred Hönes.

--

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 28 Oct 2009 09:38:45 -0700

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" <[email-masked]>
> To: "RFC Errata System" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, October 28, 2009 4:00 AM
> Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928)
>

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 28 Oct 2009 09:50:30 -0700

Hi -

> From: "Alfred Hnes" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 28, 2009 9:27 AM
...
> converted were signed integers.

That was not the intent when the text was developed.  It is also worth
keeping in mind that since its inception DISPLAY-HINT has been recognized
as being a very limited facility.  That's one of the reasons why it is
so totally optional.

> must always be regarded as unsigned.

This is my recollection of the intent when the text was written.

> around deployed implementations assuming either.)

In general, it's safest to assume that bit fields are unsigned unless
explicitly stated otherwise, the behaviour of some C compilers
notwithstanding.

> issues can be identified and resolved.

Agreed.
 
Randy