Re: VACM reports/responses

Hi, Sean,

The general design philosophy is that objects that are out 
of a MIB (VACM) view are treated as if they don't exist.
For get and set operations, if the entire object is out of view,
a noSuchObject exception should be returned.  If the object
is partially in view, but the particular instance you want is
not, a noSuchInstance exception should be returned.

Ref: RFC3416, 4.2.1 for get, which has more precise language than this.

In the case of getnext operations, the next instance that is in
the VACM view should be returned.  The instance may not be of the
object requested, if the remainder of the instances for that
object are out of view.  If there are no further instances (of 
any object) in the MIB view, then an endOfMibView exception should
be returned.

Ref: RFC3416, 4.2.2 for getnext  (for more precise language)

Note that SNMPv3 command responders will not generate noSuchName
errors in response to SNMPv3 requests.  See RFC2576 for more on this.

Best Regards,

Steve




On Thursday, May 8 2003, "Sean Lawless" <[email protected]> wrote:

> Greetings,
> 
> We are having difficulty locating a specification document for View based
> Access Control Model (VACM) error responses/reports.  Specifically, from a
> Command Responder perspective, what should be sent in response to a
> request that results in the VACM function isAccessAllowed returning
> notInView, noSuchView, etc.
> 
> >From rfc3414 and rfc3415, the best guess we can ascertain is to return a
> standard endOfMibView for GetNext requests that encounter any VACM problem
> and noSuchName for Get and Set requests.
> 
> Is this correct and does anyone know a document (rfc) that specifies this?
> 
> Thank you much and good day.
> 
> Sean Lawless
> Mibtonix, Inc.
> 
> 

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email protected]     Knoxville, TN 37920-9716 USA  http://www.snmp.com