On Wed, 24 Nov 2004 10:45:03 +0000 Dave wrote:
DS> Dave> I can envisage situations where a table might well be missing two
DS> Dave> or three "minor" column values, but still be ready to go live.
DS> Robert> I think that the RowStatus TC doesn't allow that.
DS> 
DS> Hmmm...  I see what you mean, but I don't think it's as simple as that.
DS> The RowStatus TC feels to be somewhat ambiguous (if not inconsistent).

Yep, I notices the sufficient wording too. I've been hoping that Mr. Perkins
would jump in here with his 2 cents..

DS> >                                                            "until a
DS> > value is provided, the conceptual row may not be made available for
DS> > use by the managed device."
DS> 
DS> I think your interpretation of that final comment feels to be overly
DS> prescriptive - it would automatically rule out the use of RowStatus
DS> with "sparse" tables. Such tables may be rare (and often confusing),
DS> but they are perfectly valid.

Excellent point. I think the text is prescriptive, but you've convinced me that
the right thing to do is ignore that particular bit.

DS> >                  it would be nice to get an indication, in
DS> > advance, that the agent thinks a row is ready to go active.
DS> 
DS> But surely that's exactly what the definition of 'notReady' states:
DS>    "the conceptual row ... is missing information necessary
DS>     in order to be available...."

No, notReady means it definitely is not ready to be active. The problem is that
notInService only means it *may* be ready to be active, but it may not be.

DS> >                                                          But the TC
DS> > explicitly states that "'notInService' has no implication regarding
DS> > the internal consistency of the row, availability of resources, or
DS> > consistency with the current state of the managed device".
DS> 
DS> That's something different, IMO.
DS> It feels more of a warning that just because the agent *thinks* it's
DS> ready to make the row active, actually trying to do so may still fail.

The second and third phrases deal with that. But the first bit, 'the internal
consistency of the row' *is* something the agent might know something about.
Fer instance, if two columns must sum to < 100, the agent knows that it can't
go active if both equal 55, but has no way of conveying that.


DS> Dave> That would also handle an active row becoming 'notReady' (due to some
DS> Dave> external change), and then back to active again. 
DS> 
DS> Robert> Hmm.. I think it would have to be notInService instead of notReady.
DS> 
DS> Why?
DS> The TC explicitly allows a transition from 'notReady' to 'active' in
DS> response to an SNMP request.  Why not in response to some external change?

I don't think an agent should ever activate a row on its own. If the user
didn't set it active, they probably had a good reason! Didn't you see
"Terminator"? We can't let machines make decisions! They'll kill us all! ;->

DS> I'll give you a fer-instance.
DS> Suppose I'm running a cafe, and have a row of toasters controlled via SNMP
DS> using the infamous Toaster-MIB.   Half of them are turned on and working
DS> ('active') and half of them are on stand-by, ready for the expected rush
DS> at lunchtime ('notInService').
DS>   Then a fuse blows, and all the toasters are knocked out.  Fortunately
DS> the SNMP device is powered via a UPS, so can report the fact ('notReady').
DS>
DS> That feels perfectly in keeping with the spirit of the RowStatus TC,
DS> but relies on using the 'can_activate' routine to calculate the RowStatus
DS> value dynamically.
DS> 
DS> Or do you disagree?

Of course I do! ;-) In fact, I strongly disagree here.

First, check out the state diagram in the row status TC. There is no transition
from active or notInservice back to notReady. notReady is only used during row
creation, and once you move to notInService, there's no going back.

Second, you are overloading the RowStatus column to be OperStatus. If want
operational status, it needs it's own column.

-- 
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>

You are lost in a twisty maze of little standards, all different. 


-------------------------------------------------------
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

Reply via email to