Subject: [OPSAWG] my initial review of draft-schoenw-syslog-msg-mib-00.txt

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 2 May 2008 15:41:05 +0200

In general I think a MIB module like this one makes sense and
will be usefull.

Some comments:

- I see 2 writable objects at the beginning of the MIB module.
  But it is unclear what the expected persistency behaviour is.

- Would it not be easier to use SnmpAdminString instead of
  DisplayString? Do we never expect any of these fields to
  contain Internationlized names?

- WHen I see:
         If the first octets contain the value 'EFBBBF'h, then the rest
         of the message is a UTF-8 string. Since syslog messages may be
         truncated, the message may contain invalid UTF-8 encodings at
         the end."
  I wonder if it would not be better to truncate in such a way that
  message allways contains valid UTF-8 encodings.
  What was/is your motivation to not do that?

- I find these somewhat weird:
      MIN-ACCESS  accessible-for-notify
      DESCRIPTION
          "Read write access is not required."

  The MAX-ACCESS for this (and other) objects is read-only.
  So the DESCRIPTION clause seems bogus.
  I guess you mean that one does not need to support READ
(GET/HETNEXT/GETBULK)
  access. You have several of those.

NITs/TYPOs

- second para sect 1:

   This document defines an SNMP MIB modules to represent SYSLOG

  I guess you want to s/modules/module/

- page 9

          For syslog messages without structured data element parameters
          that were not truncted by the converter, none of the bits is
          set."

  s/truncted/truncated/

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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 2 May 2008 15:46:55 +0200

- On page 8, are we sure that
        OID             = 1*DIGIT "." 1*DIGIT *("." 1*DIGIT)

  represents only valid OID encodings?

- On page 9:
   [DISCUSS: Does it really make sense to special case the first two
   varbinds sysUpTime and snmpTrapOID?  The value of the later one is
   hardly readable for humans anyways.]

  I think it would be fine to handle them teh same as all the
  other varBinds.

NITs/TYPOs:

- Section 1:
   format.  Structured data elements allow us tto map between SNMP

  s/tto/to/

Bert Wijnen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 May 2008 16:02:35 +0200

>   But it is unclear what the expected persistency behaviour is.

The author just did not know and yes this is where some input would
actually be much appreciated. My preference would certainly be to make
these two scalars be stored in nonvolatile memory. So I plan to add

   The value of this object should be kept in nonvolatile memory.

to both DESCRIPTION clauses.

>   contain Internationlized names?

We tried carefully to follow what the SYSLOG specs say. Some message
parts are ASCII while others may contain UTF-8.

>   What was/is your motivation to not do that?

The SYSLOG specification allows for arbitrary truncation; a SYSLOG
implementation is allowed to truncate without having to parse the
UTF-8 encoding. And since a truncated message may hit the SNMP engine,
I think it is fair to allow to pass it on without trying to "fix" it.
(And robust applications will have to be able to deal with truncated
UTF-8 strings anyway.)

>   access. You have several of those.

Changed to "Read access is not required."
 
>   I guess you want to s/modules/module/

fixed

>           that were not truncted by the converter, none of the bits is

fixed

/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
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 May 2008 16:06:35 +0200

>   represents only valid OID encodings?

No, this certainly can be tightened if people care. Any proposals how
tight it should be?
 
>   I think it would be fine to handle them teh same as all the

Noted. Would be nice to get more input on this question.

fixed

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 May 2008 10:55:30 -0400

Hi,

The discussion of truncation follows the syslog WG's protocol I-D.
I am not certain that it is necessary to state here that the trucation
might lead to incomplete UTF-8 characters, but it would probably be
more helpful than harmful. You might want to include a REFERENCE.

David Harrington
[email-masked]
[email-masked]
[email-masked]
syslog WG co-chair

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bert Wijnen - IETF
> Sent: Friday, May 02, 2008 9:41 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] my initial review of 
> draft-schoenw-syslog-msg-mib-00.txt
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 May 2008 11:35:13 -0600

Hi -

> From: "Bert Wijnen - IETF" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, May 02, 2008 7:46 AM
> Subject: [OPSAWG] my initial review of draft-marinov-syslog-snmp-01.txt
...
>   represents only valid OID encodings?
...

