Delivery-Date: Tue, 03 Sep 1996 07:59:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA19364 for X-agentx; Tue, 3 Sep 1996 07:59:23 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA19359 for ; Tue, 3 Sep 1996 07:59:22 -0700 (PDT) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA12164; Tue, 3 Sep 1996 10:39:45 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA17464; Tue, 3 Sep 1996 10:39:44 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA02700; Tue, 3 Sep 1996 10:42:59 -0400 Message-Id: <9609031442.AA02700@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Comments on AgentX MIB draft In-Reply-To: Your message of "Fri, 30 Aug 96 15:52:51 EDT." <199608301952.PAA10459@avalon.nexen.com> Date: Tue, 03 Sep 96 10:42:59 -0400 From: Mike Daniele X-Mts: smtp Hi Bert, >> OK. I've changed up(1) to open(1) and removed connecting, >> disconnecting, and closedBySubagentTimeout. >> >I have found that closedBySubagentTimeout is the most possible reason >why connections get closed (especially during testing when the >subagent loops or something). So again I would keep this specific >reason code. 1) How is this different than closedBySubagentError? (What other errors can occur beside timeout?) 2) Does this imply, and do you think the protocol-id should specify, that the master agent closes a logical connection whenever a subagent times out? Just once? For any registered region? >The axDefaultTimeout is what the master agent uses if a subagent does >not specifically specify a timeout value. I would suggest that subagents >do ineed not specify a timeout value but leave it up to the master agent >to use this default. Again in certain conditions, the master agents >default might not be good enough, and by making it read-write a >management station can change it if needed. It seems to me that the subagent developer knows what a reasonable timeout is for the implemented MIB objects. So it's far more likely that individua;l subagents will control this via the value specified during registration, than a (remote) manager will be able to detect that something is wrong with the AgentX default timeout value. >I know that one of our FDDI subagent developers needed a 30 second >timeout for one of the objects in the FDDI MIB (I don't recall right >away which one) for which he had to go out on the ring and collect >data which could take up to 30 seconds (he claimed). Maybe I misunderstand. What else does the subagent developer need other than the ability to specify a value of 35 or so when registering the MIB region containing this object? What good does it do the subagent developer to be able to set the master's default timeout value? Thanks, Mike   Delivery-Date: Tue, 03 Sep 1996 12:24:31 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA16496 for X-agentx; Tue, 3 Sep 1996 12:24:31 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA16491 for ; Tue, 3 Sep 1996 12:24:30 -0700 (PDT) Received: from hunch.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA16699; Tue, 3 Sep 1996 15:19:56 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA04995; Tue, 3 Sep 1996 15:19:55 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA02800; Tue, 3 Sep 1996 15:23:15 -0400 Message-Id: <9609031923.AA02800@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: AgentX protocol draft, ver 00.03 Date: Tue, 03 Sep 96 15:23:13 -0400 From: Mike Daniele X-Mts: smtp Hi Maria, >I think you'd be better off just using context here (and not saying >it's the same as a naming scope). I need to go read Entity MIB again, right? :-) > What's the relationship between the >context string that the subagent registers and the community string in >an SNMPv1 or SNMPv2c PDU? I think that's beyond the scope of this protocol, except to mention that o the master agent may have a local repository for mapping v1 or 2c comm strings into 'more complicated context information" (see section 7.2) o When sending agentx request pdus, the master appends context info "if it has determined a specific non-default context is associated with the request" (see the end of 7.2.1.1, 7.2.1.2, etc) Do you think more needs to be said about this? > > 6.2.1.1. agentx-Open-PDU Fields >... > > o.id - An Object Identifier which identifies the subagent. If > > the IS_AGENT_CAP bit in h.flags is set, this value > > identifies an agent capabilities statement with respect > > to the MIB modules supported by the subagent. Otherwise > > it represents a unique (enterprise-specific) > > sysObjectID. >Huh?? Bert suggested taking the OID and Descr the subagent provides in >the Open PDU and using them to populate the sysORTable. Is that what >this is trying to say? Yes. >But this IS_AGENT_CAP flag lets you override >that? No, it let's you specify that, as opposed to the default behavior (in general use by many current subagents, I think) where the passed oid is a sysObjectID-like thing used to identify the subagent, but does NOT imply that the oid should be represented in sysORTable. >I would suggest renaming the bit SYS_OR_ENTRY. It seemed more accurate to reference agent capabilities (since that's what the oid IS in this case) rather than what we might do with it currently (make an entry in sysORTable)... >What does the "otherwise" statement mean? Does it mean that this is the value that >the MA should use for sysObjectID? Since the MA implements the system >group, that would make sense. No! Bad wording on my part. It just means it's an oid that should identify the subagent, similar to how a sysObjectID is used. > > o.descr - An ASCII-encoded DisplayString describing o.id. >Same comment applies here as with o.id. Is this the value used to >populate sysORTable.sysORDescr or sysDescr, depending on the value of >the flag? o.oid and o.descr are used to populate axSAObjectID and axSADescr. If the bit is set, they are also used to populate sysORID and sysORDescr. Make sense? > > (r.region) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | 6 | 2 | 0 | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >... >Unless I'm confused, the first byte in r.region should be 4. No, 6 is correct. It means 6 subids follow, and the represented oid is obtained by appending those 6 to internet.2. See section 5.1. > > 8.2.1. Well-known Values >... > > A subagent creates a UNIX-domain socket endpoint called > > "/var/agentx/subagent", where is the textual representation > > of a unique identifier. The recommended value is (or is based on) > > the subagent's process identifier (e.g, > > "/var/agentx/subagent2133"). >Isn't there a length limit on these (16 characters?) You might want to >keep the important part () closer to the beginning. from un.h, /* * Definitions for UNIX IPC domain. */ #if defined(_SOCKADDR_LEN) || defined(_KERNEL) struct sockaddr_un { u_char sun_len; /* sockaddr len including null */ u_char sun_family; /* AF_UNIX */ char sun_path[104]; /* path name */ }; #else struct sockaddr_un { u_short sun_family; /* AF_UNIX */ char sun_path[104]; /* path name */ }; > > 1) Isn't this design harder to document and implement than, for > > example, one which limits each PDU to containing a single > > variable binding? >Isn't this discussion moot since a subagent can't do correct "as if >simultaneous" Set processing with only one variable at a time since >the test phase may require comparing the values of multiple variables? If we don't specify sending all varbind at once, then yes I think we'd need another PDU that tells the subagent "here are all the varbinds, complete the test phase". > > 6) SNMP version in the AgentX header > > I know may of you feel this reeks. But there were at least three > > implementors in Montreal who said it needs to be there. I'm > > hoping folks will think about it a bit more, possibly in >Yup, it reeks. Maybe take it out of protocol header and only put it in >PDUs that "need" it, like Get/Test/etc.? Is your objection that it's in the header and hence in some PDUs where it's not used? > > > > 9) States > > Do we need to specify protocol states? Some are implied by > > elements of procedure (can't register before open, etc.). > > Perhaps specifying that Test/Commit/Undo/cleanup must finish > > before other requests are forwarded to a subagent? >Yes, I think we do. We especially need to explain how to avoid >deadlock situations since a lot of "mid-level manager" applications >are going to be defined that will run as subagents. Can you expand on this? A deadlock situation I can imagine is based more on implementation details than protocol states... Thanks for your comments, Mike   Delivery-Date: Wed, 04 Sep 1996 00:15:06 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id AAA01710 for X-agentx; Wed, 4 Sep 1996 00:15:06 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id AAA01707 for ; Wed, 4 Sep 1996 00:15:05 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id AAA13665 for agentx@fv.com; Wed, 4 Sep 1996 00:15:08 -0700 From: R Venkatsubramaniam Message-Id: <199609040715.AAA13665@pointer.cisco.com> Subject: Re: AgentX protocol draft, ver 00.03 To: agentx@fv.com Date: Wed, 4 Sep 1996 00:15:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, > 7.1.2.1. Handling Duplicate OID Ranges > > As a result of this registration algorithm there are likely to be > duplicate OID ranges (regions of identical MIB objects registered to > different subagents) in the master agent's registered OID space. > Whenever the master agent's dispatching algorithm (see 7.2.1, > Dispatching AgentX PDUs) selects a duplicate OID range, the > determination of which one to use proceeds as follows: > > 1) Choose the one whose original agentx-Register-PDU > r.region contained the most subids, i.e., the most specific > r.region. Note: The presence or absence of a range subid > has no bearing on how "specific" one ObjectIdentifier is > compared to another. > > 2) If still ambiguous, there were duplicate regions. Choose the > one whose original agentx-Register-PDU specified the highest > priority. > > 3) If still ambiguous, there were duplicate registrations. > In this case, requests for objects within this OID range must > be dispatched (at least initially) to all subagents who have > registered the duplicate region. > > NOTE: This case may cause serious performance penalties > during operational dispatching. The REG_UNION bit should be > clear for all but the most unwieldy subagent configurations. > It is almost always possible to use the indexing structure of > conceptual tables to provide unique registrations among > subagents sharing the implementation of such tables, and that > is the preferred configuration. What happens when a 'Set' is performed on an object id. registered by two sub-agents with duplicate registration ? If both the sub-agents try to perform the 'set', say one of the sub-agents is able to perform the 'set', the other is not due to, say a transient problem, what is the resultant status of the 'set' ? My humble suggestion here is to NOT to allow more than one sub-agent register the same object id. Assuming that the master agent is 'responsible' for the sysuptime, 'sysuptime' can be used as the final tie-breaker by the master agent. Whichever sub-agent registers first (sysuptime is used for this time comparison), should be dispatched the request related to the object id. in question (assuming the sysuptimes are not equal !). I AM missing something !! Thanks, - Venkat.   Delivery-Date: Wed, 04 Sep 1996 07:41:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA11599 for X-agentx; Wed, 4 Sep 1996 07:41:41 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA11592 for ; Wed, 4 Sep 1996 07:41:40 -0700 (PDT) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA14525; Wed, 4 Sep 1996 10:30:14 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA20089; Wed, 4 Sep 1996 10:30:14 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA03143; Wed, 4 Sep 1996 10:33:33 -0400 Message-Id: <9609041433.AA03143@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: AgentX protocol draft, ver 00.03 Date: Wed, 04 Sep 96 10:33:33 -0400 From: Mike Daniele X-Mts: smtp >What happens when a 'Set' is performed on an object id. registered by >two sub-agents with duplicate registration ? If both the sub-agents try to >perform the 'set', say one of the sub-agents is able to perform the 'set', >the other is not due to, say a transient problem, what is the resultant >status of the 'set' ? Well, the agentx-Test-PDU would be sent to both subagents. If one responds with a successful response, and the other returns an error, the successful one wins and becomes the target subagent. This is described in 7.2.4.4 (although not very clearly, after re-reading it for the 10th time..) If both respond successfully, the master agent picks one by magic. The unselected subagents are sent a Cleanup-PDU and so never actually perform the Set. The upshot is that a single subagent is determined to be responsible for the MIB region in question, and only that subagent receives the Commit-PDU. >My humble suggestion here is to NOT to allow more than one sub-agent register >the same object id. Assuming that the master agent is 'responsible' for >the sysuptime, 'sysuptime' can be used as the final tie-breaker by the master >agent. Whichever sub-agent registers first (sysuptime is used for this time >comparison), should be dispatched the request related to the object id. in >question (assuming the sysuptimes are not equal !). Feedback from some folks with lots of experience with extensible agents is that this feature is required. Many others agree with you :-) So far we've avoided specifying optional behavior. Perhaps unionized registration is a reasonable candidate? >I AM missing something !! In all likelihood, so am I... :-) Mike   Delivery-Date: Wed, 04 Sep 1996 08:33:16 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA22633 for X-agentx; Wed, 4 Sep 1996 08:33:15 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by fv.com (8.7.4/8.7.3) with ESMTP id IAA22630 for ; Wed, 4 Sep 1996 08:33:14 -0700 (PDT) Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA16192; Wed, 4 Sep 1996 11:21:56 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA20360; Wed, 4 Sep 1996 11:21:55 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA03167; Wed, 4 Sep 1996 11:25:14 -0400 Message-Id: <9609041525.AA03167@bernie.zk3.dec.com> To: agentx@fv.com Subject: REG_CLUSTER bit in h.flags Date: Wed, 04 Sep 96 11:25:14 -0400 From: Mike Daniele X-Mts: smtp Hello, I forgot to write something about this in the appendix of the latest draft. Some platforms (Windows NT for one) support IP clusters, and the notion of a cluster alias. Without diving down too much of a rathole, a cluster alias is a host name/address that is instantiated by multiple hosts (called cluster members). Clients acccess the cluster alias like any other host, but packets targetted for the alias may be handled specially when received. The main purpose is "fault tolerance", if a cluster member goes down the cluster alias is still reachable and functioning as long as one cluster member is up. Another typical function of the cluster is load balancing. Alias code running at the IP layer actually retargets packets to specific cluster members in a modified round-robin fashion. Inbound TCP connection requests would typically be load balanced, but TCP packets sent for existing connections would not (they would be sent to the cluster member which accepted the connection). UDP packets are always distributed amongst the cluster members, unless the application using UDP carries sufficient state for app-specific code to direct the packets to specific members. SNMP does not carry such state, and as such would be targetted to various cluster member nodes according to the round-robin algorithm. This would essentially break SNMP, since the manager would see very different information coming back from what appears to be the same managed node. (For instance, at time t a request sent to the alias address for interface 1 is forwarded to member A, whose ifTable has an ethernet interface associated w/ ifIndex 1. At any subsequent time t+ this same request might be forwarded to cluster member B, whose interface 1 is ATM, or that might not even have an interface 1.) The bottom line is that SNMP requests received on a cluster alias address should only be serviced if the MIB data referenced in the request is cluster-wide (exactly the same in name and value on each cluster member). Hence the REG_CLUSTER bit, to be used in the agentx-Register-PDU. If set, the subagent is indicating the registered region IS cluster wide. The default is not set, meaning the data is not cluster-wide. (Internet-standard MIB data would almost never be cluster-wide.) This provides an extensible, transparent way for a master agent that is cluster-aware, to know what MIB regions are "safe", without having to know about specific MIBs or variable names. All cluster-specific issues (how does the master know it received an SNMP request on a cluster address? how does the subagent know (or ensure) its data is cluster-wide?) are implementation-specific. *Currently*, I don't believe NT clusters do this dynamic round-robin retargetting. (Digital UNIX and OpenVMS do.) Comments? Mike   Delivery-Date: Wed, 04 Sep 1996 10:33:48 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA20354 for X-agentx; Wed, 4 Sep 1996 10:33:48 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id KAA20346 for ; Wed, 4 Sep 1996 10:33:47 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id NAA42032; Wed, 4 Sep 1996 13:31:43 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id NAA207522; Wed, 4 Sep 1996 13:31:16 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA26913; Wed, 4 Sep 1996 13:31:15 -0400 From: Uri Blumenthal Message-Id: <9609041731.AA26913@hawpub.watson.ibm.com> Subject: Re: AgentX protocol draft, ver 00.03 To: daniele@zk3.dec.com (Mike Daniele) Date: Wed, 4 Sep 1996 13:31:15 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609041433.AA03143@bernie.zk3.dec.com> from "Mike Daniele" at Sep 4, 96 10:33:33 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > >What happens when a 'Set' is performed on an object id. registered by > >two sub-agents with duplicate registration ?......... > > Well, the agentx-Test-PDU would be sent to both subagents. If one responds > with a successful response, and the other returns an error, the successful > one wins and becomes the target subagent................ > If both respond successfully, the master agent picks one by magic. I hate designs which are supposed to work by magic, and strongly urge the designers to reconsider. In my [humble?] opinion, the problems so far outweight the benefits of duplicate registration, that it's sheer folly to go that way. Also, would somebody care to explain what it means from the managed device point of view when a sub' succeeds or fails in Set operation? How does it map onto "multiple ownership" of an OID? An example: Set - emergency shutdown to blocks 2 and 4 of nuclear powerplant. Both share the same OID, block 1 succeeds, block 4 fails. "Master agent" returns success. (:-) > >My humble suggestion here is to NOT to allow more than one sub-agent register > >the same object id. > > Feedback from some folks with lots of experience with extensible agents is > that this feature is required. Many others agree with you :-) Well, I for one think that such "extensibility" is unnecessary trouble. It's better to satisfy 90% of the market with simple straightforward design than bend over backwards satisfying 97% (and I'm not even sure these "perversions" account for that much) ending up with a mess where "magic" is required to explain how the protocol operations work. [Maybe we should split, and one group will build a "simple" multiplexing protocol, while the other one will create a "super-multiplexer", that does everything for everybody, including maybe shoe-polishing? :-] > So far we've avoided specifying optional behavior. > Perhaps unionized registration is a reasonable candidate? Quite possibly. > >I AM missing something !! > > In all likelihood, so am I... :-) Let me enlighten you then (:-) - it's SIMPLICITY and STRAIGHTFORWARD-NESS in the protocol, that appears to be lost. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Wed, 04 Sep 1996 11:46:29 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA07262 for X-agentx; Wed, 4 Sep 1996 11:46:29 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id LAA07258 for ; Wed, 4 Sep 1996 11:46:28 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id LAA08180; Wed, 4 Sep 1996 11:43:56 -0700 From: R Venkatsubramaniam Message-Id: <199609041843.LAA08180@pointer.cisco.com> Subject: Re: AgentX protocol draft, ver 00.03 To: daniele@zk3.dec.com (Mike Daniele) Date: Wed, 4 Sep 1996 11:43:56 -0700 (PDT) Cc: agentx@fv.com In-Reply-To: <9609041433.AA03143@bernie.zk3.dec.com> from "Mike Daniele" at Sep 4, 96 10:33:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > >What happens when a 'Set' is performed on an object id. registered by > >two sub-agents with duplicate registration ? If both the sub-agents try to > >perform the 'set', say one of the sub-agents is able to perform the 'set', > >the other is not due to, say a transient problem, what is the resultant > >status of the 'set' ? > > Well, the agentx-Test-PDU would be sent to both subagents. If one responds > with a successful response, and the other returns an error, the successful > one wins and becomes the target subagent. This is described in 7.2.4.4 > (although not very clearly, after re-reading it for the 10th time..) > > If both respond successfully, the master agent picks one by magic. > > The unselected subagents are sent a Cleanup-PDU and so never actually > perform the Set. The upshot is that a single subagent is determined to be > responsible for the MIB region in question, and only that subagent receives the > Commit-PDU. > > >My humble suggestion here is to NOT to allow more than one sub-agent register > >the same object id. Assuming that the master agent is 'responsible' for > >the sysuptime, 'sysuptime' can be used as the final tie-breaker by the master > >agent. Whichever sub-agent registers first (sysuptime is used for this time > >comparison), should be dispatched the request related to the object id. in > >question (assuming the sysuptimes are not equal !). > > Feedback from some folks with lots of experience with extensible agents is > that this feature is required. Many others agree with you :-) > > So far we've avoided specifying optional behavior. Perhaps unionized registration > is a reasonable candidate? > Mike, I agree with you totally on Test-Commit-Cleanup process. If two sub-agents are equally specific about the object id, have equal priorities, both are functional, then their ability to 'set' should be considered for dispatching. I think the 'magic' is sysuptime. Also, for 'get' operations, where there is no check for ability to 'get', the 'magic' should be applied immediately on sub-agents which are functional. Thanks, Venkat.   Delivery-Date: Wed, 04 Sep 1996 12:26:16 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA16255 for X-agentx; Wed, 4 Sep 1996 12:26:16 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA16251 for ; Wed, 4 Sep 1996 12:26:15 -0700 (PDT) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA05411; Wed, 4 Sep 1996 15:18:07 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA06120; Wed, 4 Sep 1996 15:18:15 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA03274; Wed, 4 Sep 1996 15:21:25 -0400 Message-Id: <9609041921.AA03274@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: AgentX protocol draft, ver 00.03 Date: Wed, 04 Sep 96 15:21:25 -0400 From: Mike Daniele X-Mts: smtp Uri, >I hate designs which are supposed to work by magic, and strongly urge >the designers to reconsider. In my [humble?] opinion, the problems so >far outweight the benefits of duplicate registration, that it's sheer >folly to go that way. >Also, would somebody care to explain what it means from the managed >device point of view when a sub' succeeds or fails in Set operation? >How does it map onto "multiple ownership" of an OID? >An example: Set - emergency shutdown to blocks 2 and 4 of nuclear >powerplant. Both share the same OID, block 1 succeeds, block 4 >fails. "Master agent" returns success. (:-) I can't quite follow your question. Is it this? 2 subagents register the nppBlockTable in the nuclearPowerPlant MIB. The master agent receives SetRequest { nppBlockAdminStatus.1 down, nppBlockAdminStatus.4 down } If I've guessed correctly and this is in fact the scenario you're concerned about, I think the subsequent processing is fairly straightforward. a) master agent sends agentx-Test-PDU with both variables, to both subagents. b1) both subagents send back error status: master picks one by magic, and reports that back to the manager master sends Cleanup-PDU to both subagents. end of processing b2) subagent A sends back success, subagent B sends back failure master selects A as the target subagent, and sends B a Cleanup-PDU all as specified by AgentX. b3) both subagents send back success master picks one of them by maic as target subagent, and sends Cleanup-PDU to the other. c) Now that there is a single target subagent (for these variables) that has passed the test phase, master agent proceeds thru Commit,Undo and cleanup phases as usual. I don't see how the master agent could end up reporting a successful Set operation unless at least 1 of the subagents actually did perform the Set. The other issue I suppose is what if one of these subagents really DOES know how to control the nppblockTable, and the other doesn't, yet we allow them both to be involved in the Set. Potentially the stupid subagent could succeed in the test phase when the smart subagent (correctly) fails. The stupid subagent becomes the target and receives the Commit, potentially causing a meltdown. This problem isn't fixed by disallowing unionized registrations. If the stupid subagent registers first, it would be dispatched to anyway. AgentX can't guard against incorrect MIB instrumentation. >Well, I for one think that such "extensibility" is unnecessary trouble. >It's better to satisfy 90% of the market with simple straightforward >design than bend over backwards satisfying 97% (and I'm not even >sure these "perversions" account for that much) ending up with >a mess where "magic" is required to explain how the protocol >operations work. The "magic" you object to are the implementation-specific details. With respect to unionized registrations, the implementation-specific details are o how to formulate the correct response when all subagent's indicate failure o how to choose 1 subagent when more than 1 return a successful response (and for Gets, varbinds with the same name) These don't seem like show-stoppers to me as far as the protocol spec is concerned. I don't relish coding the master agent to handle this tho... >[Maybe we should split, and one group will build a "simple" multiplexing >protocol, while the other one will create a "super-multiplexer", that >does everything for everybody, including maybe shoe-polishing? :-] >> So far we've avoided specifying optional behavior. >> Perhaps unionized registration is a reasonable candidate? >Quite possibly. Well, this seems like a reasonable solution. And I was mistaken in my previous message about options, we do have one presently. So if we adopt this as well, the optional behavior in AgentX would be o supporting non-default context in the master agent o supporting unionized registrations in the master agent (master would fail duplicate registrations (same oid, same priority, same context)) Mike   Delivery-Date: Wed, 04 Sep 1996 12:58:58 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA22665 for X-agentx; Wed, 4 Sep 1996 12:58:58 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA22652 for ; Wed, 4 Sep 1996 12:58:55 -0700 (PDT) Received: from hunch.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA11327; Wed, 4 Sep 1996 15:54:39 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA07662; Wed, 4 Sep 1996 15:54:45 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA03301; Wed, 4 Sep 1996 15:57:58 -0400 Message-Id: <9609041957.AA03301@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: AgentX protocol draft, ver 00.03 Date: Wed, 04 Sep 96 15:57:58 -0400 From: Mike Daniele X-Mts: smtp >Mike, >I agree with you totally on Test-Commit-Cleanup process. If two sub-agents >are equally specific about the object id, have equal priorities, both are >functional, then their ability to 'set' should be considered for dispatching. >I think the 'magic' is sysuptime. Also, for 'get' operations, where there >is no check for ability to 'get', the 'magic' should be applied immediately >on sub-agents which are functional. >Thanks, >Venkat. That can't work. The whole idea of unionized registration is that multiple subagents register the same oid (because there is no reasonable way to register more fully qualified oids), but instantiate different variables within that region. Your scheme would result in all the other subagents (and their variables) being omitted. (Note, if we make unionized registration optional, and a master agent does not implement it, then the effect would be similar to what you describe. The difference being the duplicate registrations would fail, instead of accepting them but never dispatching to them.) Mike   Delivery-Date: Wed, 04 Sep 1996 13:32:07 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA00186 for X-agentx; Wed, 4 Sep 1996 13:32:06 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id NAA00180 for ; Wed, 4 Sep 1996 13:32:05 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id QAA29983; Wed, 4 Sep 1996 16:32:05 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08395; Wed, 4 Sep 1996 16:30:51 -0400 Date: Wed, 4 Sep 1996 16:31:18 EDT From: Bob Natale Subject: AgentX simplification and optional elements To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Wed, 04 Sep 96 15:21:25 -0400 > Subject: Re: AgentX protocol draft, ver 00.03 Hi Mike, <...> >>> So far we've avoided specifying optional behavior. >>> Perhaps unionized registration is a reasonable candidate? > >>Quite possibly. > > Well, this seems like a reasonable solution. And I was mistaken > in my previous message about options, we do have one presently. > > So if we adopt this as well, the optional behavior in AgentX would be > > o supporting non-default context in the master agent > o supporting unionized registrations in the master agent > (master would fail duplicate registrations (same oid, > same priority, same context)) Speaking as a wg contributor: I would favor this course of action. I strongly endorse Uri's call for simplifications that benefit the 90% cases. Speaking as wg chair: Thanks hugely to Mike's efforts and the detailed (sometimes off-list) reviews and contributions by several other key participants and to Dale's key role in making sure the documents are readable and consistent as a set, the AgentX protocol is taking shape. We are running a bit behind schedule, but *will* make our date with destiny by the end of the year. It is appropriate at this point, as Mike continues to address the few remaining gaps, to look for ways to prune off any excesses as well. To that end, we should recall that our primary objective is to publish a protocol for agent extensibility which makes it technically and economically attractive for component vendors to build and deploy an AgentX subagent that will interoperate with multiple, independently deeveloped AgentX master agents. Many such compoonents will rely only upon a familiar subset of the kind of functionality required by a much smaller number of other, more complex, components. Viability for the former will likely mean not saddling them with the much heavier technical requirements of the latter. If we can make widespread access to AgentX-enabled master agents available to a large majority of component vendors--eliminating the need on their part to write to SMUX, DPI, and proprietary protocols, or to pick one of the above and limit themselves and their user base thusly-- that will be *the* win we were tasked to deliver. The master agent and other elements of an overall extensible agent environment can be arbitrarily more capable and feature- rich, as may suit the needs of vendors and customers. That is, they may well and almost certainly will contain a (large and possibly varied) superset of extensible agent functionaltiy. That is a good thing. The purpose of the AgentX protocol (and, possibly, its MIB and its API) is to promote the development and deployment of new managed components. We'd rather get 1000 new managed components who share the same subset of, say, 10 extensible agent features than get 100 new managed components who share the same superset of, say, 50 extensible agent features. Well, something like that anyway. Let's press on. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 04 Sep 1996 13:33:29 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA00462 for X-agentx; Wed, 4 Sep 1996 13:33:29 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id NAA00458 for ; Wed, 4 Sep 1996 13:33:27 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id QAA75324; Wed, 4 Sep 1996 16:31:23 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id QAA28697; Wed, 4 Sep 1996 16:30:56 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA41192; Wed, 4 Sep 1996 16:30:56 -0400 From: Uri Blumenthal Message-Id: <9609042030.AA41192@hawpub.watson.ibm.com> Subject: Re: AgentX protocol draft, ver 00.03 To: daniele@zk3.dec.com (Mike Daniele) Date: Wed, 4 Sep 1996 16:30:55 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609041921.AA03274@bernie.zk3.dec.com> from "Mike Daniele" at Sep 4, 96 03:21:25 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > I can't quite follow your question. Is it this?............. > I don't see how the master agent could end up reporting a successful > Set operation unless at least 1 of the subagents actually did perform > the Set. In short - it could be unacceptable to have "at least one" sub' succeed. and I could envision cases when no matter what decision master agent made about which error code [several sub's returned naturally different erros :-] to pass up, it will lose (i.e. mislead the NMS). > The other issue I suppose is what if one of these subagents really DOES > know how to control the nppblockTable, and the other doesn't, yet we allow > them both to be involved in the Set. Yup, "the audience is warming up" (:-). > The "magic" you object to are the implementation-specific details. You mean - not "The Encyclopedia Necromantik"? (:-) > Well, this seems like a reasonable solution. And I was mistaken > in my previous message about options, we do have one presently. > So if we adopt this as well, the optional behavior in AgentX would be > o supporting non-default context in the master agent > o supporting unionized registrations in the master agent > (master would fail duplicate registrations (same oid, same priority, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yes! > same context)) Now you're talking! (:-) In short - yes. This seems to be THE way to do it. Anybody else cares to comment? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Wed, 04 Sep 1996 14:46:43 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA17147 for X-agentx; Wed, 4 Sep 1996 14:46:43 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by fv.com (8.7.4/8.7.3) with SMTP id OAA17143 for ; Wed, 4 Sep 1996 14:46:42 -0700 (PDT) Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA00881; Wed, 4 Sep 96 17:46:39 -0400 Date: Wed, 4 Sep 96 17:46:39 -0400 From: Jeff Case Message-Id: <9609042146.AA00881@seymour16.snmp.com> To: agentx@fv.com Subject: an invitation for a face-to-face interaction Cc: marsha@seymour16.snmp.com dear agent-x-ers bob natale wrote me looking for opportunities for face-to-face interactions with regard to agent-x issues we discussed this via a few email exchanges and he suggested that we "piggyback" on an upcoming event for any and all of us who are planning on being there anyway networld+interop will be in atlanta sept 16-20 i think bob got the idea too late for him to be able to schedule a birds-of-a-feather session on agent extensibility however, an number of people interested in agent extensibility will already be gathering in atlanta for the 4th Meeting of the EMANATE Users Group bob would like to have a physical "place to point people to so that we can meet briefly in a corner of the room or hallway after conclusion of the primary agenda" since bob assured me that the agent-x component would not overwhelm the primary purpose of the meeting, we are happy to work with him on this, so ... You are cordially invited to attend the EMANATE Users Group Reception and Product Update at Networld+Interop Atlanta '96 Room Glenmar B Omni Hotel at CNN Center Thursday September 19 from 8:00 to 10:00 p.m. Light hors d'oeuvres will be served some of the "official" interop bofs are being held in the georgia world congress center or in the omni hotel, which is right next door, so if you, like bob natale, want to catch the beginning of the winsock bof before you participate in the discussions of agent extensibility, it is geographically possible please feel free to join us if you like if you are unable to join us, bob is going to get someone to take some notes and post them to this list if any are appropriate since there will be food, we do ask that if you plan to attend that you rsvp via a brief email to marsha@snmp.com so that we can get the logistics right if you want more information about networld+interop and you are in the united states, you may want to call 1 800 interop and ask them to fax you some information about the event bob: please feel free to add anything i missed or correct anything i mis-stated regards, jdc   Delivery-Date: Fri, 06 Sep 1996 00:53:55 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id AAA16454 for X-agentx; Fri, 6 Sep 1996 00:53:55 -0700 (PDT) Received: from stortek.com (stortek.com [129.80.22.249]) by fv.com (8.7.4/8.7.3) with SMTP id AAA16451 for ; Fri, 6 Sep 1996 00:53:54 -0700 (PDT) Received: from garonne.stortek.com by stortek.com with SMTP id AA11317 (5.65c/IDA-1.4.4 for ); Fri, 6 Sep 1996 01:53:55 -0600 Received: from chambord.stortek.com by garonne.stortek.com (SMI-8.6/SMI-SVR4) id JAA12743; Fri, 6 Sep 1996 09:53:48 +0200 Received: by chambord.stortek.com (SMI-8.6/SMI-SVR4) id JAA08235; Fri, 6 Sep 1996 09:54:26 +0200 Date: Fri, 6 Sep 1996 09:54:26 +0200 From: driffa@garonne.stortek.com (Driffa Benamar (Toulouse)) Message-Id: <199609060754.JAA08235@chambord.stortek.com> To: agentx@fv.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: AAAAAAAAAAAAAAAAAAAAAA==   Delivery-Date: Fri, 06 Sep 1996 01:01:08 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id BAA17744 for X-agentx; Fri, 6 Sep 1996 01:01:08 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id BAA17741 for ; Fri, 6 Sep 1996 01:01:07 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id BAA07357; Fri, 6 Sep 1996 01:01:09 -0700 From: R Venkatsubramaniam Message-Id: <199609060801.BAA07357@pointer.cisco.com> Subject: Multiple range of sub.ids. in an obj.id. To: agentx@fv.com Date: Fri, 6 Sep 1996 01:01:08 -0700 (PDT) Cc: rvenkat@cisco.com (R Venkatsubramaniam) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Mike, In section 6.2.3 .... While exemplifying the 'method of defining one range of sub-id' in the object identifier... " This permits registering a conceptual row with a single PDU. For example, the following PDU would register row 7 of the RFC 1573 ifTable (1.3.6.1.2.1.2.2.1.1-22.7): (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.priority | r.timeout | 5 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" Why can't more than one range of sub.ids be used in an object identifier ? Suppose a subagent wants to register two rows 7 and 8 of the ifTable. The following notation will be very useful : ifTable (1.3.6.1.2.1.2.2.1.1-22.7-8). Correspondingly, the PDU will be changed as follows : (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.priority | r.timeout | 2 | 5, 6 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22, 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the range sub id. and the upper bounds are now a list of items. The '2' after the r.timeout indicates the no. of range sub. ids. That is the 'No. of Range Sub. ids' field. Comments ? - Venkat.   Delivery-Date: Fri, 06 Sep 1996 02:09:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id CAA28252 for X-agentx; Fri, 6 Sep 1996 02:09:03 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id CAA28232 for ; Fri, 6 Sep 1996 02:09:02 -0700 (PDT) Message-Id: <199609060909.CAA28232@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7008; Fri, 06 Sep 96 05:09:11 EDT Date: Fri, 6 Sep 96 11:08:56 DST From: "Bert Wijnen" To: agentx@fv.com Subject: Latest Draft and discussions on the mailing list I am getting worried. It seems we're tending in the direction of over-disgn. PLEASE adhere to the KISS principle. The more complex you make this, the less chance that we will see wide implementation. Go for the 80-20 rule (80% of fucntion for 20% of cost). I did not have time yet to do a detaled review of the last draft. Will try to do that next week. But I do want to warn against all the bells and wistles that some seem to want to include. Bert   Delivery-Date: Fri, 06 Sep 1996 07:18:52 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA00963 for X-agentx; Fri, 6 Sep 1996 07:18:52 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA00958 for ; Fri, 6 Sep 1996 07:18:51 -0700 (PDT) Received: from hunch.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA00199; Fri, 6 Sep 1996 10:05:43 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA14348; Fri, 6 Sep 1996 10:05:42 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA04199; Fri, 6 Sep 1996 10:08:56 -0400 Message-Id: <9609061408.AA04199@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Latest Draft and discussions on the mailing list Date: Fri, 06 Sep 96 10:08:54 -0400 From: Mike Daniele X-Mts: smtp Bert, >From: "Bert Wijnen" >To: agentx@fv.com >Subject: Latest Draft and discussions on the mailing list >I am getting worried. >It seems we're tending in the direction of over-disgn. >PLEASE adhere to the KISS principle. The more complex you make this, >the less chance that we will see wide implementation. >Go for the 80-20 rule (80% of fucntion for 20% of cost). >I did not have time yet to do a detaled review of the last draft. >Will try to do that next week. >But I do want to warn against all the bells and wistles that some >seem to want to include. I'm glad you'll be doing a detailed review soon. While it's hard to respond to your concerns without specific data, I'm guessing you probably have the general sense, that "AgentX has gotten too big and too complicated". And some other folks probably feel that way too, so it may be worthwhile to address that in a general way. AgentX *is* bigger and more complicated than SMUX & DPI, etc, for 2 reasons: 1) We decided early on that this spec must contain very specific elements of procedure. None of the other specs (that I'm aware of) really describe this at all. That alone accounts for 20 pages of the i-d. 2) We decided early on that AgentX MUST define far more functionality than its predecessors. Some of this is mandatory, and some of it is optional, but it all needs to be written down in copious detail if this spec is to be implementable, and AgentX giblets truly interoperable. This makes the spec even bigger, but I don't think it makes implementations (without the optional features) *that* much more involved than existing code. Substantial changes that a master agent MUST implement are o Index reservation (updated spec will be out before Interop) o Registration of conceptual row in single PDU (range subid) o Registration at any level, new dispatching rules to handle that Substantial changes a mater agent MAY implement are o Registration and dispatching for non-default context o Unionized registration and dispatching (to multiple subagents for the same variable) And there is new transfer syntax, and modified PDU fields (altho we still have essentially the same PDUs as DPI). The dispatching and marshalling algorithms are probably different if DPI does 1 variable oer PDU, but I don't think that's a real big change. MIB support for RFC 1907, and dispatching Bulk-PDUs, you probably would have added anyway... Subagent code that doesn't support the new features should require minimal change. Hopefully subagent APIs that don't need to support the new features won't have to change at all. In short, when I step back and think about implementing this, if I ignore multiple contexts and unionized registrations, it seems pretty straightforward. (Hopefully those words won't come back to bite me :-) I'm not saying the i-d is perfect by any means, and I'm certainly not trying to squelch comments or suggested changes. I *am* saying however that if you accept 1) and 2) above, as we all did at the onset, I don't think you can avoid an i-d that's got 50 or so non-trivial pages. Regards, Mike   Delivery-Date: Fri, 06 Sep 1996 08:33:42 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA17322 for X-agentx; Fri, 6 Sep 1996 08:33:42 -0700 (PDT) Received: from world.bostech.com (world.bostech.com [192.52.71.122]) by fv.com (8.7.4/8.7.3) with SMTP id IAA17317 for ; Fri, 6 Sep 1996 08:33:39 -0700 (PDT) From: dkeeney@bostech.com Received: from btrd.bostech.com (opus.bostech.com) by world.bostech.com (4.1/SMI-4.1) id AA07772; Fri, 6 Sep 96 10:56:24 EDT Received: from heat.bostech.com by btrd.bostech.com (4.1/SMI-4.0) id AA13022; Fri, 6 Sep 96 11:00:49 EDT Message-Id: <9609061500.AA13022@btrd.bostech.com> Subject: Multiple range of sub.ids. in an obj.id. (fwd) To: agentx@fv.com Date: Fri, 6 Sep 1996 11:00:47 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, > Why can't more than one range of sub.ids be used in an > object identifier ? > Lets keep it simple. If want to register two or more rows, send seperate registrations. OID format: In keeping with "simple is better" approach I would like to go back to the OID's as null terminated ASCII strings. I have implemented OID's both as integer arrays and strings. Strings are much easier to work with and debug (except perhaps for the IBM folks). Compairing two string OID's with strcmp() does not always work but you do not have to convert to an integer array either. (Compare byte per byte until a missmatch, convert remaining bytes to integer using atoi and compare.) I know this has already been hashed out but I like to toss in my thoughts. Subagent Dispatching: The "keep it simple" principle should apply to the dispatching as well. Lets dispatch requests for any one OID range to only ONE subagent, letting the master agent determine which one it should be. There is no really good solution as to how the master agent determines which to dispatch to but I contend that it does not matter. If two subagents register the same region they should be considered equally appropreate. If a manager (a human or a management station) knows that they are not equal due to some additional information, then there should be a way to set the priority to resolve the issue. But lets not complicate the issue by adding elaberate logic to the master agent just to choose between two equal choices. keep it simple or it will not be accepted... David Keeney   Delivery-Date: Fri, 06 Sep 1996 09:53:28 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id JAA03656 for X-agentx; Fri, 6 Sep 1996 09:53:28 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id JAA03650 for ; Fri, 6 Sep 1996 09:53:27 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id MAA20548; Fri, 6 Sep 1996 12:53:20 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05355; Fri, 6 Sep 1996 12:52:06 -0400 Date: Fri, 6 Sep 1996 12:52:31 EDT From: Bob Natale Subject: Re: Multiple range of sub.ids. in an obj.id. (fwd) To: dkeeney@bostech.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: dkeeney@bostech.com > Date: Fri, 6 Sep 1996 11:00:47 -0400 (EDT) Hi Dave, > > Why can't more than one range of sub.ids be used in an > > object identifier ? > > Lets keep it simple. If want to register two or more rows, send > seperate registrations. Right. While the original suggestion does add some "power" to the protocol and it seems to do so with a small extension of a defined feature, it really is a good example of the kind of change to avoid at this stage. The small extension does introduce some additional complexity and, as your reaction explains, there is already an "easy enough" way for subagents to accomplish the task. Let's all stay vigilant on these kinds of "features"--including any they might already be lurking the spec--henceforth. That is not meant to discourage additional suggestions...keep 'em coming...but just to set a guideline for evaluating them. [I will respond to your other comments in separate e-mails with appropriate subject headers, so we can keep the threads clear.] Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 06 Sep 1996 10:02:43 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA05692 for X-agentx; Fri, 6 Sep 1996 10:02:43 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id KAA05689 for ; Fri, 6 Sep 1996 10:02:42 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id NAA22122; Fri, 6 Sep 1996 13:02:43 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05443; Fri, 6 Sep 1996 13:00:39 -0400 Date: Fri, 6 Sep 1996 13:00:43 EDT From: Bob Natale Subject: Re: OID Format To: dkeeney@bostech.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: dkeeney@bostech.com > Date: Fri, 6 Sep 1996 11:00:47 -0400 (EDT) Hi Dave, > OID format: > In keeping with "simple is better" approach I would like to > go back to the OID's as null terminated ASCII strings. I have > implemented OID's both as integer arrays and strings. Strings > are much easier to work with and debug (except perhaps for the > IBM folks). Speaking as wg chair: Well, in this case, the wg (via multiple f2f meetings and follow-up reports and discussion on the list) made a conscious trade-off with the people who previously needed non-ASCII character code support in the protocol. Overall, most participants felt that the OID as range of integers was workable and was definitely attractive if it meant that the non-ASCII character code support became a non-issue as a result. Barring a really strong outcry from a significant number of list participants, the currently specified OID format will stand as is. > Compairing two string OID's with strcmp() does not always work > but you do not have to convert to an integer array > either. (Compare byte per byte until a missmatch, convert > remaining bytes to integer using atoi and compare.) Hmmm. OIDs as integers sounds even better than I thought! ;-) > I know this has already been hashed out but I like to toss in > my thoughts. And everyone should feel free to do so. I'll try to explain such things in detail. I hope the above is clear, and convincing, on this one. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 06 Sep 1996 11:10:48 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA20080 for X-agentx; Fri, 6 Sep 1996 11:10:48 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA20074 for ; Fri, 6 Sep 1996 11:10:46 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA96047; Fri, 6 Sep 1996 14:08:30 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id OAA702054; Fri, 6 Sep 1996 14:08:03 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA29440; Fri, 6 Sep 1996 14:08:03 -0400 From: Uri Blumenthal Message-Id: <9609061808.AA29440@hawpub.watson.ibm.com> Subject: Re: Latest Draft and discussions on the mailing list To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 6 Sep 1996 14:08:02 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609061408.AA04199@bernie.zk3.dec.com> from "Mike Daniele" at Sep 6, 96 10:08:54 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > >From: "Bert Wijnen" > >I am getting worried. > >It seems we're tending in the direction of over-disgn. > >PLEASE adhere to the KISS principle. The more complex you make this, > >the less chance that we will see wide implementation. > >Go for the 80-20 rule (80% of fucntion for 20% of cost). > > AgentX *is* bigger and more complicated than SMUX & DPI, etc, > for 2 reasons: Mike, please... Nobody argues that Agentx should or should not be bigger THAN existing protocols, namely SMUX or DPI. This is 100% besides the point Bert's making. It's the "absolute" big-ness (or over-bloated-ness with "features", if I may loose my pen) that worries people, and I do suggest you pay attention to these concerns. > 1) We decided early on that this spec must contain very specific > elements of procedure. None of the other specs (that I'm aware of) > really describe this at all. That alone accounts for 20 pages > of the i-d. Again, it is NOT the size of the i-d: it is the size of the resulting monster some call protocol that sets people (me in particular) off! > 2) We decided early on that AgentX MUST define far more functionality > than its predecessors. Some of this is mandatory, and some of it > is optional, but it all needs to be written down in copious detail > if this spec is to be implementable, and AgentX giblets truly > interoperable. Of course it would be nice to put all the optional features in the appendix(es). As for truly interoperable implementations when the results of Set are implementation-dependent - somehow I'm not impressed. Same goes for the set of features. The typical argument for a feature goes like this: - Why do you need this feature? - Well, if it will be implemented that way, then without this feature it won't work. - Ah, OK... While the correct approach would be [in my view] rather like: - Doctor, when I do this it hurts! - Hmm, so don't do this! Seriously - since we are not burdened by downward compatilility issues (there's no existing Agentx implementations and customers that might influence the decision of this group, I hope?) - we shouldn't be bullied into accepting solutions that are needed only because some implementations were built that way. Just do it right this time. Or, if it proves that the "right" way is too expensive - leave it alone, for Agentx-2 or whatever. > Substantial changes that a master agent MUST implement are > o Index reservation (updated spec will be out before Interop) > o Registration of conceptual row in single PDU (range subid) > o Registration at any level, new dispatching rules to handle that OK, however dispatching rules are under fire, I think, and justly so. > Subagent code that doesn't support the new features should > require minimal change. Hopefully subagent APIs that don't > need to support the new features won't have to change at all. Hmm... It seems to be that the difference between a sub implementing all the "must" features and "must + may" would indeed be minimal. While the difference between an existing sub' (SMUX or DPI) and Agentx-sub would be tremendous. > In short, when I step back and think about implementing this, > if I ignore multiple contexts and unionized registrations, it > seems pretty straightforward. (Hopefully those words won't come > back to bite me :-) I'm sure you'll learn better. Besides, don't you remember the [in]famous SNMPv2 WG, where several implementors "proved" that V2-classic made "oh so much sense" and was "oh so easily implementable" (yours truly among those implementors, if you care to know). Care to recall where all those drafts went to? [after several iterations, editions and whatnot] I do hope this won't be a repeat. > I *am* saying however that if you accept 1) and 2) above, as we all > did at the onset, I don't think you can avoid an i-d that's got > 50 or so non-trivial pages. I don't care about the number of pages, and 50 isn't bad at all. I do care about the protocol that's too complicated to deal with. And my biggest issues _at this time_ are: dispatching logic and registration (which as you know are tighly related). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 06 Sep 1996 11:23:19 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA22760 for X-agentx; Fri, 6 Sep 1996 11:23:19 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA22756 for ; Fri, 6 Sep 1996 11:23:18 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA66826; Fri, 6 Sep 1996 14:23:39 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id OAA559090; Fri, 6 Sep 1996 14:23:12 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA29822; Fri, 6 Sep 1996 14:23:12 -0400 From: Uri Blumenthal Message-Id: <9609061823.AA29822@hawpub.watson.ibm.com> Subject: Re: OID Format To: natale@acec.com (Bob Natale) Date: Fri, 6 Sep 1996 14:23:11 -0400 (EDT) Cc: dkeeney@bostech.com, agentx@fv.com In-Reply-To: from "Bob Natale" at Sep 6, 96 01:00:43 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Bob Natale says: > > In keeping with "simple is better" approach I would like to > > go back to the OID's as null terminated ASCII strings. I have > > implemented OID's both as integer arrays and strings. Strings > > are much easier to work with and debug (except perhaps for the > > IBM folks). > > .......................Overall, most > participants felt that the OID as range of integers was workable > and was definitely attractive if it meant that the non-ASCII > character code support became a non-issue as a result. Barring > a really strong outcry from a significant number of list participants, > the currently specified OID format will stand as is. "easier" is a subjective term, as I've learned recently. For example, for me it's MUCH easier to compare two arrays of 4-byte integers than two strings [that represent those integers, each of variable length]. > > Compairing two string OID's with strcmp() does not always work > > but you do not have to convert to an integer array > > either. Well, I'd rephrase this: "comparing two string OID's with strcmp() almost never works". I insist this is much closer to reality. > (Compare byte per byte until a missmatch, convert > remaining bytes to integer using atoi and compare.) > > Hmmm. OIDs as integers sounds even better than I thought! ;-) Surprise! (:-) Besides, integer arrays are processed at about raw CPU speed, I think. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 06 Sep 1996 12:41:11 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA12045 for X-agentx; Fri, 6 Sep 1996 12:41:11 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA12038 for ; Fri, 6 Sep 1996 12:41:10 -0700 (PDT) Received: from flume.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA17350; Fri, 6 Sep 1996 15:34:56 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA26278; Fri, 6 Sep 1996 15:34:56 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA04539; Fri, 6 Sep 1996 15:38:16 -0400 Message-Id: <9609061938.AA04539@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Latest Draft and discussions on the mailing lis Date: Fri, 06 Sep 96 15:38:15 -0400 From: Mike Daniele X-Mts: smtp Uri, >Again, it is NOT the size of the i-d: it is the size of the resulting >monster some call protocol that sets people (me in particular) off! That wasn't clear to me from Bert's mail, thanks for clarifying. >As for truly interoperable interoperable implementations when the results of Set are >implementation-dependent - somehow I'm not impressed. Well, Jeff and Aleksey disagree with you. They both described implementations that do exactly this (permit duplicate registrations and dispatch equivalent PDUs to multiple subagents, then sort out the responses.) Could it possibly be that they have experience that you don't? And that the WG should pay attention to their concerns? >Hmm... It seems to be that the difference between a sub implementing >all the "must" features and "must + may" would indeed be minimal. >While the difference between an existing sub' (SMUX or DPI) and >Agentx-sub would be tremendous. Is this an issue? >> In short, when I step back and think about implementing this, >> if I ignore multiple contexts and unionized registrations, it >> seems pretty straightforward. (Hopefully those words won't come >> back to bite me :-) >I'm sure you'll learn better. *** booop! booop! *** oh, sorry, my hubris detector went off there... >I don't care about the number of pages, and 50 isn't bad at all. I do >care about the protocol that's too complicated to deal with. And my >biggest issues _at this time_ are: dispatching logic and registration >(which as you know are tighly related). Well, based on the feedback of you and others, and the wg chair, the new draft makes master agent support of unionized registrations optional. If you wish to, you simply reject the duplicate registration. I believe this is the behavior you feel is correct? Are there other aspects of registration/dispatch you feel are incorrect? Thanks for your feedback (honestly), Mike   Delivery-Date: Fri, 06 Sep 1996 15:58:36 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA00186 for X-agentx; Fri, 6 Sep 1996 15:58:36 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id PAA00181 for ; Fri, 6 Sep 1996 15:58:35 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id SAA62950; Fri, 6 Sep 1996 18:56:33 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id SAA677117; Fri, 6 Sep 1996 18:56:06 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA27647; Fri, 6 Sep 1996 18:56:05 -0400 From: Uri Blumenthal Message-Id: <9609062256.AA27647@hawpub.watson.ibm.com> Subject: Re: Latest Draft and discussions on the mailing lis To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 6 Sep 1996 18:56:05 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609061938.AA04539@bernie.zk3.dec.com> from "Mike Daniele" at Sep 6, 96 03:38:15 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > >As for truly interoperable interoperable implementations when the > >results of Set are implementation-dependent - somehow I'm not impressed. > > Well, Jeff and Aleksey disagree with you. I'd prefer to hear that from themselves, first-hand. I'm sure if they decide to speak up - they can do it as easily as you and I. > They both described > implementations that do exactly this (permit duplicate registrations > and dispatch equivalent PDUs to multiple subagents, then sort out > the responses.) I don't claim it's impossible to implement. I doubt it's wise to do. I claim that it's not what we need in a simple and straigthforward protocol. On the other hand, if this WG decides to license or copy Emanate (for example) - I personally have no problem with it. [At least it works.] > Could it possibly be that they have experience that you don't? Could it be that their technical goals are driven by requirements that are unique to their business and aren't much of a concern for the rest of us? Could it be that they will express themselves if and when they seem fit? > And that the WG should pay attention to their concerns? I hope others will answer this. Folks, do you care how complex is the protocol YOU are going to use, will be? Do you care how much of the standard YOU are going to implement will be marked "implementation specific" or "by magic"? And the result of the operation will depend on whether you bought your agent from vendor X and sub' from vendor Y........? Your time, your money - your call! > Well, based on the feedback of you and others, and the wg chair, > the new draft makes master agent support of unionized registrations optional. OK, thanks! > If you wish to, you simply reject the duplicate registration. > I believe this is the behavior you feel is correct? I think the correct behavior is: one [instantiated?] OID is owned by no more than one one sub at any time. Which one - is decided by master agent, preferably at registration time and in a manner clearly documented in the standard. Especially important when Set is involved. > Are there other aspects of registration/dispatch you feel are > incorrect? Please note: I do NOT say what I complain about is incorrect. I simply say that those registration/dispath features that were proposed don't make a solution acceptable as general-use standard. It can be made to work, but it's not worth it (in my view). More on this later [after I study the draft better]. > Thanks for your feedback (honestly), You're welcome. Nice to see people brushing through my language to the technical content of the message. (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Sat, 07 Sep 1996 01:37:29 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id BAA07948 for X-agentx; Sat, 7 Sep 1996 01:37:28 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id BAA07945 for ; Sat, 7 Sep 1996 01:37:27 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id BAA08479 for agentx@fv.com; Sat, 7 Sep 1996 01:37:30 -0700 From: R Venkatsubramaniam Message-Id: <199609070837.BAA08479@pointer.cisco.com> Subject: Comments on AgentX draft Version 00.03 To: agentx@fv.com Date: Sat, 7 Sep 1996 01:37:30 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Here are my first-look comments on AgentX specs. ver. 00.03. This is from a implementor's point of view. 1. The draft fails to give a clear-cut direction about 'what-to-do' in critical situations. Section 7.2.4.2 (1a) and Section 7.2.4.3 (1a) to mention some. A specification should define clearly the sequence of steps or the actions, specifically when it comes to critical situations like 'more than one 'good' response from multiple sub-agents'. While whether we should allow getting duplicate responses from the multiple sub-agents is itself in question (atleast optional), the specification is indecisive about the actions to be performed during such a situation. 'Implementation specific' seems to be a escapism to me. The spec. should not derilict its responsibility to guide the design about a correct behavior during such situations. If there is something that a spec. cannot define, then design cannot do anything about it. If we don't know 'what to do', then how are we going to proceed to 'how to do' ? 2. The registration process (splitting, agglomeration) is unnecessarily complex. I believe, that there is atleast one method that can be invented (if it doesn't exist right now), which will replace this scheme. 3. Is 'Unionized registration' required ? In my humble opinion, let us drop 'Unionized registration' right now. Let the implementors who need it, come up with a separate requirement, so that it can be solved in a separate domain (or in the next version of AgentX). 4. A consensus about the transport domains is required. Is the master agent going to support more than one transport domain (so that it can receive messages from sub-agents supporting different transport domains) ? Thanks, Venkat. (rvenkat@cisco.com)   Delivery-Date: Wed, 11 Sep 1996 07:00:17 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA05403 for X-agentx; Wed, 11 Sep 1996 07:00:13 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id HAA05400 for ; Wed, 11 Sep 1996 07:00:11 -0700 (PDT) Message-Id: <199609111400.HAA05400@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9843; Wed, 11 Sep 96 10:00:18 EDT Date: Wed, 11 Sep 96 15:59:56 DST From: "Bert Wijnen" To: agentx@fv.com Subject: duplicate/unionized registrations Venkat writes: >My humble suggestion here is to NOT to allow more than one sub-agent register >the same object id. Assuming that the master agent is 'responsible' for >the sysuptime, 'sysuptime' can be used as the final tie-breaker by the master >agent. Whichever sub-agent registers first (sysuptime is used for this time >comparison), should be dispatched the request related to the object id. in >question (assuming the sysuptimes are not equal !). To which Mike responds: >Feedback from some folks with lots of experience with extensible agents is >that this feature is required. Many others agree with you :-) > So who are those "some folks" ?? They probably have such an implementation currently. And that is fine. But we do not need to just include all the complexities that "some folks" (I bet one or max two) currently have introduced in their (proprietary) impementations. I have also "lots of xperience" and I have never come across this requirement although I can see that maybe in a few percent (less than 5 I think) of the cases one might "want/need" this. Mike also says: >So far we've avoided specifying optional behavior. Perhaps unionized >registration is a reasonable candidate? > I suggest that we do a few "optional" stuff as possible. Mike also said: > These don't seem like show-stoppers to me as far as the protocol spec > is concerned. I don't relish coding the master agent to handle this tho... See... there you go. When I am concerned about "complexity" in the spec, it is often not so much about the spec but more about what it means implementation wise. It is easy to write that some issues are "implementation issues" or done by "magic"... but then coding it is a bit more of a burden. Anyway, my "vote" is AGAINST the complexity of duplicate/unionized registrations. I do not even want it as an option. Bert.   Delivery-Date: Wed, 11 Sep 1996 08:14:50 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA13391 for X-agentx; Wed, 11 Sep 1996 08:14:50 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id IAA13388 for ; Wed, 11 Sep 1996 08:14:49 -0700 (PDT) Message-Id: <199609111514.IAA13388@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3649; Wed, 11 Sep 96 11:14:56 EDT Date: Wed, 11 Sep 96 17:14:40 DST From: "Bert Wijnen" To: agentx@fv.com Subject: REG_CLUSTER bit in h.flags Mmmm... I find this very Operating System dependent stuff and I doubt that this is within the scope of our WG. To me it seems similar to the ASCII-EBCDIC debate we had where we now decided to just use ASCII. Bert.   Delivery-Date: Wed, 11 Sep 1996 08:15:49 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA13491 for X-agentx; Wed, 11 Sep 1996 08:15:49 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id IAA13488 for ; Wed, 11 Sep 1996 08:15:46 -0700 (PDT) Message-Id: <199609111515.IAA13488@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3700; Wed, 11 Sep 96 11:15:55 EDT Date: Wed, 11 Sep 96 17:15:31 DST From: "Bert Wijnen" To: agentx@fv.com Subject: agent-caps and o.id and o.descr There was some discussion between Maria and Mike on the o.id and o.descr in conjunction with the IS_AGENT_CAP flag. The text in the draft (00.03) makes me worry too and should be changed. From the responses from Mike, I now have the impression that a.If IS_AGENT_CAP is set, then o.id and o.descr go into the sysORTable. The o.id and o.descr also go into the axSubagentTable into axSAObjectID and axSAdescr. b.If IS_AGENT_CAP is clear, then the o.id and o.descr only go into the axSubagentTable into axSAObjectID and axSAdescr. If this understanding is correct, then that is fine. But pls change the text to make this very clear. Specifically the words "it represents a unique (enterprise-specific) sysObjectID" (botom of page 16) are very confusing. But wait... because I think we have a more serious problem. The other problem I see here is that it is unclear in which sysORTable the o.id and o.descr need to go. Is that the sysORTable of the default context? It kind of has to be, because we have no clue as to which other one we should use. However, the sysORTable lists all the agent-caps of the agent (including subs) for the context in which this sysORTable lives. If the sub later registers mib regions with other (non-default) contexts, then the o.id and o.descr should go into the sysORTable of the specified contexts. While writing this, I also realize that agent-caps at subagent granularity is problematic, because the spec now allows a sub to register MIB regions in multiple contexts. And within each contxt we have a sysORTable that needs to properly represent the set of agent-caps within that context. So our design is broken. It seems we need to allow to SET/REGISTER agent-caps either per registration (as part of the register pdu) or via a separate register_agent_caps pdu that would allow to specify the context for which one the agent-caps registration is intended. Comments? Bert   Delivery-Date: Wed, 11 Sep 1996 08:35:49 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA15275 for X-agentx; Wed, 11 Sep 1996 08:35:49 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by fv.com (8.7.4/8.7.3) with SMTP id IAA15272 for ; Wed, 11 Sep 1996 08:35:48 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA17604; Wed, 11 Sep 96 08:35:54 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA23429; Wed, 11 Sep 96 08:35:53 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA26663; Wed, 11 Sep 96 08:35:52 PDT Date: Wed, 11 Sep 96 08:35:52 PDT From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9609111535.AA26663@santa.strata.com> To: agentx@fv.com Subject: ver 00.04 of AgentX protocol draft to be posted I'm sending in a single following post revision 00.04 of the proposed AgentX Protocol internet draft. Some changes were made to formatting, and in a few cases sentences were recast for clarity. The substantive changes from ver 00.03 to ver 00.04 are mainly the addition of index reservation and making support for unionized registrations optional. A summary of the substantive changes, section by section, is appended below. In the interest of getting this out before Interop, I've deferred action on most of the suggestions posted to the list during the last couple of weeks. I will go through them carefully for the next version. Please direct questions, comments, and suggested changes to the list (agentx@fv.com). Thanks, Dale Francisco Editor, AgentX WG dfrancisco@cisco.com voice: (805) 961-3642 fax: (805) 961-3600 Substantive changes from ver 00.03 to ver 00.04 ----------------------------------------------- 6.1. AgentX PDU header In definition of h.type, added enumeration for agentx-IndexRes-PDU. 6.2.1.1. agentx-Open-PDU Fields In definition of o.id, changed closing sentence from: "Otherwise it represents a unique (enterprise-specific) sysObjectID." to: "Otherwise it represents a sysObjectID-like value that uniquely identifies the subagent." 6.2.8. The agentx-Test-PDU In PDU diagram, changed "t.SearchRangeList" to "t.VarBindList". Added new section: "6.2.11. The agentx-IndexRes-PDU" 7.1. Processing AgentX Administrative Messages In the introductory paragraph describing what kinds of messages are administrative messages, added index reservation messages to the list. Added new section "7.1.2 Processing the agentx-IndexRes-PDU". 7.1.3. Processing the agentx-Register-PDU In (3), changed the value of res.error from 'genError' to 'inconsistentName'. In (4), made support for unionized registration optional.   Delivery-Date: Wed, 11 Sep 1996 08:38:46 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA15509 for X-agentx; Wed, 11 Sep 1996 08:38:46 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by fv.com (8.7.4/8.7.3) with SMTP id IAA15506 for ; Wed, 11 Sep 1996 08:38:43 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA17659; Wed, 11 Sep 96 08:38:45 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA23614; Wed, 11 Sep 96 08:38:40 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA26692; Wed, 11 Sep 96 08:38:35 PDT Date: Wed, 11 Sep 96 08:38:35 PDT From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9609111538.AA26692@santa.strata.com> To: agentx@fv.com Subject: AgentX protocol draft, ver 00.04 Agent Extensibility (AgentX) Protocol Version 1 Mike Daniele Digital Equipment Corporation daniele@zk3.dec.com Dale Francisco (editor) StrataCom dfrancisco@strata.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Daniele/Francisco Expires December 1996 [Page 1] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Table of Contents 1 Introduction......................................................5 2 The SNMP Framework................................................5 2.1 A Note on Terminology.........................................5 3 Extending the MIB.................................................6 3.1 Motivation for AgentX.........................................6 3.2 Design Goals for AgentX.......................................7 4 AgentX Framework..................................................7 4.1 AgentX Roles..................................................8 5 AgentX Encodings..................................................9 5.1 ObjectIdentifiers.............................................9 5.2 SearchRange..................................................11 5.3 Naming Scope.................................................12 5.4 Value Representation.........................................13 6 Protocol Definitions.............................................14 6.1 AgentX PDU Header............................................14 6.2 AgentX PDUs..................................................16 6.2.1 The agentx-Open-PDU......................................16 6.2.1.1 agentx-Open-PDU Fields...............................16 6.2.2 The agentx-Close-PDU.....................................17 6.2.2.1 agentx-Close-PDU Fields..............................17 6.2.3 The agentx-Register-PDU..................................17 6.2.3.1 agentx-Register-PDU Fields...........................18 6.2.4 The agentx-Unregister-PDU................................20 6.2.4.1 agentx-Unregister-PDU Fields.........................21 6.2.5 The agentx-Get-PDU.......................................21 6.2.6 The agentx-GetNext-PDU...................................22 6.2.7 The agentx-GetBulk-PDU...................................22 6.2.8 The agentx-Test-PDU......................................23 6.2.9 The agentx-Commit, -Undo, -Cleanup, and -Ping PDUs.....................................................24 6.2.10 The agentx-Notify-PDU...................................24 6.2.10.1 agentx-Notify-PDU Fields............................24 6.2.11 The agentx-IndexRsrv-PDU................................25 6.2.12 The agentx-Response-PDU.................................25 6.2.12.1 agentx-Response-PDU Fields..........................25 7 Elements of Procedure............................................26 7.1 Processing AgentX Administrative Messages....................26 7.1.1 Processing the agentx-Open-PDU...........................26 7.1.2 Processing the agentx-IndexRsrv-PDU......................26 7.1.3 Processing the agentx-Register-PDU.......................28 7.1.3.1 Handling Duplicate OID Ranges........................31 7.1.4 Processing the agentx-Unregister-PDU.....................31 7.1.5 Processing the agentx-Close-PDU..........................32 7.1.6 Detecting Connection Loss................................33 Daniele/Francisco Expires December 1996 [Page 2] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.1.7 Processing the agentx-Notify-PDU.........................33 7.1.8 Processing the agentx-Ping-PDU...........................33 7.2 Processing Received SNMP Protocol Messages...................33 7.2.1 Dispatching AgentX PDUs..................................34 7.2.1.1 agentx-Get-PDU.......................................34 7.2.1.2 agentx-GetNext-PDU...................................35 7.2.1.3 agentx-GetBulk-PDU...................................36 7.2.1.4 agentx-Test-PDU......................................37 7.2.1.5 Dispatch.............................................38 7.2.2 Subagent Processing of agentx-GET, GetNext, GetBulk-PDUs.............................................38 7.2.2.1 Subagent Processing of the agentx-Get-PDU............38 7.2.2.2 Subagent Processing of the agentx-GetNext-PDU...................................39 7.2.2.3 Subagent Processing of the agentx-GetBulk-PDU...................................40 7.2.3 Subagent Processing of agentx-Test, -Commit, -Undo, -Cleanup-PDUs.....................................41 7.2.3.1 Subagent Processing of the agentx-Test-PDU...........41 7.2.3.2 Subagent Processing of the agentx-Commit-PDU....................................42 7.2.3.3 Subagent Processing of the agentx-Undo-PDU...........42 7.2.3.4 Subagent Processing of the agentx-Cleanup-PDU...................................42 7.2.4 Master Agent Processing of AgentX Responses..............42 7.2.4.1 Common Processing of All AgentX Response PDUs.................................................43 7.2.4.2 Processing of Responses to agentx-Get-PDUs...........43 7.2.4.3 Processing of Responses to agentx-GetNext- and agentx-GetBulk-PDUs..............44 7.2.4.4 Processing of Responses to agentx-Test-PDUs.....................................46 7.2.4.5 Processing of Responses to agentx-Commit-PDUs...................................46 7.2.4.6 Processing of Responses to agentx-Undo-PDUs.....................................47 7.2.5 Sending the SNMP Response-PDU............................47 7.2.6 MIB Views................................................47 8 Transport Mappings...............................................48 8.1 AgentX over TCP..............................................48 8.1.1 Well-known Values........................................48 8.1.2 Operation................................................48 8.2 AgentX over UNIX-domain Sockets..............................48 8.2.1 Well-known Values........................................48 8.2.2 Operation................................................49 9 Security Considerations..........................................49 10 Acknowledgements................................................48 Daniele/Francisco Expires December 1996 [Page 3] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 11 Questions and Issues............................................50 11.1 Design......................................................50 11.2 Miscellaneous Issues........................................51 12 References......................................................53 Daniele/Francisco Expires December 1996 [Page 4] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 1. Introduction This memo defines a framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. 2. The SNMP Framework A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. 2.1. A Note on Terminology The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [2] or the textual conventions based on the SMI [3]. The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception. A variable-binding list is a simple list of variable bindings. The name of a variable is an OBJECT IDENTIFIER, which is the concatenation of the OBJECT IDENTIFIER of the corresponding object type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable. For the purpose of exposition, the original Internet-standard Daniele/Francisco Expires December 1996 [Page 5] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Network Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 framework (SNMPv1). The current framework, as described in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2). 3. Extending the MIB New MIB modules that extend the Internet-standard MIB are continuously being defined as the output of various IETF working groups. It is also common for enterprises or individuals to create or extend enterprise-specific or experimental MIBs. As a result, managed devices are frequently complex collections of manageable components that have been independently installed on a managed node. Each component provides instrumentation for the managed objects defined in the MIB module(s) it implements. Neither the SNMP version 1 or version 2 framework address how managed objects may be dynamically added to or removed from the agent view within a particular managed node. 3.1. Motivation for AgentX This very real need to dynamically extend the management objects within a node has given rise to a variety of "extensible agents", which typically comprise - a "master" agent that is available on the standard transport address and that accepts SNMP protocol messages - a set of "subagents" that each contain management instrumentation - a protocol that operates between the master agent and subagents, permitting subagents to "connect" to the master agent, and the master agent to multiplex received SNMP protocol messages amongst the subagents. - a set of tools to aid subagent development, and a runtime (API) environment that hides much of the protocol operation between a subagent and the master agent. The wide deployment of extensible SNMP agents, coupled with the lack of Internet standards in this area, makes it difficult to field SNMP-manageable applications. A vendor may have to support several different subagent environments (APIs) in order to support different target platforms. It can also become quite cumbersome to configure subagents and (possibly multiple) master agents on a particular managed node. Daniele/Francisco Expires December 1996 [Page 6] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Specifying a standard protocol for agent extensibility (AgentX) provides the technical foundation required to solve both of these problems. Independently developed AgentX-capable master agents and subagents will be able to interoperate at the protocol level. Vendors can continue to differentiate their products in all other respects. 3.2. Design Goals for AgentX The primary goal of the design described in this memo is to minimize the latency associated with AgentX protocol operations above and beyond that already incurred for monolithic agents responding to similar management requests. In other words, minimize the response time and maximize the throughput of the extensible agent as perceived by SNMP manager entities. This goal is achieved primarily by minimizing the number of AgentX PDUs required to service an SNMP request. The elements of procedure are defined so that: - Except in rare cases, each requested variable binding is dispatched to only 1 subagent - All variable bindings targeted for a subagent are included in a single AgentX PDU sent to that subagent - Subagents return a single response PDU, which contains as much data as possible; its limits (for Next/Bulk) are its own size constraints, or the boundary of the lexicographically-next MIB region for which a different subagent is responsible - The master agent's bounding of acceptable returned variable binding names, and the SMI-consistency checking (for v2->v1 mapping) in the subagent, assure that the master will not have to resend PDUs For questions and open issues, see section 11 at the end of this memo. 4. AgentX Framework Within the SNMP framework, a managed node contains a processing entity, called an agent, which has access to management information. Within the AgentX framework, an agent is further defined to consist of - a single processing entity called the master agent, which sends Daniele/Francisco Expires December 1996 [Page 7] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 and receives SNMP protocol messages in an agent role (as specified by the SNMP version 1 and version 2 framework documents) but typically has little or no direct access to management information. - 0 or more processing entities called subagents, which are "shielded" from the SNMP protocol messages processed by the master agent, but which have access to management information. The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. Other interfaces (if any) on these entities, and their associated protocols, are outside the scope of this document. While some of the AgentX protocol messages appear similar in syntax and semantics to the SNMP, bear in mind that AgentX is not SNMP. The internal operations of AgentX are invisible to an SNMP entity operating in a manager role. To the manager, the agent behaves exactly as would a non-extensible (monolithic) agent that had access to the same management instrumentation. This transparency to managers is a fundamental requirement of AgentX, and is what differentiates AgentX subagents from SNMP proxy agents. 4.1. AgentX Roles An entity acting in a master agent role performs the following functions: - Accepts logical connection requests from subagents. - Accepts registration of MIB regions by subagents. - Sends and accepts SNMP protocol messages on the agent's specified transport addresses. - Implements the agent role Elements of Procedure specified for the administrative framework applicable to the SNMP protocol message, except where they specify performing management operations. (The application of MIB views, and the access control policy for the managed node, are implemented by the master agent.) - Provides instrumentation for the MIB objects defined in [5], and for any MIB objects relevant to any administrative framework it supports. - Sends and receives AgentX protocol messages to access management information, based on the current registry of MIB regions. Daniele/Francisco Expires December 1996 [Page 8] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 - Forwards notifications on behalf of subagents. An entity acting in a subagent role performs the following functions: - Initiates a logical connection with the master agent. - Registers MIB regions with the master agent. - Instantiates managed objects. - Binds MIB region OIDs (contained in AgentX protocol messages) to actual variable names. - Performs management operations on variables. - Initiates notifications. 5. AgentX Encodings AgentX PDUs consist of a common header, followed by PDU-specific data of variable length. The PDUs are not encoded using the BER [1], but are transmitted as a contiguous byte stream. The data within this stream is organized to provide natural alignment with respect to the start of the PDU, permitting direct (integer) access by the processing entities. Numeric data is encoded in network byte order (most significant byte first). PDUs are depicted in this memo using the following convention (where byte 1 is the first transmitted byte): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 1 | byte 2 | byte 3 | byte 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 5 | byte 6 | byte 7 | byte 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 5.1. ObjectIdentifiers Object identifiers are encoded with a 4-byte header, followed by a variable number of contiguous 4-byte sub-identifiers. This representation (termed ObjectIdentifier) is as follows: Daniele/Francisco Expires December 1996 [Page 9] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 ObjectIdentifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ObjectIdentifier header fields: n_subid - The number (0-128) of sub-ids in the object identifier. An ordered list of `n_subid' 4-byte sub-ids follows the 4-byte header. A value of 0 indicates a null object identifier. prefix - An unsigned value used to reduce the length of object identifier encodings. A non-zero value x is interpreted as the first sub-id after `internet' (1.3.6.1), and indicates an implicit prefix 'internet.x' to the actual sub-ids encoded in the ObjectIdentifier. For example, a prefix field value '2' indicates an implicit prefix '1.3.6.1.2'. A value of 0 in the prefix field indicates there is no prefix to the sub-ids. include - Used only when the object identifier is part of a SearchRange. Examples: sysDescr.0 (1.3.6.1.2.1.1.1.0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 10] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 9.9.9.9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. SearchRange A SearchRange consists of two ObjectIdentifiers. In its communication with a subagent, the master agent uses a SearchRange to identify a requested variable binding, and, in GetNext and GetBulk operations, to set an upper bound on the names of managed object instances the subagent may send in reply. The first object identifier (called the starting OID) indicates the beginning of the range. It is frequently (but not necessarily) the name of a requested variable binding. The `include' field in this OID's header is a boolean value indicating whether or not the starting OID is included in the range. The second object identifier indicates the non-inclusive end of the range. Daniele/Francisco Expires December 1996 [Page 11] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Example: To indicate a search range from 1.3.6.1.2.1.25.2 (inclusive) to 1.3.6.1.2.1.25.2.1 (exclusive), the SearchRange would be (start) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 2 | 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (end) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SearchRangeList is a contiguous list of SearchRanges. 5.3. Naming Scope Naming scopes (contexts) are transferred as variable-length ASCII strings. When present, a naming scope string is always transmitted as the last item in a PDU, hence its size may be determined from the PDU size. Daniele/Francisco Expires December 1996 [Page 12] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 5.4. Value Representation Variable bindings may be transmitted within the variable-length portion of some PDUs. The representation of a variable binding (called a VarBind) consists of a 4-byte header, an ObjectIdentifier, the value data, and optional padding bytes as needed to achieve alignment on 4-byte boundaries: VarBind +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | v.size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (v.name) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (v.data) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v.type - Indicates the variable binding's syntax, and must be one of the following (SNMPv2 SMI) values: INTEGER (2), OCTET_STRING (4), OBJECT_IDENTIFIER (6), IpAddress (64), Counter32 (65), Gauge32 (66), TimeTicks (67), Opaque (68), Counter64 (70), noSuchObject (128), noSuchInstance (129), endOfMibView (130) Daniele/Francisco Expires December 1996 [Page 13] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 v.size - The number of bytes of data following the ObjectIdentifier. If this value is not zero or a multiple of 4, then 1 to 3 padding bytes are appended to the data to achieve 4-byte alignment. v.name - The ObjectIdentifier which names the variable. v.data - The actual value, encoded as follows: o 32-bit integers are 4-byte elements, MSB first. Example: '00000001'h represents 1. o 64-bit integers are 8-byte elements, MSB first. Example: '0000000100000001'h represents 4,294,967,297. o OBJECTIDENTIFIER data are represented as described in section 5.1. Note that v.size includes the size of the entire ObjectIdentifier (including the header). o IpAddress and Opaque are implicit OCTET_STRING, so they are octets (e.g. IpAddress in network byte order). o noSuchObject, noSuchInstance, are endOfMibView are implicit NULL and represented by v.size equal 0, and no data. A VarBindList is a contiguous list of VarBinds. 6. Protocol Definitions 6.1. AgentX PDU Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | h.type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h.length - The size in octets of the entire PDU, including the header. h.version - The version of the AgentX protocol (0 for this draft). Daniele/Francisco Expires December 1996 [Page 14] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 h.type - The PDU type; one of the following values: agentx-Open-PDU (1), agentx-Close-PDU (2), agentx-Register-PDU (3), agentx-Unregister-PDU (4), agentx-Get-PDU (5), agentx-GetNext-PDU (6), agentx-GetBulk-PDU (7), agentx-Test-PDU (8), agentx-Commit-PDU (9), agentx-Undo-PDU (10), agentx-Cleanup-PDU (11), agentx-Notify-PDU (12), agentx-Ping-PDU (13), agentx-IndexRsrv-PDU (14), agentx-Response-PDU (15) h.ID - A monotonically increasing packet id that should be kept unique by the sending entity, and that wraps if the maximum value is reached. h.flags - A bitmask, with bit 0 the leftmost bit. The bit definitions are as follows: Bit Definition --- ---------- 0 REG_INSTANCE 1 REG_UNION 2 REG_CLUSTER 3-4 reserved 5 CTX_ONE 6 CTX_ALL 7-8 reserved 9 IS_AGENT_CAP 10-12 reserved 13-15 unused h.snmp_version - The value of the version component of the received SNMP message. The subagent uses this value to interpret the contents of the Naming Scope field, and to bind SearchRanges to variables whose syntax is suitable to the SMI of that version. Daniele/Francisco Expires December 1996 [Page 15] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 6.2. AgentX PDUs 6.2.1. The agentx-Open-PDU An agentx-Open-PDU is generated by a subagent to establish a logical connection with the master agent. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.timeout | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (o.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.descr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.1.1. agentx-Open-PDU Fields o.timeout - The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a subagent-wide default value that may be overridden by values associated with specific registered MIB regions. The default value of 0 indicates no subagent-wide value is requested. o.id - An Object Identifier which identifies the subagent. If the IS_AGENT_CAP bit in h.flags is set, this value identifies an agent capabilities statement with respect to the MIB modules supported by the subagent. Otherwise it represents a sysObjectID-like value that uniquely identifies the subagent. Daniele/Francisco Expires December 1996 [Page 16] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 o.descr - An ASCII-encoded DisplayString describing o.id. 6.2.2. The agentx-Close-PDU an agentx-Close-PDU terminates a logical connection. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c.reason | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.2.1. agentx-Close-PDU Fields c.reason - An implementation-specific reason code. No values are specified by this memo. 6.2.3. The agentx-Register-PDU An agentx-Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within one or more contexts) that it wishes to support. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.timeout | r.priority | r.range_subid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 17] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional upper-bound sub-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Naming Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.3.1. agentx-Register-PDU Fields An agentx-Register-PDU contains the following fields: r.timeout - The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. r.timeout applies only to messages that concern MIB objects within r.region. It overrides both the subagent-wide value (if any) indicated when the logical connection with the master agent was established, and the master agent's default timeout. The default value for r.timeout is 0 (no override). r.priority - Used by cooperating subagents to achieve a desired configuration when registering identical or overlapping regions. The default value is 0 (no priority indicated). Higher numbers indicate higher priority. r.region - An ObjectIdentifier that, in conjunction with r.range_subid, indicates a region of the MIB that a subagent wishes to support. It may be a fully-qualified instance name, a partial instance name, a MIB table or group, or ranges of any of these. The choice of what to register is implementation-specific; this memo does not specify permissible values. Standard practice however is for a subagent to register at the highest level of the naming tree that makes sense. Registration of fully-qualified instances is typically done only when a subagent can Daniele/Francisco Expires December 1996 [Page 18] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 perform management operations only on particular rows of a conceptual table. If r.region is in fact a fully qualified instance name, the REG_INSTANCE bit in h.flags must be set, otherwise it must be cleared. The master agent may save this information to optimize subsequent operational dispatching. r.range_subid - Permits specifying a range in place of one of r.region's sub-ids. If this value is 0, no range is specified. Otherwise the `r.range_subid'-th sub-identifier in r.region is a range lower bound, and the range upper bound sub-identifier (r.upper_bound) immediately follows r.region. This permits registering a conceptual row with a single PDU. For example, the following PDU would register row 7 of the RFC 1573 ifTable (1.3.6.1.2.1.2.2.1.1-22.7): (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.priority | r.timeout | 5 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 19] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r.context - An optional NamingScope which may be specified by the subagent. This is present only when the CTX_ONE bit is set, and indicates r.region is to be registered only within r.context. 6.2.4. The agentx-Unregister-PDU The agentx-Unregister-PDU is sent by a subagent to remove a previously registered MIB region from the master agent's OID space. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u.reason | u.range_subid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (u.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (u.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional upper-bound sub-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 20] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (u.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Naming Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.4.1. agentx-Unregister-PDU Fields An agentx-Unregister-PDU contains the following fields: - u.reason is a placeholder for implementation-specific data; no values are specified by this memo. - u.region indicates a previously-registered region of the MIB that a subagent no longer wishes to support. It may be a fully-qualified instance name, a partial instance name, a MIB table or group, or ranges of any of these. - u.context is an optional NamingScope which may be specified by the subagent. This is present only when the CTX_ONE bit is set, and indicates r.region is to be unregistered only within r.context. 6.2.5. The agentx-Get-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (g.SearchRangeList) (start 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 21] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (end 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (g.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.6. The agentx-GetNext-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (g.SearchRangeList) ... (g.Context) ... 6.2.7. The agentx-GetBulk-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g.non_repeaters | g.max_repetitions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 22] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (g.SearchRangeList) ... (g.Context) ... 6.2.8. The agentx-Test-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (t.VarBindList) (VarBind 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | v.size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (VarBind n) (t.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Daniele/Francisco Expires December 1996 [Page 23] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 6.2.9. The agentx-Commit, -Undo, -Cleanup, and -Ping PDUs A agentx-Ping-PDU is sent by a subagent to test that the master agent is running and responding promptly. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | h.type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.10. The agentx-Notify-PDU An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (n.vblist) ... (n.context) ... 6.2.10.1. agentx-Notify-PDU Fields An agentx-Notify-PDU contains the following fields: n.vblist - A VarBindList whose contents define the actual PDU to be sent. This memo places the following restrictions on its contents: - snmpTrapOID.0 must be present - If sysUpTime.0 is not present, the master agent should supply a current value. n.context - An optional field which is used by the subagent to indicate a non-default context associated with the notification. Daniele/Francisco Expires December 1996 [Page 24] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 6.2.11. The agentx-IndexRsrv-PDU An agentx-IndexRsrv-PDU is sent by a subagent to reserve a value for specific index objects. This feature is typically used by subagents that instantiate individual conceptual rows of a MIB table. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (i.VarBindList) ... 6.2.12. The agentx-Response-PDU +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.error | res.index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (optional fields) 6.2.12.1. agentx-Response-PDU Fields res.error - Indicates error status (including 'noError'). Values are limited to those defined for errors and exceptions in the SNMPv2 SMI [4]. res.index - In error cases, this is the index of the failed variable binding within a received request PDU. Other data may follow these two fields, depending on which AgentX PDU is being responded to. These contents are specified in the subsequent elements of procedure. Daniele/Francisco Expires December 1996 [Page 25] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7. Elements of Procedure This section describes the actions of protocol entities (master agents and subagents) implementing the AgentX protocol. Note, however, that it is not intended to constrain the internal architecture of any conformant implementation. The actions of AgentX protocol entities can be broadly categorized under two headings: (1) processing AgentX administrative messages (e.g, connection requests from a subagent to a master agent); and (2) processing SNMP messages (e.g., the coordinated actions of a master agent and one or more subagents in processing a received SNMP Get-PDU). 7.1. Processing AgentX Administrative Messages This subsection describes the actions of AgentX protocol entities in processing AgentX administrative messages. Such messages include those involved in establishing and terminating a logical connection between a subagent and a master agent, those by which a subagent reserves instance index values, and those by which a subagent communicates to a master agent which MIB regions it supports. 7.1.1. Processing the agentx-Open-PDU When the master agent receives an agentx-Open-PDU, it processes it as follows: 1) If a logical connection for this subagent has already been established (via an agentx-Open-PDU from the same transport endpoint), the PDU is ignored. 2) Otherwise, an agentx-Response-PDU is sent with the res.error field set to noError(0), and the 4-byte TimeTicks value of sysUpTime.0 within the default context, following the header. This indicates the establishment of a logical connection. If the IS_AGENT_CAP bit in h.flags is set, the data in o.id and o.descr must be represented as an entry in sysORTable from [5]. A warmStart trap is issued. 7.1.2 Processing the agentx-IndexRsrv-PDU The use of this PDU results in the master agent reserving a value for a MIB index, exclusively for the subagent. This feature is necessary in situations where multiple subagents instantiate Daniele/Francisco Expires December 1996 [Page 26] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 different conceptual rows of the same table. For instance, subagents that represent a single interface in `ifTable' require a unique value of `ifIndex', and so would first reserve a value of `ifIndex' with the master agent. When the master agent receives an agentx-IndexRsrv-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Each VarBind in the VarBindList is processed until either all are successful, or one fails. If any VarBind fails, an agentx-Response-PDU is sent in reply containing the original VarBindList, with res.index set to indicate the failed VarBind, and with res.error set as described subsequently. All other VarBinds are ignored; no index values are reserved. VarBinds are processed as follows: - v.name is the name of the index for which a value is requested - v.type is the syntax of the index object - v.size and v.data indicate the specific index value requested. A null value (v.size set to 0) indicates a request for the next available index value. a) If v.type is not INTEGER, OBJECT_IDENTIFIER, OCTET_STRING, or IpAddress, the VarBind fails and res.error is set to `genError'. b) Otherwise, if there are currently reserved index values for v.name, but the syntax of those values does not match v.type, the VarBind fails and res.error is set to `wrongType'. c) Otherwise, if v.size is not 0 and the requested value has already been reserved for v.name, the VarBind fails and res.error is set to `wrongValue'. d) Otherwise, if v.size is 0, but the master agent is not able to generate the next available index value for v.name, the VarBind fails and res.error is set to `noCreation'. Note: A conformant AgentX master agent must attempt to supply a next available index value when v.type is INTEGER, and may return 'noCreation' only if a processing error is encountered (for instance, all possible indexes for v.name have been reserved). 3) If all VarBinds are processed successfully, an agentx-Response-PDU is sent in reply with res.error set to `noError'. A VarBindList Daniele/Francisco Expires December 1996 [Page 27] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 is included which is identical to the one sent in the agentx-IndexRsrv-PDU, except that VarBinds requesting the next available index value (v.size is 0) are updated with the value of the generated index value. The master agent adds these newly reserved index OID/value pairs to a local datastore. The purpose of this datastore is to ensure (as described above) that unique values are supplied for a specific index object (OID). A master agent as defined in this memo does not possess knowledge of any MIB variables, and as such, is not required to understand the semantics of index objects for which it reserves unique values. Since Internet-standard MIB index objects typically may not be reused (until the agent reboots), this memo supports that behavior. A conformant master agent must provide unique index values for all reservation requests for the same index object, between reboots of the master agent. There is no provision for unreserving index values. A conformant master agent's index reservation datastore is not required to exist across reboots of the master agent. Note: AgentX index reservation is completely distinct from AgentX registration. There is no association between the object identifiers of index objects for which subagents reserve values, and the object identifiers of MIB regions that subagents register. 7.1.3. Processing the agentx-Register-PDU When the master agent receives an agentx-Register-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Characterize the request. If r.region (or any of its set of ObjectIdentifiers if r.range is non-zero) is exactly the same as any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed a duplicate region. If r.region (or any of its set of ObjectIdentifiers if r.range is non-zero) is a subtree of, or contains, any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed an overlapping region. Daniele/Francisco Expires December 1996 [Page 28] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 If the CTX_ALL bit is set, this region is to be logically registered within all contexts known to the master agent. If the CTX_ONE bit is set, this region is to be logically registered within the single context r.context. If neither bit is set this region is to be logically registered within the default context. A registration that would result in a duplicate region with the same priority and within an identical context (including the default) as a current registration, is termed a duplicate registration. 3) If either CTX bit is set, and the master agent supports only a default context, an agentx-Response-PDU is returned with res.error set to `inconsistentName'. Note: A conformant AgentX master agent must support the notion of a default context, and may support non-default contexts. 4) If this is a duplicate registration, a) if either of the following is true, an agentx-Response-PDU is returned with res.error set to `wrongValue': - This PDU's REG_UNION bit is not set. - The REG_UNION bit is not set for any current registration of which this registration is a duplicate. b) otherwise, if the master agent does not support unionized registrations, an agentx-Response-PDU is returned with res.error set to `inconsistentValue'. Note: A conformant AgentX master agent may support unionized registrations. If it does not, it must reject duplicate registrations as described in (4b). 5) Otherwise, an agentx-Response-PDU is returned with res.error set to `noError', and a 4-byte TimeTicks value following the header. The latter is the current value of sysUpTime.0 for either a specified non-default context (if the registration message so indicated), or for the default context. The master agent adds this region to its registered OID space for the indicated context(s), to be considered during the dispatching phase for subsequently received SNMP protocol messages. NOTE: The following algorithm describes maintaining a set of OID ranges derived from "splitting" registered regions. The algorithm for operational dispatching is also stated in terms of these OID ranges. Daniele/Francisco Expires December 1996 [Page 29] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 These OID ranges are a useful explanatory device, but are not required for a correct implementation. - If r.region (R1) is a subtree of a currently registered region (R2), split R2 into 3 new regions (R2a, R2b, and R2c) such that R2b is an exact duplicate of R1. Now remove R2 and add R1, R2a, R2b, and R2c to the master agent's lexicographically ordered set of ranges (the registered OID space). Note: Though newly-added ranges R1 and R2b are identical in terms of the MIB objects they contain, they are registered by different subagents, possibly at different priorities. For instance, if subagent S2 registered `ip' (R2 is 1.3.6.1.2.1.4) and subagent S1 subsequently registered `ipNetToMediaTable' (R1 is 1.3.6.1.2.1.4.22), the resulting set of registered regions would be: 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) - If r.region (R1) overlaps one or more currently registered regions, then for each overlapped region (R2) split R1 into 3 new ranges (R1a, R1b, R1c) such that R1b is an exact duplicate of R2. Add R1b and R2 into the lexicographically ordered set of regions. Apply (5) above iteratively to R1a and R1c (since they may overlap, or be subtrees of, other regions). For instance, given the currently registered regions in the example above, if subagent S3 now registers mib-2 (R1 is 1.3.6.1.2.1) the resulting set of regions would be: 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) Note that at registration time a region may be split into multiple OID ranges due to pre-existing registrations, or as a result of any subsequent registration. This region splitting is transparent to subagents. Hence the master agent must always be able to associate any OID range with the information contained in its original agentx-Register-PDU. Daniele/Francisco Expires December 1996 [Page 30] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.1.3.1. Handling Duplicate OID Ranges As a result of this registration algorithm there are likely to be duplicate OID ranges (regions of identical MIB objects registered to different subagents) in the master agent's registered OID space. Whenever the master agent's dispatching algorithm (see 7.2.1, Dispatching AgentX PDUs) selects a duplicate OID range, the determination of which one to use proceeds as follows: 1) Choose the one whose original agentx-Register-PDU r.region contained the most subids, i.e., the most specific r.region. Note: The presence or absence of a range subid has no bearing on how "specific" one ObjectIdentifier is compared to another. 2) If still ambiguous, there were duplicate regions. Choose the one whose original agentx-Register-PDU specified the highest priority. 3) If still ambiguous, there were duplicate registrations. In this case, requests for objects within this OID range must be dispatched (at least initially) to all subagents who have registered the duplicate region. NOTE: This case may cause serious performance penalties during operational dispatching. The REG_UNION bit should be clear for all but the most unwieldy subagent configurations. It is almost always possible to use the indexing structure of conceptual tables to provide unique registrations among subagents sharing the implementation of such tables, and that is the preferred configuration. For example, a subagent "responsible" for a particular interface whose ifIndex is n, should register a specific conceptual row of ifTable (`ifEntry'.1-22.n), not `ifTable'. If this subagent also implements ipNetToMediaTable, it should register `ipNetToMediaEntry'.n.1-4, not `ipNetToMediaTable'. If it implements tcpConnTable, it should register `tcpConnEntry.a.b.c.d.1-5, where a.b.c.d is an IP address for the interface, not `tcpConnTable', etc. 7.1.4. Processing the agentx-Unregister-PDU 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) If the combination of u.region, the CTX bits, and the optional u.context do not match an existing registration, an agentx-Response-PDU is returned with res.error set to 'inconsistentValue'. Daniele/Francisco Expires December 1996 [Page 31] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 3) Otherwise, an agentx-Response-PDU is sent in reply with res.error set to `noError'. The master agent removes u.region from its registered OID space within the indicated context(s). If the original region had been split, all such related regions are removed. If this removal results in any contiguous OID ranges that share a common original agentx-Register-PDU, they are agglomerated into a single OID range. For instance, given the example registry above, if subagent S2 unregisters `ip', the resulting registry would be: 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) and after agglomeration; 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.2 (by S3) sysORTable is updated to reflect the change in configuration, and a warmStart trap is issued. 7.1.5. Processing the agentx-Close-PDU When the master agent receives an agentx-Close-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Otherwise, the master agent dissolves the logical connection as described below. No agentx-Response-PDU is sent. - All MIB regions that have been registered by this subagent are unregistered, as described in 7.1.3. (Note: In this case a single warmStart trap is issued, not one per registered region.) When a subagent receives an agentx-Close-PDU, it must reestablish a logical connection and reregister its MIB regions. Daniele/Francisco Expires December 1996 [Page 32] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.1.6. Detecting Connection Loss If a master agent is able to detect (from the underlying transport) that a subagent cannot receive AgentX PDUs, it should dissolve the logical connection as described in 7.1.4, step (2). 7.1.7. Processing the agentx-Notify-PDU A subagent sending SNMPv1 trap information must map this into (minimally) a value of snmpTrapOID.0, as described in 3.1.2 of [8]. When the master agent receives an agentx-Notify-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) The VarBindList is parsed. 3) Notifications are sent according to the implementation-specific configuration of the master agent. If SNMPv1 Trap PDUs are generated, the recommended mapping is as described in [9]. No agentx-Response-PDU is sent. 7.1.8. Processing the agentx-Ping-PDU When the master agent receives an agentx-Ping-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Otherwise, an agentx-Response-PDU is sent, whose res.error field is noError(0), and containing no other data. 7.2. Processing Received SNMP Protocol Messages When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent implements the access control policy. In particular, the master agent implements the Elements of Procedure defined in section 4.1 of [6] that apply to receiving entities. In the SNMPv1 or v2c frameworks, the master agent uses the community string as an index into a local repository of configuration Daniele/Francisco Expires December 1996 [Page 33] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 information that may include community profiles or more complex context information. If application of the access control policy results in a valid SNMP request PDU, then an SNMP Response-PDU is constructed from information gathered in the exchange of AgentX PDUs between the master agent and one or more subagents. Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents, marshal the subagent responses, and construct an SNMP response PDU. 7.2.1. Dispatching AgentX PDUs Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents. Note: In the following procedures, an object identifier is said to be "contained" within an OID range when both of the following are true: - the object identifier does not lexicographically precede the range - the object identifier lexicographically precedes the end of the range 7.2.1.1. agentx-Get-PDU An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'noSuchObject'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the region that contains the binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`noSuchObject'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: Daniele/Francisco Expires December 1996 [Page 34] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-Get-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). (5) Add a SearchRange to the end of the target subagent's PDU for this variable binding. - The variable binding's name is encoded into the starting OID. - The ending OID is encoded as null. If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.2. agentx-GetNext-PDU An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'endOfMibView'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate a) the OID range that contains the variable binding's name and is not a fully qualified instance, or b) the OID range that is the first lexicographical successor to the variable binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`endOfMibView'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-GetNext-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). Daniele/Francisco Expires December 1996 [Page 35] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (5) Add a SearchRange to the end of the target subagent's agentx-GetNext-PDU for this variable binding. - if (1a) applies, the variable binding's name is encoded into the starting OID, and the OID's `include' field is set to 0. - if (1b) applies, the target OID is encoded into the starting OID, and its `include' field is set to 1. - the ending OID is encoded with the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, it is encoded as a null OID. If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.3. agentx-GetBulk-PDU (Note: The outline of the following procedure is based closely on section 4.2.3, "The GetBulkRequest-PDU" of [4]. Please refer to it for details on the format of the SNMP GetBulkRequest-PDU itself.) An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU. The SNMP Response-PDU contains N + (M * R) variable bindings whose values are set to `EndOfMibView', where N ("non-repeaters") is the minimum of: a) the value of the non-repeaters field in the request, and b) the number of variable bindings in the request M ("max-repetitions") is the value of the max-repetitions field in the request R ("repeaters") is the maximum of: a) (number of variable bindings in the request) - N, and b) zero Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range and target subagent(s), exactly as described for the agentx-GetNext-PDU (see 7.2.1.2). (2) If this is the first variable binding to be dispatched to the target subagent during the processing of this Request-PDU, create an agentx-GetBulk-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). Daniele/Francisco Expires December 1996 [Page 36] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Set g.non_repeaters to 0. g.max_repetitions is generally set to the max_repetitions value in the Request-PDU. However, the master agent may elect a smaller value based on the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint. (3) Add a SearchRange to the end of the target subagent's agentx-GetBulk-PDU for this variable binding, as described for the agentx-GetNext-PDU. If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.4. agentx-Test-PDU AgentX employs the well-known test-commit-undo-cleanup phases to achieve "as if simultaneous" semantics of the SNMP SetRequest-PDU within the extensible agent. The initial phase involves the agentx-Test-PDU. An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'noSuchObject'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the range that contains the variable binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`noSuchObject'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-Test-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). Daniele/Francisco Expires December 1996 [Page 37] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 (5) Add a VarBind to the end of the target subagent's PDU for this variable binding, as described in section 5.4. If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into t.context. 7.2.1.5. Dispatch When all variable bindings have been processed, send any AgentX PDUs to their respective target subagents. Calculate a timeout value for each target subagent that is the maximum of: - The master agent's default. - The subagent's default, as indicated by the subagent at connection establishment. - Any region-specific timeout values, as indicated by the subagent at registration. 7.2.2. Subagent Processing of agentx-GET, GetNext, GetBulk-PDUs When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns an agentx-Response-PDU. The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.error_index to 0, and the VarBindList to null. Each SearchRange in the request PDU is then processed in order, and a corresponding VarBind is added to the agentx-Response-PDU as described below. If processing should fail for any reason not described below, res.error is set to `genError', res.error_index to the index of the failed SearchRange, the VarBindList is reset to null, and this agentx-Response-PDU is returned to the master agent. 7.2.2.1. Subagent Processing of the agentx-Get-PDU Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed in order as follows: 1) The starting OID is copied to v.name. 2) If the starting OID exactly matches the name of a variable instantiated by this subagent within the indicated context, v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4, Daniele/Francisco Expires December 1996 [Page 38] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Value Representation). If the resulting VarBind's type is not compatible with the SMI for the SNMP framework of the version specified in h.snmp_version, v.type is set to `noSuchObject', and v.length to 0. 3) Otherwise, if the starting OID does not match the OBJECT IDENTIFIER PREFIX of any variable instantiated within the indicated context, v.type is set to `noSuchObject' and v.length to 0. 4) Otherwise, v.type is set to `noSuchInstance' and v.length to 0. 7.2.2.2. Subagent Processing of the agentx-GetNext-PDU Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed in order as follows: 1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context, for which the following are all true: - if the `include' field of the starting OID is 0, the variable's name is the closest lexicographical successor to the starting OID. - if the `include' field of the starting OID is 1, the variable's name is either equal to, or the closest lexicographical successor to, the starting OID. - If the ending OID is not null, the variable's name lexicographically precedes the ending OID. - The variable's syntax is compatible with the SMI for the SNMP framework of the version specified in h.snmp_version. If all of these conditions are met, v.name is set to the located variable's name. v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4, Value Representation). 2) If no such variable exists, v.name is set to the starting OID, v.type is set to `endOfMibView', and v.length to 0. Daniele/Francisco Expires December 1996 [Page 39] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.2.2.3. Subagent Processing of the agentx-GetBulk-PDU A maximum of N + (M * R) VarBinds are returned, where N equals g.non_repeaters, M equals g.max_repetitions, and R is (number of SearchRanges in the GETBULK request) - N. The first N SearchRanges are processed exactly as for the agentx-GetNext-PDU. If M and R are both non-zero, the remaining R SearchRanges are processed iteratively to produce potentially many VarBinds. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated SearchRange s, such that s is greater than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind is added to the agentx-Response-PDU as follows: 1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context, for which the following are all true: - The variable's name is the (i)-th lexicographical successor to the (N+s)-th requested OID. (Note that if i is 0 and the `include' field is 1, the variable's name may be equivalent to, or the first lexicographical successor to, the (N+s)-th requested OID.) - If the ending OID is not null, the variable's name lexicographically precedes the ending OID. - The variable's syntax is compatible with the SMI for the SNMP framework of the version specified in h.snmp_version. If all of these conditions are met, v.name is set to the located variable's name. v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4 Value Representation). 2) If no such variable exists, v.type is set to `endOfMibView' and v.length to 0. v.name is set to v.name of the (N+((i-2)*R)+s)-th VarBind unless i is currently 1, in which case it is set to the value of the starting OID in the (N+s)-th SearchRange. Daniele/Francisco Expires December 1996 [Page 40] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Note that further iterative processing should stop if - For any iteration i, all s values of v.type are `EndofMibView'. - An AgentX transport constraint or other implementation-specific constraint is reached. 7.2.3. Subagent Processing of agentx-Test, -Commit, -Undo, -Cleanup-PDUs These four PDUs are used to collectively perform the indicated management operation. An agentx-Response-PDU is sent in reply to each of the PDUs, to inform the master agent of the state of the operation. The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.error_index to 0, and the VarBindList to null. 7.2.3.1. Subagent Processing of the agentx-Test-PDU Upon the subagent's receipt of an agentx-Test-PDU, each VarBind in the PDU is validated until they are all successful, or until one fails, as described in section 4.2.5 of [4]. As a result of this validation step, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), genErr (5), noAccess (6), wrongType (7), wrongLength (8), wrongEncoding (9), wrongValue (10), noCreation (11), inconsistentValue (12), resourceUnavailable (13), notWritable (17), inconsistentName (18) If this value is not noError(0), the res.index field must be set to the index of the VarBind for which validation failed. Full context for this operation must be maintained by the subagent. Daniele/Francisco Expires December 1996 [Page 41] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.2.3.2. Subagent Processing of the agentx-Commit-PDU The agentx-Commit-PDU indicates the subagent should actually perform the management operation indicated by the previous Test-PDU, as described in section 4.2.5 of [4]. As a result of this, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), commitFailed (14) If this value is commitFailed(14), the res.index field must be set to the index of the VarBind for which the operation failed. Otherwise res.index is set to 0. Full context for this operation must be maintained by the subagent. 7.2.3.3. Subagent Processing of the agentx-Undo-PDU The agentx-Undo-PDU indicates the subagent should undo the management operation indicated in the previous Commit-PDU, as described in section 4.2.5 of [4]. As a result of this, an agentx-Response-PDU is returned whose res.index field is set to 0, and whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), undoFailed (15) This ends subagent processing of the management request. 7.2.3.4. Subagent Processing of the agentx-Cleanup-PDU The agentx-Cleanup-PDU indicates the end of processing of the management operation indicated in the previous Commit-PDU. No response is sent by the subagent. 7.2.4. Master Agent Processing of AgentX Responses The master agent now marshals all subagent agentx-Response-PDUs and builds an SNMP Response-PDU. In the next several sub-sections, the initial processing of all subagent agentx-Response-PDUs is described, followed by descriptions of subsequent processing for each Response type. Daniele/Francisco Expires December 1996 [Page 42] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7.2.4.1. Common Processing of All AgentX Response PDUs If any SearchRange was sent to more than one subagent, the "best" response must be chosen. (Note: This could only have occurred if a requested variable binding fell within a duplicate OID range that was established via duplicate registrations, i.e., the REG_UNION bit was set.) During such processing, if the master agent discovers that multiple subagents instantiate the same MIB variable, a duplicateInstance notification should be generated as described in section [TBD]. Only a single such notification should be generated per duplicated OID range (not per duplicated instance) between reboots of the master agent. 1) If any subagent did not respond within its allotted time period, this is treated as if the subagent had returned `genError' and processed as described below. 2) Otherwise, if the h.ID field of an agentx-Response-PDU does not match that of the request PDU sent to this subagent, the PDU is ignored. 3) Otherwise, the responses are processed jointly to form the SNMP Response-PDU. 7.2.4.2. Processing of Responses to agentx-Get-PDUs After common processing of the subagent's response to an agentx-Get-PDU (see 7.2.4.1 above), processing continues with the following steps: If any SearchRange was dispatched to multiple subagents: 1a) Any response whose corresponding VarBind contains data supersedes responses containing an error or whose corresponding VarBind contains an exception value. If multiple such "good" responses are received, the choice of which VarBind to use is implementation-specific. If all responses contain an error or exception value, the choice of which to use is implementation-specific. Alternately, if no SearchRange was dispatched to multiple subagents: 1b) For any received agentx-Response-PDU, if res.error is not `noError', the SNMP response PDU's error code is set to this Daniele/Francisco Expires December 1996 [Page 43] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 value, and its error index to the index of the variable binding corresponding to the failed VarBind in the subagent's agentx-Response-PDU. All other agentx-Response-PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response-PDU is sent. 2) Otherwise, the content of each VarBind in the agentx-Response-PDU is used to update the corresponding variable binding in the SNMP Response-PDU. 7.2.4.3. Processing of Responses to agentx-GetNext- and agentx-GetBulk-PDUs After common processing of the subagent's response to an agentx-GetNext-PDU or agentx-GetBulk-PDU (see 7.2.4.1 above), processing continues with the following steps: If any SearchRange was dispatched to multiple subagents: 1a) Any response whose corresponding VarBind contains data supersedes responses containing an error or whose corresponding VarBind contains an exception value. If multiple such "good" responses are received, the VarBind containing the lexicographically first value in v.name is chosen. If still ambiguous, the choice of which VarBind to use is implementation-specific. If all responses contain an error or exception value, the choice of which to use is implementation-specific. Alternately, if no SearchRange was dispatched to multiple subagents: 1b) For any received agentx-Response-PDU, if res.error is not `noError', the SNMP response PDU's error code is set to this value, and its error index to the index of the variable binding corresponding to the failed VarBind in the subagent's agentx-Response-PDU. All other agentx-Response-PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response PDU is sent. 2) Otherwise, the content of each VarBind in the agentx-Response-PDU is used to update the corresponding variable binding in the SNMP Response-PDU. Daniele/Francisco Expires December 1996 [Page 44] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 After all expected agentx-Response-PDUs have been processed, if any variable bindings still contain the value `endOfMibView', processing must continue: 3) For each such variable binding, a target OID range is identified which is the lexicographical successor to the target OID range for this variable binding on the last iteration. The target subagent is the one that registered the target OID range. 4) If this is the first variable binding to be dispatched to the target subagent (during this iteration), create an agentx-GetNext or GetBulk-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). 5a) For responses to agentx-GetNext-PDUs: i) Add a SearchRange to the end of the target subagent's PDU for this variable binding. The starting OID is set to the target OID range, and its `include' field is set to 1. The ending OID is set to the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, the ending OID is set to null. 5b) For responses to agentx-GetBulk-PDUs: i) Set the value of g.non_repeaters and g.max_repetitions to 0. ii) Add a SearchRange to the end of the target subagent's PDU for this variable binding. The starting OID is set to the target OID range, and its `include' field is set to 1. The ending OID is set to the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, the ending OID is set to null. iii) If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. Otherwise, set the value of g.max_repetitions to the maximum of its current value, or the number of response variable bindings still required for this requested variable binding. 6) The AgentX PDUs are sent to the subagent(s), and the responses are received and processed according to the steps described in section 7.2.4. Daniele/Francisco Expires December 1996 [Page 45] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7) This process continues iteratively until a complete SNMP Response-PDU has been built, or until there remain no target OID range lexicographical successors. [Include examples, TBD] 7.2.4.4. Processing of Responses to agentx-Test-PDUs After common processing of the subagent's response to an agentx-Test-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) If any agentx-Test-PDU was dispatched to multiple subagents, a single target subagent is determined. a) If a single subagent succeeded (returned `noError'), it becomes the target subagent and continues to participate in subsequent processing. b) If multiple such "good" responses are received, the choice of which subagent to use is implementation-specific. c) If all responses contain indicate an error, the choice of which to use is implementation-specific. d) An agentx-Cleanup-PDU is sent to all subagents that have not been identified as target subagents. 2) If any target subagent's response is not `noError', all other agentx-Response-PDUs received due to processing this SNMP Request are ignored. An agentx-Cleanup-PDU is sent to each target subagent. Processing is complete; the SNMP Response-PDU is constructed as described below in 7.2.4.6, step (2). 3) Otherwise an agentx-Commit-PDU is sent to each target subagent. 7.2.4.5. Processing of Responses to agentx-Commit-PDUs After common processing of the subagent's response to an agentx-Commit-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) If any response is not `noError', all other agentx-Response-PDUs received due to processing this SNMP Request are ignored. An agentx-Undo-PDU is sent to each target subagent. Daniele/Francisco Expires December 1996 [Page 46] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 2) Otherwise an agentx-Cleanup-PDU is sent to each target subagent. Processing is complete; the SNMP Response-PDU is constructed as described below in 7.2.4.6, step (2). 7.2.4.6. Processing of Responses to agentx-Undo-PDUs After common processing of the subagent's response to an agentx-Undo-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) An agentx-Cleanup-PDU is sent to each target subagent. 2) If any response is not `noError' the SNMP response PDU's error code is set to this value, and its error index to the index of the variable binding corresponding to the failed VarBind in the agentx-Test-PDU. Otherwise the SNMP Response-PDU's error code is set to `noError' and its error index to 0. 7.2.5. Sending the SNMP Response-PDU Once the processing described in sections 7.2.1 - 7.2.3 is complete, there is an SNMP Response-PDU available. The master agent now implements the Elements of Procedure for the applicable version of the SNMP protocol in order to encapsulate the PDU into a message, and transmit it to the originator of the SNMP management request. Note that this may involve altering the PDU contents for agents that support the SNMP version 1 framework. In such cases the recommended mapping is that defined in [9]. 7.2.6. MIB Views AgentX subagents are not aware of MIB views, since view information is not contained in AgentX PDUs. As stated above, the descriptions of procedures in section 7 of this memo are not intended to constrain the internal architecture of any procedures described in sections 7.2.1 and 7.2.3 may be altered so as to optimize AgentX exchanges when implementing MIB views. Such optimizations are beyond the scope of this memo. But note that section 7.2.3 defines subagent behavior in such a way that alteration of SearchRanges may be used in such optimizations. Daniele/Francisco Expires December 1996 [Page 47] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 8. Transport Mappings The same AgentX PDU formats, encodings, and elements of procedure are used regardless of the underlying transport. 8.1. AgentX over TCP 8.1.1. Well-known Values The master agent accepts TCP connection requests for the well-known port [TBD]. Subagents connect to the master agent using this port number. 8.1.2. Operation Once a TCP connection has been established, the AgentX peers use this connection to carry all AgentX PDUs. Only a single logical connection may be established per transport connection. All AgentX PDUs are presented individually to the TCP, to be sent as the data portion of a TCP PDU. 8.2. AgentX over UNIX-domain Sockets Many (BSD-derived) implementations of the UNIX operating system support the UNIX pathname address family (AF_UNIX) for socket communications. This provides a convenient method of sending and receiving datagrams (SOCK_DGRAM type) between processes on the same host. Mapping AgentX to this transport is useful for environments that - wish to guarantee subagents are running on the same managed node as the master agent - typically provide better performance than TCP or UDP, especially in the presence of heavy network I/O 8.2.1. Well-known Values A subagent creates a UNIX-domain socket endpoint called "/var/agentx/subagent", where is the textual representation of a unique identifier. The recommended value is (or is based on) the subagent's process identifier (e.g, "/var/agentx/subagent2133"). This is the subagent endpoint for all AgentX communication. The master agent creates a well-known UNIX-domain socket endpoint called "var/agentx/master". (It may create other, implementation-specific endpoints.) These endpoint names use the character set encoding native to the Daniele/Francisco Expires December 1996 [Page 48] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 managed node, and represent UNIX-domain datagram sockets. 8.2.2. Operation All AgentX PDUs are sent as individual datagrams. The maximum length of AgentX PDUs when using this transport is 2048 octets. All PDUs originated by the subagent (Open, Close, Register, Unregister, Ping, Notify) are sent to the master agent's well-known endpoint. Only a single logical connection may be established (via sending the Open PDU) from a single subagent endpoint. All PDUs originated by the master agent (Close, Get, GetNext, GetBulk, Test, Commit, Undo, Cleanup, Response) are sent to the subagent endpoint used to initiate the logical connection. All PDUs sent by the subagent in response to a received PDU (Response) are sent to the endpoint that originated the received PDU. 9. Security Considerations This memo defines a protocol between two processing entities, one of which (the master agent) is also assumed to perform authentication of received SNMP requests and to control access to management information. The master agent performs these security operations independently of the other processing entity (the subagent). Thus, security issues are outside the scope of this protocol definition. 10. Acknowledgements The initial draft of this memo was heavily influenced by the DPI 2.0 specification [7]. This document was produced by the IETF Agent Extensibility (AgentX) Working Group, and benefited especially from the contributions of the following working group members: Jeff Case, Maria Greene, Bob Natale, Randy Presuhn, Aleksey Romanov, and Bert Wijnen. Daniele/Francisco Expires December 1996 [Page 49] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 11. Questions and Issues 11.1. Design Here are some of the questions and issues (and some attempts at addressing them) that have arisen with regard to the concept of maximizing the number of varbinds in AgentX PDUs, as opposed to limiting each AgentX PDU to contain a single varbind: 1) Isn't this design harder to document and implement than, for example, one which limits each PDU to containing a single variable binding? It is somewhat more complex. But not greatly so, given that the master agent must distribute varbinds to multiple subagents anyway. An important note here is the assumption that these details of AgentX will not be made visible to subagent (end user) developers. Vendors typically ship API libraries which hide the protocol implementation and present a method routine interface. So for example, the fact that a particular AgentX request PDU is - a GetBulk with max repetitions == 10, - containing 7 variable bindings - all bounded by a different subagent's registration of (...), and - made via SNMPv1, so object types (...) must be skipped would not be visible to the MIB implementor; they would be handled within the subagent library implementation of AgentX. 2) The multiple-varbind design requires more memory (stack, heap) in both the master agent and the subagent. It's not clear that the master agent will have a bigger memory load under the multiple-varbind design, since it needs to keep all varbinds around anyway. Yes, the subagent has potentially many varbinds concurrently instead of one. But this seems like the correct design trade-off. Note that for GetBulk (where this effect will be most dramatic), the subagent is permitted to return less than the requested number of varbinds. 3) As a result of its more complex design, the multiple-varbind design will require more code space. Daniele/Francisco Expires December 1996 [Page 50] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 In at least one sample implementation, it works out to about 20 more lines of code in the subagent, which seems a tiny cost for a large performance win. It's probably more in the master (haven't checked the implementation carefully; it's somewhat harder to separate things out in the master agent). But given the inherent complexity of an extensible master agent, this additional code space seems like a small price to pay for the added functionality. 4) Maybe this is the wrong goal. Some "transports" are very fast; who cares how many transactions are required to service a request? This touches on the nature of AgentX. It had to be designed in part as interprocess communications, not simply a network protocol. This is why care is taken to achieve alignment of most structures on 4-byte offsets within the PDU, for instance. But it doesn't seem wise to assume the availability of particular mechanisms to carry AgentX (e.g., shared memory). Nor can we assume that the required transport mappings will be standardized, and that therefore the AgentX specification need not be concerned with performance. In other words, we need to try to make it work reasonably well even over TCP. 11.2. Miscellaneous Issues Below are several comments from Mike Daniele on various issues that remain to be resolved by the working group. For some of these he has proposed solutions. 1) How to transfer binary OIDs? A suggested shorthand is included in this version of this memo (specifying a prefix, etc.) There wasn't much feedback on the list; it's not something I view as critical. Just seems like an easy way to save some space. Additionally, the "RangeSpecifier" encoding was removed. Since OIDs with subid ranges are only permitted in Register and Unregister PDUs, the OID range stuff is defined there. Daniele/Francisco Expires December 1996 [Page 51] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 2) Unionized registrations We never got a real example of where this is absolutely necessary. But it seems to be something that will help integrate random subagents. So I've included it in the spec, while simultaneously trying hard to discourage its use... And it's now optional; the master agent may simply reject exact duplicate registrations. 3) Contexts Last version would not support v2*. This version includes bits in the h.flags field to differentiate "all", "default", or "specific". 4) sysUpTime Is returned with the response to an Open or Register PDU. 5) sysORTable An OID and display string are passed in the Open PDU, and a h.flags bit defines if these represent an agent capabilities. This means the level of granularity is the subagent (Open/close), not registration. May be too high, but at least it's simple. This mechanism is also the implied way to handle counter discontinuities... 6) SNMP version in the AgentX header I know may of you feel this reeks. But there were at least three implementors in Montreal who said it needs to be there. I'm hoping folks will think about it a bit more, possibly in conjunction with the background design discussion, and also in light of recent postings to the SNMPv2 list... Daniele/Francisco Expires December 1996 [Page 52] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 7) Options The following optional features are allowed by this memo. The decision of whether or not to support these features is implementation specific. Master agent: - Supporting non-default contexts - Supporting unionized registrations - Supporting next-available-index reservation for non-integer indexes Subagent: none 8) Index reservation Have added agentx-IndexRsrv-PDU and related elements of procedure, based on discussion with Maria Greene. 9) States Do we need to specify protocol states? Some are implied by elements of procedure (can't register before open, etc.). Perhaps specifying that Test/Commit/Undo/cleanup must finish before other requests are forwarded to a subagent? 12. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Daniele/Francisco Expires December 1996 [Page 53] agentx protocol 00.04 Tue Sep 10 06:25:14 PDT 1996 Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, "Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, IBM Corp., Bell Northern Research, Ltd., March 1994. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [9] Wijnen, B., and Levi, D., "V2ToV1: Mapping SNMPv2 onto SNMPv1 Within a Bilingual SNMP Agent", FYI ???, T.J. Watson Research Center, IBM Corp., SNMP Research, Inc., August 1996. Daniele/Francisco Expires December 1996 [Page 54]   Delivery-Date: Wed, 11 Sep 1996 09:45:09 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id JAA22041 for X-agentx; Wed, 11 Sep 1996 09:45:09 -0700 (PDT) Received: from uscore.underscore.com (uscore.underscore.com [199.125.69.1]) by fv.com (8.7.4/8.7.3) with SMTP id JAA22038 for ; Wed, 11 Sep 1996 09:45:07 -0700 (PDT) Received: by uscore.underscore.com (Smail3.1.28.1 #5) id m0v0sMj-000US2C; Wed, 11 Sep 96 12:42 EDT Message-Id: Date: Wed, 11 Sep 96 12:42 EDT From: jkm@underscore.com (JK Martin) To: agentx@fv.com Subject: Re: duplicate/unionized registrations Bert Wijnen wrote: > See... there you go. When I am concerned about "complexity" in the spec, > it is often not so much about the spec but more about what it means > implementation wise. It is easy to write that some issues are > "implementation issues" or done by "magic"... but then coding it is > a bit more of a burden. > > Anyway, my "vote" is AGAINST the complexity of duplicate/unionized > registrations. I do not even want it as an option. Speaking as a lurker on this list, I agree with Bert, though for somewhat different reasons. It seems troubling to me that multiple sub-agents can be "serving" the same OID(s). When two or more sub-agents try to set the same OID to differing values, what can be said about the semantics of the system when only one sub-agent wins? Seems like there can be considerable danger with regard to data integrity when this happens. Does the "losing" sub-agent know that its attempt to set the OID has failed? (Sorry if I'm not up on the spec for this question.) If the "loser" sub-agent is not aware of the set failure, then it would seem like that sub-agent's internal data domain is rendered useless. If the sub-agent can indeed detect the set failure, then what is the sub-agent supposed to do? Complain via some log file, or send some sort of non-SNMP message somewhere declaring the failure? And then what should it do? Continue as if everything is ok? I apologize in advance if these scenarios are covered by the most recent spec. Even then, it would be nice if some of the experts would summarily address these concerns, or point to existing references, etc. No matter what, it's a tough problem, indeed. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ----------------------------------------------------------------------   Delivery-Date: Wed, 11 Sep 1996 10:17:30 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA24802 for X-agentx; Wed, 11 Sep 1996 10:17:30 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id KAA24799 for ; Wed, 11 Sep 1996 10:17:29 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id NAA12475; Wed, 11 Sep 1996 13:17:16 -0400 Date: Wed, 11 Sep 1996 13:16:23 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08421; Wed, 11 Sep 1996 13:16:23 -0400 Message-Id: <9609111716.AA08421@nips.acec.com> To: wijnen@vnet.ibm.com Subject: Re: REG_CLUSTER bit in h.flags Cc: agentx@fv.com > Date: Wed, 11 Sep 96 17:14:40 DST > From: "Bert Wijnen" Hi Bert, > Mmmm... I find this very Operating System dependent stuff and I > doubt that this is within the scope of our WG. > > To me it seems similar to the ASCII-EBCDIC debate we had where > we now decided to just use ASCII. [Speaking as a wg contributor:] Yes, I agree with you and the analogy is a good one. This feature would be very limited in applicability...one can imagine many other candidates for a bit to indicate some "special case" or other...in effect, they would all have to become "optional" features and I think we are all in agreement on limiting the number of optional features to as close to zero as we can come. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 11 Sep 1996 11:48:18 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA04599 for X-agentx; Wed, 11 Sep 1996 11:48:18 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA04596 for ; Wed, 11 Sep 1996 11:48:17 -0700 (PDT) Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA22887; Wed, 11 Sep 1996 14:40:47 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA26949; Wed, 11 Sep 1996 14:40:47 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06450; Wed, 11 Sep 1996 14:44:06 -0400 Message-Id: <9609111844.AA06450@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: agent-caps and o.id and o.descr Date: Wed, 11 Sep 96 14:44:06 -0400 From: Mike Daniele X-Mts: smtp Hi Bert, >If this understanding is correct, then that is fine. But pls >change the text to make this very clear. Specifically the >words "it represents a unique (enterprise-specific) sysObjectID" >(botom of page 16) are very confusing. Yes, your understanding is correct, and that sentence now reads "it represents a sysObjectID-like value that uniquely identifies the subagent." >While writing this, I also realize that agent-caps at subagent >granularity is problematic, because the spec now allows a sub >to register MIB regions in multiple contexts. And within each >contxt we have a sysORTable that needs to properly represent >the set of agent-caps within that context. Yup, issue 5) sysORTable at the end of the draft states This means the level of granularity is the subagent (Open/close), not registration. May be too high, but at least it's simple. >So our design is broken. >It seems we need to allow to SET/REGISTER agent-caps either per >registration (as part of the register pdu) or via a separate >register_agent_caps pdu that would allow to specify the context >for which one the agent-caps registration is intended. I raised both of these on the list some time ago and got no feedback, so I'm glad you brought it up. In the absence of any feedback, I chose the simplest alternative. Per-registration agent capabilities doesn't seem to map very well either, since I expect MIB implementations will define a single capabilities oid to represent themselves, regardless of how many distinct registrations they'll make. (If I'm going to register an ifTable entry, and some media-specific stuff, do I write several AGENT-CAPABILITIES macro or just one?) I suppose the real question is, might subagents need different sysORIDs within different contexts in order to be accurately represented? Specific PDUs would be the most flexible. I haven't seen/heard of a manager that actually uses agent caps yet, so can't personally justify a lot of additional AgentX support for them. But I live under a rock... so would greatly appreciate hearing from those who know better. Regards, Mike   Delivery-Date: Wed, 11 Sep 1996 12:21:49 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA07768 for X-agentx; Wed, 11 Sep 1996 12:21:48 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by fv.com (8.7.4/8.7.3) with SMTP id MAA07765 for ; Wed, 11 Sep 1996 12:21:47 -0700 (PDT) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA09184; Wed, 11 Sep 96 15:21:49 -0400 Date: Wed, 11 Sep 96 15:21:49 -0400 From: David Battle Message-Id: <9609111921.AA09184@seymour16.snmp.com> To: agentx@fv.com Subject: Re: duplicate/unionized registrations Venkat writes: >My humble suggestion here is to NOT to allow more than one sub-agent register >the same object id. To which Mike responds: >Feedback from some folks with lots of experience with extensible agents is >that this feature is required. Many others agree with you :-) > And then Bert Says: > So who are those "some folks" ?? Me, for example. > They probably have such an implementation currently. True, EMANATE easily handles multiple sub-agents registering the same object identifier. This is particularly useful when tables are split across subagents. I resisted doing this because it *is* a bit of a pain to implement. But we did it because customers demanded it; big customers like Cisco, Siemens, and HP. I'm sure Dr. Case would be very happy if you leave this out of agentx because it will mean that EMANATE is safe from any serious competition from agentx :-). Mike also says: >So far we've avoided specifying optional behavior. Perhaps unionized >registration is a reasonable candidate? > And Bert says: > I suggest that we do a few "optional" stuff as possible. I agree. Optional stuff is useless. This should be a requirement. -David L. Battle Senior Software Engineer SNMP Research, Inc.   Delivery-Date: Wed, 11 Sep 1996 13:09:31 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA12179 for X-agentx; Wed, 11 Sep 1996 13:09:31 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id NAA12176 for ; Wed, 11 Sep 1996 13:09:30 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA17516; Wed, 11 Sep 1996 16:04:30 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA11744; Wed, 11 Sep 1996 16:04:43 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06661; Wed, 11 Sep 1996 16:07:51 -0400 Message-Id: <9609112007.AA06661@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: duplicate/unionized registrations Date: Wed, 11 Sep 96 16:07:50 -0400 From: Mike Daniele X-Mts: smtp Hi Dave, Thanks for jumping in here. I was beginning to wonder if I'd imagined the guy sitting next to me in Montreal, yelling how broken the draft was. :-) >True, EMANATE easily handles multiple sub-agents registering the same object >identifier. This is particularly useful when tables are split across >subagents. I resisted doing this because it *is* a bit of a pain to >implement. But we did it because customers demanded it; big customers >like Cisco, Siemens, and HP. Would it be possible to supply a specific example how this feature (permitting multiple subagents to register the same oid) is used/required in order for subagents to implement a table that is split across subagents? What I'm really trying to get at is this: Is it useful/required because a) These companies implement tables that CANNOT reasonably be split across subagents WITHOUT this feature. That is, the table's indexing structure and/or the nature of the data make it impossible to partition the table so that each subagent gets unique sections? (If so, an example of this would be vey helpful.) or b) These companies implement subagents that each "take the easy way out" and register the entire table, and expect the master agent to figure things out. (Perhaps this is reality and it's naive to expect otherwise...) Thanks, Mike   Delivery-Date: Wed, 11 Sep 1996 13:22:37 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA13378 for X-agentx; Wed, 11 Sep 1996 13:22:36 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id NAA13375 for ; Wed, 11 Sep 1996 13:22:35 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id QAA14725; Wed, 11 Sep 1996 16:22:23 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id QAA22151; Wed, 11 Sep 1996 16:22:23 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id QAA05559; Wed, 11 Sep 1996 16:22:22 -0400 (EDT) Date: Wed, 11 Sep 1996 16:22:22 -0400 (EDT) From: Maria Greene Message-Id: <199609112022.QAA05559@avalon.nexen.com> To: David Battle cc: agentx@fv.com Subject: Re: duplicate/unionized registrations References: <9609111921.AA09184@seymour16.snmp.com> David said (regarding duplicate OID registeration): > True, EMANATE easily handles multiple sub-agents registering the > same object identifier. This is particularly useful when tables > are split across subagents. I resisted doing this because it > *is* a bit of a pain to implement. But we did it because > customers demanded it; big customers like Cisco, Siemens, and > HP. I'm sure Dr. Case would be very happy if you leave this out > of agentx because it will mean that EMANATE is safe from any > serious competition from agentx :-). When talking about registering the same OIDs, I think we need to distinguish registering the same 'leaf' object from registering the same 'branch' object. The problem is, without MIB knowledge, the master agent can't tell the difference. I think the master agent should accept duplicate registrations for exactly the reason David cites -- to allow tables to be split across subagents. However, if two subagents register fooObject.1 that's a misconfiguration, in my opinion. (I do this occasionally when I forget to kill my subagent before starting it again.) The master agent could increment an error counter when it receives a non-error response from more than one subagent on a get or a set. Maria   Delivery-Date: Wed, 11 Sep 1996 14:15:37 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA18442 for X-agentx; Wed, 11 Sep 1996 14:15:36 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id OAA18439 for ; Wed, 11 Sep 1996 14:15:35 -0700 (PDT) Received: from hunch.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA22149; Wed, 11 Sep 1996 17:05:57 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA16551; Wed, 11 Sep 1996 17:05:56 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06855; Wed, 11 Sep 1996 17:09:17 -0400 Message-Id: <9609112109.AA06855@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: duplicate/unionized registrations Date: Wed, 11 Sep 96 17:09:17 -0400 From: Mike Daniele X-Mts: smtp Hi Maria, >When talking about registering the same OIDs, I think we need to >distinguish registering the same 'leaf' object from registering the >same 'branch' object. The problem is, without MIB knowledge, the >master agent can't tell the difference. We do have the REG_INSTANCE bit in h.flags, which the subagent is supposed to set when registering a fully qualified instance. (See 6.2.3.1.) It's there to avoid needless Next/Bulk dispatches, but I suppose could also be used as you suggest below. >I think the master agent should accept duplicate registrations for >exactly the reason David cites -- to allow tables to be split across >subagents. However, if two subagents register fooObject.1 that's a >misconfiguration, in my opinion. (I do this occasionally when I forget >to kill my subagent before starting it again.) The master agent could >increment an error counter when it receives a non-error response from >more than one subagent on a get or a set. Mike   Delivery-Date: Wed, 11 Sep 1996 14:16:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA18529 for X-agentx; Wed, 11 Sep 1996 14:16:41 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id OAA18525 for ; Wed, 11 Sep 1996 14:16:40 -0700 (PDT) Message-Id: <199609112116.OAA18525@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0778; Wed, 11 Sep 96 17:16:47 EDT Date: Wed, 11 Sep 96 23:16:25 DST From: "Bert Wijnen" To: agentx@fv.com Subject: duplicate/unionized registrations Ref: Your note of Wed, 11 Sep 96 16:07:50 -0400 Subject: duplicate/unionized registrations David writes: >True, EMANATE easily handles multiple sub-agents registering the same object >identifier. This is particularly useful when tables are split across >subagents. I resisted doing this because it *is* a bit of a pain to >implement. But we did it because customers demanded it; big customers >like Cisco, Siemens, and HP. > Those are interesting names. And I can also imagine that a fraction of the possible uses within these companies do need/want the unionized registrations. So do some very special projects in my company. But that does not make it a generic enough requirement that we should pay the price for the added complexity to our protocol. As a proof, one Cisco employee posted to this mailing list a little while ago: > From: R Venkatsubramaniam > Subject: Re: AgentX protocol draft, ver 00.03 > To: agentx@fv.com > Date: Wed, 4 Sep 1996 00:15:07 -0700 (PDT) > > Hi, > > > 7.1.2.1. Handling Duplicate OID Ranges > > > .... > > > > My humble suggestion here is to NOT to allow more than one sub-agent regi > the same object id. Assuming that the master agent is 'responsible' for > the sysuptime, 'sysuptime' can be used as the final tie-breaker by the ma > agent. Whichever sub-agent registers first (sysuptime is used for this t > comparison), should be dispatched the request related to the object id. i > question (assuming the sysuptimes are not equal !). > > I AM missing something !! > > Thanks, > - Venkat. > Bert   Delivery-Date: Wed, 11 Sep 1996 14:27:03 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA19538 for X-agentx; Wed, 11 Sep 1996 14:27:03 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id OAA19512 for ; Wed, 11 Sep 1996 14:27:02 -0700 (PDT) Message-Id: <199609112127.OAA19512@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1206; Wed, 11 Sep 96 17:27:09 EDT Date: Wed, 11 Sep 96 23:26:53 DST From: "Bert Wijnen" To: agentx@fv.com Subject: agent-caps and o.id and o.descr Ref: Your note of Wed, 11 Sep 96 14:44:06 -0400 Subject: agent-caps and o.id and o.descr Mike writes: > Yes, your understanding is correct, and that sentence now reads > > "it represents a sysObjectID-like value that uniquely > identifies the subagent." > I still think the work sysObjectID will cause confusion. why not: "it represents an OID value that uniquely identifies the subagent." Bert   Delivery-Date: Wed, 11 Sep 1996 14:31:29 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA19932 for X-agentx; Wed, 11 Sep 1996 14:31:29 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id OAA19929 for ; Wed, 11 Sep 1996 14:31:27 -0700 (PDT) Message-Id: <199609112131.OAA19929@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1353; Wed, 11 Sep 96 17:31:33 EDT Date: Wed, 11 Sep 96 23:31:17 DST From: "Bert Wijnen" To: agentx@fv.com Subject: agent-caps and o.id and o.descr Ref: Your note of Wed, 11 Sep 96 14:44:06 -0400 Subject: agent-caps and o.id and o.descr Mike, from your answer, it is unclear to me if you got the most important point of my message: - the design is broken. If we use the o.id and o.descr from the OPEN-PDU, then at that time we do NOT yet know in which context(s) the sub will register any OID-ranges So there is NO way to decide at that point in which sysORTable we must put the agent-caps data. We could solve it to request that a context is passed at OPEN time also. But if a sb is allowed to register OID-ranges in multiple contexts, then we would either need to allow to specify multiple contexts in the OPEN pdu or we would have to provide a seperate PDU to register agent-caps for a specific context. Bert   Delivery-Date: Wed, 11 Sep 1996 14:36:40 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA20296 for X-agentx; Wed, 11 Sep 1996 14:36:39 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id OAA20293 for ; Wed, 11 Sep 1996 14:36:37 -0700 (PDT) Message-Id: <199609112136.OAA20293@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1584; Wed, 11 Sep 96 17:36:44 EDT Date: Wed, 11 Sep 96 23:36:25 DST From: "Bert Wijnen" To: agentx@fv.com Subject: NITS to draft 00.03 Here is a list of "nits" that you might want to correct in a next version of the document. 1.The doc talks about a "logical connection" between master and sub in many places. I am not sure I understand the meaning of "logical". Is it as opposed to "physical"?? It gives the impression of a "special" type of connection though? I would leave the word "logical" out. 2.References. You have for instance (on page 9 at top) a reference as follows: - Provides instrumentation for the MIB objects defined in 5|, I always find it handy if the reference is of this type: - Provides instrumentation for the MIB objects defined in RFC1907 5|, That makes it easy for people who know RFC1907. It is a short addition for quick recognition, while the full title, authors etc are in the reference section. 3.Page 9 states: - Binds MIB region OIDs (contained in AgentX protocol messages) to actual variable names. I think it would be better to say: - Binds OIDs within its registered MIB regions to actual variable names. 4.Page 11, sample OID of 9.9.9.9 Seems like a real bad sample, because the second subid of an OID can not be GT 2. So why not use 1.2.3.4 (which is also clearly an example but at the same time is a valid OID). 5.At a few places the doc refers to ASCII strings. It seems their lengths are all derived from length fields in the PDU. So they are not NULL terminated. It might be wise to explicitly state that. A lot of people assume that an ASCII string is NULL terminated. I mean the strings: context (page 12) o.descr (page 17) 6.Section 6.2.11. The agentx-Response-PDU +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : h.length : h.version : 14 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : h.ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : h.flags : h.snmp_version : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : res.error : res.index : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is it intentional that res.error and res.index are not aligned with fields like h.flags and h.snmp_version? 8.Page 27 7.1.2. Processing the agentx-Register-PDU When the master agent receives an agentx-Register-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Characterize the request. If r.region (or any of its set of ObjectIdentifiers if r.range ======== ?? should this if be the word in ?? is non-zero) is exactly the same as any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed a duplicate region. If r.region (or any of its set of ObjectIdentifiers if r.range ======== ?? should this if be the word in ?? is non-zero) is a subtree of, or contains, any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed an overlapping region. 9.Page 45 at the top says: If all responses contain indicate an error, the choice of ================ which to use is implementation-specific. I guess we do not want these 2 verbs to follow each other. 10.Page 48, at bottom Is "bounded" correct? I thought it should be "bound" 11.Page 14 (middle) has this text: o noSuchObject, noSuchInstance, are endOfMibView are ====== implicit NULL and represented by v.size equal 0, and no data. I think we mean "and endOfMibView" === Bert   Delivery-Date: Wed, 11 Sep 1996 14:47:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA21301 for X-agentx; Wed, 11 Sep 1996 14:47:23 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id OAA21298 for ; Wed, 11 Sep 1996 14:47:21 -0700 (PDT) Message-Id: <199609112147.OAA21298@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1992; Wed, 11 Sep 96 17:47:28 EDT Date: Wed, 11 Sep 96 23:47:12 DST From: "Bert Wijnen" To: agentx@fv.com Subject: various items - based on version 00.03 draft 1.May I suggest that we do NOT specify any fields but that we make those fields. Let us also specify that those fields MUST be zero. That way it is easier in the future to extend and use those fields. 2.May I suggest that the padding bytes (wherever they are used) MUST be zero. That way they are easier to recognize when debugging. Let us also explicitly state that such padding bytes are ignored. 3.I see various places in the elements of procedure that the master agent "ignores" a PDU from a sub in certain error conditions. The result will be that the sub will wait for a (relatively long) while to find out that "something" was wrong, but it does not know what was wrong. I think it is better to always try to send a response with an error code, so that the sub QUICKLY knows what is wrong. In fact, in SNMPv1 we had many places where we "dropped an SNMP PDU" and now in SNMPv2u/v2* we see that we added the report-PDU so that an agent can QUICKLY tell the manager what was wrong as opposed to the manager just timing out without having an idea what was wrong. The DPI in fact does return an erro-response whenever possible, and we found that VERY USEFUL. 4.I am 100% against passing SNMP version info to the sub. And I left Montreal with the impression that we had AGREED to leave it out. We decided (I think) that the SNMP header info would be usefull in only in VERY VERY specific (and in a ver small percentage of the) situations. And in those situations, the sub would probably want more than just the SNMP version number. Besides, the current doc now puts the burdon of skipping Counter64 onto the sub, while the referenced document number 9 (which is now available as draft-rfced-info-wijnen-00.txt in the ID-draft repository) specifies how an (master) agent can/should convert the SNMPv2 data into SNMPv1 data and how/when it should skip Counter64. More to follow. Bert   Delivery-Date: Wed, 11 Sep 1996 18:21:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id SAA10965 for X-agentx; Wed, 11 Sep 1996 18:21:23 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id SAA10961 for ; Wed, 11 Sep 1996 18:21:22 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id SAA29046; Wed, 11 Sep 1996 18:21:26 -0700 From: R Venkatsubramaniam Message-Id: <199609120121.SAA29046@pointer.cisco.com> Subject: Re: duplicate/unionized registrations To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Wed, 11 Sep 1996 18:21:25 -0700 (PDT) Cc: agentx@fv.com In-Reply-To: <199609112116.OAA18525@fv.com> from "Bert Wijnen" at Sep 11, 96 11:16:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bert, That was a comment from my personal side, and nothing to do with the organisation that I work with. Sorry that I missed to add the standard disclaimer :-). Again, I repeat, that was my personal design experience, and has nothing to do with the organisation that I work with. Thanks, Venkat. (rvenkat@cisco.com) Oops ... should be careful while adding this line, hereafterwards :-). > > Ref: Your note of Wed, 11 Sep 96 16:07:50 -0400 > > Subject: duplicate/unionized registrations > > David writes: > >True, EMANATE easily handles multiple sub-agents registering the same object > >identifier. This is particularly useful when tables are split across > >subagents. I resisted doing this because it *is* a bit of a pain to > >implement. But we did it because customers demanded it; big customers > >like Cisco, Siemens, and HP. > > > Those are interesting names. And I can also imagine that a fraction of > the possible uses within these companies do need/want the unionized > registrations. So do some very special projects in my company. > But that does not make it a generic enough requirement that we should > pay the price for the added complexity to our protocol. > > As a proof, one Cisco employee posted to this mailing list a little while > ago: > > > From: R Venkatsubramaniam > > Subject: Re: AgentX protocol draft, ver 00.03 > > To: agentx@fv.com > > Date: Wed, 4 Sep 1996 00:15:07 -0700 (PDT) > > > > Hi, > > > > > 7.1.2.1. Handling Duplicate OID Ranges > > > > > .... > > > > > > > My humble suggestion here is to NOT to allow more than one sub-agent regi > > the same object id. Assuming that the master agent is 'responsible' for > > the sysuptime, 'sysuptime' can be used as the final tie-breaker by the ma > > agent. Whichever sub-agent registers first (sysuptime is used for this t > > comparison), should be dispatched the request related to the object id. i > > question (assuming the sysuptimes are not equal !). > > > > I AM missing something !! > > > > Thanks, > > - Venkat. > > > > Bert > > ---------------- > This e-mail message was sent to all subscribers to the > agentx mailing list. > > To unsubscribe from this mailing list, please send mail to: > agentx-request@fv.com > with > Subject: unsubscribe your.address@your.domain > > (NOTE: Please do not reply to this message to unsubscribe. You must send > your request to agentx-request@fv.com Thank you.) >   Delivery-Date: Wed, 11 Sep 1996 23:41:07 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id XAA07635 for X-agentx; Wed, 11 Sep 1996 23:41:07 -0700 (PDT) Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by fv.com (8.7.4/8.7.3) with ESMTP id XAA07632 for ; Wed, 11 Sep 1996 23:41:03 -0700 (PDT) Received: from D018V042.mch.sni.de (D018V042.mch.sni.de [139.22.104.42]) by thoth.mch.sni.de (8.7.5/8.7.3) with SMTP id IAA15030 for ; Thu, 12 Sep 1996 08:41:04 +0200 (MDT) Received: by D018V042.mch.sni.de id AA12646 (5.67b/IDA-1.5 for agentx@fv.com); Thu, 12 Sep 1996 08:39:03 +0200 From: "Mr. T. Bohrer" Message-Id: <199609120639.AA12646@D018V042.mch.sni.de> Subject: Re: duplicate/unionized registration To: agentx@fv.com Date: Thu, 12 Sep 1996 08:39:03 +0200 (DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text   Delivery-Date: Wed, 11 Sep 1996 23:43:59 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id XAA07831 for X-agentx; Wed, 11 Sep 1996 23:43:58 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id XAA07828 for ; Wed, 11 Sep 1996 23:43:58 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id XAA05222 for agentx@fv.com; Wed, 11 Sep 1996 23:44:04 -0700 From: R Venkatsubramaniam Message-Id: <199609120644.XAA05222@pointer.cisco.com> Subject: 02:No. of varbinds in the VarBindList To: agentx@fv.com Date: Wed, 11 Sep 1996 23:44:03 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike, Should there be a 'No. of Var Binds' field in AgentX Test PDU to tell me the no. of Var Binds in the VarBIndList ? Thanks, - Venkat. (rvenkat@cisco.com)   Delivery-Date: Thu, 12 Sep 1996 01:05:25 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id BAA13791 for X-agentx; Thu, 12 Sep 1996 01:05:25 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id BAA13788 for ; Thu, 12 Sep 1996 01:05:24 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id BAA18950; Thu, 12 Sep 1996 01:05:28 -0700 From: R Venkatsubramaniam Message-Id: <199609120805.BAA18950@pointer.cisco.com> Subject: Re: NITS to draft 00.03 To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Thu, 12 Sep 1996 01:05:27 -0700 (PDT) Cc: agentx@fv.com In-Reply-To: <199609112136.OAA20293@fv.com> from "Bert Wijnen" at Sep 11, 96 11:36:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike, One more ... In Page 32, Section 7.1.6, Detecting Connection Loss, should the section be 7.1.5 rather than 7.1.4 ? Thanks, Venkat. (rvenkat@cisco.com) > > Here is a list of "nits" that you might want to correct in a next > version of the document. . . (stuff deleted) . > > Bert   Delivery-Date: Thu, 12 Sep 1996 07:58:51 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA16339 for X-agentx; Thu, 12 Sep 1996 07:58:51 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by fv.com (8.7.4/8.7.3) with SMTP id HAA16336 for ; Thu, 12 Sep 1996 07:58:49 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA14292; Thu, 12 Sep 96 07:57:22 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA11456; Thu, 12 Sep 96 07:57:21 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA02244; Thu, 12 Sep 96 07:57:20 PDT Date: Thu, 12 Sep 96 07:57:20 PDT From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9609121457.AA02244@santa.strata.com> To: wijnen@vnet.ibm.com Subject: Re: NITS to draft 00.03 Cc: agentx@fv.com, greene@nexen.com, daniele@zk3.dec.com Bert, Thanks for pointing out inconsistencies or outright errors in the text of the draft. It seems to take several people looking at a document to find the problems; there are certain things I read over and over again and just don't see. And some, unfortunately (such as "contain indicate" on page 45), are the result of my having violated the Editorial Oath to first do no harm. Maria and others have also pointed out several problems, and I plan to fold in all the purely "editorial" fixes (such as eliminating doubled verbs!) with the next version of the draft. This will probably come in a couple weeks after most of the substantive/contentious issues have been resolved by consensus of the group. I want everyone to know that though I haven't responded in detail to the various posted suggestions for improving the "quality of prose" in the protocol draft, I'm following the discussion and will eventually consider each one and incorporate the necessary changes. I appreciate the care and attention with which so many have reviewed this document-in-progress. Dale   Delivery-Date: Thu, 12 Sep 1996 11:37:53 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA11939 for X-agentx; Thu, 12 Sep 1996 11:37:52 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA11936 for ; Thu, 12 Sep 1996 11:37:51 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA09322 for ; Thu, 12 Sep 1996 14:38:23 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA605369 for ; Thu, 12 Sep 1996 14:37:49 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA27542; Thu, 12 Sep 1996 14:37:49 -0400 From: Uri Blumenthal Message-Id: <9609121837.AA27542@hawpub.watson.ibm.com> Subject: Re: various items - based on version 00.03 draft To: agentx@fv.com Date: Thu, 12 Sep 1996 14:37:48 -0400 (EDT) In-Reply-To: <199609112147.OAA21298@fv.com> from "Bert Wijnen" at Sep 11, 96 11:47:12 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Bert Wijnen says: > 1.May I suggest that we do NOT specify any fields but that > we make those fields. Let us also specify that those > fields MUST be zero. Strongly support. > 2.May I suggest that the padding bytes (wherever they are used) > MUST be zero. That way they are easier to recognize when debugging. > Let us also explicitly state that such padding bytes are ignored. Strongly support. > 3.I see various places in the elements of procedure that the master > agent "ignores" a PDU from a sub in certain error conditions..... > I think it is better to always try to send a response with an error > code, so that the sub QUICKLY knows what is wrong. Yes! You'll thank Bert when you're debugging your own sub'! > 4.I am 100% against passing SNMP version info to the sub. And so am I. Why did this surface again? Haven't we solved it in Montreal (deciding it will NOT be there)? I can understand [and appreciate] the need for Context id to be passed to a sub'. Questionable, but useful (possibly). SNMP version? Excuse me! -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 12 Sep 1996 11:44:35 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA13028 for X-agentx; Thu, 12 Sep 1996 11:44:34 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA13025 for ; Thu, 12 Sep 1996 11:44:33 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA20779; Thu, 12 Sep 1996 14:45:04 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA492572; Thu, 12 Sep 1996 14:44:36 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA22852; Thu, 12 Sep 1996 14:44:35 -0400 From: Uri Blumenthal Message-Id: <9609121844.AA22852@hawpub.watson.ibm.com> Subject: Re: 02:No. of varbinds in the VarBindList To: rvenkat@cisco.com (R Venkatsubramaniam) Date: Thu, 12 Sep 1996 14:44:35 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <199609120644.XAA05222@pointer.cisco.com> from "R Venkatsubramaniam" at Sep 11, 96 11:44:03 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text R Venkatsubramaniam says: > Should there be a 'No. of Var Binds' field in AgentX Test PDU to tell me > the no. of Var Binds in the VarBIndList ? I'd say - yes of course! -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 12 Sep 1996 12:03:51 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA14933 for X-agentx; Thu, 12 Sep 1996 12:03:50 -0700 (PDT) Received: from informixs-bh.na.informix.com (informixs-bh.na.informix.com [204.167.252.66]) by fv.com (8.7.4/8.7.3) with SMTP id MAA14930 for ; Thu, 12 Sep 1996 12:03:49 -0700 (PDT) Received: (from uucp@localhost) by informixs-bh.na.informix.com (8.6.12/8.6.11) id OAA28132 for ; Thu, 12 Sep 1996 14:05:52 -0500 Received: from atlas.na.informix.com by informixs-bh.na.informix.com via smap (V1.3) id sma028110; Thu Sep 12 14:05:33 1996 Received: from lynx.informix.com by atlas.na.informix.com with ESMTP (1.40.112.6/16.2) id AA152205010; Thu, 12 Sep 1996 14:03:31 -0500 Received: from cheetah (cheetah.informix.com) by lynx.informix.com with SMTP (1.39.111.2/16.2) id AA091775011; Thu, 12 Sep 1996 12:03:31 -0700 From: Willy Wong - CONTRACTOR 03/95 - tonyr Received: by cheetah id ; Thu, 12 Sep 96 12:03:30 PDT Date: Thu, 12 Sep 96 12:03:30 PDT Message-Id: <9609121903.AA27356@cheetah> To: agentx@fv.com Subject: unsubscribe Unsubscribe. Thanks WIlly@informix.com   Delivery-Date: Thu, 12 Sep 1996 12:53:39 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA19476 for X-agentx; Thu, 12 Sep 1996 12:53:35 -0700 (PDT) Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by fv.com (8.7.4/8.7.3) with SMTP id MAA19473 for ; Thu, 12 Sep 1996 12:53:34 -0700 (PDT) Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA0A9.7D305FA0@tide21.microsoft.com>; Thu, 12 Sep 1996 12:54:09 -0700 Message-ID: From: Don Ryan To: "'uri@watson.ibm.com'" Cc: "'agentx@fv.com'" Subject: RE: various items - based on version 00.03 draft Date: Thu, 12 Sep 1996 12:51:46 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 23 TEXT Without passing the SNMP version, how is a subagent going to correctly format the instance identifier for a columnar object if one of the conceptual table indices is marked with the IMPLIED keyword? For version 1, all variable-length instance identifiers must be prefixed by their length. This is not always the case in SNMPv2 since the last index can be marked with the IMPLIED keyword. Don Ryan >---------- >From: Uri Blumenthal[SMTP:uri@watson.ibm.com] >Sent: Thursday, September 12, 1996 11:37 AM >To: agentx@fv.com >Subject: Re: various items - based on version 00.03 draft > >I can understand [and appreciate] the need for Context id to be passed >to a sub'. Questionable, but useful (possibly). SNMP version? Excuse me! >-- >Regards, >Uri uri@watson.ibm.com >   Delivery-Date: Thu, 12 Sep 1996 13:43:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA23878 for X-agentx; Thu, 12 Sep 1996 13:43:04 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id NAA23875 for ; Thu, 12 Sep 1996 13:43:03 -0700 (PDT) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA00387; Thu, 12 Sep 1996 16:36:54 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA16761; Thu, 12 Sep 1996 16:36:54 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07279; Thu, 12 Sep 1996 16:40:15 -0400 Message-Id: <9609122040.AA07279@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: 02:No. of varbinds in the VarBindList Date: Thu, 12 Sep 96 16:40:14 -0400 From: Mike Daniele X-Mts: smtp Uri said >R Venkatsubramaniam says: >> Should there be a 'No. of Var Binds' field in AgentX Test PDU to tell me >> the no. of Var Binds in the VarBIndList ? >I'd say - yes of course! Up till this minute I would have said no. As for all the other PDUs with a variable number of VarBinds (Test and Response) or SearchRanges (Get*), you just keep parsing till you run out of PDU, based on h.length. Just like DPI :-) However, this i-d is broken. There's no way to know when you've run out of VarBinds or SearchRanges, and are into the context field. So we need to include either number of "variables" (VarBinds or SearchRanges), or the context length. I suggest context length. Mike   Delivery-Date: Thu, 12 Sep 1996 14:14:14 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA26570 for X-agentx; Thu, 12 Sep 1996 14:14:13 -0700 (PDT) Received: from crow.bmc.com (crow.bmc.com [198.147.191.100]) by fv.com (8.7.4/8.7.3) with SMTP id OAA26567 for ; Thu, 12 Sep 1996 14:14:12 -0700 (PDT) Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA11709; Thu, 12 Sep 1996 16:12:35 -0500 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA231922852; Thu, 12 Sep 1996 14:14:12 -0700 Date: Thu, 12 Sep 1996 14:14:12 -0700 From: Randy Presuhn Message-Id: <199609122114.AA231922852@dorothy.peer.com> To: agentx@fv.com Subject: RE: various items - based on version 00.03 draft Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: > From: Don Ryan > Subject: RE: various items - based on version 00.03 draft > Date: Thu, 12 Sep 1996 12:51:46 -0700 ... > Without passing the SNMP version, how is a subagent going to correctly > format the instance identifier for a columnar object if one of the > conceptual table indices is marked with the IMPLIED keyword? For > version 1, all variable-length instance identifiers must be prefixed by > their length. This is not always the case in SNMPv2 since the last > index can be marked with the IMPLIED keyword. ... We should keep SMI issues separate from protocol issues whenever possible. The structure of INDEXes embedded in OBJECT IDENTIFIERS is specified in the SMI, not the protocol. Unlike the Counter64 debates, there is no question of support for the underlying data type, OBJECT IDENTIFIER. Generating different OBJECT IDENTIFIER encodings for a given instance does not aid interoperability. SNMPv1 agents encoding variable-length string indexes as though they had been marked with the IMPLIED keyword were out there long before SNMPv2 was even mentioned. One of the rationales for adding the IMPLIED keyword to the SMI was to describe the unusual behaviour of those agents. For an agent (or subagent) to employ different OBJECT IDENTIFIER encodings based on the protocol used by the manager: - breaks SNMPv2 to SNMPv1 proxy (the system in the middle has no way of knowing it would need to twiddle the oid) - produces different get-next orderings for the same data (just imagine the proxy behaviour needed to fix this!) - increases the complexity of recording log records - increases the complexity of formulating view masks in conjunction with access control - increases subagent complexity (not just run-time library code, but also any user code connected with the location and ordering of instances) I see no benefits to differing encodings, and plenty of disadvantages. One can argue whether those existing SNMPv1 systems that encode things as though they were IMPLIED are broken because they don't observe RFC 1212 clause 4.1.6 (3), or that they were simply ahead of their time. Managers have dealt successfully with these systems for some time; we're not doing them any favors by changing the encodings. ----------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: rpresuhn@bmc.com USA -----------------------------------------------------------------------   Delivery-Date: Thu, 12 Sep 1996 14:23:58 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA27435 for X-agentx; Thu, 12 Sep 1996 14:23:58 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by fv.com (8.7.4/8.7.3) with ESMTP id OAA27431 for ; Thu, 12 Sep 1996 14:23:55 -0700 (PDT) Received: from hunch.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA02386; Thu, 12 Sep 1996 17:17:10 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA18887; Thu, 12 Sep 1996 17:17:08 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07347; Thu, 12 Sep 1996 17:20:29 -0400 Message-Id: <9609122120.AA07347@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: various items - based on version 00.03 draft Date: Thu, 12 Sep 96 17:20:28 -0400 From: Mike Daniele X-Mts: smtp Bert, Uri, (lurkers), >2.May I suggest that the padding bytes (wherever they are used) > MUST be zero. That way they are easier to recognize when debugging. > Let us also explicitly state that such padding bytes are ignored. Good points. >4.I am 100% against passing SNMP version info to the sub. > And I left Montreal with the impression that we had AGREED to leave > it out. We decided (I think) that the SNMP header info would be > usefull in only in VERY VERY specific (and in a ver small percentage > of the) situations. And in those situations, the sub would probably > want more than just the SNMP version number. I recall Jeff saying that a particular customer situation required they send much more than just the version. but I don't think that particular discussion is the important one. 1) I believe he also stated that a subagent needs the version info to understand the contents of the context field. (I may be wrong, but I thought that's what he said.) > Besides, the current doc now puts the burdon of skipping Counter64 > onto the sub, while the referenced document number 9 (which is now > available as draft-rfced-info-wijnen-00.txt in the ID-draft repository) > specifies how an (master) agent can/should convert the SNMPv2 data > into SNMPv1 data and how/when it should skip Counter64. That draft says o On an SNMPv1 GETNEXT request, we skip the object instance and fetch the next object instance that follows the one with a syntax of Counter64. The "we" in this statement is the extended agent, the master and subagents acting jointly (transparently to the manager). The AgentX entity that is defined to know about object syntax is the subagent, not the master. 2) It will require an indeterminate amount of agentx-GetNext-PDUs for the master agent to find the next object instance of suitable syntax. I find this unacceptable, and I believe Randy P. agreed with me on this point at Montreal. It is one line of code in the subagent to make this check when searching for a suitable object type whose method to call. It is (or should be) INVISIBLE to subagent developers, since this check would be in the "library", not the method routine. I listed these concerns in issue 6 of the appendix: I know may of you feel this reeks. But there were at least three implementors in Montreal who said it needs to be there. I'm hoping folks will think about it a bit more, possibly in conjunction with the background design discussion, and also in light of recent postings to the SNMPv2 list... The recent postings I alluded to have recently been posted to this list (on the use of the IMPLIED keyword). I kept it in the draft because I was hoping to see more discussion, and feel strongly it's important to have it. If you all want it out, so be it (Bob N?) But I sure would like to see some technical reason for WHY you would like it removed, and what the design/deployment advantages of removing it are, instead of just shouting that it's horrible. Regards, Mike   Delivery-Date: Thu, 12 Sep 1996 14:27:28 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA27835 for X-agentx; Thu, 12 Sep 1996 14:27:27 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id OAA27832 for ; Thu, 12 Sep 1996 14:27:26 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id RAA100713; Thu, 12 Sep 1996 17:25:28 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id PAA492661; Thu, 12 Sep 1996 15:55:50 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA22332; Thu, 12 Sep 1996 15:55:49 -0400 From: Uri Blumenthal Message-Id: <9609121955.AA22332@hawpub.watson.ibm.com> Subject: Re: various items - based on version 00.03 draft To: donryan@MICROSOFT.com (Don Ryan) Date: Thu, 12 Sep 1996 15:55:48 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: from "Don Ryan" at Sep 12, 96 12:51:46 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Don Ryan says: > Without passing the SNMP version, how is a subagent going to correctly > format the instance identifier for a columnar object if one of the > conceptual table indices is marked with the IMPLIED keyword? Easily - because the sub' is to be compliant with V2 specs. And if any conversion is needed - it's master agent's job. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 12 Sep 1996 15:00:44 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA00703 for X-agentx; Thu, 12 Sep 1996 15:00:44 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by fv.com (8.7.4/8.7.3) with SMTP id PAA00700 for ; Thu, 12 Sep 1996 15:00:43 -0700 (PDT) Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA0BB.1D26EF40@mail2.microsoft.com>; Thu, 12 Sep 1996 15:00:19 -0700 Message-ID: From: Don Ryan To: "'uri@watson.ibm.com'" Cc: "'agentx@fv.com'" Subject: RE: various items - based on version 00.03 draft Date: Thu, 12 Sep 1996 15:00:25 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 31 TEXT So how is the master agent going to find out that about the format of some random columnar object's instance identifier in order to provide this mapping? The subagent will have to register every component of every instance identifier that has IMPLIED enabled. Then the master agent will have to figure out it has been returned one of those columnar objects, parse the instance identifiers into it's components, and then reconstruct the instance identifier with the last component modified. This will of course screw up the lexographical ordering but just keeping track of all of these objects will be problematic enough. I do not see how this can be solved "easily" at all. Please explain. >---------- >From: Uri Blumenthal[SMTP:uri@watson.ibm.com] >Sent: Thursday, September 12, 1996 12:55 PM >To: Don Ryan >Cc: agentx@fv.com >Subject: Re: various items - based on version 00.03 draft > >Don Ryan says: >> Without passing the SNMP version, how is a subagent going to correctly >> format the instance identifier for a columnar object if one of the >> conceptual table indices is marked with the IMPLIED keyword? > >Easily - because the sub' is to be compliant with V2 specs. >And if any conversion is needed - it's master agent's job. >-- >Regards, >Uri uri@watson.ibm.com >-=-=-=-=-=-=- > >   Delivery-Date: Thu, 12 Sep 1996 17:41:19 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id RAA14628 for X-agentx; Thu, 12 Sep 1996 17:41:19 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id RAA14625 for ; Thu, 12 Sep 1996 17:41:17 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id UAA83309; Thu, 12 Sep 1996 20:41:38 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA605438; Thu, 12 Sep 1996 14:17:14 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA23397; Thu, 12 Sep 1996 14:17:13 -0400 From: Uri Blumenthal Message-Id: <9609121817.AA23397@hawpub.watson.ibm.com> Subject: Re: duplicate/unionized registrations To: greene@nexen.com (Maria Greene) Date: Thu, 12 Sep 1996 14:17:13 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <199609112022.QAA05559@avalon.nexen.com> from "Maria Greene" at Sep 11, 96 04:22:22 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Maria Greene says: > David said (regarding duplicate OID registeration): > > True, EMANATE easily handles multiple sub-agents registering the > > same object identifier.........I resisted doing this because it > > *is* a bit of a pain to implement. "easily"..........."*is* a bit of a pain".... Exactly what I thought. (:-) [Can I get hired by the media now? :-] > When talking about registering the same OIDs, I think we need to > distinguish registering the same 'leaf' object from registering the > same 'branch' object. The problem is, without MIB knowledge, the > master agent can't tell the difference. Then the registration should help master agent to determine this. > I think the master agent should accept duplicate registrations for > exactly the reason David cites -- to allow tables to be split across > subagents. However, if two subagents register fooObject.1 that's a > misconfiguration, in my opinion. In my opinion, if two subagents register X (where X is whatever) that's a misconfiguration. Because, if they're not smart enough to request a "clean" separation at registration time, what makes you think they both aren't going to return X.1 on GetNext? And how are you going to react them? Which "next" is "better"? Same thing with Set, only worse... Instead of going through this pain, it's simpler and technically correct [maybe even politically correct? :-] to register only clean sub's. You want a whole subtree? Fine, then you'll either kick somebody out, or will be denied, if this subtree is already taken by somebody else (otherwise it's yours, naturally). [A minor concern might be somebody having a sub' for the whole MIB-II and another one for Interfaces, for example. Comments?] You want a leaf? Fine, same restrictions. Plus, tell the master that it's a leaf. You want only certain leaves of the branch? Fine, now we're in a deeper swamp (:-). What do you think? The easiest would be to forbid mixing leaf vs. non-leaf registration, i.e. if I parceled one group of leaves (instance 1), then one has to register for any other leaf explicitely - i.e. if no takers showed up for instance 2, then it's non-existent. Another approach would be to *exclude* the registered leaves from the "ownership" of the sub' that used to handle the whole subtree, but it's becoming a pain... Again, what do you think? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 12 Sep 1996 18:09:53 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id SAA16917 for X-agentx; Thu, 12 Sep 1996 18:09:53 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id SAA16914 for ; Thu, 12 Sep 1996 18:09:52 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id SAA20127; Thu, 12 Sep 1996 18:07:21 -0700 From: R Venkatsubramaniam Message-Id: <199609130107.SAA20127@pointer.cisco.com> Subject: Re: 02:No. of varbinds in the VarBindList To: daniele@zk3.dec.com (Mike Daniele) Date: Thu, 12 Sep 1996 18:07:20 -0700 (PDT) Cc: agentx@fv.com In-Reply-To: <9609122040.AA07279@bernie.zk3.dec.com> from "Mike Daniele" at Sep 12, 96 04:40:14 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike wrote : > > Uri said > > >R Venkatsubramaniam says: > >> Should there be a 'No. of Var Binds' field in AgentX Test PDU to tell me > >> the no. of Var Binds in the VarBIndList ? > > >I'd say - yes of course! > > Up till this minute I would have said no. > As for all the other PDUs with a variable number of VarBinds (Test and Response) > or SearchRanges (Get*), you just keep parsing till you run out of PDU, based on > h.length. Just like DPI :-) > > However, this i-d is broken. > > There's no way to know when you've run out of VarBinds or SearchRanges, > and are into the context field. > > So we need to include either number of "variables" (VarBinds or > SearchRanges), or the context length. The idea of including no. of varbinds is straight-forward for implementation. 1. Read the 'No. of VarBinds' field. 2. Skip the packet till the header. 3. Start reading the VarBindList. 4. When the local counter reaches the No. of VarBinds, you conclude that context has begun. if context length is specified, 1. Read the Context Length field. 2. Context Start Location = Packet Length - Context Length. 3. Skip the packet till the header. 4. Start reading the VarBindList. 5. When the location you are reading is same as the Context Start Location, you conclude that context has begun. As you see, there is an additional calculation in the second method. > > I suggest context length. > Why ? > Mike > Thanks, Venkat. (rvenkat@cisco.com)   Delivery-Date: Thu, 12 Sep 1996 20:29:31 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id UAA28445 for X-agentx; Thu, 12 Sep 1996 20:29:30 -0700 (PDT) Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by fv.com (8.7.4/8.7.3) with SMTP id UAA28442 for ; Thu, 12 Sep 1996 20:29:30 -0700 (PDT) Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA0E9.7932D820@tide21.microsoft.com>; Thu, 12 Sep 1996 20:32:10 -0700 Message-ID: From: Don Ryan To: "'agentx@fv.com'" Subject: RESEND: various items - based on version 00.03 draft Date: Thu, 12 Sep 1996 20:29:46 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 89 TEXT >Randy Presuhn says: >> Generating different OBJECT IDENTIFIER encodings for a given instance >> does not aid interoperability. > >Designing a keyword which specifies OBJECT IDENTIFIER encodings that can only >be interpreted by downlevel managers if they have a priori knowledge of the >format of the instance identifier does not aid interoperability either. Some >SMIv2->v1 MIB translators actually just drop the keyword which means that >downlevel managers are mislead as to the format of the instance identifier. >I find the thought of downlevel managers struggling with these malformed >(from their perspective) OIDs much more bothersome than having to reveal to >the subagents what SNMP version was included in the PDU. > >> SNMPv1 agents encoding variable-length >> string indexes as though they had been marked with the IMPLIED keyword >> were out there long before SNMPv2 was even mentioned. One of the >> rationales for adding the IMPLIED keyword to the SMI was to describe >> the unusual behaviour of those agents. > >Is your point that some "unusual" SNMPv1 agents are already sending bogus >OIDs to SNMPv1 managers so AgentX subagents should reserve the right to do >the same? > >> For an agent (or subagent) to employ different OBJECT IDENTIFIER encodings >> based on the protocol used by the manager: >> >> - breaks SNMPv2 to SNMPv1 proxy (the system in the middle >> has no way of knowing it would need to twiddle the oid) > >The entity instantiating the columnar object is the SNMPv1 agent, correct? >Having an SNMPv2 manager query a SNMPv1 agent (via a proxy) for the columnar >object using SMIv2 syntax is problematic anyway. Either the SNMPv2 manager >has a priori knowledge that this will work or the MIB given to the SNMPv2 >manager includes the IMPLIED keyword. In the either case, the SNMPv1 agent >will not interoperate with SNMPv1 managers unless they also have a priori >knowledge of the instance identifier format. > >> - produces different get-next orderings for the same data >> (just imagine the proxy behaviour needed to fix this!) > >Obviously the ordering would be different based on the encoding which is the >main reason I decided not to use the IMPLIED keyword in any private MIBs. >The choice was to sort the data differently based on the protocol version, >not return any objects from the table to downlevel managers, or return an >v2-formatted OID and distribute the format of the instance identifier in the >DESCRIPTION string. I did not find any of those options satisfactory but >others may. Without the SNMP version then the last option is the only one >available since the first two are runtime decisions that can be made only by >the subagent. > >> - increases the complexity of recording log records >> - increases the complexity of formulating view masks in >> conjunction with access control >> - increases subagent complexity (not just run-time library code, >> but also any user code connected with the location and ordering >> of instances) > >This are valid arguments for not modifying the OID based on the SNMP version >but what about the case where the subagent simply returns noSuchObject when >being queried by a downlevel manager? As I mentioned above, this is a >runtime decision that can only be made by the subagent. > >> I see no benefits to differing encodings, and plenty of disadvantages. > >I would address this statement to the folks who decided to add the IMPLIED >keyword. Yes, a conceptual table can now be sorted alphabetically but the >instance identifier of the table can only be parsed correctly by a downlevel >manager if the agent modifies the OID encoding or the manager as a priori >knowledge about the format. > >> One can argue whether those existing SNMPv1 systems that encode things >> as though they were IMPLIED are broken because they don't observe RFC >> 1212 clause 4.1.6 (3), or that they were simply ahead of their time. > >My opinion is that these systems were broken originally and that the IMPLIED >keyword has made the situation worse by legitimizing their incorrect >implementations and causing headaches for SNMPv1 managers. > >> Managers have dealt successfully with these systems for some time; we're >> not doing them any favors by changing the encodings. > >If I design and implement a private MIB which includes a conceptual table >whose INDEX clause includes an OCTET STRING modified by the IMPLIED keyword >and I expose this MIB to the world via an SNMPv2 AgentX master, explain to me >how any of these SNMPv1 managers will "successfully deal" with the parsing of >the instance identifier. > > >   Delivery-Date: Thu, 12 Sep 1996 22:06:34 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id WAA06108 for X-agentx; Thu, 12 Sep 1996 22:06:34 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id WAA06105 for ; Thu, 12 Sep 1996 22:06:33 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id BAA03899; Fri, 13 Sep 1996 01:06:37 -0400 Date: Fri, 13 Sep 1996 01:05:58 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03318; Fri, 13 Sep 1996 01:05:58 -0400 Message-Id: <9609130505.AA03318@nips.acec.com> To: uri@watson.ibm.com Subject: Re: various items - based on version 00.03 draft Cc: agentx@fv.com > From: Uri Blumenthal > Date: Thu, 12 Sep 1996 15:55:48 -0400 (EDT) Hi Uri, > Don Ryan says: > > Without passing the SNMP version, how is a subagent going to correctly > > format the instance identifier for a columnar object if one of the > > conceptual table indices is marked with the IMPLIED keyword? > > Easily - because the sub' is to be compliant with V2 specs. > And if any conversion is needed - it's master agent's job. Yes, this is exactly right. In a nutshell, that's what the "top ten" list I just posted said. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 12 Sep 1996 22:08:37 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id WAA06264 for X-agentx; Thu, 12 Sep 1996 22:08:37 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id WAA06261 for ; Thu, 12 Sep 1996 22:08:36 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id BAA03745; Fri, 13 Sep 1996 01:01:57 -0400 Date: Fri, 13 Sep 1996 01:01:18 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03272; Fri, 13 Sep 1996 01:01:18 -0400 Message-Id: <9609130501.AA03272@nips.acec.com> To: daniele@zk3.dec.com Subject: SNMP version info Cc: agentx@fv.com > Subject: Re: various items - based on version 00.03 draft > Date: Thu, 12 Sep 96 17:20:28 -0400 > From: Mike Daniele Hi Mike, > > Bert Wijnen > > 4.I am 100% against passing SNMP version info to the sub. <...> > If you all want it out, so be it (Bob N?) <...> > But I sure would like to see some technical reason for WHY you > would like it removed, and what the design/deployment advantages > of removing it are, instead of just shouting that it's horrible. Speaking as wg chair: The SNMP version info is superfluous, because: 1. AgentX assumes SNMPv2c as the base SNMP level. 2. AgentX sub-agents MUST be SNMPv2c-aware, at a minimum. 3. The "at a minimum" means that they might also be SNMPv2u and/or SNMPv2* and/or whatever else emerges...but they MUST be SNMPv2c-aware. 4. AgentX sub-agents are not SNMPv1 agents, except insofar as SNMPv1 is a subset of SNMPv2c. 5. The AgentX protocol between master and sub, while not SNMP, is based upon the assumption of SNMPv2c-awareness in the sub-agent. 6. Every AgentX sub-agent's MIB MUST be SNMPv2c compliant (and it MAY also be SNMPv1 compliant). 7. Only the AgentX master agent is aware of the SNMP version level of the remote management applications. 8. Any mapping of AgentX protocol operations down to SNMPv1 for communications with remote management applications MUST be done by the master agent, iaw the "coexistence" RFC and the recent draft on the same topic (if it becomes a standards-track RFC...otherwise it will just be an informational asset for implementation guidance). 9. #1, above, was a fundamental consensus point of the wg from the outset...and the other points all derive from it. 10. This does mean that--contrary to my personal preference-- sometimes the master agent may have to "twiggle" responses from one or more sub-agents to satisfy a request from an SNMPv1 management application. Don't feel bad if you don't know what "twiggle" means...I think I just made it up, but you probably get the drift. I hope (and expect) that such twiggling will be minimal. Oh, and just in case you haven't noticed: No AgentX agents exist yet. If somene wants to use an existing agent as an AgentX sub-agent, he will have to do so via an AgentX "proxy sub-agent" or--if that term is too loaded for you--an AgentX adapter agent. Better choice is to revise/re-write it as an AgentX native sub-agent. That's the view from here (and, remember, I wear bi-focals). Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 12 Sep 1996 23:14:40 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id XAA11813 for X-agentx; Thu, 12 Sep 1996 23:14:39 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id XAA11810 for ; Thu, 12 Sep 1996 23:14:39 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id XAA26358 for agentx@fv.com; Thu, 12 Sep 1996 23:14:44 -0700 From: R Venkatsubramaniam Message-Id: <199609130614.XAA26358@pointer.cisco.com> Subject: 06b:No. of sub-agents that can connect to a master To: agentx@fv.com Date: Thu, 12 Sep 1996 23:14:44 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Section 7.1.1 of Version 00.04 AgentX specs. does not mention about what happens when the no. of sub-agents connecting to the master agent exceeds the limit that the master agent can handle. I think master cannot send a response with error value, since the connection is not yet established with the sub-agent trying to open a connection (or trying to bind). My suggestion is to issue a SNMP trap 'Too many sub-agents', so that the network administrator will get alerted. Thanks, Venkat. (rvenkat@cisco.com)   Delivery-Date: Fri, 13 Sep 1996 06:03:34 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id GAA13029 for X-agentx; Fri, 13 Sep 1996 06:03:34 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id GAA13026 for ; Fri, 13 Sep 1996 06:03:33 -0700 (PDT) Received: from flume.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id IAA13271; Fri, 13 Sep 1996 08:56:03 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA15889; Fri, 13 Sep 1996 08:56:19 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07559; Fri, 13 Sep 1996 08:59:21 -0400 Message-Id: <9609131259.AA07559@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: 02:No. of varbinds in the VarBindList Date: Fri, 13 Sep 96 08:59:20 -0400 From: Mike Daniele X-Mts: smtp Venkat, >The idea of including no. of varbinds is straight-forward for >implementation. > 1. Read the 'No. of VarBinds' field. > 2. Skip the packet till the header. > 3. Start reading the VarBindList. > 4. When the local counter reaches the No. of VarBinds, > you conclude that context has begun. >if context length is specified, > 1. Read the Context Length field. > 2. Context Start Location = Packet Length - Context Length. > 3. Skip the packet till the header. > 4. Start reading the VarBindList. > 5. When the location you are reading is same as the > Context Start Location, you conclude that context has begun. >As you see, there is an additional calculation in the second method. >> >> I suggest context length. >> >Why ? Because adding a "number of variables" field affects every implementation. Adding a "size of context" field only affects those that support non-default contexts, which I guess would be a minority. Mike   Delivery-Date: Fri, 13 Sep 1996 07:57:42 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA23488 for X-agentx; Fri, 13 Sep 1996 07:57:42 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA23485 for ; Fri, 13 Sep 1996 07:57:40 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA10816; Fri, 13 Sep 1996 10:48:56 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA11137; Fri, 13 Sep 1996 10:48:54 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07614; Fri, 13 Sep 1996 10:52:15 -0400 Message-Id: <9609131452.AA07614@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: SNMP version info Date: Fri, 13 Sep 96 10:52:15 -0400 From: Mike Daniele X-Mts: smtp Hi Bob, Thanks for your input. I was signalling the need for you to determine consensus, not necessarily to summarize the reasoning behiond it. Given that you did ... I disagree with the reasoning you've outlined. >The SNMP version info is superfluous, because: >1. AgentX assumes SNMPv2c as the base SNMP level. >9. #1, above, was a fundamental consensus point of the wg > from the outset...and the other points all derive from it. I think this is the problem. The consensus was that we would use SNMPv2 SMI in the protocol. It was understood that AgentX subagents might have to "fix up" responses from v1 MIB instrumentation to do so. >2. AgentX sub-agents MUST be SNMPv2c-aware, at a minimum. Agreed, but I would point out that it's the "protocol library" part of the subagent, NOT the MIB instrumentation, that MUST be v2c aware. >3. The "at a minimum" means that they might also be SNMPv2u > and/or SNMPv2* and/or whatever else emerges...but they > MUST be SNMPv2c-aware. Same as above. >4. AgentX sub-agents are not SNMPv1 agents, except insofar > as SNMPv1 is a subset of SNMPv2c. I'm not sure how to interpret this part... >5. The AgentX protocol between master and sub, while not > SNMP, is based upon the assumption of SNMPv2c-awareness > in the sub-agent. Same reply as for 2. >6. Every AgentX sub-agent's MIB MUST be SNMPv2c compliant > (and it MAY also be SNMPv1 compliant). I completely disagree with this statement. I view it as a fundamental requirement that an AgentX subagent be able to implement a SNMPv1 MIB. Hell, most of the Internet-standard MIB specs are still v1. More below. >7. Only the AgentX master agent is aware of the SNMP version > level of the remote management applications. I don't see how this logically follows from #1. >8. Any mapping of AgentX protocol operations down to SNMPv1 > for communications with remote management applications > MUST be done by the master agent, iaw the "coexistence" > RFC and the recent draft on the same topic (if it becomes > a standards-track RFC...otherwise it will just be an > informational asset for implementation guidance). I'll double check, but I'm willing to bet a dollar that neither of these specs refers to the master agent specifically. :-) Even if AgentX was already an RFC, they wouldn't refer to the master agent, because the fact that a master agent even exists on a managed node is INVISIBLE to a manager entity. These specs refer to how the SNMP agent should function. I respectfully submit that it's up to us to further specify a reasonable mechanism to perform these functions in the extensible agent. Which parts belong in the master, and which belong in the sub... >Oh, and just in case you haven't noticed: No AgentX agents >exist yet. If somene wants to use an existing agent as an >AgentX sub-agent, he will have to do so via an AgentX "proxy >sub-agent" or--if that term is too loaded for you--an AgentX >adapter agent. Better choice is to revise/re-write it as an >AgentX native sub-agent. The rewriting will be in the subagent protocol library, NOT the MIB instrumentation!!! There are 3 conceptual interfaces involved here: manager ======= #1 agent { master agent ============ #2 subagent ============ #3 MIB instrumentation } #1 is the SNMP #2 is AgentX #3 is the private (or at least vendor-specific) interface to MIB instrumentation. (Method routines, etc) One function of this interface is to "hide" SNMP, and AgentX specifics from the instrumentation. We specified that we'll use SNMPv2 SMI across interface #2. I think at the time, we meant v2 error and exception values. This requires the master agent to map v2 error/exception values to v1 if it wished to support v1. But I didn't interpret that as meaning we have to accept that ALL such mapping be done at this point. With respect to counter64, your argument is (I think) o It is a cleaner design to put ALL v2->v1 mapping in the master agent o It makes the protocol simpler (one less field) o It makes the subagent (elements of procedure) simpler o v1 access of v2 counter64 objects is a rare thing to which I agree (except for the last point. i think a year or two from now it will be a very common thing) My argument is o Mapping v2 error/exception values to v1 is logical to do in the master agent. But handling syntax (and instances) is not. Causing the master to blindly resend GetNexts just seems to me like very bad design, largely because it's unbounded. (A v1 getnext walk of a managed node with 10 interfaces that bumps into ifXTable will have to send/receive 80 agentx-GetNext-PDUs before it can respond to the manager.) We are in essence placing contraints on MIB designers (don't create tables with lots of consecutive Counter64 objects). o Interface #3 already does some version mapping, since it may be "attached" to v1 instrumentation and must use v2 in AgentX. o Sending the version in the protocol is a very small increase in complexity. Adding this check in the elements of procedure for GetNext is a very small increase in complexity and implementation. To me it seems like a better choice to accept this unpleasantness than the runtime unpleasantness of not doing so. o This syntax compatibility check does NOT impact the instrumentation code, it's a part of AgentX that's hidden by interface #3 o I think we'll need SNMP version info for other reasons anyway... Well, sorry for the length but I want to make sure we're all working from the same set of assumptions. I won't (or at least will try not to :-) drag this out any longer. Regards, Mike   Delivery-Date: Fri, 13 Sep 1996 09:25:50 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id JAA04778 for X-agentx; Fri, 13 Sep 1996 09:25:49 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id JAA04775 for ; Fri, 13 Sep 1996 09:25:48 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id MAA17421; Fri, 13 Sep 1996 12:25:44 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10241; Fri, 13 Sep 1996 12:23:14 -0400 Date: Fri, 13 Sep 1996 12:23:42 EDT From: Bob Natale Subject: Re: SNMP version info To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Fri, 13 Sep 96 10:52:15 -0400 Hi Mike, > Thanks for your input. I was signalling the need for you > to determine consensus, not necessarily to summarize the > reasoning behiond it. Ok. From the available evidence on the list, there is no consensus on this point. In the absence of that, it is reasonable to look at any pre-existing points on which the wg did reach consensus and attempt to extrapolate from them. While it is possible (and not necessarily a bad thing) for a wg to change its mind on a previously settled point, it is not acceptable to arrive at mutually contradictory consensus points. So, to break the evident deadlock on this issue, I am doing my best to represent the "argument from first principles", given the pre-existing consensus points. > Given that you did ... I disagree with the reasoning > you've outlined. Fair enough--I could have it wrong--nonetheless, I'll take one more stab at justifying it with responses to your points below. > >The SNMP version info is superfluous, because: > > >1. AgentX assumes SNMPv2c as the base SNMP level. > > >9. #1, above, was a fundamental consensus point of the wg > > from the outset...and the other points all derive from it. > > I think this is the problem. The consensus was that we would use > SNMPv2 SMI in the protocol. The consensus was that SNMPv2c was the base level for AgentX... the consensus to use the SNMPv2 SMI was a natural derivative of that larger consensus...it was not a limitation on the meaning of the former. > It was understood that AgentX subagents might have to "fix up" > responses from v1 MIB instrumentation to do so. That is correct. In essence, the subagent's MIB would be an SNMPv2c MIB from the perspective of the master agent. > >2. AgentX sub-agents MUST be SNMPv2c-aware, at a minimum. > > Agreed, but I would point out that it's the "protocol library" > part of the subagent, NOT the MIB instrumentation, that MUST be > v2c aware. We are tasked with defining the protocol itself. The protocol must be workable on its own merits for interoperation between independently developed master and subagents. While I fully realize that most (all) subagents will be written with the assistance of AgentX development/runtime toolkits, I do not believe it is permissable to build such dependencies into the protocol. I could be wrong about this. > >3. The "at a minimum" means that they might also be SNMPv2u > > and/or SNMPv2* and/or whatever else emerges...but they > > MUST be SNMPv2c-aware. > > Same as above. Right. > >4. AgentX sub-agents are not SNMPv1 agents, except insofar > > as SNMPv1 is a subset of SNMPv2c. > > I'm not sure how to interpret this part... Ok...it was just an attempt to say the same thing the other way around...AgentX subagents are SNMPv2c agents from the perspective of master agent, insofar as SNMP is used to define parts of AgentX. > >5. The AgentX protocol between master and sub, while not > > SNMP, is based upon the assumption of SNMPv2c-awareness > > in the sub-agent. > > Same reply as for 2. Right. Again, I was just reinforcing the basic point... one on which we seem to disagree. > >6. Every AgentX sub-agent's MIB MUST be SNMPv2c compliant > > (and it MAY also be SNMPv1 compliant). > > I completely disagree with this statement. > > I view it as a fundamental requirement that an AgentX subagent > be able to implement a SNMPv1 MIB. Hell, most of the > Internet-standard MIB specs are still v1. Not all v1 MIBs are incompatible with the v2 SMI. The IETF NM Area has had a deliberate policy of nuturing migration to the v2 SMI for a *long* time now. AgentX should do its best to leverage this for consistency with the fundamental consensus on the use of SNMPv2c as the base SNMP protocol level, and to ween people off of v1. > More below. > > >7. Only the AgentX master agent is aware of the SNMP version > > level of the remote management applications. > > I don't see how this logically follows from #1. Since all AgentX subagents must present themselves as SNMPv2c-capable agents to the master agent and since all v2 <-> v1 mapping for v1 management applications is done by the master agent, it is then superfluous for the subagent to have this information. > >8. Any mapping of AgentX protocol operations down to SNMPv1 > > for communications with remote management applications > > MUST be done by the master agent, iaw the "coexistence" > > RFC and the recent draft on the same topic (if it becomes > > a standards-track RFC...otherwise it will just be an > > informational asset for implementation guidance). > > I'll double check, but I'm willing to bet a dollar that neither > of these specs refers to the master agent specifically. :-) Sure, you're right, I was not saying they did...I was saying that AgentX will meet its goals in this respect iaw the guidance provided in those documents. > Even if AgentX was already an RFC, they wouldn't refer to the > master agent, because the fact that a master agent even exists > on a managed node is INVISIBLE to a manager entity. We agree 100% on that. > These specs refer to how the SNMP agent should function. > I respectfully submit that it's up to us to further specify > a reasonable mechanism to perform these functions in the extensible > agent. Which parts belong in the master, and which belong in the > sub... Right. The subs are SNMPv2c; the master handles mappings for v1 management applications. > >Oh, and just in case you haven't noticed: No AgentX agents > >exist yet. If somene wants to use an existing agent as an > >AgentX sub-agent, he will have to do so via an AgentX "proxy > >sub-agent" or--if that term is too loaded for you--an AgentX > >adapter agent. Better choice is to revise/re-write it as an > >AgentX native sub-agent. > > The rewriting will be in the subagent protocol library, NOT the > MIB instrumentation!!! I disagree...see my comments above wrt dependency upon a protocol library (including the statement that I could be wrong). The subagent must present itself to the master agent, at the protocol level, as an SNMPv2c-capable entity. How it achieves that is its own business, I guess...but the AgentX protocol can assume it. > There are 3 conceptual interfaces involved here: > > manager > ======= #1 > agent > { master agent > ============ #2 > subagent > ============ #3 > MIB instrumentation > } > > #1 is the SNMP > #2 is AgentX > #3 is the private (or at least vendor-specific) interface > to MIB instrumentation. (Method routines, etc) > One function of this interface is to "hide" SNMP, and > AgentX specifics from the instrumentation. That is correct. The subagent *knows* it got an AgentX request on interface #2 which assumed SNMPv2c-ness. How it deals with that fact across interface #3 is entirely its own business and has no bearing on whether the remote management application sent a v1 or a v2 request to the master agent. > We specified that we'll use SNMPv2 SMI across interface #2. > I think at the time, we meant v2 error and exception values. Right...and the SMI and everything else that comes with SNMPv2c...no exclusions and no limitations. > This requires the master agent to map v2 error/exception values > to v1 if it wished to support v1. That is correct. > But I didn't interpret that as meaning we have to accept that > ALL such mapping be done at this point. Well, then I respectfully suggest that you made the wrong interpretation...why would you interpret that as meaning there should be some exclusions or redundancies? I am open to the possibility that your answer to that question could prove me wrong. > With respect to counter64, your argument is (I think) > > o It is a cleaner design to put ALL v2->v1 mapping in > the master agent > o It makes the protocol simpler (one less field) > o It makes the subagent (elements of procedure) simpler > o v1 access of v2 counter64 objects is a rare thing > > to which I agree (except for the last point. i think a year or > two from now it will be a very common thing) I am glad we agree on so much of the list. As for your last bullet, without attempting to estimate the growth of Counter64 objects, all I can say is that a developer/vendor/user of a v1 management application that needs to handle MIBs with Counter64 objects should play his part in getting that app to v2c compliance. Lord knows, it couldn't be any easier and still require a version number change! > My argument is > > o Mapping v2 error/exception values to v1 is logical to > do in the master agent. But handling syntax (and instances) > is not. Distributing the roles along these lines is inconsistent, messy, and leads to complexities. > Causing the master to blindly resend GetNexts just seems to > me like very bad design, largely because it's unbounded. > (A v1 getnext walk of a managed node with 10 interfaces > that bumps into ifXTable will have to send/receive 80 > agentx-GetNext-PDUs before it can respond to the manager.) Yes, I do not like having perform "discovery" operations like this either. My estimate is that they really are not all that prevalent; apps will eventually want/have to evolve to v2c level anyway; and the trade-off in the interim is still a positive one overall. > We are in essence placing contraints on MIB designers > (don't create tables with lots of consecutive Counter64 > objects). Nope, we are not. We are placing constraints on app vendors: Make the modest effort required to comply with SNMPv2c or be labeled a dog in the marketplace. > o Interface #3 already does some version mapping, since > it may be "attached" to v1 instrumentation and must > use v2 in AgentX. Right. It has its appropriate share of the workload...i.e., the part that cannot be done anywhere else. It knows it got a v2c-aware request from the master and it has to do any mappings vis-a-vis the instrumentation. > o Sending the version in the protocol is a very small > increase in complexity. > Adding this check in the elements of procedure for GetNext > is a very small increase in complexity and implementation. This is true. > To me it seems like a better choice to accept this > unpleasantness than the runtime unpleasantness of > not doing so. It is helpful to express these cost/benefit trade-offs. I reached a different result when I ran my calculation. We are probably not including all the same factors. My formula allows for the possibility of some input scenarios not being supported and it allows for v1 management apps to possibly incur a runtime penalty. > o This syntax compatibility check does NOT impact the > instrumentation code, it's a part of AgentX that's hidden > by interface #3 I consider that an argument for the superfluity of the info. > o I think we'll need SNMP version info for other reasons > anyway... Aha! And that's the rub! If that is true, then we have failed, IMHO...if that is so, then we should just be passing SNMP packets down to the subagents. We cannot have it as our target to support every conceivable subagent application. That is neither necessary nor desirable. It is not necessary because there is a vast majority of subagent applications that do not require a high degree of complexity and there is an established cadre of experts to deal with the minority of subagent applications requiring more complexity; it is not desirable because building in the complexity to support the minority of subagent applications which need it will thwart the deployment of AgentX among the majority of potential applications which don't. > Well, sorry for the length but I want to make sure we're > all working from the same set of assumptions. And, yes, I am as guilty as always of not shortening it! But this is an important topic at this point, so I thought it best to keep the whole thing intact. > I won't (or at least will try not to :-) drag this out > any longer. Ok...it appears from the active contributions that the wg is somewhat deadlocked on this issue at the moment... I, as wg chair, have tried to argue from "first principles" as to what I think the resolution of that deadlock must be. Wg chairs are hardly infallible people, especially those as junior in the process as I am. But I have done my best to interpret and explain the situation. If others feel that I have this "wrong"--realizing there is no absolute "right" and we are choosing among plausible alternatives-- then please post your comments to the list asap. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 13 Sep 1996 11:23:44 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA19310 for X-agentx; Fri, 13 Sep 1996 11:23:43 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA19307 for ; Fri, 13 Sep 1996 11:23:42 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA16617; Fri, 13 Sep 1996 14:21:40 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA689944; Fri, 13 Sep 1996 14:21:11 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA32825; Fri, 13 Sep 1996 14:21:10 -0400 From: Uri Blumenthal Message-Id: <9609131821.AA32825@hawpub.watson.ibm.com> Subject: Re: 02:No. of varbinds in the VarBindList To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 13 Sep 1996 14:21:10 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609131259.AA07559@bernie.zk3.dec.com> from "Mike Daniele" at Sep 13, 96 08:59:20 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > >The idea of including no. of varbinds is straight-forward for > >implementation. > >> I suggest context length. > >Why ? > Because adding a "number of variables" field affects every implementation. > Adding a "size of context" field only affects those that support > non-default contexts, which I guess would be a minority. Mike, Mike... What on earth ARE you talking about?! There can possibly be no implementations, as the draft itself hasn't solidified yet! I personally consider it a great benefit that we are NOT dragged by any existing implementation we might need to be compatible with. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 13 Sep 1996 11:24:05 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA19385 for X-agentx; Fri, 13 Sep 1996 11:24:05 -0700 (PDT) Received: from crow.bmc.com (crow.bmc.com [198.147.191.100]) by fv.com (8.7.4/8.7.3) with SMTP id LAA19376 for ; Fri, 13 Sep 1996 11:24:03 -0700 (PDT) Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA10974; Fri, 13 Sep 1996 13:22:21 -0500 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA259769039; Fri, 13 Sep 1996 11:23:59 -0700 Date: Fri, 13 Sep 1996 11:23:59 -0700 From: Randy Presuhn Message-Id: <199609131823.AA259769039@dorothy.peer.com> To: agentx@fv.com Subject: RE: various items - based on version 00.03 draft Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - My apologies for an inordinately long message. Summary: It has been argued that IMPLIED INDEXes should be encoded differently depending on the choice of protocol, and that that requirement justifies inclusion of SNMP version information in the agent/subagent dialog. I present counter-arguments in opposition to the supposed requirement. |Message-Id: |From: Don Ryan |Subject: RE: various items - based on version 00.03 draft |Date: Thu, 12 Sep 1996 20:26:00 -0700 ... |>> Generating different OBJECT IDENTIFIER encodings for a given instance |>> does not aid interoperability. | |Designing a keyword which specifies OBJECT IDENTIFIER encodings that can |only be interpreted by downlevel managers if they have a priori |knowledge of the format of the instance identifier does not aid |interoperability either. True, but this is not a new problem. It's one of the reasons the IMPLIED qualifier was added. | Some SMIv2->v1 MIB translators actually just |drop the keyword which means that downlevel managers are mislead as to |the format of the instance identifier. Dave Perkins can provide plenty of reasons why that's probably not the best approach. | I find the thought of downlevel |managers struggling with these malformed (from their perspective) OIDs |much more bothersome than having to reveal to the subagents what SNMP |version was included in the PDU. A robust manager needs to be able to deal with one of these anyway, even if only to say the index information is improperly encoded. This gets back to the well-established goal of encouraging support for the v2 SMI. |>> SNMPv1 agents encoding variable-length |>> string indexes as though they had been marked with the IMPLIED keyword |>> were out there long before SNMPv2 was even mentioned. One of the |>> rationales for adding the IMPLIED keyword to the SMI was to describe |>> the unusual behaviour of those agents. | |Is your point that some "unusual" SNMPv1 agents are already sending |bogus OIDs to SNMPv1 managers so AgentX subagents should reserve the |right to do the same? Not quite. The master agent should not be messing with non-protocol issues. Error codes are defined in protocol. Data types are constrained by protocol. The encoding of INDEX values within OBJECT IDENTIFIERS is not protocol; it is SMI. The approach of changing the encoding is equivalent to claiming that, based on the choice of protocol for conveying the information, we should use different class definitions for the managed information. This is not clean design. This does not help existing managers that already know how to deal with miscreant v1 implementations. This does not simplify agentx protocol, master agent, or subagent design. |>> For an agent (or subagent) to employ different OBJECT IDENTIFIER encodings |>> based on the protocol used by the manager: |>> |>> - breaks SNMPv2 to SNMPv1 proxy (the system in the middle |>> has no way of knowing it would need to twiddle the oid) | |The entity instantiating the columnar object is the SNMPv1 agent, |correct? Having an SNMPv2 manager query a SNMPv1 agent (via a proxy) |for the columnar object using SMIv2 syntax is problematic anyway. I haven't encountered this problem, whatever it is. One of the motivations for permitting the old SNMPv1 error codes in responses from an SNMPv2 agent is the support of this configuration. |Either the SNMPv2 manager has a priori knowledge that this will work or |the MIB given to the SNMPv2 manager includes the IMPLIED keyword. In Exactly. That's why the IMPLIED keyword was added: to provide a way telling systems that this was the desired behaviour. |the either case, the SNMPv1 agent will not interoperate with SNMPv1 |managers unless they also have a priori knowledge of the instance |identifier format. This is true, and has been true even before v2 SMI appear on the scene. |>> - produces different get-next orderings for the same data |>> (just imagine the proxy behaviour needed to fix this!) | |Obviously the ordering would be different based on the encoding which is |the main reason I decided not to use the IMPLIED keyword in any private |MIBs. The choice was to sort the data differently based on the protocol |version, not return any objects from the table to downlevel managers, or |return an v2-formatted OID and distribute the format of the instance |identifier in the DESCRIPTION string. I did not find any of those |options satisfactory but others may. Without the SNMP version then the |last option is the only one available since the first two are runtime |decisions that can be made only by the subagent. Reordering and not returning anything are not useful. My personal preference is to avoid the use of the IMPLIED keyword except when describing someone's fielded implementation that has that behaviour. The point is to separate the definition of management information from the protocol choice. If a MIB is defined as using the IMPLIED index approach, then any manager accessing that MIB should be prepared to deal with that, regardless of the protocol in use. |>> - increases the complexity of recording log records |>> - increases the complexity of formulating view masks in |>> conjunction with access control |>> - increases subagent complexity (not just run-time library code, |>> but also any user code connected with the location and ordering |>> of instances) | |This are valid arguments for not modifying the OID based on the SNMP |version but what about the case where the subagent simply returns |noSuchObject when being queried by a downlevel manager? As I mentioned |above, this is a runtime decision that can only be made by the subagent. If a manager asks for the information, it is presumably prepared to deal with the response. As a practical matter, robust managers that only know the v1 SMI already need to deal with these encodings. The long-standing direction of the NM area has been to encourage migration to SNMPv2 SMI. These two facts taken together lead me to the conclusion that special-casing this on the agent or subagent side would be counter-productive. |>> I see no benefits to differing encodings, and plenty of disadvantages. | |I would address this statement to the folks who decided to add the |IMPLIED keyword. Yes, a conceptual table can now be sorted |alphabetically but the instance identifier of the table can only be |parsed correctly by a downlevel manager if the agent modifies the OID |encoding or the manager as a priori knowledge about the format. The latter is historically what has been done. There have been v1 SMI MIB compilers for some time that have accepted the IMPLIED keyword, as well as ad hoc solutions. |>> One can argue whether those existing SNMPv1 systems that encode things |>> as though they were IMPLIED are broken because they don't observe RFC |>> 1212 clause 4.1.6 (3), or that they were simply ahead of their time. | |My opinion is that these systems were broken originally and that the |IMPLIED keyword has made the situation worse by legitimizing their |incorrect implementations and causing headaches for SNMPv1 managers. I think we actually agree on this point. I was trying to be nice. :-) |>> Managers have dealt successfully with these systems for some time; we're |>> not doing them any favors by changing the encodings. | |If I design and implement a private MIB which includes a conceptual |table whose INDEX clause includes an OCTET STRING modified by the |IMPLIED keyword and I expose this MIB to the world via an SNMPv2 AgentX |master, explain to me how any of these SNMPv1 managers will |"successfully deal" with the parsing of the instance identifier. It depends on the manager. Some accept the IMPLIED keyword in what are nominally v1 SMI mib definitions. Some have other ways of learning that the OID component are tacked together oddly. In others, the extraction of indexing information from OIDs is so lame (or is it robust? :-) that they don't even notice the difference. Developers of manager-role systems have had three and a half years (since the publication of RFC 1442) to prepare for this. This issue has been around much longer. I have limited sympathy for management systems that can't deal with it yet. ----------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: rpresuhn@bmc.com USA -----------------------------------------------------------------------   Delivery-Date: Fri, 13 Sep 1996 11:37:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA20758 for X-agentx; Fri, 13 Sep 1996 11:37:22 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA20750 for ; Fri, 13 Sep 1996 11:37:15 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA105554; Fri, 13 Sep 1996 14:35:19 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA94661; Fri, 13 Sep 1996 14:34:38 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA28193; Fri, 13 Sep 1996 14:34:37 -0400 From: Uri Blumenthal Message-Id: <9609131834.AA28193@hawpub.watson.ibm.com> Subject: Re: SNMP version info To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 13 Sep 1996 14:34:37 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609131452.AA07614@bernie.zk3.dec.com> from "Mike Daniele" at Sep 13, 96 10:52:15 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > >The SNMP version info is superfluous, because: > > >1. AgentX assumes SNMPv2c as the base SNMP level. > > I think this is the problem. The consensus was that we would use > SNMPv2 SMI in the protocol. It was understood that AgentX subagents > might have to "fix up" responses from v1 MIB instrumentation to do so. Excuse me, but the request from the master agent goes to the sub'. This request is V2. Sub' speaks V2 to the master. Normally it's the sub' itself that does the instrumentation, and the whole reason to have sub' on the first place is that the sub' is doing actual instrumentation while the master is worrying about SNMP protocol specifics. If sub's not doing instrumentation, why the heck do you need that sub'?! > >2. AgentX sub-agents MUST be SNMPv2c-aware, at a minimum. > > Agreed, but I would point out that it's the "protocol library" > part of the subagent, NOT the MIB instrumentation, that MUST be > v2c aware. Respectfully disagree. Plus, we are NOT standardizing on the interface between the "protocol" part and the "instrumentation" part of the sub' itself. For all I care - a sub' is MONOLYTHIC. (:-) > >4. AgentX sub-agents are not SNMPv1 agents, except insofar > > as SNMPv1 is a subset of SNMPv2c. > > I'm not sure how to interpret this part... It means - when V1 and V2c say exactly the same thing - feel free to call your sub' V1, if you wish. As soon as V1 and V2 disagree - your sub' MUST follow V2. > >5. The AgentX protocol between master and sub, while not > > SNMP, is based upon the assumption of SNMPv2c-awareness > > in the sub-agent. > > Same reply as for 2. > > >6. Every AgentX sub-agent's MIB MUST be SNMPv2c compliant > > (and it MAY also be SNMPv1 compliant). > > I completely disagree with this statement. And I agree with Bob's statement and strongly disagree (or is it "completely disagree"? :-) with yours. Anybody else cares to comment? > I view it as a fundamental requirement that an AgentX subagent > be able to implement a SNMPv1 MIB. Amazing! I view it as a fundamental requirement that an AgentX sub's implemented V2 MIBs... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 13 Sep 1996 12:09:12 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA24646 for X-agentx; Fri, 13 Sep 1996 12:09:11 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA24642 for ; Fri, 13 Sep 1996 12:09:10 -0700 (PDT) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA32145; Fri, 13 Sep 1996 15:02:55 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA09310; Fri, 13 Sep 1996 15:02:53 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07809; Fri, 13 Sep 1996 15:06:14 -0400 Message-Id: <9609131906.AA07809@bernie.zk3.dec.com> To: agentx@fv.com Subject: snmp version Date: Fri, 13 Sep 96 15:06:14 -0400 From: Mike Daniele X-Mts: smtp Hi Bob, I'll keep this short :-) >> But I didn't interpret that as meaning we have to accept that >> ALL such mapping be done at this point. >Well, then I respectfully suggest that you made the wrong >interpretation...why would you interpret that as meaning >there should be some exclusions or redundancies? I am open >to the possibility that your answer to that question >could prove me wrong. Because of this. In reality, there is no "mapping" of Counter64 onto v1. It's not something the master agent can do by itself. It requires finding the next instance of non-Counter64 syntax. And the AgentX role that knows about what object types are present, and what their syntax is, is the subagent. >Ok...it appears from the active contributions that the >wg is somewhat deadlocked on this issue at the moment... I am the only person I've seen on the list arguing for snmp version information to be passed (at least for the purpose of dealing w/ v2-only syntax). So I concede. Let's move on to the next issue. Regards, Mike I, as wg chair, have tried to argue from "first principles" as to what I think the resolution of that deadlock must be. Wg chairs are hardly infallible people, especially those as junior in the process as I am. But I have done my best to interpret and explain the situation. If others feel that I have this "wrong"--realizing there is no absolute "right" and we are choosing among plausible alternatives-- then please post your comments to the list asap. Cordially, BobN - ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com - ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- - ------- NetPlus (r) "FCAPS" Telemanagement Applications -------- ------- End of Forwarded Message   Delivery-Date: Fri, 13 Sep 1996 13:30:51 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA03091 for X-agentx; Fri, 13 Sep 1996 13:30:51 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by fv.com (8.7.4/8.7.3) with SMTP id NAA03088 for ; Fri, 13 Sep 1996 13:30:50 -0700 (PDT) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA23872; Fri, 13 Sep 96 16:30:54 -0400 Date: Fri, 13 Sep 96 16:30:54 -0400 From: David Battle Message-Id: <9609132030.AA23872@seymour16.snmp.com> To: agentx@fv.com Subject: Re: duplicate/unionized registrations > Would it be possible to supply a specific example how this feature > (permitting multiple subagents to register the same oid) is used/required > in order for subagents to implement a table that is split across subagents? Sure. The clasic example is the Interfaces table. These days, interfaces can come as loadable software drivers, plug-in hardware, or both. Are you going to require every interface hardware/software vendor to reserve a chunk of ifIndex space so that their subagents can pre-register which instance they will support? -David   Delivery-Date: Fri, 13 Sep 1996 13:42:43 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA04924 for X-agentx; Fri, 13 Sep 1996 13:42:42 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by fv.com (8.7.4/8.7.3) with SMTP id NAA04880 for ; Fri, 13 Sep 1996 13:42:24 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA21718; Fri, 13 Sep 96 13:39:58 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA06174; Fri, 13 Sep 96 13:39:57 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA17959; Fri, 13 Sep 96 13:39:56 PDT Date: Fri, 13 Sep 96 13:39:56 PDT From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9609132039.AA17959@santa.strata.com> To: daniele@zk3.dec.com Subject: Re: SNMP version info Cc: agentx@fv.com There's an unwritten AgentX design maxim that says: Master agent is MIB ignorant, SNMP omniscient; subagent is SNMP ignorant, MIB omniscient. It's a clear and simple idea, and we should think twice before breaking it. The only argument I've seen in favor of breaking it (by sending SNMP version info to the subagent; an analogous tweak would be giving the master agent the ability to distinguish the object and instance pieces of a varbind's OID) is that Counter64 columns in a table with lots of rows will cause lots of wasted getnext cycles when a v1 manager is doing the query. The only equipment I can think of in the near-term that is likely to have Counter64 objects is high-end (e.g., ATM switches), and is likely to be deployed by exactly the people (carriers, ISPs, large enterprises) with the money and motivation to adopt v2 managers if they need them. So unless there's another, more compelling argument, I think we should keep this particular wall of separation between master agent and subagent. Because it's not at all clear that there's anything significant to be gained by punching a hole in the wall. --Dale   Delivery-Date: Fri, 13 Sep 1996 14:10:07 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA07880 for X-agentx; Fri, 13 Sep 1996 14:10:06 -0700 (PDT) Received: from crow.bmc.com (crow.bmc.com [198.147.191.100]) by fv.com (8.7.4/8.7.3) with SMTP id OAA07869 for ; Fri, 13 Sep 1996 14:10:05 -0700 (PDT) Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA05551; Fri, 13 Sep 1996 16:08:25 -0500 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA269869004; Fri, 13 Sep 1996 14:10:04 -0700 Date: Fri, 13 Sep 1996 14:10:04 -0700 From: Randy Presuhn Message-Id: <199609132110.AA269869004@dorothy.peer.com> To: agentx@fv.com Subject: Re: duplicate/unionized registrations Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 13 Sep 96 16:30:54 -0400 > From: David Battle > Message-Id: <9609132030.AA23872@seymour16.snmp.com> > To: agentx@fv.com > Subject: Re: duplicate/unionized registrations > > > Would it be possible to supply a specific example how this feature > > (permitting multiple subagents to register the same oid) is used/required > > in order for subagents to implement a table that is split across subagents? > > Sure. The clasic example is the Interfaces table. These days, interfaces > can come as loadable software drivers, plug-in hardware, or both. Are you > going to require every interface hardware/software vendor to reserve a chunk > of ifIndex space so that their subagents can pre-register which instance > they will support? ... Dynamic index reservation (clause 7.1.2 of the draft) is supposed to handle this. From the discussion so far, it sounds like the index reservation approach would also be more efficient and less likely to result in non-deterministic behaviour. ----------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: rpresuhn@bmc.com USA -----------------------------------------------------------------------   Delivery-Date: Fri, 13 Sep 1996 14:25:36 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA10138 for X-agentx; Fri, 13 Sep 1996 14:25:35 -0700 (PDT) Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by fv.com (8.7.4/8.7.3) with SMTP id OAA10134 for ; Fri, 13 Sep 1996 14:25:34 -0700 (PDT) Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA17F.C80E00A0@tide21.microsoft.com>; Fri, 13 Sep 1996 14:28:07 -0700 Message-ID: From: Don Ryan To: "'Randy Presuhn'" Cc: "'agentx@fv.com'" Subject: RE: various items - based on version 00.03 draft Date: Fri, 13 Sep 1996 14:25:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 29 TEXT My main argument is that subagent developers should not be precluded from providing whatever downward compatibility that they think is appropriate. As Jeff Case mentioned at Montreal he was eventually forced into making the SNMP version available in his ENAMATE product based on customer demand. It is my opinion that the migration to SNMPv2 is not going to become truly widespread until: a.) we all strongly support one version instead of some of us half-heartedly supporting one of three b.) that one version supports features compelling enough to offset the cost of migration (read security) However, if the concensus of the working group is that clean design is more important than downward compatibility then so be it. >---------- >From: Randy Presuhn[SMTP:rpresuhn@peer.com] >Sent: Friday, September 13, 1996 11:23 AM >To: agentx@fv.com >Subject: RE: various items - based on version 00.03 draft > >Summary: > It has been argued that IMPLIED INDEXes should be encoded > differently depending on the choice of protocol, and that that > requirement justifies inclusion of SNMP version information > in the agent/subagent dialog. I present counter-arguments in > opposition to the supposed requirement. > >   Delivery-Date: Fri, 13 Sep 1996 15:34:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA16628 for X-agentx; Fri, 13 Sep 1996 15:34:03 -0700 (PDT) Received: from crow.bmc.com (crow.bmc.com [198.147.191.100]) by fv.com (8.7.4/8.7.3) with SMTP id PAA16615 for ; Fri, 13 Sep 1996 15:34:02 -0700 (PDT) Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA13474; Fri, 13 Sep 1996 17:32:19 -0500 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA274414038; Fri, 13 Sep 1996 15:33:58 -0700 Date: Fri, 13 Sep 1996 15:33:58 -0700 From: Randy Presuhn Message-Id: <199609132233.AA274414038@dorothy.peer.com> To: agentx@fv.com Subject: Re: SNMP version info Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 13 Sep 96 13:39:56 PDT > From: dfrancis@stratacom.com (Dale Francisco) > Message-Id: <9609132039.AA17959@santa.strata.com> > To: daniele@zk3.dec.com > Subject: Re: SNMP version info > Cc: agentx@fv.com > > There's an unwritten AgentX design maxim that says: > > Master agent is MIB ignorant, SNMP omniscient; > subagent is SNMP ignorant, MIB omniscient. Can we turn this (with appropriate editorial refinement) into a written design maxim in clause 3.2 of the draft? This seems to conflict with the last bullet in that clause, which has other problems anyway with respect to access control and get-next/bulk, and which should therefor be deleted. ----------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: rpresuhn@bmc.com USA -----------------------------------------------------------------------   Delivery-Date: Fri, 13 Sep 1996 22:01:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id WAA18754 for X-agentx; Fri, 13 Sep 1996 22:01:02 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id WAA18728 for ; Fri, 13 Sep 1996 22:01:01 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id BAA11662; Sat, 14 Sep 1996 01:01:03 -0400 Date: Sat, 14 Sep 1996 01:00:24 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA18020; Sat, 14 Sep 1996 01:00:24 -0400 Message-Id: <9609140500.AA18020@nips.acec.com> To: donryan@microsoft.com Subject: RE: various items - based on version 00.03 draft Cc: agentx@fv.com > From: Don Ryan > Date: Fri, 13 Sep 1996 14:25:43 -0700 Hi Don, > My main argument is that subagent developers should not be precluded > from providing whatever downward compatibility that they think is > appropriate. And they are not. AgentX--like any other well-focused protocol-- might not provide all of the "whatever" itself. When one of those is an absolute requirement for the subagent, that developer might have to augment or replace AgentX with something tuned to his special needs. > As Jeff Case mentioned at Montreal he was eventually forced into > making the SNMP version available in his ENAMATE product > based on customer demand. There will always be customers who want something more or something different. That is fine. That makes the world go 'round and keeps food on many of our tables. I am absolutely convinced that robust full-featured extensible agent development and runtime enironments from reputable vendors such as SNMP Research, Peer/BMC, Epilogue, IBM, DEC, and others will all see absolute market growth after AgentX is deployed. It is not a purpose of AgentX to replace such extensible agent environments. Its purpose is to provide a standard protocol that will significantly enlarge the population of available managed components to end-users by making it both technically and economically more attractive for the component vendors and others to build AgentX subagents for those components. There are many, many such components--esp. software entities-- that could reap such benefits with much added complexity in the AgentX protocol. There are some components that cannot be managed in an extensible fashion w/o additional features that might not be part of AgentX. Those vendors will be able to fill that (relatively small, IMHO) void just fine. > It is my opinion that the migration to SNMPv2 > is not going to become truly widespread until: > > a.) we all strongly support one version instead of some > of us half-heartedly supporting one of three SNMPv2c is the protocol to promote at this time. > b.) that one version supports features compelling enough > to offset the cost of migration (read security) This is an old argument and I hope we can avoid resurrecting it in this forum. I believe that the practices of "incremental upgrades" and "slip-streaming" are proving themselves to be wildly effective in various high-visibility software segments. I do not see a reason why those same methods cannot be effective wrt SNMP software. There is no silver bullet. > However, if the concensus of the working group is that clean > design is more important than downward compatibility then so > be it. I think the consensus appears to be that a clean design and relatively simple protocol which addresses the needs of a large majority of subagents is more important than an having a comlicated design and a complex protocol just for the sake of bringing in an additional samll fraction of possible subagents. I don't think the recent flow on these threads has signaled a major lack of concern for "downward compatibility"--just a re- assertion of its "proper" locus in the master agent--and even that can be stated positively as a concern for promoting "upward compatibility". SNMPv1 management applications with such weak support from their developers/vendors that they cannot make the easy migration to SNMPv2c are not worth buying or keeping much longer if you already own them, IMHO. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 13 Sep 1996 22:45:45 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id WAA23227 for X-agentx; Fri, 13 Sep 1996 22:45:45 -0700 (PDT) Received: from pointer.cisco.com (pointer.cisco.com [171.69.1.206]) by fv.com (8.7.4/8.7.3) with SMTP id WAA23224 for ; Fri, 13 Sep 1996 22:45:45 -0700 (PDT) Received: (rvenkat@localhost) by pointer.cisco.com (8.6.12/8.6.5) id WAA14800; Fri, 13 Sep 1996 22:41:56 -0700 From: R Venkatsubramaniam Message-Id: <199609140541.WAA14800@pointer.cisco.com> Subject: Re: 02:No. of varbinds in the VarBindList To: uri@watson.ibm.com Date: Fri, 13 Sep 1996 22:41:56 -0700 (PDT) Cc: daniele@zk3.dec.com, agentx@fv.com In-Reply-To: <9609131821.AA32825@hawpub.watson.ibm.com> from "Uri Blumenthal" at Sep 13, 96 02:21:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Uri writes : > > Mike Daniele says: > > >The idea of including no. of varbinds is straight-forward for > > >implementation. > > >> I suggest context length. > > >Why ? > > Because adding a "number of variables" field affects every implementation. > > Adding a "size of context" field only affects those that support > > non-default contexts, which I guess would be a minority. > > Mike, Mike... What on earth ARE you talking about?! There can possibly > be no implementations, as the draft itself hasn't solidified yet! I > personally consider it a great benefit that we are NOT dragged by > any existing implementation we might need to be compatible with. True. Mike, can you tell me which 'implementation' you are talking about ? Thanks, Venkat. (rvenkat@cisco.com)   Delivery-Date: Sun, 15 Sep 1996 18:56:13 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id SAA26083 for X-agentx; Sun, 15 Sep 1996 18:56:13 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id SAA26080 for ; Sun, 15 Sep 1996 18:56:12 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id VAA06473; Sun, 15 Sep 1996 21:56:44 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id VAA636921; Sun, 15 Sep 1996 21:56:15 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA17522; Sun, 15 Sep 1996 21:56:14 -0400 From: Uri Blumenthal Message-Id: <9609160156.AA17522@hawpub.watson.ibm.com> Subject: Re: duplicate/unionized registrations To: battle@seymour16.snmp.com (David Battle) Date: Sun, 15 Sep 1996 21:56:14 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <9609132030.AA23872@seymour16.snmp.com> from "David Battle" at Sep 13, 96 04:30:54 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text David Battle says: > > Would it be possible to supply a specific example how this feature > > (permitting multiple subagents to register the same oid) is used/required > > in order for subagents to implement a table that is split across subagents? > > Sure. The clasic example is the Interfaces table. These days, interfaces > can come as loadable software drivers, plug-in hardware, or both. Are you > going to require every interface hardware/software vendor to reserve a chunk > of ifIndex space so that their subagents can pre-register which instance > they will support? Oh, so now they both support "ifIndex.1", right? Feel free to decide which "ifIndex.1" is "better" to return in GetNext. (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Sun, 15 Sep 1996 23:59:54 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id XAA21882 for X-agentx; Sun, 15 Sep 1996 23:59:54 -0700 (PDT) Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by fv.com (8.7.4/8.7.3) with SMTP id XAA21877 for ; Sun, 15 Sep 1996 23:59:53 -0700 (PDT) Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA362.4E12FB90@tide21.microsoft.com>; Mon, 16 Sep 1996 00:02:09 -0700 Message-ID: From: Don Ryan To: "'agentx@fv.com'" Subject: encoding and pdus Date: Mon, 16 Sep 1996 00:00:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 763 TEXT Here are some ideas I had over the weekend about the AgentX encodings and PDUs. Note the extension header idea was stolen from IPv6 and was included below because I thought at one time there was talk of supporting remote subagents. Even if this is no longer the case, I would still suggest we invest the four bytes for such future extensions. Don Ryan P.S. I was using v00.03 as a reference. ///////////////////////////////////// >5. AgentX Encodings > > AgentX messages consist of a common header, zero or more extension >headers, an AgentX PDU header, and then PDU-specific data of variable length. >Messages are transmitted as a contiguous octet stream and not encoded using >the BER [1]. The data within this stream is aligned on 32-bit boundaries >relative to the start of the AgentX message. > > Numeric data in all AgentX headers is in network byte order. The byte >order of numeric data within the AgentX PDUs is specified by the PDU-specific >flag X_FLAG_NETWORK_BYTE_ORDER. It is important to note that subagents >always read and write numeric data in the PDUs using the subagent's natural >byte ordering and that their only responsibility is to set the above flag >correctly. AgentX master agents are responsible for translating the byte >order in incoming and outgoing PDU's. This will only be necessary, however, >if the master agent's own ordering differs from that of the subagent. > >5.1 Object Identifier > > An object identifier is transmitted as a 32-bit value describing the >number of sub-identifiers present followed by the 32-bit sub-identifiers >themselves. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Sub-Identifiers (S) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Identifier 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Identifier S | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >5.2 Octet String > > A octet string is transmitted as a 32-bit value describing the number of >octets in the octet string followed by the octets themselves. If the octet >string is not positioned at the end of a PDU then padding octets should be >added to maintain 32-bit alignment. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet String Length (L) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet 1 | Octet 2 | Octet 3 | Octet 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet L - 1 | Octet L | Optional Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >5.3 Variable Binding > > A variable binding is transmitted as a 32-bit value describing the number >of octets making up the variable binding name and value followed by the >variable binding name and value themselves. The variable binding name is >transmitted as described in section 5.3.1 whereas the variable binding value >is transmitted as described in section 5.3.2. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding Name | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >5.3.1 Variable Name > > A name component of a variable binding is transmitted as a 32-bit view >identifier describing the registered view containing the variable followed by >an partial object identifer describing the variable. This partial object >identifier is relative to view prefix registered with the view identifier as >described in section 6.3.3. If the object identifier is not relative to any >view (as is the case in trap variable names) then the view identifier should >be set to the reserved value of 0xFFFFFFFF. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Name Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >5.3.2 Variable Value > > A value component of a variable binding is transmitted as a 32-bit type >identifier followed by the value data transmitted as outlined in the comments >below. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >Value Type - value syntax restricted to SNMPv2 SMI values: > > Integer (2), > OctetString (4), > ObjectIdentifier (6), > IpAddress (64), > Counter32 (65), > Gauge32 (66), > TimeTicks (67), > Opaque (68), > Counter64 (70), > noSuchObject (128), > noSuchInstance (129), > endOfMibView (130) > >Value Data - actual value, encoded as follows: > > Integer, Counter32, Gauge32, and TimeTicks values are > transmitted as four contiguous octets ordered using the > subagent's natural byte ordering. > > Counter64 are transmitted as eight contiguous octets > ordered using the subagent's natural byte ordering. > > ObjectIdentifier values are transmitted as described in > section 5.1. > > OctetString, IpAddress, and Opaque values are all octet > strings and are transmitted as described in section 5.2. > > noSuchObject, noSuchInstance, and endOfMibView have no > additional octets that need to be transmitted. > >5.3.3 Variable Range > > A variable range is transmitted as a variable name describing the starting >point of a search operation followed by an object identifier describing the >non-inclusive upper bound to a search operation. Both object identifiers >are relative to the view prefix registered with the view identifier as >described in section 6.3.3. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Name Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Upper Bound Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >6. Protocol Definitions > >6.1 AgentX Message Header > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Next Header | Total Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Version - version of the AgentX protocol (0 for this draft). > >Next Header - type of header upcoming; one of the following values: > > agentx-AgentX-PDU-Header (1), > agentx-Authentication-Header (2), > agentx-Encrypted-Payload-Header (3), > agentx-SNMP-Message-Details-Header (4) > >Total Payload Length - length of the AgentX message including any extension >headers and AgentX PDUs but not including the header itself. > >6.2 AgentX PDU Header > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Type - type of AgentX PDU; one of the following values: > > agentx-Connect-PDU (1), > agentx-Disconnect-PDU (2), > agentx-Register-PDU (3), > agentx-Unregister-PDU (4), > agentx-Get-PDU (5), > agentx-GetNext-PDU (6), > agentx-GetBulk-PDU (7), > agentx-Test-PDU (8), > agentx-Commit-PDU (9), > agentx-Undo-PDU (10), > agentx-Cleanup-PDU (11), > agentx-Notify-PDU (12), > agentx-Ping-PDU (13), > agentx-Response-PDU (14) > >PDU Flags - optional characteristics of PDU (see PDUs below). > >PDU Payload Length - length of the AgentX PDU (excluding header). > >Connection Identifier - assigned by the master agent to a subagent during the >connection operation. The subagent then passes this value back to the master >agent in all subsequent PDUs. This value identifies a single logical >connection between master agent and subagent. > >6.3 AgentX PDUs > >6.3.1 AgentX Connect PDU > > The subagent sends an agentx-Connect-PDU to the master agent in order to >establish a logical connection. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 1 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Subagent Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Subagent Description | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >Connection Identifier - the master agent ignores this value in the >agentx-Connect-PDU and sends the newly allocated identifier to the subagent >via the agentx-Response-PDU. The subagent must save this identifier and >include it in all subsequent PDUs. > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1 X_FLAG_AGENT_CAPABILITIES > 2-7 unused (must be zero) > > X_FLAG_NETWORK_BYTE_ORDERING - if 0 then the PDU payload > (excluding the header) is ordered "little-endian". If 1 > the PDU payload is ordered "big-endian". The AgentX PDU > header is always ordered "big-endian" as is the AgentX > Message Header. The purpose of this flag is to minimize > conversions by using the host's natural byte ordering as > much as possible. It is important to note the subagent > simply specifies the byte order used in the PDU payload. > The AgentX master agent is responsible for conversion. > > X_FLAG_AGENT_CAPABILITIES - if 1 then the subagent object > identifier is from an agent capabilities statement and so > the master agent can use it in the sysORTable. > >Subagent Object Identifier - an object identifier uniquely describing the >subagent. This value is transmitted as described in section 5.1. > >Subagent Description String - an ASCII-encoded DisplayString describing the >subagent. This value is transmitted as described in section 5.2. > >6.3.2 AgentX Disconnect PDU > > The subagent sends an agentx-Disconnect-PDU to the master agent (or vice >versa) in order to terminate the logical connection established in the >agentx-Connect-PDU. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 2 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Connection Identifier - value allocated by the master agent and passed to the >subagent in the response to the agentx-Connect-PDU. > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >6.3.3 AgentX Register PDU > > The subagent sends an agentx-Register-PDU to the master agent in order to >register a MIB view that the subagent wishes to support. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 3 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Priority | Timeout | View Prefix Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Starting OID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Ending OID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Naming Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1 X_FLAG_ADD_TO_ALL_CONTEXTS > 2 X_FLAG_OBJECT_INSTANCE > 3-7 unused (must be zero) > > X_FLAG_ADD_TO_ALL_CONTEXTS - if 1 this indicates that > the view specified should be registered in all contexts > supported by the master agent and that no naming context > is included in the PDU. If 0 this indicates that a naming > context is specified in the PDU and that the view should be > registered only within that context. The master agent's > default naming context is specified by a zero-length octet > string. > > X_FLAG_OBJECT_INSTANCE - if 1 this indicates that the view > consists of a fully-qualified instance name. Master agents > should use this information to optimize dispatching of both > the GetNext and GetBulk PDUs. > >View Identifier - assigned by the subagent to the master agent during the >registration operation. The master agent then passes this value back to the >subagent in subsequent Get, Set, GetNext, and GetBulk PDUs. The subagent >uses this value to identify the subtree and naming context. Multiple views >can be registered with the same view identifier as long as the view prefix, >prefix length and naming context are the same. > >Priority - used by cooperating subagents who are registering identical or >overlapping views to achieve a desired configuration. The default value is 0 >indicating that no priority is requested. Higher numbers indicate higher >priority. > >Timeout - length of time in seconds that a master agent should allow to >elaspe after dispatching a message to a subagent before it regards the >subagent as not responding. This value applies only to objects within this >view and overrides the master agent's default timeout value. The default >view timeout is 0 indicating no override is requested. > >View Prefix Length - specifies the number of sub-identifiers in the View >Starting OID that a subagent feels are unnecessary in order to uniquely >identify the object of interest. Note the Starting OID sub-identifiers must >equal the Ending OID sub-identifiers for this entire length. When the AgentX >master agent transmits the variable binding names in the Get, Set, GetNext, >GetBulk PDUs, sub-identifiers up to and including the view prefix length are >ignored. > >View Starting OID - an object identifier specifing the start of the view >which the subagent wishes to support. > >View Ending OID - an object identifier specifing the end of the view which >the subagent wishes to support. > >Naming Context - octet string describing the naming context under which the >subagent would like the view registered under. > >6.3.4 AgentX Unregister PDU > >The subagent sends an agentx-Unregister-PDU to the master agent in order to >unregister a previously registered MIB view(s). > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 4 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >View Identifier - value allocated by the subagent and passed to the master >agent during the registration operation. Note the master agent should >unregister all of the views registered with this value that are from the same >logical connection. > >6.3.5 AgentX Get PDU > > The master agent sends an agentx-Get-PDU to the subagent in order to >resolve variables determined to be contained in the views registered by the >subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 5 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variables (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Name 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Name V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >6.3.6. AgentX GetNext PDU > > The master agent sends an agentx-GetNext-PDU to the subagent in order to >resolve variables determined to be contained in the views registered by the >subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 6 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variables (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Range 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Range V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >6.3.7. AgentX GetBulk PDU > > The master agent sends an agentx-GetBulk-PDU to the subagent in order to >resolve variables determined to be contained in the views registered by the >subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 7 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Non-Repeaters (N) | Max-Repetitions (M) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variables (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Range 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Range V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >6.3.8. AgentX Test PDU > > The master agent sends an agentx-Test-PDU to the subagent in order to >validate variables determined to be contained in the views registered by the >subagent which are to be set. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 8 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variable Bindings (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >Set Identifier - assigned by the master agent to the subagent for the >duration of the multi-phase set operation. The master agent passes this >value back to the subagent in all subsequent phases of the write so the >subagent must cache the variable bindings. > >6.3.9 AgentX Commit PDU > > The master agent sends an agentx-Commit-PDU to the subagent in order to >write variables determined to be contained in the views registered by the >subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 9 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >Set Identifier - assigned by the master agent to the subagent during the test >phase of the multi-phase write operation. > >6.3.10 AgentX Undo PDU > > The master agent sends an agentx-Undo-PDU to the subagent in order to >rollback variables in the previous set operation that were determined to be >contained in the views registered by the subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 10 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >Set Identifier - assigned by the master agent to the subagent during the test >phase of the multi-phase write operation. > >6.3.11. AgentX Cleanup PDU > > The master agent sends an agentx-Cleanup-PDU to the subagent in order to >notify the subagent to release resources allocated in the multi-phase set >operation. Note this PDU is sent whether the set operation succeeds or not >since either way the subagent may have allocated resources for the rollback >operation. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 11 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >Set Identifier - assigned by the master agent to the subagent during the test >phase of the multi-phase write operation. > >6.3.12. AgentX Notify PDU > > The subagent sends an agentx-Notify-PDU to the master agent in order to >notify the master agent that the subagent needs to send a trap. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 12 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variable Bindings (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Naming Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1-7 unused (must be zero) > >6.3.13 AgentX Ping PDU > > The subagent sends an agentx-Ping-PDU to the master agent in order to test >that the master agent is running and responding promptly and vice versa. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 13 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1 X_FLAG_ARE_YOU_ALIVE > 2 X_FLAG_I_AM_ALIVE > 3-7 unused (must be zero) > > X_FLAG_ARE_YOU_ALIVE - if 1 indicates that the sender of the > agentx-Ping-PDU is requesting a status report in the form of > a agentx-Ping-PDU with the X_FLAG_I_AM_ALIVE flag set. > > X_FLAG_I_AM_ALIVE - if 1 indicates that the sender of the > agentx-Ping-PDU is running and reponding. > >Connection Identifier - this can be 0xFFFFFFFF if a logical connection >between the master agent and subagent has not yet been establised. > >6.3.14 AgentX Response PDU > > The subagent sends an agentx-Response-PDU to the master agent in order to >respond to all AgentX PDUs except for agentx-Ping-PDU. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 14 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Error Status | Error Index | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variable Bindings (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > >Error Status - specifies error as defined in SNMPv2 SMI [4]. > >Error Index - specifies the index of the variable binding in error if >applicable. > > > >   Delivery-Date: Mon, 16 Sep 1996 06:27:46 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id GAA22529 for X-agentx; Mon, 16 Sep 1996 06:27:46 -0700 (PDT) Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by fv.com (8.7.4/8.7.3) with SMTP id GAA22526 for ; Mon, 16 Sep 1996 06:27:45 -0700 (PDT) Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA398.849F75E0@tide21.microsoft.com>; Mon, 16 Sep 1996 06:30:13 -0700 Message-ID: From: Don Ryan To: "'agentx@fv.com'" Subject: RESEND: encodings and pdus Date: Mon, 16 Sep 1996 06:27:46 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 763 TEXT Here are some ideas I had over the weekend about the AgentX encodings and PDUs. Note the extension header idea was stolen from IPv6 and was included below because I thought at one time there was talk of supporting remote subagents. Even if this is no longer the case, I would still suggest we invest the four bytes for such future extensions. Don Ryan P.S. I was using v00.03 as a reference. ///////////////////////////////////// 5. AgentX Encodings AgentX messages consist of a common header, zero or more extension headers, an AgentX PDU header, and then PDU-specific data of variable length. Messages are transmitted as a contiguous octet stream and not encoded using the BER [1]. The data within this stream is aligned on 32-bit boundaries relative to the start of the AgentX message. Numeric data in all AgentX headers is in network byte order. The byte order of numeric data within the AgentX PDUs is specified by the PDU-specific flag X_FLAG_NETWORK_BYTE_ORDER. It is important to note that subagents always read and write numeric data in the PDUs using the subagent's natural byte ordering and that their only responsibility is to set the above flag correctly. AgentX master agents are responsible for translating the byte order in incoming and outgoing PDU's. This will only be necessary, however, if the master agent's own ordering differs from that of the subagent. 5.1 Object Identifier An object identifier is transmitted as a 32-bit value describing the number of sub-identifiers present followed by the 32-bit sub-identifiers themselves. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Sub-Identifiers (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Identifier 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Identifier S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2 Octet String A octet string is transmitted as a 32-bit value describing the number of octets in the octet string followed by the octets themselves. If the octet string is not positioned at the end of a PDU then padding octets should be added to maintain 32-bit alignment. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Optional Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Variable Binding A variable binding is transmitted as a 32-bit value describing the number of octets making up the variable binding name and value followed by the variable binding name and value themselves. The variable binding name is transmitted as described in section 5.3.1 whereas the variable binding value is transmitted as described in section 5.3.2. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 5.3.1 Variable Name A name component of a variable binding is transmitted as a 32-bit view identifier describing the registered view containing the variable followed by an partial object identifer describing the variable. This partial object identifier is relative to view prefix registered with the view identifier as described in section 6.3.3. If the object identifier is not relative to any view (as is the case in trap variable names) then the view identifier should be set to the reserved value of 0xFFFFFFFF. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 5.3.2 Variable Value A value component of a variable binding is transmitted as a 32-bit type identifier followed by the value data transmitted as outlined in the comments below. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Value Type - value syntax restricted to SNMPv2 SMI values: Integer (2), OctetString (4), ObjectIdentifier (6), IpAddress (64), Counter32 (65), Gauge32 (66), TimeTicks (67), Opaque (68), Counter64 (70), noSuchObject (128), noSuchInstance (129), endOfMibView (130) Value Data - actual value, encoded as follows: Integer, Counter32, Gauge32, and TimeTicks values are transmitted as four contiguous octets ordered using the subagent's natural byte ordering. Counter64 are transmitted as eight contiguous octets ordered using the subagent's natural byte ordering. ObjectIdentifier values are transmitted as described in section 5.1. OctetString, IpAddress, and Opaque values are all octet strings and are transmitted as described in section 5.2. noSuchObject, noSuchInstance, and endOfMibView have no additional octets that need to be transmitted. 5.3.3 Variable Range A variable range is transmitted as a variable name describing the starting point of a search operation followed by an object identifier describing the non-inclusive upper bound to a search operation. Both object identifiers are relative to the view prefix registered with the view identifier as described in section 6.3.3. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper Bound Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 6. Protocol Definitions 6.1 AgentX Message Header 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Next Header | Total Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - version of the AgentX protocol (0 for this draft). Next Header - type of header upcoming; one of the following values: agentx-AgentX-PDU-Header (1), agentx-Authentication-Header (2), agentx-Encrypted-Payload-Header (3), agentx-SNMP-Message-Details-Header (4) Total Payload Length - length of the AgentX message including any extension headers and AgentX PDUs but not including the header itself. 6.2 AgentX PDU Header 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Type - type of AgentX PDU; one of the following values: agentx-Connect-PDU (1), agentx-Disconnect-PDU (2), agentx-Register-PDU (3), agentx-Unregister-PDU (4), agentx-Get-PDU (5), agentx-GetNext-PDU (6), agentx-GetBulk-PDU (7), agentx-Test-PDU (8), agentx-Commit-PDU (9), agentx-Undo-PDU (10), agentx-Cleanup-PDU (11), agentx-Notify-PDU (12), agentx-Ping-PDU (13), agentx-Response-PDU (14) PDU Flags - optional characteristics of PDU (see PDUs below). PDU Payload Length - length of the AgentX PDU (excluding header). Connection Identifier - assigned by the master agent to a subagent during the connection operation. The subagent then passes this value back to the master agent in all subsequent PDUs. This value identifies a single logical connection between master agent and subagent. 6.3 AgentX PDUs 6.3.1 AgentX Connect PDU The subagent sends an agentx-Connect-PDU to the master agent in order to establish a logical connection. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 1 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subagent Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subagent Description | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Connection Identifier - the master agent ignores this value in the agentx-Connect-PDU and sends the newly allocated identifier to the subagent via the agentx-Response-PDU. The subagent must save this identifier and include it in all subsequent PDUs. PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1 X_FLAG_AGENT_CAPABILITIES 2-7 unused (must be zero) X_FLAG_NETWORK_BYTE_ORDERING - if 0 then the PDU payload (excluding the header) is ordered "little-endian". If 1 the PDU payload is ordered "big-endian". The AgentX PDU header is always ordered "big-endian" as is the AgentX Message Header. The purpose of this flag is to minimize conversions by using the host's natural byte ordering as much as possible. It is important to note the subagent simply specifies the byte order used in the PDU payload. The AgentX master agent is responsible for conversion. X_FLAG_AGENT_CAPABILITIES - if 1 then the subagent object identifier is from an agent capabilities statement and so the master agent can use it in the sysORTable. Subagent Object Identifier - an object identifier uniquely describing the subagent. This value is transmitted as described in section 5.1. Subagent Description String - an ASCII-encoded DisplayString describing the subagent. This value is transmitted as described in section 5.2. 6.3.2 AgentX Disconnect PDU The subagent sends an agentx-Disconnect-PDU to the master agent (or vice versa) in order to terminate the logical connection established in the agentx-Connect-PDU. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 2 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connection Identifier - value allocated by the master agent and passed to the subagent in the response to the agentx-Connect-PDU. PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) 6.3.3 AgentX Register PDU The subagent sends an agentx-Register-PDU to the master agent in order to register a MIB view that the subagent wishes to support. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 3 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Timeout | View Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Starting OID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Ending OID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Naming Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1 X_FLAG_ADD_TO_ALL_CONTEXTS 2 X_FLAG_OBJECT_INSTANCE 3-7 unused (must be zero) X_FLAG_ADD_TO_ALL_CONTEXTS - if 1 this indicates that the view specified should be registered in all contexts supported by the master agent and that no naming context is included in the PDU. If 0 this indicates that a naming context is specified in the PDU and that the view should be registered only within that context. The master agent's default naming context is specified by a zero-length octet string. X_FLAG_OBJECT_INSTANCE - if 1 this indicates that the view consists of a fully-qualified instance name. Master agents should use this information to optimize dispatching of both the GetNext and GetBulk PDUs. View Identifier - assigned by the subagent to the master agent during the registration operation. The master agent then passes this value back to the subagent in subsequent Get, Set, GetNext, and GetBulk PDUs. The subagent uses this value to identify the subtree and naming context. Multiple views can be registered with the same view identifier as long as the view prefix, prefix length and naming context are the same. Priority - used by cooperating subagents who are registering identical or overlapping views to achieve a desired configuration. The default value is 0 indicating that no priority is requested. Higher numbers indicate higher priority. Timeout - length of time in seconds that a master agent should allow to elaspe after dispatching a message to a subagent before it regards the subagent as not responding. This value applies only to objects within this view and overrides the master agent's default timeout value. The default view timeout is 0 indicating no override is requested. View Prefix Length - specifies the number of sub-identifiers in the View Starting OID that a subagent feels are unnecessary in order to uniquely identify the object of interest. Note the Starting OID sub-identifiers must equal the Ending OID sub-identifiers for this entire length. When the AgentX master agent transmits the variable binding names in the Get, Set, GetNext, GetBulk PDUs, sub-identifiers up to and including the view prefix length are ignored. View Starting OID - an object identifier specifing the start of the view which the subagent wishes to support. View Ending OID - an object identifier specifing the end of the view which the subagent wishes to support. Naming Context - octet string describing the naming context under which the subagent would like the view registered under. 6.3.4 AgentX Unregister PDU The subagent sends an agentx-Unregister-PDU to the master agent in order to unregister a previously registered MIB view(s). 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 4 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) View Identifier - value allocated by the subagent and passed to the master agent during the registration operation. Note the master agent should unregister all of the views registered with this value that are from the same logical connection. 6.3.5 AgentX Get PDU The master agent sends an agentx-Get-PDU to the subagent in order to resolve variables determined to be contained in the views registered by the subagent. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 5 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variables (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Name 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Name V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) 6.3.6. AgentX GetNext PDU The master agent sends an agentx-GetNext-PDU to the subagent in order to resolve variables determined to be contained in the views registered by the subagent. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 6 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variables (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Range 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Range V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) 6.3.7. AgentX GetBulk PDU The master agent sends an agentx-GetBulk-PDU to the subagent in order to resolve variables determined to be contained in the views registered by the subagent. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 7 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Non-Repeaters (N) | Max-Repetitions (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variables (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Range 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Range V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) 6.3.8. AgentX Test PDU The master agent sends an agentx-Test-PDU to the subagent in order to validate variables determined to be contained in the views registered by the subagent which are to be set. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 8 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variable Bindings (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) Set Identifier - assigned by the master agent to the subagent for the duration of the multi-phase set operation. The master agent passes this value back to the subagent in all subsequent phases of the write so the subagent must cache the variable bindings. 6.3.9 AgentX Commit PDU The master agent sends an agentx-Commit-PDU to the subagent in order to write variables determined to be contained in the views registered by the subagent. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 9 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) Set Identifier - assigned by the master agent to the subagent during the test phase of the multi-phase write operation. 6.3.10 AgentX Undo PDU The master agent sends an agentx-Undo-PDU to the subagent in order to rollback variables in the previous set operation that were determined to be contained in the views registered by the subagent. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 10 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) Set Identifier - assigned by the master agent to the subagent during the test phase of the multi-phase write operation. 6.3.11. AgentX Cleanup PDU The master agent sends an agentx-Cleanup-PDU to the subagent in order to notify the subagent to release resources allocated in the multi-phase set operation. Note this PDU is sent whether the set operation succeeds or not since either way the subagent may have allocated resources for the rollback operation. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 11 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) Set Identifier - assigned by the master agent to the subagent during the test phase of the multi-phase write operation. 6.3.12. AgentX Notify PDU The subagent sends an agentx-Notify-PDU to the master agent in order to notify the master agent that the subagent needs to send a trap. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 12 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variable Bindings (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Naming Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1-7 unused (must be zero) 6.3.13 AgentX Ping PDU The subagent sends an agentx-Ping-PDU to the master agent in order to test that the master agent is running and responding promptly and vice versa. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 13 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PDU Flags - optional characteristics of PDU: Bit --- 0 X_FLAG_NETWORK_BYTE_ORDER 1 X_FLAG_ARE_YOU_ALIVE 2 X_FLAG_I_AM_ALIVE 3-7 unused (must be zero) X_FLAG_ARE_YOU_ALIVE - if 1 indicates that the sender of the agentx-Ping-PDU is requesting a status report in the form of a agentx-Ping-PDU with the X_FLAG_I_AM_ALIVE flag set. X_FLAG_I_AM_ALIVE - if 1 indicates that the sender of the agentx-Ping-PDU is running and reponding. Connection Identifier - this can be 0xFFFFFFFF if a logical connection between the master agent and subagent has not yet been establised. 6.3.14 AgentX Response PDU The subagent sends an agentx-Response-PDU to the master agent in order to respond to all AgentX PDUs except for agentx-Ping-PDU. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Type = 14 | PDU Flags | PDU Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Status | Error Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Variable Bindings (V) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Binding V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Error Status - specifies error as defined in SNMPv2 SMI [4]. Error Index - specifies the index of the variable binding in error if applicable.   Delivery-Date: Mon, 16 Sep 1996 11:24:44 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA19440 for X-agentx; Mon, 16 Sep 1996 11:24:44 -0700 (PDT) Received: from iggy.iwsc.com (iggy.iwsc.com [206.13.100.17]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA19437 for ; Mon, 16 Sep 1996 11:24:39 -0700 (PDT) Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA250; Mon, 16 Sep 1996 11:29:39 +0100 Message-ID: <323D9AEB.606F@metacomm.com> Date: Mon, 16 Sep 1996 11:22:35 -0700 From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.0b8Gold (WinNT; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Call for Papers - Global Internet - IEEE Communications Magazine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CALL FOR PAPERS IEEE COMMUNICATIONS MAGAZINE SPECIAL ISSUE ON THE GLOBAL INTERNET The IEEE Communications Magazine is soliciting original tutorial-style manuscripts for a planned Special Issue on the Global Internet. From its origins as a US government research project, the Internet has grown to become a major component of the global world-wide network infrastructure, linking millions of machines and tens of millions of users around the world. If the Internet were a stock it would be considered a market phenomenon, with sustained double-digit growth and no apparent end in sight to its upward spiral. Over 70 countries have full TCP/IP Internet connectivity, and about 150 have at least e-mail services through IP or via more limited means of connectivity (e.g., UUCP or Fidonet). Given such phenomenal growth, the Global Internet is increasingly viewed as the catalyst for a communications revolution resulting in a plethora of new technological, economic, and social changes. The focus of the special issue is on the technologies of the Internet, the technological changes driven by the emergence of a truly Global Internet, and collateral economic and social issues. Papers are solicited on the following specific subjects: * Internet Applications - information retrieval, directory services, catalogs, search tools and user agents; electronic publishing; education; www; languages; collaborative work environments. * Internet Connectivity Infrastructure - service characteristics ("best effort" vs. guaranteed); reliability (utility); addressing; multicasting; routing; protocols. * Internet Administrative Infrastructure - regulation; public policy; economics; standards. * Internet Security - security technology; export controls; privacy. * Internet Management - protocols; agent technology; standards; platforms. * Internet Commerce - electronic banking; virtual retailing; payment systems. Submitted manuscripts must be no longer than 12 single-spaced pages. The cover page should include the title of the paper, a brief abstract, a list of keywords, and the full name, affiliation, postal address, telephone number, and electronic mail address of each author. Papers may be submitted in postscript format via e-mail or as hardcopy (six copies). Authors should obtain company and government clearances prior to submission of papers. Papers should be submitted by October 31, 1996 to either of the guest co-editors. All papers will go through a peer-review process. They will be judged with respect to their quality and relevance to the Special Issue and the IEEE Communications Magazine. Authors will be notified of acceptance or rejection by December 15, 1996. Final copies of accepted papers will be due by January 31, 1997. Publication is scheduled for May 1997. Please submit manuscripts by October 31 to either: Branislav Meandzija - OR- Lyman Chapin Meta Communications, Inc. BBN CORPORATION 322 North Cleveland Ave., Suite 100 10 Moulton Street Oceanside, CA 92054 USA Cambridge, MA 02138 USA Phone: +1 619 721 6033 Phone: +1 617 873 3133 Fax: +1 619 456 7472 Fax: +1 617 873 3243 e-mail: bran@metacomm.com e-mail: lyman@bbn.com   Delivery-Date: Tue, 17 Sep 1996 05:29:36 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA24133 for X-agentx; Tue, 17 Sep 1996 05:29:35 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id FAA24130 for ; Tue, 17 Sep 1996 05:29:34 -0700 (PDT) Message-Id: <199609171229.FAA24130@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3174; Tue, 17 Sep 96 08:29:58 EDT Date: Tue, 17 Sep 96 14:29:10 DST From: "Bert Wijnen" To: agentx@fv.com Subject: more comments/questions on draft version 00.04 Sorry for a long e-mail, but since it is more review of the draft document I figured it might be handier to post it all in one go. More comments/questions on agentX draft version 00.04 I am not repeating all my earlier comments on version 00.04, because it is my understanding that those comments were not at all considered yet when this version 00.04 draft was created. So I assume they are still on the table. 1.Page 10, explains n_subid as follows: n_subid - The number (0-128) of sub-ids in the object identifier. An ordered list of `n_subid' 4-byte sub-ids follows the 4-byte header. A value of 0 indicates a null object identifier. Now?? what is this "null object identifier" supposed to mean? I am not sure such a thing exists at all. 2.Page 14, explains h.length as follows h.length - The size in octets of the entire PDU, including the header. So I think I understand that it also includes the h.length field itself, right? If so, then may I ask to state that explicitly. The reason I ask is so that it becomes very clear to DPI users. In DPI, the initial 2 octets specify the length of the data following those 2 bytes. It is kind of handy, because it allows me to do: read 2 octets read as many octets as indicated by the length field. Of course I can still calculate that by subtracting 2 bytes. 3.Page 16 descrobes 0.timeout: o.timeout - The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a subagent-wide default value that may be overridden by values associated with specific registered MIB regions. The default value of 0 indicates no subagent-wide value is requested. So a default of zero means "no subagent-wide" value. But what value will be used in this case? I'd add this "In this case a master-agent defined value will be used instead". 4.Page 17 specifies c.reason as follows: c.reason - An implementation-specific reason code. No values are specified by this memo. If we do not define any reasons right now, then I suggest we make it a field. Just defining fields for "implementation-specific" use seems useless to me. But I do believe we better specify some reasons. From the DPI RFC1592 I can suggest a list of candidate reasons: +-----------------------------------------------------------------+ : Table 21. Valid CLOSE reason codes : +-------+---------------------------------------------------------+ : VALUE : REASON CODE : +-------+---------------------------------------------------------+ : 1 : SNMP_CLOSE_otherReason : +-------+---------------------------------------------------------+ : 2 : SNMP_CLOSE_goingDown : +-------+---------------------------------------------------------+ : 3 : SNMP_CLOSE_unsupportedVersion : +-------+---------------------------------------------------------+ : 4 : SNMP_CLOSE_protocolError : +-------+---------------------------------------------------------+ : 5 : SNMP_CLOSE_authenticationFailure : +-------+---------------------------------------------------------+ : 6 : SNMP_CLOSE_byManager : +-------+---------------------------------------------------------+ : 7 : SNMP_CLOSE_timeout : +-------+---------------------------------------------------------+ : 8 : SNMP_CLOSE_openError : +-------+---------------------------------------------------------+ Some of thise are used by the master agent when sending a CLOSE to a sub, some are used by the sub whensending a CLOSE to the master. Codes like: protocolError, unsupportedVersion, timeout and such would not occur base on the current document where it states at a few places that an incoming agentX packet is ignored without sending a response about the error to the sub. I have already stated that we should always send a response or a close so that the sub finds out as quickly as possible what is going on. 5.Page 18 explains r.priority Do we all know what a "higher priority" is ?? I have found many times that this causes confusion. The term "better priority" is easier understood (at least that is what I found), but still it causes confusion once in a while. Also the term "higher number" is not understood the same by everyone, especially not if we talk about priority. At the Olympics, 1 is a higher number than 2. But in math, 2 is a higher number than 1 is it not? I suggest we add explicitly something like this: "So priority 1 is better than priority 2 and so on." or "So pritority 1 registrations are served before priority 2 registrations and so on." 6.Page 20 explains u.reason as follows: - u.reason is a placeholder for implementation-specific data; no values are specified by this memo. Same comment as I made for c.reason. Specify a list of reasons, or make the field . "Implementation-specific data" does not foster interoperability. May I suggest a list of candiate reasons as defined in the DPI RFC1592 +-----------------------------------------------------------------+ : Table 20. Valid UNREGISTER reason codes : +-------+---------------------------------------------------------+ : VALUE : REASON CODE : +-------+---------------------------------------------------------+ : 1 : SNMP_UNREGISTER_otherReason : +-------+---------------------------------------------------------+ : 2 : SNMP_UNREGISTER_goingDown : +-------+---------------------------------------------------------+ : 3 : SNMP_UNREGISTER_justUnregister : +-------+---------------------------------------------------------+ : 4 : SNMP_UNREGISTER_newRegistration : +-------+---------------------------------------------------------+ : 5 : SNMP_UNREGISTER_higherPriorityRegistered : +-------+---------------------------------------------------------+ : 6 : SNMP_UNREGISTER_byManager : +-------+---------------------------------------------------------+ : 7 : SNMP_UNREGISTER_timeout : +-------+---------------------------------------------------------+ 7.Section 7.1 states at various places that a warmStart trap is issued. I wonder though if we can claim that "the configuration is unaltered" as is required for a warmStart as defined in RFC1157 and RFC1907. For example if we add an entry to the sysORTable, then I think our config changed, because we now have more capabilities. Also, if a sub adds a registration for an interface in ifTable, then I think that that is a change in the configuration, no? And some text in our draft (page 32) even explicitly states that we issue a wamr start to reflect a "change in configuration": sysORTable is updated to reflect the change in configuration, and a warmStart trap is issued. According to RFC1157/RFC1907 that MUST be a coldStart trap. But, the definition in RFC1157 or RFC1907 is not eplicit in what a "changed configuration" means. 8.Page 24, Commit,Undo,Cleanup PDUs I see that these do NOT include a varBindList, where as the Test PDU does include the varBindList. This is a complete deviation from DPI where the varBindList was passed on all these PDUs. Our reasoning was that that the master must retain the varBindList anyway in order to do a proper response in error situations. So we would give the sub the flexibility to keep the varBindList in between Test-Commit or Test-Undo or to just set some switches/flags and use the varBindList in the final Commit/Undo. Certainly for many of the simpler subs, this is a fine approach. In fact I found I can keep my subs (and the API) simpler that way. So what is the reasoning for not passing the varBinds? 9.Page 29 point 5 (at bottom) says: 5) Otherwise, an agentx-Response-PDU is returned with res.error set to `noError', and a 4-byte TimeTicks value following the header. The latter is the current value of sysUpTime.0 for either a specified non-default context (if the registration message so indicated), or for the default context. I have already brought up the problem that putting the agnet-caps in the proper sysORTable is problematic (in fact broken in current draft). Here is another example where it is unclear as to which sysUpTime must be returned if CTX_ALL flag is set. I am starting to think that CTX_ALL flag should be abolished. 10.On page 31 I read (in the middle): NOTE: This case may cause serious performance penalties during operational dispatching. The REG_UNION bit should be clear for all but the most unwieldy subagent configurations. ===================== It is almost always possible to use the indexing structure of conceptual tables to provide unique registrations among subagents sharing the implementation of such tables, and that is the preferred configuration. I am happy that at least the unionized registration is optional. But if we all agree (and I do) that it is only required by the MOST UNWIELDY subagent configuration, then why the hell do we want to include this in a standard. My proposal: abolish unionized registrations. 11.Page 37 Section 7.2.1.4, 2nd para states: An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'noSuchObject'. This is really strange, because a response to s SET request will NEVER have a value of noSuchObject in it's varBinds. In fact, I think that the RESPONSE to a SET must ALWAYS have exactly the same varBindList as received in the SET PDU, except for a case of tooBig error. So I would replace this para with: An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU. We must then also change: (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`noSuchObject'). Into: (2) If no such OID range exists the variable binding is not processed further. 12.Page 38, section 7.2.1.5 - timeout calculation. I totally disagree with this. In DPI I do this: - if a value was specified at registration-pdu, then use that value - else if a value was specified at open-pdu then use that value - otherwise use the master agent default value. The reason is that if a sub tells you that it wants a specific timeout whihc possibly is less than the default, then why would you wait any longer.... A master agent default value is porbably on the safe side and so probably higher than optimal for some subagents. I understand that in DPI I dispatch at for every registration, while agentX dispatches once per sub, even if there are multiple registrations for this subagent. So you need to find the max of all registrations (if any) and use that one as a first choice. 13.Page 41, Section 7.2.3.1 Do I understand correctly that a response to the TEST pdu does NOT include a varBindList? I hope the answer is yes (there is no need to return any data). I would like to see that stated explicitly though. Or do you think it is clear enough from section 7.2.3 14.Page 43, Section 7.2.4.1 states: 1) If any subagent did not respond within its allotted time period, this is treated as if the subagent had returned `genError' and processed as described below. The DPI also CLOSEs the connection in this case. Was this explicitly omitted here? My reasoning is that the sub is probaly in trouble, and so you do not want to wait for a (long) timeout for subsequent SNMP PDUs. In fact if you do not close, you could end-up in a genErr loop for GETNEXT/GETBULK requests (that is, a manager keeps sending and you keep returning genErr). By CLOSing the connection, you eliminate the possible genErr for the next request. 15.Sections 7.2.4.2 and 7.2.4.3. I did not find it obvious (at first sight) that from steps 1a one skips step 1b and goes to step 2. Anyone else who had this same perception? Probablt it is more obvious if you would move the 1a) and 1b) labels to the previous sentence, so you would get: 1a) If any SearchRange was dispatched to multiple subagents: Any response whose .... 1b) Alternately, if no SearchRange was dispatched to multiple subagents: For any received agentx-Response-PDU, .... 16.Page 47, Section 7.2.5 first sentence reads: Once the processing described in sections 7.2.1 - 7.2.3 is ====== I think this should be: 7.2.4 17.Page 47, Section 7.2.5. Every SNMP implementer of course knows. Yet I propose we add something like: If any error (except tooBig) is returned in the SNMP response, then the original varBindList of the SNMP request must be returned in the response. 18.Page 50-51, Section 11.1 item 3. Besides some more code and also more complex code at the master agent, the multiple-varBind requirement also requires more copying of data I think. In DPI, I am allowed to send the varBinds either in one or in multiple PDUs. When I have decoded the varBinds I often send subsequent varBinds that go to the same sub in one PDU. So if the SNMP PDU requests an opration on varBinds a1,a2,b3,a4 (where 1-4 are the 4 varBinds and a and b represent the subs that implement them, then I send a1,a1 in one PDU, then b3 in another pdu and then a4 in yet another pdu. So I do not need to allocate a new buffer and merge a1,a2,a4 into sequence before sending. 19.Complexity. Places where I see complexity as compared to for example DPI. Maybe it is OK, but I do want to list it because I expressed my concern about complexity.I am not addressing unionized registrations, because I feel they should be abolished in our document. I am also not addressing multiple contexts, because that is stated to be optional. 1.Must merge varBinds out of sequence into one PDU. (as described in 18 above). 2.Must handle overlapping registrations. I am not sure we really need this either... that is: do we need it in at least 25% of the master-sub environments? 3.The "Elements of procedure" (possibly as a result of the above 2 points) is setup such that you send out multiple requests and then await multiple responses, which you have to merge back into a single response. Not only that, if you get endOfMibView situations it is going to be quite complicated to re-issue GETNEXTs (let alobe GETBULKs) to other subagents to try and find a proper response. In DPI this is all quite straight forward since you handle one (set of) varBinds which all map one to one onto the sequence in the varBindList in the original request. Now you will have to keep track that varBind number 3 in a agentX response is actually varBind number 6 in the original request and so on. 4.GETBULK support seems mandatory. At the sub this is fine. At the master this can become quite complex if some varBinds in the middle return endOfMibView (like for empty cells in a table). 5.The fact that a sub also returns variables on GETNEXT/GETBULK regardless of registrations, makes the handling at the agent side more complex. Maybe people do/did not realize. But most of the things that DPI allows are now mandatory. In DPI you are allowed to send all varBinds for the same subagent in one single PDU... but you do not have to do that. The subs (can) work correctly in both cases. In DPI you can support GETBULK but you do not need to. The subs will work correctly in both cases. So with the DPI approach, if you want/need to provide HIGH PERFORMANCE, then use/buy a more complex (and so probably more expensive) agent that does that. Otherwise use a cheap and more simpler agent. With the current agentX approach I see that we will have just a choice out of (more) expensive agents, that is assuming the protocol will indeed be implemented widely and correctly. 20.Design Goals (Page 7, section 3.2). I wonder if the "primary" goal is indeed to minimize latency. I would think that the primary goal is to ensure an interoperable extensible agent environment in which insrumentation from multiple vendors can (as easily as possible) be integrated into one managed system (agent). Of course we should keep in mind that we want as good a performance as possible within the constraints of the promary goal. If performance is really the PRIMARY issue, then often standards do not really jump out as the best solution. That is one of the reasons why I have stated repeatedly that the agentX protocol may not really be applicable to routers and such. By the way, if the PERFORMANCE is indeed a primary concern, then that would suggest that we DO pass view information to the sub, so that it does not return any varBinds that might turn out to be not-in-view. As you all know, I am very much against that too and I am happy to see we do NOT pass this to the sub. 21.agentX error codes. Throughout the document I see that we re-use SNMP error codes to indicate errors in the agentX protocol/operations. I think that that is incorrect. We should use our own agentX-specific error codes for our agentX protocol. Otherwise things just get confusing. Bert   Delivery-Date: Tue, 17 Sep 1996 05:29:56 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA24146 for X-agentx; Tue, 17 Sep 1996 05:29:55 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id FAA24143 for ; Tue, 17 Sep 1996 05:29:54 -0700 (PDT) Message-Id: <199609171229.FAA24143@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3187; Tue, 17 Sep 96 08:30:22 EDT Date: Tue, 17 Sep 96 14:29:44 DST From: "Bert Wijnen" To: agentx@fv.com Subject: Index Reservation Section 7.1.2 on Pages 16-28 describe the processing of the PDU by the master agent. Let me see if I understand it correctly: - There is no provision for multiple index fields, right? If so we should state that explicitly. If the support is there, then I do not udnerstand how it works, pls explain in that case (I guess we then also need additional text in the document, unless I am the only one who does not understand it). Examples of these are EtherHistoryEntry (RFC1271), ipNetToMediaEntry (RFC1213) - I think I have always seen that a NIC card always uses the same ifIndex in the ifTable. I understand that such is no longer required, but it is also not forbidden, is it? The elements of procedure seem to make this impossible though, because "there is no provision for unreserving an index". Is this really what we want? If yes, then this would mean that everytime your sub (that implements ifEntry for say your ethernet-card) restarts, you get a new ifIndex. When thinking about index reservation in the past, I played with this idea: when you get a positive response on a reservation request, you also get back a cooki that you can use next time to try and re-reserve the same index. Maybe you could use the reserved index as the cooki. So first time you reserve without an index, 2nd time you try to re-reserve with same index. But.... there is no way you know it is you who reserved this index the first time (master may have restarted too)?? Bert   Delivery-Date: Tue, 17 Sep 1996 07:53:06 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA05825 for X-agentx; Tue, 17 Sep 1996 07:53:06 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA05819 for ; Tue, 17 Sep 1996 07:53:02 -0700 (PDT) Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA23632; Tue, 17 Sep 1996 10:48:15 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA17553; Tue, 17 Sep 1996 10:48:15 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA10837; Tue, 17 Sep 1996 10:51:36 -0400 Message-Id: <9609171451.AA10837@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Index Reservation Date: Tue, 17 Sep 96 10:51:35 -0400 From: Mike Daniele X-Mts: smtp Hi Bert, >Section 7.1.2 on Pages 16-28 describe the processing of the PDU by >the master agent. Let me see if I understand it correctly: > - There is no provision for multiple index fields, right? > If so we should state that explicitly. > If the support is there, then I do not udnerstand how it works, > pls explain in that case (I guess we then also need additional > text in the document, unless I am the only one who does not > understand it). > Examples of these are > EtherHistoryEntry (RFC1271), > ipNetToMediaEntry (RFC1213) If each of the multiple index objects is an arbitrary number, and the subagent needs to reserve values for both of them, then it would reserve a value for each index object (using 2 VarBinds). The master agent wouldn't know that the 2 objects are related and used in the same INDEX clause. But in general, I *think* a subagent would need to reserve values only for the first index of multiply indexed tables (assuming subsequent registration using that reserved index value). For instance, if I reserve ifIndex 6, and register ifEntry.[a-b].6 and ipNetToMediaEntry.[c-d].6, I don't need to reserve index values for ipNetToMediaNetAddress (the other index) because I 'own' the MIB region that contains those values anyway. The net to media table raises another interesting point, that subagents need to understand the semantics of these objects and "do the right thing". In this case, I would think that subagents would rendezvous on (register values of) ifIndex, not ipNetToMediaIfIndex. > - I think I have always seen that a NIC card always uses the same > ifIndex in the ifTable. I understand that such is no longer > required, but it is also not forbidden, is it? > The elements of procedure seem to make this impossible though, > because "there is no provision for unreserving an index". > Is this really what we want? Our thinking was that the safest and easiest approach would be for index reservations to be permanent until the master agent reboots. > If yes, then this would mean that everytime your sub (that implements > ifEntry for say your ethernet-card) restarts, you get a new ifIndex. I hope there are solutions to this that don't require AgentX specification. For instance, a subagent could remember what index values it has reserved and registered (not necessarily the same) across restarts, and re-register the same regions. A subagent that "always registers interface 2" could be configured to start first so it registers successfully before the others try to reserve ifIndex values. The master might support a config file of indexes and values that are "pre-reserved", etc. > Maybe you could use the reserved index as the cooki. So first time > you reserve without an index, 2nd time you try to re-reserve with > this index ... Yup, you can request to reserve a specific value, or get the next available value. Thanks for the review, looking for further comments... Mike   Delivery-Date: Wed, 18 Sep 1996 12:57:30 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA05574 for X-agentx; Wed, 18 Sep 1996 12:57:30 -0700 (PDT) Received: from card.com (card.com [206.97.242.10]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA05569 for ; Wed, 18 Sep 1996 12:57:24 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by card.com (8.7.4/8.7.3) with SMTP id OAA29659 for ; Wed, 18 Sep 1996 14:57:31 -0500 (CDT) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA15188; Wed, 18 Sep 96 15:55:05 -0400 Date: Wed, 18 Sep 96 15:55:05 -0400 From: David Battle Message-Id: <9609181955.AA15188@seymour16.snmp.com> To: agentx@fv.com Subject: transport mappings I note that in the unix domain socket transport mappings that both the master agent and subagent are supposed to create an endpoint. This is unnecessary because when the subagents connect to the endpoint created by the master agent a 2-way communication path is established. -David   Delivery-Date: Thu, 19 Sep 1996 07:08:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA06725 for X-agentx; Thu, 19 Sep 1996 07:08:40 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by fv.com (8.7.4/8.7.3) with SMTP id HAA06722 for ; Thu, 19 Sep 1996 07:08:39 -0700 (PDT) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA20616; Thu, 19 Sep 96 10:08:47 -0400 Date: Thu, 19 Sep 96 10:08:47 -0400 From: David Battle Message-Id: <9609191408.AA20616@seymour16.snmp.com> To: agentx@fv.com Subject: sample impelmentation Does anyone have a sample implementation of an agentx subagent which they would be willing to share with me for interoperability testing purposes? Thanks, -David battle@snmp.com   Delivery-Date: Sun, 22 Sep 1996 14:28:36 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA14148 for X-agentx; Sun, 22 Sep 1996 14:28:35 -0700 (PDT) Received: from mail.dialogic.com (mail.dialogic.com [146.152.224.2]) by fv.com (8.7.4/8.7.3) with SMTP id OAA14137 for ; Sun, 22 Sep 1996 14:28:26 -0700 (PDT) Received: from kakapo by mail.dialogic.com with smtp (Smail3.1.29.1 #1) id m0v4w4m-000IfxC; Sun, 22 Sep 96 17:28 EDT Received: from ruru by kakapo with smtp (Smail3.1.28.1 #1) id m0v5IZR-0001ayC; Mon, 23 Sep 96 09:29 NZT Message-Id: <2.2.32.19960922192717.002d1994@kakapo> X-Sender: umesh@kakapo X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 09:27:17 +1400 To: agentx@fv.com From: Umesh C Solanki Subject: AgentX Implementations I understand that AgentX is undergoing revisions within the working group. But are there any implementations of AgentX based on the draft specifications? Thanks - Umesh ========================================================================= Internet: u.solanki@nz.dialogic.com D I A L Company: Dialogic (N.Z.) Ltd _| _| _| O Mail: P O Box 548, _| _| _| G Auckland, NEW ZEALAND. _| _| _| I Voice: +(649) 366 1135 x814 _| _| _| C URL: http://www.dialogic.com   Delivery-Date: Tue, 24 Sep 1996 10:42:40 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA06118 for X-agentx; Tue, 24 Sep 1996 10:42:40 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id KAA06114 for ; Tue, 24 Sep 1996 10:42:39 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id NAA13335; Tue, 24 Sep 1996 13:36:02 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA24927; Tue, 24 Sep 1996 13:32:40 -0400 Date: Tue, 24 Sep 1996 13:35:12 EDT From: Bob Natale Subject: AgentX coverage at EMANATE Interop meeting? To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, As fate would have, I was unable to be at Interop for the EMANATE Users Meeting to record any AgentX notes...and none of the four or five active AgentX participants that I checked with could be there either. So, if anyone who was there would care to post whatever summary he or she can muster, that would be greatly appreciated. Contemporaneously, I will be working with Mike, Maria, and Dale (among others) over the next week or so to see if we can put out one more revision of the draft, incorporating the recent feedback on revs 3 and 4 and, I hope, integrating the index reservation elements contributed by SNMP Research. Our collective goal will be (has to be) to make the next draft the basis for early implementations and early interop testing in time for reports at the Dec IETF. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------