Re: View Granularity

Aleksey Y Romanov <ralex@world.std.com> Fri, 14 May 1993 21:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11129; 14 May 93 17:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11125; 14 May 93 17:38 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23521; 14 May 93 17:38 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA23394> for ietf-archive@nri.reston.va.us; Fri, 14 May 93 17:39:10 EDT
Received: from world.std.com by thumper.bellcore.com (4.1/4.7) id <AA23386> for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 14 May 93 17:39:08 EDT
Received: by world.std.com (5.65c/Spike-2.0) id AA21540; Fri, 14 May 1993 17:39:05 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Aleksey Y Romanov <ralex@world.std.com>
Message-Id: <199305142139.AA21540@world.std.com>
Subject: Re: View Granularity
To: John Seligson <johns@synoptics.com>
Date: Fri, 14 May 1993 17:39:04 -0400 (EDT)
Cc: snmp2@thumper.bellcore.com, snmp@psi.com
In-Reply-To: <9305142022.AA18672@holbein> from "John Seligson" at May 14, 93 01:22:39 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2579

> 
> We have since agreed upon in our exchange that instance level view
> granularity is not required but may be supported, as an implementation
> permits.  If I misunderstood your original posting, I apologize.

Yes you did but it does not worth apology.

>  What 
> I believe you are now proposing is that, for agents that choose not to
> support instance level granularity, instance specific portions of a view
> subtree be ignored during creation, manipulation and operation.

I mean during operations only.

> 
> > Do you see anything wrong with it ?
> 
> It is my opinion that simply ignoring the instance portion of a specified
> view subtree is the wrong type of behavior for an agent.  An agent may
> choose to not support instance level granularity and reject (with the
> appropriate error value) requests attempting to create this type of entry.

I do think that to eliminate agents with dynamically mountable subtrees
is a too big price for this.

> Or an agent may support view subtrees with instance portions and deal with
> them in accordance with the specifications.

I never saw any problems here.

> To simply ignore the instance
> portion would be misleading to an NMS trying to create a specific view and
> this is undesirable.  An NMS must be told whether the REQUESTED operation was
> successful or not so that it can operate efficiently.  An NMS could query
> the viewTable and find specific subtrees yet the agent would not behave in
> the expected fashion.

IMHO, it will behave  in  expected fashion: it will ignore instance
portion of view any time there is such a part. :)


Let us consider other line of resoning.
a) Instance level granularity is not required by standard
b) So, NMS does not have to use instance level granularity
c) If, it happen to USE (not create) a view with such a level
   on some variable it is NMS side andian agent will react in
   a predictable manner.

May be itis more reasonable to return genErr in the case ?
I do not think so, but it looks not so bad.

> 
> Once again, could you please at least CC: the snmp2 mailing list on your

Sorry I will do it.

> responses.  I feel that list is the appropriate forum for these types
> of discussions.
> 
> John
> 

I am considering your arguments as valid ones. I just have a feeling
that to REQUIRE instance level granularity means too heavy burden for
an agent. Just imagine you have a 1000 instances of some
variable, doing get-next  you can dig down into kernel 1000 times just
in order to find out that all of them are mapped out by instance
level granularity.

Aleksey