RFC 1207:FYI on Questions and Answers: Answers...
RFC-Ref

7. Questions About Network Management Implementations

7.1. In reading the SNMP RFCs [3, 4 ,5, 6] I find mention of authentication of PDUs. Are there any standards for authentication mechanisms?

There is a working group of the IETF that is working on this problem. They are close to a solution, but nothing has yet reached RFC publication yet. Expect something solid and implementable by October of 1991.

7.2. Can vendors make their enterprise-specific variables available to users through a standard distribution mechanism?

Yes. But before someone submits a MIB, they should check it out themselves.

      On uu.psi.com in pilot/snmp-wg/, there are two files

              mosy-sparc-4.0.3.c

              mosy-sun3-3.5

The first will run on a Sun-Sparc, the second will run on a Sun-3. After retrieving one of these files in BINARY mode via anonymous FTP, the submittor can run their MIB through it, e.g.,

              % mosy mymib.my

Once your MIB passes, send it to:

              mib-checker@isi.edu

If everything is OK, the mib-checker will arrange to have it installed in the /share/ftp/mib directory on venera.isi.edu.

Note: This processing does not offer an official endorsement. The documents submitted must not be marked proprietary, confidential, or the like.

7.3. I have a question regarding those pesky octet strings again.

I use the variable-type field of the Response pdu to determine how the result should be displayed to the user. For example, I convert NetworkAddresses to their dotted decimal format ("132.243.50.4"). I convert Object Identifiers into strings ("1.3.6.1.2....").

I would LIKE to just print Octet Strings as strings. But, this causes a problem in such cases as atPhysAddress in which the Octet string contains the 6 byte address instead of a printable ASCII string. In this case, I would want to display the 6 bytes instead of just trying to print the string.

MY QUESTION IS: Does anyone have a suggestion as to how I can determine whether I can just print the string or whether I should display the octet bytes. * Remember: I want to support enterprise specific variables too.

In general, there is no way that you can tell what is inside an OCTET STRING without knowing something about the object that the OCTET STRING comes from. In MIB-II [6], some objects are marked as DisplayString which has the syntax of OCTET STRING but is restricted to characters from the NVT ASCII character set (see the TELNET Specification, RFC 854std8 [7], for further information). These objects are:

         sysDescr
         sysContact
         sysName
         sysLocation
         ifDescr

If you want to be able to arbitrarily decide how to display the strings, without knowing anything about the object, then you can scan the octets, looking for any octet which is not printable ASCII. If you find at least one, you can print the entire string, octet by octet, in "%02x:" notation. If all of the octets are printable ASCII, then you can just printf the string.

7.4. If archived MIBs must be 1155-compatible [3], it would be nice if those who submit them check them first.

Where are these MIB tools available for public FTP? Ideally, a simple syntax checker (that didn't actually generate code) would be nice.

In the ISODE 6.0 release there is a tool called MOSY which recognizes the 1155 syntax and produces a flat ASCII file. If you can run it through MOSY without problems then you are OK.

7.5. Suppose I want to create a private MIB object for causing some action to happen

, say, do a reset. Should the syntax or this object specify a value such as:

         Syntax:
            INTEGER {
               perform reset (1),
            }

even though there is only a single value? Or, is it ok to just allow a Set on this object with any value to perform the desired action? If the later, how is this specified?

For our SNMP manageable gizmos and doohickies with similar "action" type MIB variables, I've defined two values

            Syntax:
               INTEGER {
                  reset(1)
                  not-reset(2)
               }

And defined behavior so that the only valid value that the variable may be set to is "reset" (which is returned in the get response PDU) and at all other times a get/getnext will respond with "not-reset".


Google
Web
RFC-Ref