HI,
Well, this discussion points out the problems with the RowStatus
model, and is a demonstration why many MIB definitions and
agent designs support ONLY values createAndGo(4), active(1),
and destroy(6).
To support other values requires that the resource manager
or most probably the agent to keep shadow copies or rows
in a table that have RowStatus values of notInService(2)
and notReady(3) to support action value createAndWait(5).
Supporting shadow copies mean that the agent design has
the following problems:
1) additional storage (there mat be a copy in the agent
and possibly in the resource manager of the values)
2) additional processing (On SNMP operations, both the
shadow copy and the actual values in the resource
manager have to be checked.)
3) consistency and rule definition and resolution
(That is, there may be multiple management interfaces
on a system (such as SNMP, CLI, WEB, etc), and
changes could be made through any. Ideally a change
via one of them and by operation of the resource
that is being managed will show up via retrieval
operations on any other management interface.)
The most important concept is that SNMP simply provides
access to management information in managed subsystems,
and the subsystems themselves are NOT contained inside
the SNMP agent.
Now I know that this layering is abused and not followed
in some systems due to:
1) lazy agent coders
2) unqualified agent coders
3) misinformed agent coders
4) systems lacking in SNMP friendly APIs to resource
managers
5) MIB designs that are a complete mismatch with the
model used by the resource implementation
I hope this note will help the unqualified and/or misinformed
agent coders.
See further comments inline below...
On Wed, 24 Nov 2004, Dave Shield wrote:
> Dave> I can envisage situations where a table might well be missing two
> Dave> or three "minor" column values, but still be ready to go live.
> Robert> I think that the RowStatus TC doesn't allow that.
>
>
> Hmmm... I see what you mean, but I don't think it's as simple as that.
> The RowStatus TC feels to be somewhat ambiguous (if not inconsistent).
>
> The definition of 'notReady' at the start of the description talks
> about *required* columns not having been instanciated[sic].
> The discussion of the agent under Interaction 2a and 2b talks
> about having *sufficient* information to make the row available.
> The discussion of the manager under Interaction 3 requires the
> manager to provide values for all missing instances, as you spotted
> The discussion of the agent under Interaction 4 talks about
> *sufficient* information again.
>
>
> I suggest that Interaction 3 is primarily aimed at the implementer of
> a management application, which only has the MIB interface to work with.
> The agent is closer to the device actually being managed, and is in a
> better position to determine whether or not it has sufficient information
> to make the row active.
First, the RowStatus model is only for "read-create" columns
and not "read-only" columns. Secondly, use of the RowStatus TC
REQUIRES that the MIB designer specify the columns whose instances
MUST exist before the row can be made active.
>
> > "until a
> > value is provided, the conceptual row may not be made available for
> > use by the managed device."
>
> I think your interpretation of that final comment feels to be overly
> prescriptive - it would automatically rule out the use of RowStatus
> with "sparse" tables. Such tables may be rare (and often confusing),
> but they are perfectly valid.
> I suspect that this is down to unwarrented assumptions when the
> text of this bit was drawn up. But I suggest that a more reasonable
> interpretation of this (still justifiable from the precise wording, but
> closer to the spirit of this TC) would be as a warning to the manager
> along the lines of:
> "if there are noSuchInstances in the row, you can *try* setting
> the row active, but you better be ready for this to fail."
> rather than as an instruction to the agent that it *must* fail.
>
>
> > it would be nice to get an indication, in
> > advance, that the agent thinks a row is ready to go active.
>
> But surely that's exactly what the definition of 'notReady' states:
> "the conceptual row ... is missing information necessary
> in order to be available...."
>
>
> > But the TC
> > explicitly states that "'notInService' has no implication regarding
> > the internal consistency of the row, availability of resources, or
> > consistency with the current state of the managed device".
>
> That's something different, IMO.
> It feels more of a warning that just because the agent *thinks* it's
> ready to make the row active, actually trying to do so may still fail.
>
> 'notInService' means it's worth a go - suck it and see
> 'notReady' means that it isn't, so don't even bother trying
NOTE: if there are external consistency requirements or resource
needs for values in a row, they are not checked while the row
is not active. When the RowStatus column is set to 'active',
the SET will fail with 'inconsistentValue' if inconsistancys
exist or resource needs cannot be met. If there are consistency
requirements between columns within a row, then it doesn't
matter the value of the RowStatus column. Those consistency
requirements must be met. (This is a place where the MIB designer
needs to be VERY clear, and ideally not create such tables
unless absolutely necessary.)
> > it looks like can_activate should only be called when the row is
> > actually being set to active.
>
> I disagree - this is a private internal routine, and we can call it
> whenever we wish. And I think it has a useful role to play, even
> once the row has been activated.
>
>
> Dave> That would also handle an active row becoming 'notReady' (due to some
> Dave> external change), and then back to active again.
>
> Robert> Hmm.. I think it would have to be notInService instead of notReady.
>
> Why?
> The TC explicitly allows a transition from 'notReady' to 'active' in
> response to an SNMP request. Why not in response to some external change?
I believe that it is not following the RowStatus for changes in
the resource to cause a row to transition from 'active' to
'notReady' or 'notInService'. I believe that the only change
that can occur in a resource is that which causes the row
to deleted (and, thus, there will never be a change of
RowStatus to be seen).
> I'll give you a fer-instance.
> Suppose I'm running a cafe, and have a row of toasters controlled via SNMP
> using the infamous Toaster-MIB. Half of them are turned on and working
> ('active') and half of them are on stand-by, ready for the expected rush
> at lunchtime ('notInService').
You are mixing two different concepts that use the same terms.
The status of a resource and the status of the row are different,
and you are falling into a MIB design trap of trying to optimize
the MIB design by combining two separate things.
In general, it doesn't make sense to use RowStatus on rows that
represent instances of physical components or instances of dynamic
resources that are created and deleted during operation of
the managed subsystem. (For example, RowStatus could not be
used to create TCP connections. And using it to delete rows
is a little overkill.)
> Then a fuse blows, and all the toasters are knocked out. Fortunately
> the SNMP device is powered via a UPS, so can report the fact ('notReady').
> I replace the fuse, and all the toasters come back again, just as they
> were before. I'd expect to see them reported as half-and=half 'active'
> and 'notInService' - rather than them all being 'notInService'
>
>
> That feels perfectly in keeping with the spirit of the RowStatus TC,
> but relies on using the 'can_activate' routine to calculate the RowStatus
> value dynamically.
>
> Or do you disagree?
This is an inappropriate example.
>
> Dave
>
Regards,
/david t. perkins
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
