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
- Re: View Granularity Aleksey Y Romanov