Subject: Notification Log MIB

From: Rohit <[email-masked]>
Date: Tue, 22 Aug 2000 17:15:50 +0530

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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Aug 2000 14:24:53 +0200

>>>>> Rohit  writes:

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

Rohit>      This looks like an inefficient mechanism.

You usually use getnext/getbulks. That is, you can reduce to some
extend the number of interactions (if you know a good estimation for
max-repetitions - which is another story).
     
Rohit>      Instead of this we could have packed up the Varbinds in
Rohit> one object.

Yes. The point here is that the SMI has no support for structured
types and people did not like the idea to put things into something
opaque like an OCTET STRING.

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

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

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

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

The ASCII representation you are proposing does not work for several
reasons. First, the notification logger has not necessarily MIB
knowledge. Second, a single descriptor like ifDescr is not guaranteed
to be unique. Third, encoding everything (including type names) in
pure ASCII can make the OCTET STRING pretty long which can badly
interact with SNMP message size constraints.

One could however argue that the MIB should export the whole BER
encoded notification varbind list instead (or in addition?) to the
table we have right now. This of course requires that the application
which reads the logging table is capable to decode a BER varbind list
- but this is not much harder than decoding yet another ad-hoc ASCII
representation, I think.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Rohit <[email-masked]>
Date: Tue, 22 Aug 2000 18:34:57 +0530

Hi Juergen,

  My comments are inline :-

> max-repetitions - which is another story).

  If we use getnext , we are increasing the traffic on the network.
  If we are using getbulk , its not a straight forward to estimate the
  number of max-repititions.

  With the alternate solution, one get will get you one complete 
  notification.

> which reads the logging table is capable to decode a BER varbind list

   I agree to the fact that suggested representation is not a standard
   but this can be documented in the MIB.
   Size of the OctetString will depend on the 'number of Varbinds' and
their
   types which i believe should not not cross SNMP message size.

   Thanks
   Rohit

---

From: Ram Kavasseri <[email-masked]>
Date: Tue, 22 Aug 2000 09:29:59 -0700

>   With the alternate solution, one get will get you one complete

Parsing values from an encoded OctetString is discouraged.

You're trying to solve two problems here:
1. encapsulating all the objects you need into one PDU
2. apply some sort of compression or OID suppression to make the
transfer
more efficient.

The former can be done today using bulk transfer...For the latter, the
NMRG
(Network Management Research Group) is investigating various
bulk-transfer
methods with OID suppression (and/or compression)...

Inventing ways to do either of the above for a few objects only is wrong
and non-standard, IMHO...

Ram

---

From: Ram Kavasseri <[email-masked]>
Date: Tue, 22 Aug 2000 08:58:09 -0700

>      e.g we could have used an OctetString as follows to

Packing varbinds into an octetstring means:
1. you'll have to parse the octetstring to get the "sum of the parts".
Parsing
OctetStrings to get individual fields is discouraged.

2. you'll need to come up with some way to delimit each varbind in the
OctetString, and
represent the datatypes - afaik, there aren't rules to tell you how to
do this 
OctetString packaging (and we shouldn't be inventing ways to encode this
into an OctetString).

3. solving the inefficiency of a couple of extra objects by slamming
them all into
one OctetString is the wrong way, IMHO, to address this problem. The
inefficieny you point
to is a general handicap for every SNMP transmission (i.e. the number of
octets taken
up by the non-instance part of the OID, the repeated OID data in
multiple packets)...
The right way to address this would be to adopt a bulk-transfer method
that works for
*all* objects, and not hack a few objects in a MIB into an
OctetString...

Ram

---

From: Ram Kavasseri <[email-masked]>
Date: Tue, 22 Aug 2000 09:00:16 -0700

> - but this is not much harder than decoding yet another ad-hoc ASCII

Nicely put - I didn't even think of the BER encoded notification varbind
list
as a possible option. I learn something new everyday :-)

Thanks,

Ram

---

From: Rohit <[email-masked]>
Date: Wed, 23 Aug 2000 10:30:04 +0530

Hi, 

> and non-standard, IMHO...

  I think you have a point here.
  
  But still i haven't got clarification of my second comment :-

  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