Subject: [OPSAWG] comments ion syslog-msg-mib-01

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Feb 2009 21:24:28 +0100 (CET)

Hi,

I have a few minor comments on this document.

In the syslogMsgTable, some of the objects have special values when
the corresponding field has no value in the original syslog message.
For example, syslogMsgTimeStamp uses a value of 20 zeros.  I just
wonder why this scheme is chosen instead of simply not making the
instance available?  Is this some BCP?   This also means that these
dummy values are sent in the syslogMsgNotification I guess?

Should the object syslogMsgSDElementName be called
syslogMsgSDElementID (or just syslogMsgSDID) to match the terminology
in the syslog spec?

In the DESCRIPTION of syslogMsgSDParamIndex:
   s/This objects indexes/This object indexes/
   s/instance of a structured data element/
     instance of a parameter/
   s/occure/occurs/

In the DESCRIPTION of syslogMsgNotification:
  "The syslogMsgNotification is generated when a new syslog
   message is generated"
           ^^^^^^^^^^^^
  Do you mean "is received"?

In syslogMsgNotificationCompliance you say that the syslogMsg* objects
have a MIN-ACCESS accessible-for-notify.  I just wonder what the
instance identifier part of these objects would be in the varbind list
of syslogMsgNotification in this case?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Feb 2009 08:51:25 +0100

> dummy values are sent in the syslogMsgNotification I guess?

There are I think two reasons:

a) Some applications apparently do not deal well with holes in tables.

b) RFC 3416 says for notifications:

     If the OBJECTS clause is present in the invocation of the
     corresponding NOTIFICATION-TYPE macro, then each corresponding
     variable, as instantiated by this notification, is copied, in
     order, to the variable-bindings field.

   It is somewhat unclear how to interpret this text if notification
   objects do not exist. (Note that variables protected by access
   control cause the whole notification to be dropped.) We bypass this
   issue by making sure the objects always exist.

Since syslogMsgTimeStamp now uses DateAndTimeMicroSeconds, one could
perhaps choose a zero-length string in order to save some 20 bytes in
the cases where the timestamp is not known. Perhaps I should change
the name of DateAndTimeMicroSeconds to SyslogTimeStamp and leave it to
some other module to define a reusable DateAndTimeMicroSeconds TC.

> syslogMsgSDElementID (or just syslogMsgSDID) to match the
> terminology in the syslog spec?

Yes, but then I would choose syslogMsgSDID as this is closest to the
SYSLOG protocol specificiation.

>    s/instance of a structured data element/

This text has already been rewritten since we changed the semantics of
this object to reflect the position of the param. It now reads:

syslogMsgSDParamIndex OBJECT-TYPE
    SYNTAX      Unsigned32 (1..4294967295)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
       "This object indexes the structured data element parameters
        contained in a SYSLOG message. The first structured data
        element parameter has the index value 1 and subsequent
        parameters are indexed by incrementing the index of the
        previous parameter. The index increases across structured
        data element boundaries so that the value reflects the
        position of a structured data element parameter in a
        SYSLOG message."
    REFERENCE
       "RFCYYYY: The syslog Protocol (section 6.3.3)"
    ::= { syslogMsgSDEntry 1 }

>   "The syslogMsgNotification is generated when a new syslog

Yes, fixed.

> of syslogMsgNotification in this case?

The MIN-ACCESS does not change how the instance identifier is
formed. You do exactly the same as if the objects were accessible
except that you can't access them.

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 20 Feb 2009 09:17:12 +0100 (CET)

> except that you can't access them.

So it would be ok to always use syslogMsgIndex 1 in all notifications?
Or any random Unsigned32 value != 0?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Feb 2009 10:12:17 +0100

> Or any random Unsigned32 value != 0?

I do not see this mentioned in the description of syslogMsgIndex. Ah,
because the description does not state the value starts with 1? If
your implementation can't affort a 32-bit counter, you might claim
that the MIB module suffers from a discontinuity due to a restart of
the submodule after ever notification generated...

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Feb 2009 21:19:11 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> because the description does not state the value starts with 1?

The object is defined to "identify entries in the syslogMsgTable".
But in this case there are no such entries.  Hmm, I guess that
conceptually there *are* entries, but they are not accessible other
than through the notifciations.

> If your implementation can't affort a 32-bit counter, you might
> claim that the MIB module suffers from a discontinuity due to a
> restart of the submodule after ever notification generated...

After your clarification it is clear to me how it should be
implemented if the table is accessible-for-notify.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Feb 2009 22:22:15 +0100

> than through the notifciations.

Your last sentence is a good summary of my interpretation of what
accessible-for-notify means.  There is not a great deal of text about
accessible-for-notify in RFC 2578. But I think this interpretation
makes sense and is consistent with the rest of the framework (e.g.
how access control is checked for notification objects).

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 23 Feb 2009 16:37:57 -0500

Hi,

As I recall from the SNMPv3 WG, accessible-for-notify was added to
support devices like printers that might have events it wants to
report, but the device does not support having MIBs instantiated
(i.e., you cannot GET or SET the information). IIRC, the idea was for
things like out-of-ink notifications that could be generated
dynamically as needed.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Monday, February 23, 2009 4:22 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [OPSAWG] comments ion syslog-msg-mib-01
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>