Subject: Re: How to detect when to report noSuchInstance error?

From: Randy Presuhn <[email-masked]>
Date: Thu, 28 Dec 2000 15:58:51 -0800 (PST)

Hi -

Catching up on OLD email....

> Message-ID: <[email-masked]>
> Date: Tue, 05 Sep 2000 00:33:14 +0200
> From: [email-masked] (Frank Fock)
> To: "[email-masked]" <[email-masked]>
> Subject: How to detect when to report noSuchInstance error?
...
> When a subagent registers a row of a table (let's say ifEntry.1-22.1)
> at the master and a SNMP request for an instance of a non registered
> row (e.g., ifIndex.2) comes in, how does the master agent finds out
> whether it should return noSuchInstance (which would be correct) or
> noSuchObject (which would be wrong)?
> 
> Since the master cannot know through the AgentX protocol,
> that ifIndex is a multi-instance object, and since it cannot ask
> any subagent about ifIndex.2 (because no subagent has registered
> for that region) the master agent will have to return a noSuchObject
> error.
> 
> Has anyone solved this dilemma?
...

I think noSuchObject is a reasonable answer.  One could also
argue for noSuchName, since subagent technologies are, at
least in a historical sense, a kind of proxy (though 2573
takes pains to say that they are not).

I think the noSuchName/noSuchObject/noSuchInstance distinction
introduced with SNMPv2 has not proven to be useful, but
eliminating it would be too painful to even contemplate.

Do any management applications vary their behaviour based
on which of these three error-status values shows up in
a response?  I suspect that most will handle them in the
same way, making the question largely academic.

Looking more closely at RFC 1905 (and the update's)
clause 4.2.1, and then at how RFC 2573 describes when
the access decision is made, it looks like the whole
noSuchObject/noSuchInstance dichotomy is at not accounted for
in the processing steps described in RFC 2573.  Certainly RFC
2575 doesn't distinguish these two cases.

Perhaps this thread should move to the snmpv3 WG list?
Or maybe this is a can of worms that would be best
left buried.  :-)

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 29 Dec 2000 10:07:46 -0800 (PST)

Hi -

This morning, it occurred to me that there IS a way to get the
noSuchInstance to happen in a pure AgentX environment.  Just
have a "fallback" subagent claim the table's entire subtree,
and always respond to get requests with noSuchInstance.

The only get requests dispatched to this subagent would be
the ones for which no other subagent has registered the
row in question.  Viva le (la?) kludge!

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 29 Dec 2000 10:09:45 -0800 (PST)

Hi -

I'm forwarding a post from Bob Natale from yet another address,
which I have dutifully added to the agentx "posters" list.

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA08149;
> 	Thu, 28 Dec 2000 18:35:07 -0800 (PST)
> From: [email-masked]
> Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBT2Y2c27288;
> 	Thu, 28 Dec 2000 20:34:02 -0600 (CST)
> Received: from bnatale.acecomm.com (dhcppm15.acec.com [38.249.211.237])
> 	by relay1.acec.com (8.9.3/8.9.3) with ESMTP id VAA16556;
> 	Thu, 28 Dec 2000 21:36:02 -0500 (EST)
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
> Date: Thu, 28 Dec 2000 21:42:53 -0500
> To: Randy Presuhn <[email-masked]>
> Subject: Re:  How to detect when to report noSuchInstance error?
> Cc: [email-masked]
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> 
> At 12/28/2000:06:58 PM, Randy Presuhn wrote:
> 
> Hi Randy,
> 
> <...>
> I agree.
> At least for the management apps I am familiar with, the
> behavior is not materially different for any of these
> error-status values relative to any of the other two.
> (They leave it to the user to somehow correct the object
> name in the varbind, usually via a moderately friendly
> GUI front-end, with access to the relevant MIB object
> definitions as an aid in most cases.)
> 
> <...>
> If it needs to be continued, but...
> 
> I hope that conclusion is the consensus of the group!
> 
> Cordially,
> 
> BobN
> 
>