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.
> "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
> 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'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').
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?
Dave
-------------------------------------------------------
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
