Subject: RE: Notification Log MIB

From: "Golovinsky, Eugene" <[email-masked]>
Date: Tue, 22 Aug 2000 11:25:02 -0500

Hi.

Just a few observations from my previous usage experience.

I tried to do very similar thing and packed information into single trap
OCTET STRING varbind.

In fact, they were multiple varbinds separated by something, space for
example.
While it seems to be a good idea it does not really works for the following
reasons.

1. People get really upset when forced to parse long strings without having
rules of how to parse it (fields within the varbind are of arbitrary
length).

2. A few times we got to the prohibitively long varbind

3. You are forced to represent everything as ASCII string even though it not
always
a good idea. Integer values would be an example.

4. To have a meaningful separator is not easy, since it always could be part
of the
varbind itself.

So, I think it is not an ideal solution. An though it might seem appealing
at 
first glance, practical reality does not prove it.

Thanks,
--Gene

Eugene Golovinsky
[email-masked]

-----Original Message-----
From: Rohit [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 6:46 AM
To: [email-masked]
Subject: Notification Log MIB

Hi, 

  I just did a quick scan of the notification log MIB and i noticed
  that

  1. For SNMP Manager to retrieve information about one notification,
     it has to issue several SNMP Get Requests depending upon
     the number of varbinds in the notification.

     This looks like an inefficient mechanism.
     
     Instead of this we could have packed up the Varbinds in 
     one object.

     e.g we could have used an OctetString as follows to
     pack up the Varbind.

      OCTET STRING (SIZE (0..65535))
        DESCRIPTION
                "The stringifed value of the VarBinds that were sent
                as part of the trap generated by this fault. The
                VarBinds are stringified as follows:
                (i) The format of the strigified varbind would be,
                    '<objectname#objecttype#value>', where,
                    'objectname' - is the name of the object
                                   (including the instance) and not
                                   the entire OID.
                    For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3

                    'objecttype' - is the type of the object stored as
                                   an ASCII string.
                    For ex: 'Integer32', 'SnmpAdminString'

                    'value' - is the value of the object
               (ii) The rules for encoding the 'value' in the string
                    are as follows,
                    - Integral types are converted into ASCII string
                    - For OctetString with printable characters,
                      again use ASCII
                    - For OctetString with non-printable characters,
                      they will be stored in HEX
                    - Since we use '>' as the ending delimiter for
                      each varbind in the stringified value, if the
                      'value' itself has a '>', then that would be
                      escaped with another '>'.
                      For ex: if the value was say 'abcde>>f' then it
                              would be stored as 'abcde>>>>f' in the
                              stringified value."

  2. Why don't we have a nlmConfigLogAgeout for each entry in the
     nlmConfigLogTable ? This could even be used for associating
priority
     to the notification being logged.

   Thanks
   Rohit

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Aug 2000 19:34:01 -0400

> From: Golovinsky, Eugene [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2000 12:25 PM
> To: 'Rohit'; [email-masked]
> Subject: RE: Notification Log MIB
> <clip>

I have to completely agree with that point and go further and say that I
don't care how short it is - I don't want to parse it.  I get very nervous
with these proposals of putting stuff in Octet strings which I need to
parse out.  Given 10 devices, I will likely have to managed 11 incompatible
interpretations of the parsable object.  I'll take the hit on efficiency
for a predictable and consistent SMI definition most days of the week.
This is one of my major "manager" pet peeves .

Sharon

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 30 Aug 2000 16:45:47 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Wed, 23 Aug 2000 10:30:04 +0530
> From: Rohit <[email-masked]>
> To: [email-masked]
> CC: Juergen Schoenwaelder <[email-masked]>, [email-masked]
> Subject: Re: Notification Log MIB
> References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
...
>   Why don't we have a nlmConfigLogAgeout for each entry in the
>   priority to the notification being logged.
...

Because no one asked for it, and because a major figure from
Cisco thought the global one was sufficient.   :-)  * 0.5

I personally think adding an nlmConfigLogAgeOut is technically
worth considering, but as WG chair I must say that it's
really too late to make such a change in this iteration.
Not only are we past the close of WG last call, the IETF last
call ended last month.

When the implementation reports start pouring in and it's
time to consider advancement to Draft Standard, we'll have
to see whether this has been a problem that merits fixing,
and whether this solution is the right one.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------