There are valid OIDs that this expression cannot represent, e.g. "0.12"
This expression can represent things that are not valid OIDs, e.g, "7.0"

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 May 2008 20:49:31 +0200

> This expression can represent things that are not valid OIDs, e.g, "7.0"

I fail to see why "0.12" is not covered.

The real question is how precise this definition has to be for the
purpose of this specification. We can make this ABNF really complex if
we take all the SNMP specifics into account (e.g. that sub-identifier
are limited to 32-bit unsigned numbers).

The real question is to what extend it is helpful to express all
details in complicated ABNF grammar given that we talk about
converting OIDs found in SNMP notifications into a string format
anyway. This is the more important question I like to get an answer
and proposals for. Will people be happy if we mimic the XSD pattern in
<draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt> even though this is
also not perfect?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 May 2008 12:23:45 -0600

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, May 02, 2008 12:49 PM
> Subject: Re: [OPSAWG] my initial review of draft-marinov-syslog-snmp-01.txt
...
> I fail to see why "0.12" is not covered.

You're right, my mistake.

> <draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt> even though this is

It all depends on how much checking it's worthwhile to do at the syntactic
level, and what an implementation could reasonably be expected to do
if something fails the syntax check.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 May 2008 15:52:09 -0400

Hi,

If this were an SNMP application receiving the OID, it would probably
check it for validity, but accept it anyway and flag it for operator
review of validity if it failed the check (depending on the
application, of course).

If this is delivered via syslog, and the OID is invalid, then it could
impact the ability to correlate the information. If the OID is
invalid, the act of translating could also make it difficult for an
operator to debug whether the bad OID was created by the SNMP
originator, or the snmp-syslog translator. Personally, I think these
are corner cases, and we probably don't need to worry about them very
much in this specification. 

If a receiver application wants to validate the input more rigorously,
the developer can always add a validation routine that is more
rigorous than this specification specifies.

If we make this spec more rigorous, I would have concerns that we
might make something illegal that shouldn't be, such as an OID from a
MIB registered in the IEEE subtree.

So I recommend being lenient in what we accept.

dbh

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Friday, May 02, 2008 2:50 PM
> To: Randy Presuhn
> Cc: [email-masked]
> > > To: <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> > > Cc: <[email-masked]>
> draft-marinov-syslog-snmp-01.txt
> > ...

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sat, 3 May 2008 10:58:25 +0200

So that seems a good reason for this sort of truncation.
Indeed, explaing (with prefereably a reference) why it
is done this way would be good.

If I had been involved in the syslog effort, I would 
probably have objected to this type of truncation.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: David Harrington [mailto:[email-masked]]
> Verzonden: vrijdag 2 mei 2008 16:56
> Aan: 'Bert Wijnen - IETF'; [email-masked];
> [email-masked]; [email-masked]
> CC: [email-masked]
> Onderwerp: RE: [OPSAWG] my initial review of

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 4 May 2008 15:34:22 -0600

Hi -

> From: "David Harrington" <[email-masked]>
> To: <[email-masked]>; "'Randy Presuhn'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, May 02, 2008 1:52 PM
> Subject: RE: [OPSAWG] my initial review of draft-marinov-syslog-snmp-01.txt
... 
...

It sounds like we mave have differing ideas of what a "valid" object identifier is.
I was assuming "valid" meant the ASN.1 definition, i.e, 
  - subidentifiers are non-negative integers
  - first subidentifier is constrained to the range 0..2
  - there must be at least two subidentifiers
  - the second subidentifier is in the range 0 to 39 if first subidentifier is 0 or 1

No possible OID could be excluded by such a definition, and only well-formed
OIDs would be permitted by it.

We could make a narrower definition based on SNMP's definition, i.e,
  - no more than 128 subidentifiers
  - no subidentifier larger than 4294967295

We could tighten it even more:
  - the second subidentifier must not be larger than 4294967215
    (this is a natural result of the implementation shortcuts that led to the
    4294967295 limit for other subidentifiers)

While I'm agnostic on whether this specification needs to be this rigorous,
It would be a mistake to make it any more rigorous, since doing so
would preclude legitimate SNMP OIDs.

Randy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 5 May 2008 09:18:02 +0200

