Re: View Granularity Was:Re: SNMPv2 is a good thing.

[Aleksey Y Romanov <[e-mail]>]

> 
>
> Though RFC 1445 does indeed state, when refering to access control
> granularity at the object instance level, that "such granularity is
> considered beyond the scope of a SNMPv2 entity acting in an agent role",
> it does not preclude this level of access or suggest that these types
> of views should be rejected.  From my reading, it seems that object level
> granularity is not required to claim compliance (RFC 1445 page 8) but is
> useful in a number of situations.

OK. My agent is not going to support object granularity by two
reasons which really are not mportant:
     1. In my view it does not buy anything 
     2. The performance impact is significant: sometimes
        you will have to perform kernel digging just in order to
        find out that this instance is mapped out by the view
        The same is true but evere worse in case of get-next
        operations.

Again the reason  why is not so important. So, I can choose this
policy and it is compliant with SNMPv2 . What is appropriate reaction
of such an agent on  the following events ?

1. NMS is creating a view wich will impose instance level granularity
   on one or more of the variables.

2. Agent is dynamicaly mounting MIB subtree and some of currently
   defined views will impose  instance level granularity on
   on one or more of the variables in this subtree.

3. NMS is trying to access variable  using a context with a view
   which imposes instance level granularity on this variable.


> Thus, is it not an implementation
> issue whether an agent wishes to deal with instance level views or not?

IMHO, if it is not required by standard, it is an implemetation
issue.

> Also, could we please post discussions such as this to the snmp2 mailing
> list where they seem more appropriate.  

I will do cc: to this list, but I did not see anything over there
for a long time.

> 
> John
> 

Aleksey