Dave> Hmmm... I see what you mean, but I don't think it's as simple as that. Dave> The RowStatus TC feels to be somewhat ambiguous (if not inconsistent). Robert> Yep, I notices the sufficient wording too. I've been hoping that Robert> Mr. Perkins would jump in here with his 2 cents..
Yes - that thought had occurred to me too :-) David - any comments on this issue? Robert> it would be nice to get an indication, in Robert> advance, that the agent thinks a row is ready to go active. Dave> But surely that's exactly what the definition of 'notReady' states Robert> No, notReady means it definitely is not ready to be active. Exactly - if the agent *knows* the row isn't ready, it can say so (using 'notReady') Robert> The problem is that notInService only means it *may* be ready Robert> to be active, but it may not be. Yup - so the manager must be prepared for this to fail. But if the agent can provide a more informed response, why not let it? Robert> I don't think an agent should ever activate a row on its own. If Robert> the user didn't set it active, they probably had a good reason! Of course - but if they *did* make the row active (by pressing buttons on the front, or a command-line interface), then the SNMP information should reflect this. Remember that SNMP is not the only way to perform management. Robert> First, check out the state diagram in the row status TC. There is Robert> no transition from active or notInservice back to notReady. But that state diagram is only concerned with responding to SNMP SET requests. It is totally irrelevant when it comes to external influences. You're right that an SNMP manager can't *explicitly* force a row into the 'notReady' state, and the transitions for "any other column" probably implies that it shouldn't be done implicitly either. (Though I'd argue this is a reasonable thing to do, and the transition diagram is flawed). But it doesn't cover external influences. Robert> notReady is only used during row creation Where does it say that? Robert> Second, you are overloading the RowStatus column to be OperStatus. Yup. Robert> If want operational status, it needs it's own column. Why? I've got a perfectly serviceable column object which can do that job? Why clutter the MIB up with another (unnecessary) one? 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