It was specifically these that I had in mind when I 
made my comment on the definition of valid OIDs:

> Van: [email-masked] [mailto:[email-masked]]Namens
> Randy Presuhn
> Verzonden: zondag 4 mei 2008 23:34
> Aan: [email-masked]
> Onderwerp: Re: [OPSAWG] my initial review of
> No possible OID could be excluded by such a definition, and only 
> well-formed OIDs would be permitted by it.
> 

.. snip ...

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 10:33:08 +0200

> - the second subidentifier is in the range 0 to 39 if first

This is inconsistent with <draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt>
which says:

   <xs:simpleType name="ObjectIdentifier">
     <xs:restriction base="xs:string">
       <xs:pattern value=
       "[0-2](\.[1-3]?[0-9])(\.(0|([1-9]\d*))){0,126}"/>
     </xs:restriction>
   </xs:simpleType>

This regex restricts the second subidentifier also for the case where
the first subidentifier is 2. I checked the 2003 edition of the BER
standard (ISO/IEC 8825-1:2003) and it indeed mentions only a
restriction for the values 0 and 1 of the first OID component. So the
XSD regex needs to be something like this:

  ([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*)))(\.(0|([1-9]\d*))){0,126}

And for the SYSLOG to SNMP draft, I am going to use the following:

  OID             = OIDSTART *("." OIDSUBID)
  OIDSTART        = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID)
  OIDSUBID        = ZERO / (NONZERODIGIT *DIGIT)

  NONZERODIGIT    = %d49-57
  ZERO            = %d48
  DIGIT           = ZERO / NONZERODIGIT

Do people think it is important to also cover the SNMP restriction of
128 subidentifiers? It is easy to do but then we are also locked in to
it (but then this limit might never change anyhow).

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 5 May 2008 08:15:29 -0400

Hi,

What does a translator application do when it is given a notification
with an invalid OID to translate? Refuse to deliver the notification?
Substitute an exception? drop the varbind?

Are there security and operational considerations stemming from not
passing on the notification received, as received?

dbh

> Sent: Monday, May 05, 2008 3:18 AM
> To: Randy Presuhn; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 14:20:14 +0200

> Substitute an exception? drop the varbind?

An SNMP packet with an invalid OID is simply invalid; I think there is
no point in trying to translate garbage.
 
> passing on the notification received, as received?

Not passing on garbage is I think a security feature. ;-) Since
everything that is valid can be represented, I do not really
understand what the problem is.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 5 May 2008 08:25:56 -0400

Hi,

The document should state what the expected behavior is, so different
implementations of a translator behave consistently.

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, May 05, 2008 8:20 AM
> To: David Harrington
> Cc: 'Bert Wijnen - IETF'; 'Randy Presuhn'; [email-masked]

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 5 May 2008 08:51:11 -0400

Hi Juergen and Randy,

The xsd:pattern restriction for ObjectIdentifier in
<draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt>, cited below,
originally came from Steedman's text on ASN.1 (1990)...which limits the
first sub-id to 0:2, so I am worried by Juergen's reference to the 2003
edition of the BER as being different (0:1).  In Steedman's time
"joint-iso-ccitt" had the value 2; today I think it is designated as
"joint-iso-itu-t":

From ITU-T Rec. X.660 (2004) | ISO/IEC 9834-1:2004: "the top-level arcs
are restricted to three arcs numbered 0 to 2".

And from http://www.oid-info.com/faq.htm#15:
"Why are top-level arcs restricted to three arcs numbered 0 to 2, and
why are arcs beneath root arcs 0 and 1 restricted to forty arcs
numbered 0 to 39?
This enables optimized encodings to be used in which the values of the
top two arcs for all arcs under top-level arcs 0 and 1, and arcs 0 to
47 under top-level arc 2 encode in a single octet in an object
identifier encoding (see the ITU-T Rec. X.690 series | ISO/IEC 8825
multi-part Standard)".

I would really appreciate a definitive judgment from people like
Juergen and Randy on this, so I can put the matter to rest for the
smi-datatypes-in-xsd draft.  My personal strong feeling is that the 0:2
range is correct (at least for what was probably encoded in most legacy
SNMP engines)...but others have more expertise in ASN.1 than I do, for
sure.

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Monday, May 05, 2008 4:33 AM
To: Randy Presuhn
Cc: [email-masked]
Subject: Re: [OPSAWG] my initial review of
draft-marinov-syslog-snmp-01.txt

