Re: Setting multiple table rows in one set operation

On 17/01/2008, Mike Ayers <[email protected]> wrote:
>  I would strongly recommend against creating multiple rows in a single PDU
> despite the fact that, by spec, it should work, unless the MIB specifies that
> this is a supported operation.

I'd probably offer slightly different advice.
I would suggest that you don't *rely* on creating multiple rows in a single PDU,
without first checking whether this works in practise for a particular MIB
module implementation.

   It doesn't really matter whether the MIB says that this is or isn't
supported.
What is important is whether the *code* handles this correctly.

>   it looks to me like you're trying to create the index objects, which is definitely
> a bad idea, and (I'd have to hit the RFCs for this) probably illegal.

This is wrong - yes.

>From RFC 2578 - section 7.7.  (Mapping of the INDEX clause)

   Objects which are both specified in the INDEX clause of a conceptual
   row and also columnar objects of the same conceptual row are termed
   auxiliary objects.  The MAX-ACCESS clause for auxiliary objects is
   "not-accessible",

(so you shouldn't even be reading the index object, let alone setting a value)

                             except in the following circumstances:

(2)  ..... In the event that all of a conceptual
     row's columnar objects are also specified in its INDEX clause, then
     one of them must be accessible, i.e., have a MAX-ACCESS clause of
     "read-only".


Note "read-only" - not "read-write" or "read-create".
You still shouldn't be including this in a SET request.


>         In any case, the ability to create and retain rows is strictly internal to the
> MIB implementation, so if you're having trouble with this, you need to deal
> with the MIB's author.

Or to be more precise, the programmer who wrote the code to *implement* the
MIB module (rather than the person who designed the MIB itself).

   I suspect this is just a difference in terminology between Mike and myself.
I tend to use the term "MIB" to refer to the collection of managed object
definitions, rather than the code that implements these objects.   My guess
is that Mike is referring to the code file as the MIB.

  In either case, it's the person who wrote the code that needs to fix this.

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users