> - the second subidentifier is in the range 0 to 39 if first

This is inconsistent with
<draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt>
which says:

  NONZERODIGIT    = %d49-57
  ZERO            = %d48

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 15:43:18 +0200

On Mon, May 05, 2008 at 08:51:11AM -0400, Natale, Bob wrote:
 
> edition of the BER as being different (0:1).

This is not what I wrote. You have missed the point of the debate.

[...]

> SNMP engines)...but others have more expertise in ASN.1 than I do, for

The current XSD regex does not allow OIDs such as 2.40 or 2.1234 which
seem to be legal OIDs. This is what I was trying to fix. See the new
regex that I posted.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 17:55:17 +0200

> implementations of a translator behave consistently.

I have added the sentence

  Implementations MUST drop invalid SNMP messages before they
  are passed to the snmp-to-syslog translator

just above section 3.1. I personally believe the sentence does not add
value since I expect that SNMP specs already only allow to pass valid
messages to an SNMP application; but probably the SNMP specs are not
really clear enough about varbind content.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 5 May 2008 11:26:42 -0600

Hi -

> To: "David Harrington" <[email-masked]>
> Cc: "'Bert Wijnen - IETF'" <[email-masked]>; "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Monday, May 05, 2008 9:55 AM
...

I think it's worth keeping in mind that these pathological cases are
*impossible* to encode in BER, simply because of how BER encodes
object identifiers.  They *cannot* have been received as BER encoded
data.  They could arise because of local corruption after BER decoding,
or because the information arrived in some form other than BER.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 20:46:32 +0200

> or because the information arrived in some form other than BER.

I think I can BER encode an OID that has more than 128 subidentifier
or an OID with a subidentifier which is larger than an unsigned 32-bit
number. In both cases, I violate SNMP but not BER.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 5 May 2008 12:05:09 -0600

Hi -

> Sent: Monday, May 05, 2008 12:46 PM
...
...

That's why (many messages ago in this thread) I split the constraints into those
inherent to BER and those from SNMP.  Since Bert's response, the context here
had been just the ASN.1 constraints, about which I think we're in violent agreement.

The question is whether to include SNMP's additional constraints on object identifiers.
Enforcing the BER constraint cannot lose information, since the things it would
reject could only arise by bad behaviour at the receiving end.  Enforcing the additional
SNMP constraints *could* lose information if the receiver is a "liberal in what
you accept" one.  I can see both sides to this question, but don't feel strongly
about one or the other.  I just think that if SNMP's tighter constraints are "re-enforced"
here, that a distinction is made (if only in a note) between the "impossible" stuff
precluded by the BER spec, and the "illegal" stuff outlawed by the SNMP spec.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 May 2008 21:29:52 +0200

On Mon, May 05, 2008 at 12:05:09PM -0600, Randy Presuhn wrote:
 
> The question is whether to include SNMP's additional constraints on
> object identifiers.  Enforcing the BER constraint cannot lose
> information, since the things it would reject could only arise by
> bad behaviour at the receiving end.  Enforcing the additional SNMP
> constraints *could* lose information if the receiver is a "liberal
> in what you accept" one.  I can see both sides to this question, but
> don't feel strongly about one or the other.  I just think that if
> SNMP's tighter constraints are "re-enforced" here, that a
> distinction is made (if only in a note) between the "impossible"
> stuff precluded by the BER spec, and the "illegal" stuff outlawed by
> the SNMP spec.

I am open to concrete text suggestions. The current wording is:

   Implementations MUST drop invalid SNMP messages before they are
   passed to the snmp-to-syslog translator.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 5 May 2008 12:43:45 -0600

Hi -

> Sent: Monday, May 05, 2008 1:29 PM
...
>    passed to the snmp-to-syslog translator.

Fine with me.

The grammar for the syslog representation is what got us into this discussion.
If all object identifiers that show up on *that* interface must have come from
valid SNMP messages, then any that violate the tighter SNMP constraints
are corrupt, and should be treated as an error.

Randy