Delivery-Date: Mon, 03 Jun 1996 03:46:02 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA04761 for X-agentx-local; Mon, 3 Jun 1996 03:46:02 -0700 (PDT) Received: from relay2.eunet.fr (relay2.EUnet.fr [192.134.192.149]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id DAA04721 for ; Mon, 3 Jun 1996 03:45:58 -0700 (PDT) Received: from orly363.airfrance.fr by relay2.eunet.fr (5.65c8d/96.05.03) via EUnet-France id AA20488; Mon, 3 Jun 1996 12:45:16 +0200 (MET) Received: by orly363.airfrance.fr (5.x/SMI-SVR4) id AA11086; Mon, 3 Jun 1996 12:46:25 +0200 Date: Mon, 3 Jun 1996 12:46:25 +0200 From: kdjoneidi@orly363.airfrance.fr (Air France - Kamyar Djoneidi) Message-Id: <9606031046.AA11086@orly363.airfrance.fr> To: agentx@fv.com Subject: About sub agents X-Sun-Charset: US-ASCII Hello ! I would like to know if it is possible to have one agent and his subagents on the same node. It seems that that Oracle has an Smux agent. Can I have one sub agent for each application and one master agent for the Server ? All that on the same station ? Thank you in advence, Kamyar   Delivery-Date: Mon, 03 Jun 1996 07:00:32 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id HAA13598 for X-agentx-local; Mon, 3 Jun 1996 07:00:31 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id HAA13586 for ; Mon, 3 Jun 1996 07:00:30 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id KAA14087; Mon, 3 Jun 1996 10:00:28 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03597; Mon, 3 Jun 1996 09:59:10 -0400 Date: Mon, 3 Jun 1996 10:03:54 EDT From: Bob Natale Subject: Re: About sub agents To: Air France - Kamyar Djoneidi Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Air France - Kamyar Djoneidi > Date: Mon, 3 Jun 1996 12:46:25 +0200 Hi Kamyar, > I would like to know if it is possible to have one agent and > his subagents on the same node. Yes, assuming that the "one agent" you are referring to is the "master agent" to the "subagents", then that would be the typical way an extensible agent is configured. The work underway in the AgentX working group will likely result in a design which will allow implementations to have the subagents running on one or more systems possibly "remote" from the "local" machine the master agent is running on. [The initial draft of the AgentX protocol I-D--authored by Mike Daniele--is being filtered through the wg editor, Dale Francisco, at this time and should appear on the list in the very near future for wg review and discussion prior to the forthcoming Montreal IETF.] > It seems that that Oracle has an Smux agent. Can I have one sub > agent for each application and one master agent for the Server? I am fairly certain the answer is "yes", although I guess specific implementation decisions (possibly of an interim nature) could preclude it. I trust that someone from Oracle and/or BMC/Perr will respond with more details if necessary. > All that on the same station ? Yes, per above that would be the typical configuration. > Thank you in advence, Thanks for asking...we need to rev up the activity on this list anyway...we have some concrete deliverables to make leading up and and as a result of the Montreal IETF. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 04 Jun 1996 08:25:11 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA01285 for X-agentx-local; Tue, 4 Jun 1996 08:25:10 -0700 (PDT) Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA01270 for ; Tue, 4 Jun 1996 08:25:07 -0700 (PDT) Received: from alterdial.UU.NET by relay1.UU.NET with ESMTP (peer crosschecked as: alterdial.UU.NET [192.48.96.22]) id QQasqv11680; Tue, 4 Jun 1996 11:24:40 -0400 (EDT) Received: from ppp09147 by alterdial.UU.NET with SMTP (peer crosschecked as: pool044.Max3.Chicago.IL.DYNIP.ALTER.NET [153.37.180.44]) id QQasqv22035; Tue, 4 Jun 1996 11:23:32 -0400 (EDT) Date: Tue, 4 Jun 1996 11:23:32 -0400 (EDT) Message-Id: X-Sender: mail09794@alterdial.uu.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: Keith Thomas Subject: subscribe subscribe   Delivery-Date: Mon, 10 Jun 1996 05:15:38 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA18120 for X-agentx-local; Mon, 10 Jun 1996 05:15:38 -0700 (PDT) Received: from master.einev.ch (master.einev.ch [145.232.174.34]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id FAA18051 for ; Mon, 10 Jun 1996 05:15:22 -0700 (PDT) Message-Id: <199606101215.FAA18051@zloty.fv.com> Received: by master.einev.ch ($Revision: 1.37.109.26 $/16.2) id AA038938911; Mon, 10 Jun 1996 14:15:12 +0200 From: bruttin pascal Subject: subscribe To: agentx@fv.com Date: Mon, 10 Jun 96 14:15:10 METDST Mailer: Elm [revision: 70.85.1.76] subscribe   Delivery-Date: Mon, 10 Jun 1996 09:14:18 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA10671 for X-agentx-local; Mon, 10 Jun 1996 09:14:17 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA10656 for ; Mon, 10 Jun 1996 09:14:12 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26071; Mon, 10 Jun 96 09:14:06 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA03459; Mon, 10 Jun 96 09:14:05 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06839; Mon, 10 Jun 96 09:14:05 PDT Date: Mon, 10 Jun 96 09:14:05 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101614.AA06839@santa.strata.com> To: agentx@fv.com Subject: Editor's note on initial version of AgentX draft I am posting in 5 following mail messages the initial version of a proposed AgentX Protocol internet draft. The author of the initial version is Mike Daniele. It has benefited so far from the pre-release comments of Bert Wijnen, whose work along with several others on DPI 2.0 formed a starting point for AgentX protocol discusssions. This document has also benefited (or not) from an initial edit by me. There are still several areas in this document that remain to be filled in: Index reservation Sets (row creation) Transport mappings AgentX Open-, Close-, Trap-PDUs ASN.1 representation of PDUs Please post to the list all comments and suggestions for additions, deletions, and modifications to this document. The deadline for our submission to the IETF repository in order to be available for the Montreal IETF meeting is June 13. Thanks, Dale Francisco AgentX WG Editor dfrancisco@strata.com voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Mon, 10 Jun 1996 09:14:31 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA10715 for X-agentx-local; Mon, 10 Jun 1996 09:14:31 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA10712 for ; Mon, 10 Jun 1996 09:14:29 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26074; Mon, 10 Jun 96 09:14:30 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA03465; Mon, 10 Jun 96 09:14:29 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06842; Mon, 10 Jun 96 09:14:28 PDT Date: Mon, 10 Jun 96 09:14:28 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101614.AA06842@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (1 of 5) 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). Table of Contents 1. Introduction 2. The SNMP framework 2.1 A Note on Terminology 3. Extending the MIB 3.1 Motivation For AgentX 4. The AgentX Framework 4.1 AgentX Roles 5. AgentX Encodings 5.1 Character Set Selection 5.2 Value Representation 6. Protocol Definitions 6.1 Common Constructs 6.1.1 RegionSpecifier 6.1.2 NamingScope 6.1.3 SearchRange 6.1.4 AgentX PDU Header 6.2 AgentX PDUs 7. Elements of Procedure 7.1 AgentX Administrative PDUs 7.1.1 The Open-PDU 7.1.2 The Register-PDU 7.1.2.1 Register-PDU Fields 7.1.2.2 Processing the Register-PDU 7.1.2.2.1 The AddRegion Procedure 7.1.2.2.2 Handling Duplicate Regions 7.1.3 The Unregister-PDU 7.1.3.1 Unregister-PDU Fields 7.1.3.2 Processing the Unregister-PDU 7.1.4 The Close-PDU 7.2 Processing Received SNMP Protocol Messages 7.2.1 Dispatching AgentX PDUs 7.2.1.1 GetRequest-PDU 7.2.1.2 GetNextRequest-PDU 7.2.1.3 GetBulkRequest-PDU 7.2.2 Subagent Processing of AgentX PDUs 7.2.2.1 Subagent Processing of the AgentX Get-PDU 7.2.2.2 Subagent Processing of the AgentX GetNext-PDU 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU 7.2.3 Master Agent Processing AgentX Responses 7.2.4 Sending the SNMP Response PDU 8. Master Agent Transport Mappings 9. Security Considerations 10. Acknowledgements 11. References 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 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. 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. 4. AgentX Framework A managed node contains a processing entity, called an agent, which has access to management information. Within the AgentX framework, an agent consists of both - a single processing entity called the master agent, which sends 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 access to management information. - 0 or more processing entities called subagents, which do not send or receive SNMP protocol messages, but which have access to management information. The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. While some of these protocol messages appear similar in syntax and semantics to the SNMP, it is important to remember that AgentX subagents are not themselves SNMP protocol entities. 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. An entity acting in a subagent role performs the following functions: - 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 traps.   Delivery-Date: Mon, 10 Jun 1996 09:15:40 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA10961 for X-agentx-local; Mon, 10 Jun 1996 09:15:39 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA10956 for ; Mon, 10 Jun 1996 09:15:38 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26083; Mon, 10 Jun 96 09:15:39 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA03494; Mon, 10 Jun 96 09:15:38 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06847; Mon, 10 Jun 96 09:15:37 PDT Date: Mon, 10 Jun 96 09:15:37 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101615.AA06847@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (2 of 5) 5. AgentX Encodings AgentX PDUs consist of a common, fixed-format header; an optional PDU-specific subheader; and optional, possibly variable-length data. The PDUs are not encoded using the BER [1], but are represented as a simple byte stream. Within the header and subheaders, numeric data is always encoded most significant byte (MSB) first. The length of this data is not transmitted explicitly since it is known by the packet format. Variable-length data within the subheaders is transmitted as null-terminated strings. The length of this data is not transmitted explicitly since it may be determined by the string's length. Object identifiers are represented within the subheaders as null-terminated, ASN.1 dotted notation strings. 5.1. Character Set Selection Strings are represented in the native character set of the system on which the subagent resides. If this is not ASCII, the master agent must perform any required conversions. 5.2. Value Representation Variable bindings may be transmitted within the variable-length portion of some PDUs. This representation (called a VarBind) is as follows: VarBind +--------+------+--------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+--------------------------------------------+ | X | var | v.name (OID, null-terminated, length L) | +--------+------+--------------------------------------------+ | X+L+1 | 1 | v.type | +--------+------+--------------------------------------------+ | X+L+2 | 2 | v.length (MSB first) | +--------+------+--------------------------------------------+ | X+L+4 | var | v.data (format depends on data type) | +--------+------+--------------------------------------------+ v.type indicates the variable binding's syntax, and must be one of the following values: +-----------------------------------------------------------------+ | Table 17. Valid values for the Value Type field | +-------+---------------------------------------------------------+ | VALUE | VALUE TYPE | +-------+---------------------------------------------------------+ | 129 | SNMP_TYPE_Integer32 | +-------+---------------------------------------------------------+ | 2 | SNMP_TYPE_OCTET_STRING | +-------+---------------------------------------------------------+ | 3 | SNMP_TYPE_OBJECT_IDENTIFIER | +-------+---------------------------------------------------------+ | 4 | SNMP_TYPE_NULL (empty, no value) | +-------+---------------------------------------------------------+ | 5 | SNMP_TYPE_IpAddress | +-------+---------------------------------------------------------+ | 134 | SNMP_TYPE_Counter32 | +-------+---------------------------------------------------------+ | 135 | SNMP_TYPE_Gauge32 | +-------+---------------------------------------------------------+ | 136 | SNMP_TYPE_TimeTicks (1/100ths seconds) | +-------+---------------------------------------------------------+ | 9 | SNMP_TYPE_DisplayString | +-------+---------------------------------------------------------+ | 13 | SNMP_TYPE_Counter64 | +-------+---------------------------------------------------------+ | 14 | SNMP_TYPE_Opaque | +-------+---------------------------------------------------------+ | 15 | SNMP_TYPE_noSuchObject | +-------+---------------------------------------------------------+ | 16 | SNMP_TYPE_noSuchInstance | +-------+---------------------------------------------------------+ | 17 | SNMP_TYPE_endOfMibView | +-------+---------------------------------------------------------+ v.length is a 2-byte integer, MSB first, which indicates the number of octets of v.data. v.data is the actual value, and is encoded as follows: - 32-bit integers are 4-byte elements, MSB first. Example: '00000001'h represents 1. - 64-bit integers are 8-byte elements, MSB first. Example: '0000000100000001'h represents 4,294,967,297. - Object Identifiers are NULL terminated strings in the selected character set, representing the OID in ASN.1 dotted notation. The length includes the terminating NULL. Example ASCII: '312e332e362e312e322e312e312e312e3000'h represents "1.3.6.1.2.1.1.1.0" which is sysDescr.0. Example EBCDIC: 'f14bf34bf64bf14bf24bf14bf14bf14bf000'h represents "1.3.6.1.2.1.1.1.0" which is sysDescr.0. - DisplayStrings are in the selected character set. The length specifies the length of the string. Example ASCII: '6162630d0a'h represents "abc\r\n", no NULL. Example EBCDIC: '8182830d25'h represents "abc\r\n", no NULL. - IpAddress, NsapAddress and Opaque are implicit OCTET_STRING, so they are octets (e.g. IpAddress in network byte order). - NULL has a zero length for the value, and no value data. - noSuchObject, noSuchInstance and endOfMibView are implicit NULL and represented as such. - BIT_STRING is an OCTET_STRING of the form uubbbb...bb, where the first octet (uu) is 0x00-0x07 and indicates the number of unused bits in the last octet (bb). The bb octets represent the bit string itself, where bit zero (0) comes first and so on. VarBindList is a contiguous list of VarBinds. 6. Protocol Definitions 6.1. Common Constructs 6.1.1. RegionSpecifier A RegionSpecifier is an object identifier that may optionally contain a range in place of exactly one of its sub-identifiers. The range is represented as "[" lower-bound "-" upper-bound "]". For example, "1.2.3.[4-7].8" is a valid RegionSpecifier. 6.1.2. NamingScope [TBD] 6.1.3. SearchRange SearchRange +--------+------+----------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------+ ... +--------+------+--------------------------------------------+ | X | var | g.requested (null-terminated OID, len L) | +--------+------+--------------------------------------------+ | X+L+1 | var | g.limit (null-terminated OID) | +--------+------+--------------------------------------------+ g.requested is the name of a requested variable binding. g.limit is an optional object identifier derived by the master agent to limit the search done by a subagent. SearchRangeList is a contiguous list of SearchRanges. 6.1.4. AgentX PDU Header Header +--------+------+----------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------+ | 0 | 4 | h.length (MSB first) | +--------+------+----------------------------------------+ | 2 | 4 | h.ID (MSB first) | +--------+------+----------------------------------------+ | 8 | 1 | h.major | +--------+------+----------------------------------------+ | 9 | 1 | h.minor | +--------+------+----------------------------------------+ | 10 | 1 | h.flags | +--------+------+----------------------------------------+ | 11 | 1 | h.type | +========+======+========================================+ h.length is the size in octets of the entire PDU, including the header. (HL is the length of the header itself.) h.ID is a monotonically increasing packet id that should be kept unique by the sending entity. h.major is the protocol major version. This memo specifies a value of 0. h.minor is the protocol minor version number. This memo specifies a value of 0. h.flags is a one-octet bitmask, bit 0 first, etc. Bit definitions are Bits Contain ---- ------- 0-3 SNMP version 4 Alone 5-7 reserved h.type is the PDU type, and must be one of the following values: +-----------------------------------------------------------------+ | Table 16. Valid values for the packet type field | +-------+---------------------------------------------------------+ | VALUE | PACKET TYPE | +-------+---------------------------------------------------------+ | 1 | AGENTX_GET | +-------+---------------------------------------------------------+ | 2 | AGENTX_GETNEXT | +-------+---------------------------------------------------------+ | 3 | AGENTX_SET | +-------+---------------------------------------------------------+ | 4 | AGENTX_TRAP | +-------+---------------------------------------------------------+ | 5 | AGENTX_RESPONSE | +-------+---------------------------------------------------------+ | 6 | AGENTX_REGISTER | +-------+---------------------------------------------------------+ | 7 | AGENTX_UNREGISTER | +-------+---------------------------------------------------------+ | 8 | AGENTX_OPEN | +-------+---------------------------------------------------------+ | 9 | AGENTX_CLOSE | +-------+---------------------------------------------------------+ | 10 | AGENTX_COMMIT | +-------+---------------------------------------------------------+ | 11 | AGENTX_UNDO | +-------+---------------------------------------------------------+ | 12 | AGENTX_GETBULK | +-------+---------------------------------------------------------+ | 13 | AGENTX_TRAPV2 (not yet used) | +-------+---------------------------------------------------------+ | 14 | AGENTX_INFORM (not yet used) | +-------+---------------------------------------------------------+ | 15 | AGENTX_ARE_YOU_THERE | +-------+---------------------------------------------------------+   Delivery-Date: Mon, 10 Jun 1996 09:18:58 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA11635 for X-agentx-local; Mon, 10 Jun 1996 09:18:57 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA11628 for ; Mon, 10 Jun 1996 09:18:55 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26127; Mon, 10 Jun 96 09:18:55 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA03798; Mon, 10 Jun 96 09:18:54 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06867; Mon, 10 Jun 96 09:18:53 PDT Date: Mon, 10 Jun 96 09:18:53 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101618.AA06867@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (3 of 5) 6.2. AgentX PDUs Register-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 2 | r.priority (MSB first) | +--------+------+----------------------------------------------+ | HL+2 | 2 | r.timeout (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | var | r.region (RegionSpecifier, length L) | +--------+------+----------------------------------------------+ |HL+4+L+1| var | r.context (NamingScope) | +--------+------+----------------------------------------------+ Unregister-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 1 | u.reason code | +--------+------+----------------------------------------------+ | HL+1 | var | u.region (RegionSpecifier, length L) | +--------+------+----------------------------------------------+ |HL+1+L+1| var | u.context (NamingScope) | +--------+------+----------------------------------------------+ Get-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | var | g.context (NamingScope, length L) | +--------+------+----------------------------------------------+ | HL+L+1 | var | SearchRangeList | +--------+------+----------------------------------------------+ GetNext-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | var | g.context (NamingScope, length L) | +--------+------+----------------------------------------------+ | HL+L+1 | var | SearchRangeList | +--------+------+----------------------------------------------+ GetBulk-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 4 | g.non_repeaters (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | 4 | g.max_repetitions (MSB first) | +--------+------+----------------------------------------------+ | HL+8 | var | g.context (NamingScope, length L) | +--------+------+----------------------------------------------+ |HL+8+L+1| var | SearchRangeList | +--------+------+----------------------------------------------+ Response-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 4 | res.error_code (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | 4 | res.error_index (MSB first) | +--------+------+----------------------------------------------+ | HL+8 | var | VarBindList | +--------+------+----------------------------------------------+ 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: processing AgentX administrative messages (e.g, connection requests from a subagent to a master agent); and processing SNMP messages (e.g., the coordinated actions of a master agent and one or more subagents in processing a received SNMP GetRequest-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 connection between a subagent and a master agent, and those by which a subagent communicates to a master agent which MIB subtrees it supports. 7.1.1. The Open-PDU [TBD] 7.1.2. The Register-PDU A Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within a specific context) that it wishes to support. 7.1.2.1. Register-PDU Fields A Register-PDU contains the following fields: - r.region 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 perform management operations only on particular rows of a conceptual table. Note that the RegionSpecifier syntax (see 6.1.1) permits registering a conceptual row in a single operation. For instance, "1.3.6.1.2.1.2.2.1.[1-22].7" would register row 7 of the RFC 1573 ifTable. - r.context is used by the subagent when identically named objects require a context to differentiate them. A null string indicates the default context. - r.priority is used by cooperating subagents to achieve a desired configuration when registering identical regions. The default value is 0 (no priority indicated). Higher numbers indicate higher priority. - r.timeout is the length of time, in centiseconds, 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). 7.1.2.2. Processing the Register-PDU When the master agent receives a Register-PDU, it processes it as follows: If an Open-PDU has not been received and successfully processed for this subagent, ignore the message [or send back error?]. Otherwise, the master agent adds this region to its registered OID space for that context, to be considered during the dispatching phase for subsequently received SNMP protocol messages. 7.1.2.2.1. The AddRegion Procedure In this region addition phase, RegionSpecifiers that contain subid ranges are processed as if the master agent had received multiple registrations, each containing no subid ranges. (For instance, "1.2.3.[4-6].7" is processed as if the master had received registrations whose RegionSpecifiers where "1.2.3.4.7", "1.2.3.5.7", and "1.2.3.6.7".) 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 regions (the registered OID space). Note: Though newly-added regions 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 regions (R1a, R1b, R1c) such that R1b is an exact duplicate of R2. Add R1b and R2 into the lexicographically ordered set of regions. Apply the AddRegion operation 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 regions 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 registered region with the information contained in its original Register-PDU. 7.1.2.2.2. Handling Duplicate Regions As a result of this registration algorithm there are likely to be duplicate regions (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 region, the determination of which one to use proceeds as follows: 1) Choose the one whose original Register-PDU r.region contained the most subids, i.e., the most specific r.region. Note: A range subid is no "longer" (more specific) than a single subid. 2) If still ambiguous, choose the one whose original Register-PDU specified the highest priority. 3) If still ambiguous, choose the one whose original Register-PDU was received most recently.   Delivery-Date: Mon, 10 Jun 1996 09:22:36 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA12534 for X-agentx-local; Mon, 10 Jun 1996 09:22:36 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA12527 for ; Mon, 10 Jun 1996 09:22:34 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26197; Mon, 10 Jun 96 09:22:35 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA04095; Mon, 10 Jun 96 09:22:34 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06883; Mon, 10 Jun 96 09:22:33 PDT Date: Mon, 10 Jun 96 09:22:33 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101622.AA06883@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (4 of 5) 7.1.3. The Unregister-PDU The Unregister-PDU is sent by a subagent to remove a previously registered RegionSpecifier from the master agent's OID space. 7.1.3.1. Unregister-PDU Fields An Unregister-PDU contains the following fields: - u.reason - 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 used by the subagent when identically named objects require a context to differentiate them. A null string indicates the default context. 7.1.3.2. Processing the Unregister-PDU If u.region and u.context do not exactly match the values of r.region and r.context of a previously processed Register-PDU which was sent from this subagent, the request is rejected with an appropriate error response. Otherwise the master agent removes u.region from its registered OID space for u.context. If the original region had been split, all such related regions are removed. If this removal results in any contiguous regions that share a common original Register-PDU, they are agglomerated into a single region. 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) 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 effect at the managed node. In particular, the master agent implements the Elements of Procedure defined in section 4.1 of [6] that apply to receiving entities. [We can't refer to 1901, or v2u/v2* ?] If this processing 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 1 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. 7.2.1.1 GetRequest-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 region. (2) Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate the RegionSpecifier that is identical to or is the closest lexicographical predecessor to the variable binding's name. (3) If no such region exists the variable binding is not processed further. (4) Identify the target subagent, which is the one that registered the target region. (5) 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 in section 6.1.3, and the context in the Request-PDU encoded into g.context. (6) Add a SearchRange to the end of the target subagent's Get-PDU for this variable binding. (7) The variable binding's name is copied to g.requested. (8) g.limit is set to null. 7.2.1.2. GetNextRequest-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 region. (2) Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate the longest RegionSpecifier of which the variable binding's name is a subtree. If no such region exists, locate the RegionSpecifier which is the first lexicographical successor to the variable binding's name. (3) If no such region exists the variable binding is not processed further. (4) Identify the target subagent, which is the one that registered the target region. (5) 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 in section 6.1.3 and the context in the Request-PDU encoded into g.context. (6) Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. (7) The variable binding's name is copied to g.requested. (8) g.limit is set to the RegionSpecifier that is the first lexicographical successor to the target Regionspecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.limit is set to null. 7.2.1.3. GetBulkRequest-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 region and target subagent, exactly as described for the GetNextRequest-PDU (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 in section 6.1.3 and the context and max_repetitions value in the request PDU encoded into g.context and g.max_repetitions. Set g.non_repeaters to 0. (3) Add a SearchRange to the end of the target subagent's GetBulk-PDU for this variable binding, as described for the GetNext-PDU. If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. When all variable bindings have been processed, send any AgentX PDUs to their respective target subagents (at the transport endpoint used to initiate the subagent's logical connection). 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 Request PDUs When a subagent receives an AgentX Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns a response PDU. The 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_code 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 added to the response PDU as described below. If processing should fail for any reason not described below, res.error_code is set to `genError', res.error_index to the index of the failed SearchRange, the VarBindList is reset to null, and this 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 variable binding in the request is processed in order as follows: 1) g.requested is copied to v.name. 2) If the value of g.requested 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 in section 5.2. If the resulting VarBind's type is not part of the SNMPv1 SMI, and h.flags indicate this is an SNMPv1-style request, v.type is set to `noSuchObject', and v.length to 0. 3) Otherwise, if the value of g.requested 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 variable binding 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: - The variable's name is the closest lexicographical successor to g.requested. - If g.limit is not null, the variable's name lexicographically precedes g.limit. - If h.flags indicates this is an SNMPv1 request, the variable's syntax is part of the SNMPv1 SMI. 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 in section 5.2. 2) If no such variable exists, v.name is set to g.requested, v.type is set to `endOfMibView', and v.length to 0.   Delivery-Date: Mon, 10 Jun 1996 09:26:23 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA13336 for X-agentx-local; Mon, 10 Jun 1996 09:26:23 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA13325 for ; Mon, 10 Jun 1996 09:26:21 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26249; Mon, 10 Jun 96 09:26:22 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA04228; Mon, 10 Jun 96 09:26:20 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06923; Mon, 10 Jun 96 09:26:20 PDT Date: Mon, 10 Jun 96 09:26:20 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101626.AA06923@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (5 of 5) 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 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 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. - If g.limit is not null, the variable's name lexicographically precedes g.limit. - If h.flags indicates this is an SNMPv1 request, the variable's syntax is part of the SNMPv1 SMI. 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 in section 5.2. 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 one, in which case it is set the value of g.requested in the (N+s)-th SearchRange. Note that further iterative processing should stop if for any iteration i, all s values of v.type are `EndofMibView'. When the AgentX response PDU has been generated, it is sent back to the master agent's transport endpoint from which the request was sent. 7.2.3. Master Agent Processing of AgentX Responses The master agent now marshals all subagent response PDUs and builds an SNMP response PDU. To do so, the master agent must be able to determine the corresponding variable binding (or error_index value) in the SNMP Response-PDU for each received AgentX VarBind (or res.error_index value). (Note in particular that a response PDU may contain more VarBinds than are required to complete the SNMP Response-PDU.) 1) If any subagent did not respond within its allotted time period, the SNMP Response PDU's error code is set to `genError' and its error index to the index of the variable binding corresponding to the first VarBind in the request PDU that was sent to this subagent. All other subagent response PDUs received due to processing this SNMP request are ignored. Processing is complete; the SNMP response PDU is sent. 2) Otherwise, if the h.ID field of the AgentX response PDU does not match that of the request PDU sent to this subagent, the PDU is ignored. 3) Otherwise, if res.error code 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 response PDU. All other response PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response PDU is sent. 4) Otherwise, the VarBinds in the RESPONSE PDU are processed as follows: Get If v.name is not within the relevant MIB view, the VarBind is ignored. (This determination is implementation-specific.) Otherwise, the name and value of the corresponding variable binding in the SNMP Response-PDU are updated with the contents of the VarBind. GetNext If v.name is not within the relevant MIB view, the VarBind is ignored. (This determination is implementation-specific.) Otherwise, the name and value of the corresponding variable binding in the SNMP Response-PDU are updated with the contents of the VarBind. 5) After all expected response PDUs have been processed, if any variable bindings still contain the value `endOfMibView', processing must continue: - For each such variable binding, a target region is identified which is the lexicographical successor to the target region for this variable binding on the last iteration. The target subagent is the one that registered the target region. - If this is the first variable binding to be dispatched to the target subagent (during this iteration), create an AgentX GetNext-PDU for the subagent, with the header fields initialized as described in section 6.1.3 and the context in the Request-PDU encoded into g.context. - Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. The variable binding's name is copied to g.requested. g.limit is set to the RegionSpecifier that is the first lexicographical successor to the target Regionspecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.limit is set to null. - The AgentX PDUs are sent, received, and processed according to section 7.2.3. - This process continues iteratively until a complete SNMP Response-PDU has been built, or until there remain no target region lexicographical successors. GetBulk If v.name is not within the relevant MIB view, the VarBind is ignored. (This determination is implementation-specific.) Otherwise, the name and value of the corresponding variable binding in the SNMP Response-PDU are updated with the contents of the VarBind. 5) If after all expected RESPONSE PDUs have been processed, any variable bindings still contain the value `endOfMibView', processing must continue: - For each such variable binding, a target region is identified which is the lexicographical successor to the target region for this variable binding on the last iteration. The target subagent is the one that registered the target region. - If this is the first variable binding to be dispatched to the target subagent (during this iteration), create an AgentX GetBulk-PDU for the subagent, with the header fields initialized as described in section 6.1.3 and the context from the Request-PDU encoded into g.context. - Set the value of g.non_repeaters and g.max_repetitions to 0. - Add a SearchRange to the end of the target subagent's GetBulk-PDU for this variable binding. - g.requested is set to v.name of the (last repeating) VarBind that was returned for this variable binding on the previous iteration. g.limit is set to the RegionSpecifier that is the first lexicographical successor to the target Regionspecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.limit is set to null. 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. - The AgentX PDUs are sent, received, and processed according to the procedures in section 7.2.3. - This process continues iteratively until a complete SNMP response PDU has been built, or until there are no target region lexicographical successors. [Would it be a good idea to include an example of say, bulk request processing that causes this kind of rollover between subagents?] 7.2.4. 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 also involve altering the PDU contents for agents that support the SNMP version 1 framework. [Do we need to mention explicit mappings? For instance, for v2 Set error codes?] 8. Master Agent Transport Mappings [TBD] 9. Security Considerations Security issues are not discussed in this memo. 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. 11. 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 S. Waldbusser, "Structure of Management Information for Version 2 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 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.   Delivery-Date: Mon, 10 Jun 1996 12:40:04 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA29241 for X-agentx-local; Mon, 10 Jun 1996 12:40:03 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA29177 for ; Mon, 10 Jun 1996 12:39:56 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA29612; Mon, 10 Jun 96 12:39:55 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA16836; Mon, 10 Jun 96 12:39:54 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA08174; Mon, 10 Jun 96 12:39:53 PDT Date: Mon, 10 Jun 96 12:39:53 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606101939.AA08174@santa.strata.com> To: agentx@fv.com Subject: Initial version of AgentX draft (4 of 5) [repost] Since there seems to be a notable lag in the appearance of this message (4 of 5 of the initial AgentX draft) on the list, I'm reposting it. I apologize if two versions of part 4 now appear on the list; they are identical. Dale Francisco AgentX WG Editor dfrancisco@strata.com voice: (805) 961-3642 fax: (805) 961-3600 ----- Begin Included Message ----- From dxf Mon Jun 10 09:21:29 1996 To: agentx@fv.com Subject: Initial version of AgentX draft (4 of 5) Content-Length: 11540 7.1.3. The Unregister-PDU The Unregister-PDU is sent by a subagent to remove a previously registered RegionSpecifier from the master agent's OID space. 7.1.3.1. Unregister-PDU Fields An Unregister-PDU contains the following fields: - u.reason - 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 used by the subagent when identically named objects require a context to differentiate them. A null string indicates the default context. 7.1.3.2. Processing the Unregister-PDU If u.region and u.context do not exactly match the values of r.region and r.context of a previously processed Register-PDU which was sent from this subagent, the request is rejected with an appropriate error response. Otherwise the master agent removes u.region from its registered OID space for u.context. If the original region had been split, all such related regions are removed. If this removal results in any contiguous regions that share a common original Register-PDU, they are agglomerated into a single region. 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) 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 effect at the managed node. In particular, the master agent implements the Elements of Procedure defined in section 4.1 of [6] that apply to receiving entities. [We can't refer to 1901, or v2u/v2* ?] If this processing 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 1 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. 7.2.1.1 GetRequest-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 region. (2) Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate the RegionSpecifier that is identical to or is the closest lexicographical predecessor to the variable binding's name. (3) If no such region exists the variable binding is not processed further. (4) Identify the target subagent, which is the one that registered the target region. (5) 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 in section 6.1.3, and the context in the Request-PDU encoded into g.context. (6) Add a SearchRange to the end of the target subagent's Get-PDU for this variable binding. (7) The variable binding's name is copied to g.requested. (8) g.limit is set to null. 7.2.1.2. GetNextRequest-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 region. (2) Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate the longest RegionSpecifier of which the variable binding's name is a subtree. If no such region exists, locate the RegionSpecifier which is the first lexicographical successor to the variable binding's name. (3) If no such region exists the variable binding is not processed further. (4) Identify the target subagent, which is the one that registered the target region. (5) 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 in section 6.1.3 and the context in the Request-PDU encoded into g.context. (6) Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. (7) The variable binding's name is copied to g.requested. (8) g.limit is set to the RegionSpecifier that is the first lexicographical successor to the target Regionspecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.limit is set to null. 7.2.1.3. GetBulkRequest-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 region and target subagent, exactly as described for the GetNextRequest-PDU (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 in section 6.1.3 and the context and max_repetitions value in the request PDU encoded into g.context and g.max_repetitions. Set g.non_repeaters to 0. (3) Add a SearchRange to the end of the target subagent's GetBulk-PDU for this variable binding, as described for the GetNext-PDU. If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. When all variable bindings have been processed, send any AgentX PDUs to their respective target subagents (at the transport endpoint used to initiate the subagent's logical connection). 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 Request PDUs When a subagent receives an AgentX Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns a response PDU. The 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_code 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 added to the response PDU as described below. If processing should fail for any reason not described below, res.error_code is set to `genError', res.error_index to the index of the failed SearchRange, the VarBindList is reset to null, and this 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 variable binding in the request is processed in order as follows: 1) g.requested is copied to v.name. 2) If the value of g.requested 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 in section 5.2. If the resulting VarBind's type is not part of the SNMPv1 SMI, and h.flags indicate this is an SNMPv1-style request, v.type is set to `noSuchObject', and v.length to 0. 3) Otherwise, if the value of g.requested 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 variable binding 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: - The variable's name is the closest lexicographical successor to g.requested. - If g.limit is not null, the variable's name lexicographically precedes g.limit. - If h.flags indicates this is an SNMPv1 request, the variable's syntax is part of the SNMPv1 SMI. 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 in section 5.2. 2) If no such variable exists, v.name is set to g.requested, v.type is set to `endOfMibView', and v.length to 0. ----- End Included Message -----   Delivery-Date: Tue, 11 Jun 1996 03:06:34 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA19550 for X-agentx-local; Tue, 11 Jun 1996 03:06:33 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id DAA19546 for ; Tue, 11 Jun 1996 03:06:32 -0700 (PDT) Message-Id: <199606111006.DAA19546@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3145; Tue, 11 Jun 96 06:06:19 EDT Date: Tue, 11 Jun 96 11:31:46 DST From: "Bert Wijnen" To: agentx@fv.com Subject: DRAFT agentX text Mike, Dale and myself have had quite a few e-mails about the agentX draft text that Dale posted yesterday. After reviewing wat got posted I (still) have these comments: - section 5.1 I'd rather see a flag-byte in the agentX OPEN packet that allows to negotiate a character set. By default it would be the NATIVE character set (and so for all of you ASCII guys it is then a moot point... while for IBM-ers like myself it will allow for more simple APIs on EBCDIC systems... and other non-ASCI systems can profit in the same way). In the rare case where an ASCII sub-agent must talk to a non-ASCII master agent, it could then specify that it wants to talk ASCII (again a moot point for most of you). A master agent is allowed to return that it DOES not support that. The current text is impossible. How will a master agent be able to figure out what the character set of the sub-agent is and if it should translate? Right... impossible. The idea is that if we define it in the same way as it was defined in DPI 2.0, then all this is moot for the ASCII platforms. At the same time it addresses the needs for non-ASCII environments (like IBM EBCDIC). - We have taken BIT_STRING out of he list of SNMP_TYPE_xxx types in section 5.2. That is good. But we should also take out this text: > - BIT_STRING is an OCTET_STRING of the form uubbbb...bb, where > the first octet (uu) is 0x00-0x07 and indicates the number of > unused bits in the last octet (bb). The bb octets represent > the bit string itself, where bit zero (0) comes first and so > on. The BITS construct is encoded as an OCTET_STRING, and so I think that there indeed is no need to add that as a seperate TYPE. - I am also surprised that we still have the high order bit set for "interger-type" types. I used this in DPI on the mainframe to quickly determine if a type was "interger-type". Still kind of handy I guess, but not really needed. - Section 6.1.4 Header I am strongly against passing SNMP version info donw to the subagent. I have found in DPI, that it allows us to easily write instrumentation independent of SNMP version if we just do NOT expose to the subagents what SNMP version was in the original request. Our subagents talk SNMPv2 specific (types, error-codes, exceptions and such) and the master agent takes care of the conversion to SNMPv1 if the SNMP request was from an SNMPv1 manager. - Section 6.1.4 PDU types - I suggest to take out the "(not yet used)" text for TRAPv2/INFORM. - Do we all agree that we want to keep the INFORM pdu? This came out of DPI 2.0. I had defined the type, but never implemented it. Now.... and INFORM is send in a "manager-role" ... so one could claim that it has nothing to do with a sub-agent ?? However, the data that is being send with an INFORM is the data as it is available in an agent role (at that SNMP entity). So in that sense ... it could very well be handy to have the capability to send an INFORM from a sub-agent containing variables that are available in the instrumentation of that subagent. - Section 6.1.4 - It seems that the context is a (nul-terminated??) string. I think we should explicitly state so if it is the case. If such is not the case (do we need to support arbitrary octets in the contextname??) then the context should have a length field. - Section 7.1.2.1 - All of a sudden I see that r.timeout is specified in centi-seconds. I really think that timeout in terms of seconds a fine enough granularity. DPI 2.0 used seconds, and I have never been asked for a finer granularity.... In fact, I used a default of 3 seconds, and all that was ever wanted was a way to specify a longer timout value as opposed to be able to specify a shorter one. Do we really think that we want to assume a problem if some subagent does not respond for say half a second? I'd say that probably some high-priority task is active for a little bit in that case. - section 7.1.2.2 asks: If an Open-PDU has not been received and successfully processed for this subagent, ignore the message or send back error?|. If an Open-PDU has not been received and successfully processed for this subagent, ignore the message or send back error?|. I'd say send back an error like: ERROR_mustOpenFirst - section 7.2.3 Seems we must re-check/re-arrange this section. We have item 5 twice. We're now trying to describe all RESPONSE handling, no matter what the PDU was. I think it will be easier to understand if take the same approach as in section 7.2.1 and 7.2.2. - view checking - for GET/SET processing, it would be wiser to do a view check first, before even sending a PDU to a subagent The response then does NOT need to be checked. - for GETNEXT/GETBULK processing, it may also be wise to do some view checking forst to ensure that possibly at least one variable might be in the range supported by the subagent. The response in this case needs to be checked also... and if there is an endOfMibView included, then a re-iteration may be needed. - section 7.2.4 asks: > Note that this may also involve altering the PDU contents for agents > that support the SNMP version 1 framework. > > Do we need to mention explicit mappings? For instance, for v2 > Set error codes?| Yep I think so. I have submitted text to Mike/Dale for inclusion. Mike/Dale, do you want me to post that to the mailing list or are you integrating that text already? Bert Wijnen   Delivery-Date: Tue, 11 Jun 1996 11:05:15 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA00461 for X-agentx-local; Tue, 11 Jun 1996 11:05:14 -0700 (PDT) Received: from world.bostech.com (world.bostech.com [192.52.71.122]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA00441 for ; Tue, 11 Jun 1996 11:05:11 -0700 (PDT) From: dkeeney@bostech.com Received: from btrd.bostech.com (opus.bostech.com) by world.bostech.com (4.1/SMI-4.1) id AA00258; Tue, 11 Jun 96 13:53:13 EDT Received: from heat.bostech.com by btrd.bostech.com (4.1/SMI-4.0) id AA01942; Tue, 11 Jun 96 13:57:27 EDT Message-Id: <9606111757.AA01942@btrd.bostech.com> Subject: DRAFT agentX text (fwd) To: agentx@fv.com Date: Tue, 11 Jun 1996 13:57:25 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In former message Bert Wijnen said: > (..lots of good stuff removed) > - Section 6.1.4 Header > I am strongly against passing SNMP version info donw to the subagent. > I have found in DPI, that it allows us to easily write instrumentation > independent of SNMP version if we just do NOT expose to the subagents > what SNMP version was in the original request. Our subagents talk > SNMPv2 specific (types, error-codes, exceptions and such) and the > master agent takes care of the conversion to SNMPv1 if the SNMP > request was from an SNMPv1 manager. The subagent needs to know the SNMP version so that it can "skip over" MIB elements that contain V2 data types on a V1 request. It would be messy to have the master agent filter out this stuff, particularly for GETNEXT. The master would have to keep going back to a subagent, one element at a time, until it found a V1 compatable element or end-of-MIB. I do think that error codes and exceptions should all be V2. > - view checking > - for GET/SET processing, it would be wiser to do a view check first, > before even sending a PDU to a subagent > The response then does NOT need to be checked. > - for GETNEXT/GETBULK processing, it may also be wise to do some view > checking forst to ensure that possibly at least one variable might be > in the range supported by the subagent. > The response in this case needs to be checked also... and if there > is an endOfMibView included, then a re-iteration may be needed. Here I agree. Post-viewchecking would only be needed for GETNEXT/GETBULK if the view was not a continuous range (the bitmask was used to indicate wildcards). In this case it might not be practical to try to limit the requested OID range such that the entire range is in-view. David Keeney   Delivery-Date: Tue, 11 Jun 1996 12:45:55 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA24115 for X-agentx-local; Tue, 11 Jun 1996 12:45:55 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA24107 for ; Tue, 11 Jun 1996 12:45:53 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id VAA06707; Tue, 11 Jun 1996 21:45:48 +0200 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id VAA08661; Tue, 11 Jun 1996 21:45:44 +0200 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id VAA05657; Tue, 11 Jun 1996 21:45:45 +0200 Date: Tue, 11 Jun 1996 21:45:45 +0200 Message-Id: <199606111945.VAA05657@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: agentx@fv.com CC: wijnen@vnet.ibm.com In-reply-to: <199606111006.DAA19546@zloty.fv.com> (wijnen@vnet.ibm.com) Subject: Re: DRAFT agentX text "Bert Wijnen" wrote: > The current text is impossible. How will a master agent be able to > figure out what the character set of the sub-agent is and if it > should translate? Right... impossible. > The idea is that if we define it in the same way as it was defined in > DPI 2.0, then all this is moot for the ASCII platforms. At the same > time it addresses the needs for non-ASCII environments (like IBM > EBCDIC). Why does the agentx protocol bother with non-ASCII character sets at the protocol level? It should be easy and not too expensive to convert into an ASCII representation on systems that do not use ASCII. This can be done at compile time and the required conversion can happen in an agentx library. Note also that section 5.1 requires that > Strings are represented in the native character set of the system on > which the subagent resides. If this is not ASCII, the master agent > must perform any required conversions. This actually means that a master agent must be able to understand all character sets of all possible sub-agents (in a "distributed system"). I also think that the special treatment of DisplayStrings (which are just a MIB specific interpretation of OCTET STRINGS) in the agentx protocol is irritating. How does the master agent decide if an OCTET STRING value contained in a SNMP request is processed like a DisplayString or not? Do you require that the master agent has knowledge about the MIBs implemented by the subagents? Is it really an acceptable design decision to hard wire this one textual convention while keeping the implementation of all other textual conventions up to the implementor of the MIB objects? Unless someone has some very convincing arguments, I propose to remove the concept of different character sets and to remove the special tag for DisplayStrings. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Tue, 11 Jun 1996 14:29:46 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA16613 for X-agentx-local; Tue, 11 Jun 1996 14:29:46 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA16608 for ; Tue, 11 Jun 1996 14:29:45 -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 RAA07941 for ; Tue, 11 Jun 1996 17:30:07 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.2.250.126]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id RAA36294 for ; Tue, 11 Jun 1996 17:29:45 -0400 Message-Id: <199606112129.RAA36294@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7564; Tue, 11 Jun 96 17:29:40 EDT Date: Tue, 11 Jun 96 16:53:18 EDT From: "Geoff Carpenter (8-862-1970)" To: agentx@fv.com Subject: DRAFT agentX text Ref: Your note of Tue, 11 Jun 1996 21:45:45 +0200 (attached) >Why does the agentx protocol bother with non-ASCII character sets at >the protocol level? Probably because the first product implementation of a DPI-capable agent occurred on VM, so many of the issues of having a non-ASCII character set were staring us in the face. Since the agent-x effort has been influenced by the DPI experiences, an attempt to carry forward some of the good features of DPI is being made. >It should be easy and not too expensive to convert >into an ASCII representation on systems that do not use ASCII. >This can be done at compile time and the required conversion can happen in >an agentx library. You have to know what's binary data and what's ASCII text which can be converted to and from another character set. You'd like your sub-agent applications to not have to be aware of the underying character set. And you would like to avoid unnecessary character set translations if both the master agent and sub-agent use the same character set. >Note also that section 5.1 requires that > >> Strings are represented in the native character set of the system on >> which the subagent resides. If this is not ASCII, the master agent >> must perform any required conversions. > >This actually means that a master agent must be able to understand all >character sets of all possible sub-agents (in a "distributed system"). Which is probably why Bert used the word "impossible" to describe the current description. Whatever gets decided, the current wording is not workable. >I also think that the special treatment of DisplayStrings (which are >just a MIB specific interpretation of OCTET STRINGS) in the agentx >protocol is irritating. Irritating or not, different character sets are a fact of life. Of the 3 issues I listed above, only one is a must: you have to know what data is text which should be translated from one character set to another. The DisplayString textual convention is the best we came up with. It would have been nice if was actually encoded as a separate type so that one could figure out whether or not an octet string should be converted upon parsing an SNMP packet. As it is, you need some sort of auxiliary information. >How does the master agent decide if an OCTET >STRING value contained in a SNMP request is processed like a >DisplayString or not? Do you require that the master agent has >knowledge about the MIBs implemented by the subagents? Is it really an >acceptable design decision to hard wire this one textual convention >while keeping the implementation of all other textual conventions up >to the implementor of the MIB objects? >Unless someone has some very convincing arguments, I propose to remove >the concept of different character sets and to remove the special tag >for DisplayStrings. Given the history of the DPI, it would seem silly to me if the agent-x specification ends up being an "improved" version of DPI that is impossible to implement on IBM mainframes. Clearly the working group has the right to do such a thing, but it seems short-sighted. Bert's been clear that the specification he wants means that an agent implementor on an ASCII platform will not have to be concerned with EBCDIC. The request is to retain the hooks needed to make the protocol work on machines with non-ASCII character sets. Geoff Carpenter IBM Research -- Yorktown Heights, NY   Delivery-Date: Tue, 11 Jun 1996 18:23:09 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id SAA07219 for X-agentx-local; Tue, 11 Jun 1996 18:23:09 -0700 (PDT) Received: from hammurabi.nh.ultra.net (hammurabi.nh.ultra.net [205.162.79.24]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id SAA07215 for ; Tue, 11 Jun 1996 18:23:08 -0700 (PDT) Received: from keeney (dek.bluefin.net [205.162.68.223]) by hammurabi.nh.ultra.net (8.7.4/dae0.6) with SMTP id VAA10720 for ; Tue, 11 Jun 1996 21:23:07 -0400 (EDT) Date: Tue, 11 Jun 1996 21:23:07 -0400 (EDT) Message-Id: <199606120123.VAA10720@hammurabi.nh.ultra.net> X-Sender: keeney@pop.nh.ultranet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: David Keeney Subject: Agentx Draft Document on Web Page The Agentx Draft Document submitted by Mike Daniele and Dale Francisco is availale on the Agentx Web Page: http://www.scguild.com/agentx/ David Keeney ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Tue, 11 Jun 1996 19:18:39 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id TAA18752 for X-agentx-local; Tue, 11 Jun 1996 19:18:38 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id TAA18748 for ; Tue, 11 Jun 1996 19:18:37 -0700 (PDT) From: kennethw@VNET.IBM.COM Message-Id: <199606120218.TAA18748@zloty.fv.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0283; Tue, 11 Jun 96 22:18:24 EDT Date: Tue, 11 Jun 96 22:16:19 EDT To: agentx@fv.com Subject: Juergen Schoenwaelder's character set note I would like to speakup in favor of keeping the capability of a subagent to inform the master agent of the character set it is using. I have used this capability with DPI and like what it provides. Its a better design to have character conversion in a single place then distributing it amongst the agents. It saves code and makes changing the translation tables much simpler. A DisplayString object gets converted if its not ASCII. An OCTET STRING just gets passed along. An master agent implementation would decide what its native character set was if not ASCII, and thus would support it and ASCII since subagents could be of different character sets. The subagents that I deal with need dynamic character conversion. Compile time conversation doesn't work. Very few DisplayString objects are static even if they are read-only in the MIBs that my subagents support. However, I'm not in favor of having the master agent: "... understand all character sets of all possible sub-agents (in a "distributed system")." I would propose that the master agent knows its (if not ASCII) character set. A remote subagent if not the same character set would use ASCII. Regards, Ken White IBM TCP/IP for MVS Development   Delivery-Date: Tue, 11 Jun 1996 21:41:16 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id VAA17103 for X-agentx-local; Tue, 11 Jun 1996 21:41:15 -0700 (PDT) Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id VAA17078 for ; Tue, 11 Jun 1996 21:41:09 -0700 (PDT) Received: from plutonium.bflsl.soft.net. by netra.soft.net (5.x/SMI-SVR4) id AA21487; Wed, 12 Jun 1996 10:07:16 +0500 Received: from localhost by plutonium.bflsl.soft.net. (5.x/SMI-SVR4) id AA27343; Wed, 12 Jun 1996 10:09:40 -0400 Date: Wed, 12 Jun 1996 10:09:39 -0400 (EDT) From: "Ramaprasad K.R." X-Sender: bflram@plutonium To: agentx@fv.com Subject: Re: Initial version of AgentX draft (1 of 5) In-Reply-To: <9606101614.AA06842@santa.strata.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I have a comment on the AgentX Roles of the master agent entity.. Its function of accepting the Trap PDUs from the sub-agent and sending them across to the management station as a SNMP Trap should be enumerated here ? > 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. Regards -rampi |-------------------------------------------------------------------| | The Brain is a wonderful organ. It starts working the moment you | | get up and does not stop until you get into office. | | - Robert Frost | |-------------------------------------------------------------------|   Delivery-Date: Tue, 11 Jun 1996 22:55:05 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id WAA02022 for X-agentx-local; Tue, 11 Jun 1996 22:55:05 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id WAA02019 for ; Tue, 11 Jun 1996 22:55:03 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id HAA09261; Wed, 12 Jun 1996 07:54:56 +0200 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id HAA11818; Wed, 12 Jun 1996 07:54:54 +0200 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id HAA06848; Wed, 12 Jun 1996 07:54:55 +0200 Date: Wed, 12 Jun 1996 07:54:55 +0200 Message-Id: <199606120554.HAA06848@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: GCC@watson.ibm.com CC: agentx@fv.com In-reply-to: <199606112129.RAA36294@mailhub1.watson.ibm.com> (GCC@watson.ibm.com) Subject: Re: DRAFT agentX text "Geoff Carpenter (8-862-1970)" wrote: > Given the history of the DPI, it would seem silly to me if the > agent-x specification ends up being an "improved" version of DPI that > is impossible to implement on IBM mainframes. I don't think that using only one character set makes it impossible to implement agentx on IBM mainframes. The conversions can be done in the DPI library if you like to have this feature. It might require some additional overhead (which is IMHO very low compared to the overhead in using an agentx solution anyway). I still don't understand how the master agent decides if an OCTET STRING is a DisplayString or not. Juergen   Delivery-Date: Tue, 11 Jun 1996 22:59:07 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id WAA02805 for X-agentx-local; Tue, 11 Jun 1996 22:59:06 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id WAA02798 for ; Tue, 11 Jun 1996 22:59:03 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id HAA09272; Wed, 12 Jun 1996 07:59:01 +0200 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id HAA11843; Wed, 12 Jun 1996 07:58:59 +0200 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id HAA06863; Wed, 12 Jun 1996 07:59:00 +0200 Date: Wed, 12 Jun 1996 07:59:00 +0200 Message-Id: <199606120559.HAA06863@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: kennethw@vnet.ibm.com CC: agentx@fv.com In-reply-to: <199606120218.TAA18748@zloty.fv.com> (kennethw@vnet.ibm.com) Subject: Re: Juergen Schoenwaelder's character set note kennethw@vnet.ibm.com wrote: > The subagents that I deal with need dynamic character conversion. > Compile time conversation doesn't work. Very few DisplayString > objects are static even if they are read-only in the MIBs that > my subagents support. Sorry, I did not express myself clear here. I meant that character set conversion can be a compile time option of the DPI library. Juergen   Delivery-Date: Wed, 12 Jun 1996 02:14:22 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id CAA04765 for X-agentx-local; Wed, 12 Jun 1996 02:14:22 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id CAA04762 for ; Wed, 12 Jun 1996 02:14:21 -0700 (PDT) Message-Id: <199606120914.CAA04762@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3935; Wed, 12 Jun 96 05:14:09 EDT Date: Wed, 12 Jun 96 11:14:12 DST From: "Bert Wijnen" To: agentx@fv.com Subject: DRAFT agentX text Ref: Your note of Tue, 11 Jun 1996 21:45:45 +0200 Subject: Draft agentX text Juergen writes: > > This actually means that a master agent must be able to understand all > character sets of all possible sub-agents (in a "distributed system"). > No, it does not if we take the DPI approach. Let me repeat: - The default is the native character set of the system on which the subagent runs. Normally this is the same system as where the master agent runs. So translation between ASCII-EBCDIC is mostly done in one place, namely in the master agent. - DisplayStrings are special, because they are often used in human-interaction, and so if such interaction is needed at a non-ascii system, then it better be in the native character set, otherwise it becomes garbage. - The master agent can only determine if a value is a DisplayString if it indeed has knowledge about the MIB. In many cases that is the case if master agent and subagent run on same system. If the masteragent does not have the info, then the OCTET STRING is just passed as octetstring, and possibly the subagent then has to take care of the conversion... (Mind that this is only for SETs). At the other hand, if a subagent sends data (responses/traps etc) to the agent (which happens much more than the other way around), then the subagent can just use the native character set (so in a C-program it can be just a constant like "blablabla") and send the response to the masteragent as DisplayString and the masteragent will convert it to ASCII and encode it into an OCTET STRING - I do not suggest (nor does DPI 2.0) that a master agent recognizes umpty different character sets if it talks to distributed subagents. In this case, the communication between the master agent and the subagents would be in ASCII. - And again: for the majority of the world all of this is a moot point, because they are all ASCII based. > I also think that the special treatment of DisplayStrings (which are > just a MIB specific interpretation of OCTET STRINGS) in the agentx > protocol is irritating. How does the master agent decide if an OCTET > STRING value contained in a SNMP request is processed like a > DisplayString or not? Do you require that the master agent has > knowledge about the MIBs implemented by the subagents? Is it really an > acceptable design decision to hard wire this one textual convention > while keeping the implementation of all other textual conventions up > to the implementor of the MIB objects? > > Unless someone has some very convincing arguments, I propose to remove > the concept of different character sets and to remove the special tag > for DisplayStrings. > I hope some of the above helps convince you... or at least take your concerns away. I have had this argument agains non-ASCII character sets many times.... my main convincing argument I think is: The DPI apporach solves the non-ASCII related problems while at the same time it is a MOOT POINT for the ASCII world. We tried very hard, to make this indeed transparent to the ASCII world so that they would not be bothered with our (IBM) problems. Now... as Geoff Carpenter and Ken White explained, we have experience: - We use the DPI approach on VM, MVS and AS/400, AIX, OS/2 etc. - It is used with agents/subagents that run just on ASCII - It is used with agents/subagents that run just on EBCDIC - It is used with agents on EBCDIC and subagents on ASCII - I am not aware it is used with agent on ASCII and subagent on EBCDIC... that would be something to test with also. For us it has worked very well, that is why we want to see continued support for this. Has anyone else experience with an environment that is non-ASCII ? It would be interesting to see if our DPI 2.0 approach does work in their environment also. How about tests with some of the international character sets? Who has such an environment and is willing to test? Bert Wijnen, IBM Research   Delivery-Date: Wed, 12 Jun 1996 09:24:34 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA25583 for X-agentx-local; Wed, 12 Jun 1996 09:24:34 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA25580 for ; Wed, 12 Jun 1996 09:24:33 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id MAA21262; Wed, 12 Jun 1996 12:24:22 -0400 Date: Wed, 12 Jun 1996 12:23:41 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06847; Wed, 12 Jun 1996 12:23:41 -0400 Message-Id: <9606121623.AA06847@nips.acec.com> To: wijnen@vnet.ibm.com Subject: Character Sets in AgentX Cc: agentx@fv.com > Date: Wed, 12 Jun 96 11:14:12 DST > From: "Bert Wijnen" > Subject: DRAFT agentX text Hi Bert, <...> First, let me say (as wg chair) that since DPI v2 is the base document for AgentX, then changes which impair deployed DPI v2 implementations are to be avoided unless those changes are essential to meeting our charter requirements...and they do include engineering goals such as efficiency and self-consistency, among others (under the general rubric of "protocol quality"). Now (as a technical contributor)...I am somewhat opposed to the idea of including the character set indicator in AgentX. In part, this results from my original position that I would prefer to have the master agent and the subagents exchange SNMP messages (with a small number of new message types included for OPEN, REGISTER, etc.)--but that position was generally rejected by the wg. So be it. Nonetheless, the questions asked below--which, in my view somewhat relate to the underlying, quintessential SNMP nature of AgentX-- have yet to be answered satisfactorily, IMHO: >> I also think that the special treatment of DisplayStrings (which are >> just a MIB specific interpretation of OCTET STRINGS) in the agentx >> protocol is irritating. How does the master agent decide if an OCTET >> STRING value contained in a SNMP request is processed like a >> DisplayString or not? Do you require that the master agent has >> knowledge about the MIBs implemented by the subagents? Is it really an >> acceptable design decision to hard wire this one textual convention >> while keeping the implementation of all other textual conventions up >> to the implementor of the MIB objects? I think these are very good questions. SNMP messages do not convey information about DisplayStrings...or any other textual conventions...only the types defined as "ObjectSyntax" in RFC 1902. Why should a subagent need to know anything more to answer an SNMP query (or set a value)? Textual conventions seem, to me, to be primarily relevant at the application/presentation layer. (Granted some TCs have "behavioral" implications in the agent, but these are typically not variant at run time in the agent.) >> Unless someone has some very convincing arguments, I propose >> to remove the concept of different character sets and to remove >> the special tag for DisplayStrings. I agree. I have not seen a convincing argument yet. Maybe I have not put enough effort/intelligence into understanding Bert's rationale (which seem post facto sensible, but do not seem to offer the a priori justification). I guess what I'd ask is "Can an MVS box with a TCP/IP stack include a native, monolithic SNMP agent today that will respond correctly to normal SNMP Get and Set requests carrying OCTET_STRING varbinds?". And, if the answer to that is "yes", then "Why is it necessary for subagents on that platform to have other capabilities in this respect?". > I hope some of the above helps convince you... or at least > take your concerns away. I have had this argument agains > non-ASCII character sets many times.... Yes, and both your patience and your persistence are to be admired! :-) > my main convincing argument I think is: > The DPI apporach solves the non-ASCII related problems Ah, there's the rub, I for one don't see why there is any such thing as "the non-ASCII related problems"...? > while at the same time it is a MOOT POINT for the ASCII world. > We tried very hard, to make this indeed transparent to the ASCII > world so that they would not be bothered with our (IBM) problems. And that will probably end up being its salvation...unless, of course, we can convince you that IBM really doesn't have any problems (in this respect). :-) <...> > For us it has worked very well, that is why we want to see > continued support for this. And, as I said above, there is a procedural bias toward doing this. > Has anyone else experience with an environment that is non-ASCII ? Not insofar as SNMP is concerned! :-) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 12 Jun 1996 09:36:50 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA28494 for X-agentx-local; Wed, 12 Jun 1996 09:36:50 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA28483 for ; Wed, 12 Jun 1996 09:36:48 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id MAA22679; Wed, 12 Jun 1996 12:36:43 -0400 Date: Wed, 12 Jun 1996 12:36:04 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07008; Wed, 12 Jun 1996 12:36:04 -0400 Message-Id: <9606121636.AA07008@nips.acec.com> To: schoenw@cs.utwente.nl Subject: Character sets & MIB info Cc: agentx@fv.com > Date: Wed, 12 Jun 1996 07:54:55 +0200 > From: Juergen Schoenwaelder > Subject: Re: DRAFT agentX text Hi Juergen, > "Geoff Carpenter (8-862-1970)" wrote: > >> Given the history of the DPI, it would seem silly to me if the >> agent-x specification ends up being an "improved" version of >> DPI that is impossible to implement on IBM mainframes. > I don't think that using only one character set makes it impossible to > implement agentx on IBM mainframes. The conversions can be done in the > DPI library if you like to have this feature. It might require some > additional overhead (which is IMHO very low compared to the overhead > in using an agentx solution anyway). I agree. > I still don't understand how the master agent decides if an OCTET > STRING is a DisplayString or not. Neither do I. Btw, this also relates to *another* of my favorite ideas for AgentX that got totally rejected by the wg early on (hard to believe I'm the putative chairperson of this group, huh! :-)...namely, in addition to preferring that the master and subagents exchange SNMP messages, I felt that registration should be done at the "MIB level" (which could be as small as one instance or as large as, say, MIB-2). While not needed for SYNTAX knowledge, such info could could be used for access control, lexicographic optimizations, etc. Anyway, that is beside the point now...we have a good scheme for instance-level and up registration in the current draft... it will get some refining I am sure over the coming weeks. But Juergen's question remains open...where does the master get this MIB-level info about the object? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 12 Jun 1996 11:16:02 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA22607 for X-agentx-local; Wed, 12 Jun 1996 11:16:01 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA22566 for ; Wed, 12 Jun 1996 11:16:00 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id UAA16421; Wed, 12 Jun 1996 20:15:51 +0200 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id UAA20971; Wed, 12 Jun 1996 20:15:48 +0200 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id UAA12405; Wed, 12 Jun 1996 20:15:48 +0200 Date: Wed, 12 Jun 1996 20:15:48 +0200 Message-Id: <199606121815.UAA12405@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: wijnen@vnet.ibm.com CC: agentx@fv.com In-reply-to: <199606120914.CAA04762@zloty.fv.com> (wijnen@vnet.ibm.com) Subject: Re: DRAFT agentX text "Bert Wijnen" wrote: > - The master agent can only determine if a value is a DisplayString > if it indeed has knowledge about the MIB. In many cases that is > the case if master agent and subagent run on same system. If the > masteragent does not have the info, then the OCTET STRING is just > passed as octetstring, and possibly the subagent then has to > take care of the conversion... (Mind that this is only for SETs). If I am going to write subagents against this draft for an unknown master agent (which is why we try to standardize agentx), than I have to expect that a DisplayString value might come in as a DisplayString or as an OCTET STRING, depending on the MIB knowledge of the master agent. If it does not come in as a DisplayString, I have to convert it into the native character set myself. So I end up writing code like: switch (type) { case SNMP_TYPE_OCTET_STRING: #ifdef NONASCII ascii2native(value); #endif break; case SNMP_DISPLAY_STRING: break; default: return WRONG_TYPE; } I am not sure if this is really simpler than just knowing that every OCTET STRING is coming in as an OCTET STRING. The only way to save some code during SET processing is to know for sure that the master agent is able to recognize DisplayStrings. I want is a clear specification how a master agent determines if a value contained in a SET request is treated as an OCTET STRING or a DisplayString. If the master is free to choose the type in a best effort manner as you propose above, than we will have to deal with this ambiguity in the subagents as shown above. (Please correct me if I am wrong - IBM has written DPI agents and must know if I am correct.) > The DPI apporach solves the non-ASCII related problems > while at the same time it is a MOOT POINT for the ASCII world. To support character sets, DPI introduces a new type which has to be accepted together with the base type when processing SET requests as indicated above. This creates a potential interoperability problem if subagent implementations only expect one type for a DisplayString MIB instance. Other than that, it is transparent. > For us it has worked very well, that is why we want to see continued > support for this. I fully understand IBMs position. If there is agreement to keep the support for different character sets (because we honor the DPI work done by IBM), than we need to solve the problems with it. It might be a solution to require that a master agent never uses the DisplayString type when sending a value to a subagent - this makes the situation clear for SET requests. But I still think that different encodings at the protocol level is is a bad design. Fortunately, we only have one format for numbers. ;-) Juergen   Delivery-Date: Wed, 12 Jun 1996 12:26:55 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA08559 for X-agentx-local; Wed, 12 Jun 1996 12:26:55 -0700 (PDT) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA08551 for ; Wed, 12 Jun 1996 12:26:54 -0700 (PDT) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) id PAA12185; Wed, 12 Jun 1996 15:17:19 -0400 Date: Wed, 12 Jun 1996 15:17:19 -0400 Message-Id: <199606121917.PAA12185@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: natale@acec.com (Bob Natale), schoenw@cs.utwente.nl From: george.best@antec.com (George Best) Subject: Re: Character sets & MIB info Cc: agentx@fv.com At 12:36 PM 6/12/96 -0400, Bob Natale wrote: >messages, I felt that registration should be done at the "MIB level" >(which could be as small as one instance or as large as, say, MIB-2). BobN - How does this differ from what has been discussed? I thought AgentX was going to allow registration at individual OIDs, nodes in the tree, and table rows. Thanks, Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: george.best@antec.com Digital Video voice: (770)734-0400 ext. 8534 A Division of Arris Interactive Norcross GA, USA   Delivery-Date: Wed, 12 Jun 1996 12:37:56 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA11261 for X-agentx-local; Wed, 12 Jun 1996 12:37:55 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA11256 for ; Wed, 12 Jun 1996 12:37:54 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id PAA13431; Wed, 12 Jun 1996 15:37:54 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA09391; Wed, 12 Jun 1996 15:35:49 -0400 Date: Wed, 12 Jun 1996 15:40:23 EDT From: Bob Natale Subject: Character sets and purpose of AgentX To: Juergen Schoenwaelder Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Juergen Schoenwaelder > Date: Wed, 12 Jun 1996 20:15:48 +0200 > Subject: Re: DRAFT agentX text Hi Juergen, > If I am going to write subagents against this draft for an unknown > master agent (which is why we try to standardize agentx), Yes, and that is definitely worth repeating any number of times in this process...we all have to keep that in mind, constantly. A lot of the (very important) input on the list comes from people (myself included) who probably anticipate providing complete extensible agent environments...master, one or more core subs, an API, a toolkit, etc. We have to be careful to keep that perspective distinct from the fundamental one that you identify above...anyone should be able to build an AgentX subagent that will "plug in" and work with an AgentX master, simply by virtue of using the AgentX protocol (and whatever else may be required for connectivity/interoperability by the non-AgentX aspects of the target configuration). <...> > But I still think that different encodings at the protocol > level is is a bad design. In general, I agree...but there are other (valid) considerations at work here...that remain to be fully understood and assessed. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 12 Jun 1996 13:55:26 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA27566 for X-agentx-local; Wed, 12 Jun 1996 13:55:21 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA27562 for ; Wed, 12 Jun 1996 13:55:20 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id QAA21415; Wed, 12 Jun 1996 16:54:22 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10330; Wed, 12 Jun 1996 16:53:06 -0400 Date: Wed, 12 Jun 1996 16:57:38 EDT From: Bob Natale Subject: Re: Character sets & MIB info To: George Best Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: George Best > Date: Wed, 12 Jun 1996 15:17:19 -0400 Hi George, > At 12:36 PM 6/12/96 -0400, Bob Natale wrote: > >messages, I felt that registration should be done at the "MIB level" > >(which could be as small as one instance or as large as, say, MIB-2). > > How does this differ from what has been discussed? I thought AgentX > was going to allow registration at individual OIDs, nodes in the tree, > and table rows. That is correct. AgentX as currently proposed (which I endorse) does this by passing a "region identifier" (OID), which could range from the single instance up to the MIB root level...and requires "A Register-PDU to be generated by a subagent for each region of the MIB variable naming tree (within a specific context) that it wishes to support." [7.1.2] I had wanted the subagent to pass a pointer to a "MIB description file" in the Open-PDU. This would allow for some run-time optimizations of the basic registration process *and* would give the master full access to all of the MIB syntax/semantic/lexi info. In that scheme, only instance level registration would entail the use of the Register-PDU. Anyway, that's history. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 12 Jun 1996 14:44:46 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA08556 for X-agentx-local; Wed, 12 Jun 1996 14:44:46 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA08525 for ; Wed, 12 Jun 1996 14:44:41 -0700 (PDT) Message-Id: <199606122144.OAA08525@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4224; Wed, 12 Jun 96 17:44:23 EDT Date: Wed, 12 Jun 96 23:44:25 DST From: "Bert Wijnen" To: agentx@fv.com Subject: DRAFT agentX text Juergen writes: > If I am going to write subagents against this draft for an unknown > master agent (which is why we try to standardize agentx), than I have > to expect that a DisplayString value might come in as a DisplayString > or as an OCTET STRING, depending on the MIB knowledge of the master > agent. If it does not come in as a DisplayString, I have to convert it > into the native character set myself. So I end up writing code like: > > switch (type) { > case SNMP_TYPE_OCTET_STRING: > #ifdef NONASCII > ascii2native(value); > #endif > break; > case SNMP_DISPLAY_STRING: > break; > default: > return WRONG_TYPE; > } > > I am not sure if this is really simpler than just knowing that every > OCTET STRING is coming in as an OCTET STRING. The only way to save > some code during SET processing is to know for sure that the master > agent is able to recognize DisplayStrings. > Well, the above may not be simpler maybe, but is is also not more complicated than: case SNMP_TYPE_OCTET_STRING: if (TC == DisplayString) /* assume the DisplayString */ ascii2native(value); /* needs to be used by a humen */ /* else leave it alone */ break; Your general kind of sub-agent will not work for 2 or more character set environments unless you add #ifdefs and conversion routines anyway. Now look at many of the MIBs that have DisplayStrings as read-only objects. I also see very many of them that will contain a text that will very often be filled in in a C-program like: char * hostname 80Y; char * config_location 80Y; gethostname(hostname,80); read_config_location(config_location, 80); object_1Value = "IBM MVS DB2"; object_2Value = "Version 2.0, Revision 1.3.2"; sysName = hostname; sysLocation = config_location; Now, when you compile all this on an EBCDIC machine, do you realize that all these strings are EBCDIC and so that it comes in very very handy if I can return them on a GET and indicate that they are DisplayStrings (in native character set)? Often, you also want to display these values at the subagent and that then must be done in EBCDIC. Or these values come from config files that have been edited (or filled in on panels) and such editing (filling in) is done in EBCDIC. Do you also realize that if I want the above sort of code to work on both ASCII and EBCDIC systems, that with our DPI approach all of it will work, but that with just ASCII transfer between agent and subagent that I then will have to add a lot of code to convert all the ebcdic strings to ascii (only on EBCDIC systems of course). The above would also work with XYZ character set, while not using the DPI approach would have to have a 3rd conversion for that character set included. It is specifically the many many READ-ONLY objects that become so easy with the DPI 2.0 approach. > I want is a clear specification how a master agent determines if a > value contained in a SET request is treated as an OCTET STRING or a > DisplayString. If the master is free to choose the type in a best > effort manner as you propose above, than we will have to deal with > this ambiguity in the subagents as shown above. (Please correct me if > I am wrong - IBM has written DPI agents and must know if I am > correct.) > In most situation within IBM, I believe that the MIB info (so also the TC of an object) for the main sub-agents is included in the master agent. In that case the master agent translates DisplayStrings in a SET request. If the master agent does not know the TC (let us assume it is a new subagent that does not come with MIB info), then it just passes the OCTET_STRING without conversion. > > The DPI apporach solves the non-ASCII related problems > > while at the same time it is a MOOT POINT for the ASCII world. > > To support character sets, DPI introduces a new type which has to be > accepted together with the base type when processing SET requests as > indicated above. This creates a potential interoperability problem if > subagent implementations only expect one type for a DisplayString MIB > instance. Other than that, it is transparent. > A subagent (when it ever expects to run on a non-ASCII system) and specifically if it will accept SETs for DisplayString that need to be converted to the non-ASCII formm such a subagent better be prepared to handle both OCTET_STRING and DisplayString. > > For us it has worked very well, that is why we want to see continued > > support for this. > > I fully understand IBMs position. If there is agreement to keep the > support for different character sets (because we honor the DPI work > done by IBM), than we need to solve the problems with it. It might be > a solution to require that a master agent never uses the DisplayString > type when sending a value to a subagent - this makes the situation > clear for SET requests. But I still think that different encodings at > the protocol level is is a bad design. Fortunately, we only have one > format for numbers. ;-) > Yeah... I'd rather would see just one encoding. Namely that the encoding would bve DisplayString.... As Geoff Carpenter indicated, it probably would have been very wise to not do DisplayString as a TC but as a real type.... but that can not be reversed anymore (I guess). The otehr solution then would be to pre-scribe how a master agent must read MIB info for/from subagents and to also pre-scribe how the subagent makes such info available to the master-agent. That seems to be outside the scope of our task. So we leave it up to the implementer. Bert Wijnen   Delivery-Date: Wed, 12 Jun 1996 17:03:00 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA10833 for X-agentx-local; Wed, 12 Jun 1996 17:03:00 -0700 (PDT) Received: from hammurabi.nh.ultra.net (hammurabi.nh.ultra.net [205.162.79.24]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id RAA10775 for ; Wed, 12 Jun 1996 17:02:45 -0700 (PDT) Received: from keeney (dek.bluefin.net [205.162.68.223]) by hammurabi.nh.ultra.net (8.7.4/dae0.6) with SMTP id UAA11799 for ; Wed, 12 Jun 1996 20:02:32 -0400 (EDT) Date: Wed, 12 Jun 1996 20:02:32 -0400 (EDT) Message-Id: <199606130002.UAA11799@hammurabi.nh.ultra.net> X-Sender: keeney@pop.nh.ultranet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: David Keeney Subject: Agentx Draft Mike, The draft contains many very good ideas. Thanks for the hard work. I picked up a few things that should be considered. 1) Include/Exclude flag in SearchRange RE: 6.1.3 SearchRange The search range set needs an additional flag. In the usage as described, for a GETNEXT or GETBULK, the g.requested field is either the OID of the SNMP request or the start of a registered region. It may also be someplace in the middle of a region if views are implemented (see below). If g.requested field is not the OID of the SNMP request and happens to be an instance, then that OID will never be returned by an subagent because it is looking for something lexically greater. What is needed is a way to tell the subagent that the given g.requested field is to be included or excluded from the range of the search. If the OID came directly off of the SNMP GETNEXT/GETBULK request, then the OID should be excluded because we want the lexically next OID. If this is the beginning of a registered region, we want it to be included in the range because it may be an instance. The eSNMP implementation used an additional byte to carry this information. Perhaps there is another way to pass this information. 2) Views Views should be performed entirely by the Master Agent. In addition, the view check should be performed on the request OID (g.requested) prior to sending the request to the subagent. A view can be thought of as a set of regions in the same way as the subtree registrations. By taking into account the included and excluded parts of a view, it can be reduced to a list of regions. The view check could be very simular to searching for the next active registered region. For a GET/SET operation, the operation can be rejected right away if it is outside the view (i.e. is not within one of the view regions). For GETNEXT/GETBULK operations, if the value of g.requested is not in the view, then the master should continue to look for a lexically greater registered subtree region until it finds one that is within view or has at least part of it within view. If the first part of the region is not within view, move ahead to the first OID within that region that is within view and make that the new g.requested value (the starting point of the search - mark this with the searchrange include flag). Now that we have the starting point, we must then check the g.limit field to see if there is a contiguous range that is in view. If the view is more restrictive, then g.limit should be adjusted to the end of the view range. That means that if we must later re-dispatch a request, the master agent must start at the previous g.limit when searching for another "in view" segment rather than at the next lexically registered subtree region as stated in the procedure in 7.2.3 step 5. There could possibly be a second view range within the same region. Note that if a bit mask is used with a view specification, the view may be riddled with holes. I suggest that the above view check should be performed without the bit mask so that we are dealing with contiguous ranges. But if a bit mask is present, an additional check should be performed on the OID returned by the subagent to see if it is still in view. 3) Priority RE: 7.1.2.2.2 Handling Duplicate Regions (Register PDU) Here you are specifying the precedence of overlapping registrations. With the order that you specify, the most specific r.region takes precidence over the piority. I would expect that priority should come first since it is your overide. If you wanted a larger registration to take precedence over (and hiding) a smaller region, you should be able to set the larger region's priority higher so it can take precidence. (start soapbox) The registration priority should be something that is set by the user (system admin) as a runtime parameter or configuration of the SUBAGENT. This could then be used to modify or overide the default behavior of registration precedence to fix problems that could occur from conflicting registrations. At least the system administrator should be able to overide it if he/she does not like the default behavior. (end soapbox). 4) GETBULK processing RE: 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU The subagent should also teminate the processing when it fills its buffer or has reached the max_iteration count. 5) VarBind response processing RE: 7.2.3, step 4 If the view processing is performed up-front (pre-view) before sending it to the subagent then this view check on the returned value (post-view processing) will only be needed if the view contains a bitmask. And even if there is a bitmask the pre-view processing would reduce the frequency of redispatching back to the same subagent. With post-view processing only, you may end up walking through every mib element in a subagent and not use any of them if they were all out of view. Looking at the post-view processing procedures in the master agent: GET - The procecures state: If the varbind is not within the mib view, it should be ignored. However, should not be ignored. It should be rejected with noSuchObject. GetNext - The procedures state: If the varbind is not within the mib view, the VarBind should be ignored. It cannot be ignored. The master agent will need to re-dispatach the request (possibly back to the same subagent) using this varbind's OID as the g.requested (with the exclude flag - see above). Ignoring it such that its value still contained 'endOfMibView' would cause it to be re-dispatched to the lexically next region according to the given procedure. The eSNMP implementation used the pre-view processing but did not implement the view bitmask and therefore had no post-view processing. Dave. ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Wed, 12 Jun 1996 17:41:22 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA19429 for X-agentx-local; Wed, 12 Jun 1996 17:41:21 -0700 (PDT) Received: from hammurabi.nh.ultra.net (hammurabi.nh.ultra.net [205.162.79.24]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id RAA19422 for ; Wed, 12 Jun 1996 17:41:18 -0700 (PDT) Received: from keeney (dek.bluefin.net [205.162.68.223]) by hammurabi.nh.ultra.net (8.7.4/dae0.6) with SMTP id UAA19733 for ; Wed, 12 Jun 1996 20:41:17 -0400 (EDT) Date: Wed, 12 Jun 1996 20:41:17 -0400 (EDT) Message-Id: <199606130041.UAA19733@hammurabi.nh.ultra.net> X-Sender: keeney@pop.nh.ultranet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: David Keeney Subject: RE: 02f Character Set I have opened a new sub-item under Architecture in the Open issues list on the Agentx Web site and have called it 02f Character Set. We currently have 13 responses in this category. ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Wed, 12 Jun 1996 18:04:58 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id SAA24485 for X-agentx-local; Wed, 12 Jun 1996 18:04:58 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id SAA24436 for ; Wed, 12 Jun 1996 18:04:44 -0700 (PDT) From: kennethw@VNET.IBM.COM Message-Id: <199606130104.SAA24436@zloty.fv.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8725; Wed, 12 Jun 96 21:04:28 EDT Date: Wed, 12 Jun 96 20:55:39 EDT To: agentx@fv.com, natale@acec.com Subject: Character Sets in AgentX Bob, >First, let me say (as wg chair) that since DPI v2 is the base >document for AgentX, then changes which impair deployed DPI v2 >implementations are to be avoided unless those changes are >essential to meeting our charter requirements...and they do >include engineering goals such as efficiency and self-consistency, >among others (under the general rubric of "protocol quality"). I doubt that dropping support of native character sets or leaving it in will effect the chances of meeting the working group's charter. I don't understand what the problem is in allowing agents and their subagent the choice of supporting non-ASCII based character sets. >Now (as a technical contributor)...I am somewhat opposed to >the idea of including the character set indicator in AgentX. >In part, this results from my original position that I would >prefer to have the master agent and the subagents exchange >SNMP messages (with a small number of new message types >included for OPEN, REGISTER, etc.)--but that position was >generally rejected by the wg. So be it. Nonetheless, the >questions asked below--which, in my view somewhat relate >to the underlying, quintessential SNMP nature of AgentX-- >have yet to be answered satisfactorily, IMHO: >> I also think that the special treatment of DisplayStrings (which are >> just a MIB specific interpretation of OCTET STRINGS) in the agentx >> protocol is irritating. How does the master agent decide if an OCTET >> STRING value contained in a SNMP request is processed like a >> DisplayString or not? Do you require that the master agent has >> knowledge about the MIBs implemented by the subagents? Is it really an >> acceptable design decision to hard wire this one textual convention >> while keeping the implementation of all other textual conventions up >> to the implementor of the MIB objects? I'm not trying to be controversial but its irritating to me to have to convert to ASCII in numerous subagents when my current agent does this quite well. I didn't create the concept of DisplayString but prefer it to just OCTET STRING for objects that truly represent textual data. We compile our MIBs into our agent, thus giving the agent full knowledge of our MIBs. This isn't necessary but does yield the side benefit of having the agent handle character conversion. I thought that it was common practice to use compiled MIBs for providing MIB knowledge. To me DisplayString is special since it implies character data which within the an agent's operational domain may not be ASCII. Continued support of native character set allows non-ASCII based platforms to maintain compatibility with DPI and allows the agent implementer the flexibility to decide what to implement. An ASCII based agent just ignores it. >I think these are very good questions. SNMP messages do not >convey information about DisplayStrings...or any other textual >conventions...only the types defined as "ObjectSyntax" in RFC 1902. >Why should a subagent need to know anything more to answer an >SNMP query (or set a value)? Textual conventions seem, to me, >to be primarily relevant at the application/presentation layer. >(Granted some TCs have "behavioral" implications in the agent, >but these are typically not variant at run time in the agent.) >> Unless someone has some very convincing arguments, I propose >> to remove the concept of different character sets and to remove >> the special tag for DisplayStrings. >I agree. I have not seen a convincing argument yet. Maybe >I have not put enough effort/intelligence into understanding >Bert's rationale (which seem post facto sensible, but do not >seem to offer the a priori justification). I guess what I'd >ask is "Can an MVS box with a TCP/IP stack include a native, >monolithic SNMP agent today that will respond correctly to >normal SNMP Get and Set requests carrying OCTET_STRING varbinds?". >And, if the answer to that is "yes", then "Why is it necessary >for subagents on that platform to have other capabilities in >this respect?". If an agent does have awareness of which objects are of DisplayString TC then to have it perform the conversion (if not ASCII based and if a subagent informs the agent that it wants the conversion to occur) is simple. My argument for keeping the capability is for migration from DPI to agentx and that it makes subagent development simpler on non-ASCII platforms. The cost of leaving this in the protocol is much less than removing it. >> I hope some of the above helps convince you... or at least >> take your concerns away. I have had this argument agains >> non-ASCII character sets many times.... >Yes, and both your patience and your persistence are to be >admired! :-) >> my main convincing argument I think is: >> The DPI apporach solves the non-ASCII related problems >Ah, there's the rub, I for one don't see why there is any >such thing as "the non-ASCII related problems"...? Do you work on a non-ASCII based system? I find it a problem. I would like to continue to have a agent and its subagents on non-ASCII based platforms decide how they handle character conversion between themselves. >> while at the same time it is a MOOT POINT for the ASCII world. >> We tried very hard, to make this indeed transparent to the ASCII >> world so that they would not be bothered with our (IBM) problems. >And that will probably end up being its salvation...unless, >of course, we can convince you that IBM really doesn't have >any problems (in this respect). :-) <...> >> For us it has worked very well, that is why we want to see >> continued support for this. >And, as I said above, there is a procedural bias toward doing >this. Bob, you previously said that DPI was adopted as the base for agentx. This capability is in DPI. Why not leave it. What are the arguments for taking it out? The only one I can remember is that it simplifies the protocol. To me this isn't enough justification for removing it since there are DPI implementations that use and like it. How does it adversely effect ASCII based agents? >> Has anyone else experience with an environment that is non-ASCII ? >Not insofar as SNMP is concerned! :-) I believe that IBM has provided SNMP support on VM and MVS which are EBCDIC based systems for a number of years. >Cordially, >BobN Regards, Ken White IBM TCPIP for MVS Development   Delivery-Date: Wed, 12 Jun 1996 22:10:36 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id WAA16939 for X-agentx-local; Wed, 12 Jun 1996 22:10:36 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id WAA16931 for ; Wed, 12 Jun 1996 22:10:34 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id BAA21568; Thu, 13 Jun 1996 01:10:33 -0400 Date: Thu, 13 Jun 1996 01:09:53 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13813; Thu, 13 Jun 1996 01:09:53 -0400 Message-Id: <9606130509.AA13813@nips.acec.com> To: kennethw@VNET.IBM.COM Subject: Re: Character Sets in AgentX Cc: agentx@fv.com > Date: Wed, 12 Jun 96 20:55:39 EDT > From: kennethw@VNET.IBM.COM Hi Ken, <...much deleted throughout...> > I'm not trying to be controversial Likewise (although it seems like I do it without trying! :-). > We compile our MIBs into our agent, thus giving the > agent full knowledge of our MIBs. This isn't necessary but does yield > the side benefit of having the agent handle character conversion. I > thought that it was common practice to use compiled MIBs for > providing MIB knowledge. When you say "agent" here, are you referring to the master agent? I presume so, and then I find your practice very interesting (and exactly what I would do in this specific respect). Yes, I'd say it is obviously common practice to use cmopiled MIBs for providing MIB knowledge...although typically at build-time for agents vs run-time (load or access) for manager apps. (As I've said before, I would have like to see load-time MIB knowledge for the master agent built into AgentX.) > My argument for keeping > the capability is for migration from DPI to agentx and > that it makes subagent development simpler on non-ASCII platforms. > The cost of leaving this in the protocol is much less than > removing it. And that is definitely a valid consideration...but it must be assessed (by the wg) in light of the collection of such valid considerations (see below). > Do you work on a non-ASCII based system? Not in the past 10 years or so. ;-) > Bob, you previously said that DPI was adopted as the base for > agentx. VERY IMPORTANT (speaking as wg chair): The DPI v2 specification *document* was adopted as the baseline for working on the AgentX protocol...as a starting point for discussion, debate, refinement, wholesale changes, etc...whatever comes out of it. You might even think of it as just a catalyst. Speaking as a technical contributor, I think that DPI v2 is a very workable protocol and I suspect that a lot of it will be incorporated in AgentX...but at the moment that's still up for grabs. > This capability is in DPI. Why not leave it. What are > the arguments for taking it out? The only one I can remember is that > it simplifies the protocol. To me this isn't enough justification > for removing it since there are DPI implementations that use and like > it. How does it adversely effect ASCII based agents? Keeping the protocol simple, efficient, minimal, and implementable is a big part of "protocol quality"...the wg must consider the entire collection of requirements/features that included to satisfy less-than-universal constituencies...so far, I can think of two things--priority and character sets--that really do not play a *necessary* role in the general use of AgentX...and I think that number is small enough to not pose a threat...but you have to question each and every one in depth to avoid "opening the floodgates", as it were. >>> Has anyone else experience with an environment that is non-ASCII ? > >>Not insofar as SNMP is concerned! :-) > > I believe that IBM has provided SNMP support on VM and MVS which are > EBCDIC based systems for a number of years. Yes, and again I would just like to know what happens when, for example, an HP OpenView management app sends a Get-Request for sysDescr to such an agent...? (I am interested in pursuing this only out of intellectual curiousity...not as a further debating point on this thread...my own personal view is that we can live with a character set indicator and a priority indicator--both of which I personally consider useless overhead in the protocol.) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ 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 ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 13 Jun 1996 01:36:04 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id BAA24209 for X-agentx-local; Thu, 13 Jun 1996 01:36:03 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id BAA24192 for ; Thu, 13 Jun 1996 01:36:02 -0700 (PDT) Message-Id: <199606130836.BAA24192@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2738; Thu, 13 Jun 96 04:35:49 EDT Date: Thu, 13 Jun 96 10:35:52 DST From: "Bert Wijnen" To: agentx@fv.com Subject: Re: 02f Character Set BobN answers to Ken White: > > I believe that IBM has provided SNMP support on VM and MVS which are > > EBCDIC based systems for a number of years. > > Yes, and again I would just like to know what happens when, for example, > an HP OpenView management app sends a Get-Request for sysDescr to such > an agent...? (I am interested in pursuing this only out of intellectual > curiousity...not as a further debating point on this thread... > OK, let me explain so that we all understand... because this question seems to indicate that a non-EBCDIC based SNMP manager might be impacted also. So on an EBCDIC system: - The SNMP manager (be it IBM NetView, HP OpenView, or any other) sends the SNMP request. A varbind (sysDescr,0, NULL). The NULL (or any other value) is ignored at the agent. - The master agent just sends it to the subagent. - The subagent has either: - hardcoded value like "Some system Description" which if compiled on the EBCDIC system would be an EBCDIC string. - a string that is read from a configuration file. In most cases the string in that config file is also EBCDIC (so that humans rean read it if they edit/browse the config file). The subagents sends a response to the master agent, using the EBCDIC string as the value and indicates that it is a DisplayString (after all, we assume that the subagent does have knowledge about the MIB... how else would it be able to implement it??). - The master agent sees the DisplayString as the TYPE in the subagent response. It converts the EBCDIC string into ASCII changes the type to OCTET STRING in the SNMP response that is then send back to the manager. ASCII based agents are not impacted (it is a MOOT POINT remember): - The SNMP manager (be it IBM NetView, HP OpenView, or any other) sends the SNMP request. A varbind (sysDescr,0, NULL). The NULL (or any other value) is ignored at the agent. - The master agent just sends it to the subagent. - The subagent has either: - hardcoded value like "Some system Description" which if compiled on the ASCII system would be an ASCII string - a string that is read from a configuration file. In most cases the string in that config file is also ASCII (so that humans rean read it if they edit/browse the config file). The subagents sends a response to the master agent, using the ASCII string as the value and indicates that it is a DisplayString (after all, we assume that the subagent does have knowledge about the MIB... how else would it be able to implement it??). - The master agent sees the DisplayString as the TYPE in the subagent response. It changes the type to OCTET STRING in the SNMP response that is then send back to the manager. Pretty simple is it not. Bert Wijnen   Delivery-Date: Thu, 13 Jun 1996 07:24:43 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id HAA27374 for X-agentx-local; Thu, 13 Jun 1996 07:24:43 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id HAA27369 for ; Thu, 13 Jun 1996 07:24:42 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA17866; Thu, 13 Jun 1996 10:19:47 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA11891; Thu, 13 Jun 1996 10:19:46 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA18855; Thu, 13 Jun 1996 10:21:01 -0400 Message-Id: <9606131421.AA18855@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: 02f Character Set Date: Thu, 13 Jun 96 10:21:00 -0400 From: Mike Daniele X-Mts: smtp Hi Bert, >OK, let me explain so that we all understand... because this question >seems to indicate that a non-EBCDIC based SNMP manager might be >impacted also. So on an EBCDIC system: > - The SNMP manager (be it IBM NetView, HP OpenView, or any other) > sends the SNMP request. A varbind (sysDescr,0, NULL). The NULL > (or any other value) is ignored at the agent. > - The master agent just sends it to the subagent. > - The subagent has either: > - hardcoded value like "Some system Description" > which if compiled on the EBCDIC system would be an EBCDIC > string. > - a string that is read from a configuration file. In most cases > the string in that config file is also EBCDIC (so that humans > rean read it if they edit/browse the config file). > The subagents sends a response to the master agent, using the > EBCDIC string as the value and indicates that it is a DisplayString > (after all, we assume that the subagent does have knowledge about > the MIB... how else would it be able to implement it??). > - The master agent sees the DisplayString as the TYPE in the > subagent response. It converts the EBCDIC string into ASCII > changes the type to OCTET STRING in the SNMP response that is > then send back to the manager. So the bottom line is the manager and the agent expect ASCII on the wire, regardless of the native character set? Clearly the simplest way to handle this in AgentX would be to specify ASCII to/from the subagent, and let the subagent deal with non-ASCII issues. The objections I hear to this idea are: 1) This would make (DPI) subagent implementation more difficult. 2) If both subagent and master agent are EBCDIC, this forces both sides to do unnecessary conversions. Is that about right? Also, could you explain how it work for SetRequests? Again, sorry for the confusion of not being able to straighten this out before it hit the wg... Thanks, Mike   Delivery-Date: Thu, 13 Jun 1996 09:08:25 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA21690 for X-agentx-local; Thu, 13 Jun 1996 09:08:24 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA21680 for ; Thu, 13 Jun 1996 09:08:21 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA32673; Thu, 13 Jun 1996 11:53:01 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05526; Thu, 13 Jun 1996 11:53:00 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA18937; Thu, 13 Jun 1996 11:54:17 -0400 Message-Id: <9606131554.AA18937@bernie.zk3.dec.com> To: agentx@fv.com Subject: your comments Date: Thu, 13 Jun 96 11:54:16 -0400 From: Mike Daniele X-Mts: smtp Hi Dave! >1) Include/Exclude flag in SearchRange > RE: 6.1.3 SearchRange > The search range set needs an additional flag. In the usage as described, > for a GETNEXT or GETBULK, the g.requested field is either the OID of the > SNMP request or the start of a registered region. It may also be > someplace in the middle of a region if views are implemented (see below). > If g.requested field is not the OID of the SNMP request and > happens to be an instance, then that OID will never be returned > by an subagent because it is looking for something lexically greater. No, g.requested is ALWAYS the OID from the SNMP request PDU. From 7.2.1.2 (7) The variable binding's name is copied to g.requested. I agree that the method used in eSNMP makes the subagent code more effecient, but I thought it would be wise to trade that off against protocol simplicity. The AgentX subagent is not told which if its registered regions was selected. It is simply told what the requested oid is, and optionally where to stop looking (g.limit). It has to figure out the rest. >2) Views > Views should be performed entirely by the Master Agent. That seemed to be the consensus in previous discussion (I think Aleksey was a notable dissenter.) I also think that's specified in the draft, at least I hope so :-) >In addition, the view check should be performed on the request OID (g.requested) >prior to > sending the request to the subagent. A view can be thought of as > a set of regions in the same way as the subtree registrations. > By taking into account the included and excluded parts of a view, > it can be reduced to a list of regions. The view check could be very > simular to searching for the next active registered region. > For a GET/SET operation, the operation can be rejected right away if > it is outside the view (i.e. is not within one of the view regions). > For GETNEXT/GETBULK operations, if the value of g.requested is not in > the view, then the master should continue to look for a lexically greater > registered subtree region until it finds one that is within view or has at > least part of it within view. If the first part of the region is not >within > view, move ahead to the first OID within that region that is within > view and make that the new g.requested value (the starting point > of the search - mark this with the searchrange include flag). > Now that we have the starting point, we must then check the g.limit > field to see if there is a contiguous range that is in view. If the > view is more restrictive, then g.limit should be adjusted to the end > of the view range. That means that if we must later re-dispatch a > request, the master agent must start at the previous g.limit when searching > for another "in view" segment rather than at the next lexically registered > subtree region as stated in the procedure in 7.2.3 step 5. There could > possibly be a second view range within the same region. > Note that if a bit mask is used with a view specification, the view may > be riddled with holes. I suggest that the above view check should be > performed without the bit mask so that we are dealing with contiguous > ranges. But if a bit mask is present, an additional check should be > performed on the OID returned by the subagent to see if it is still in >view. Thanks for making several good points. Bert had also made some similar suggestions recently. At this point I'm leaning towards removing any discussion of how specifically (algorithmically) to handle views. Just mention that view information is currently not specified in AgentX the elements of procedure may be optimized in an implementation-specific fashion to optimize operational dispatching with respect to MIB views g.limit may be used in this regard, since we DO specify that a subagent must limit its response based on g.limit I'd be interested in feedback from you and everyone else about this. >3) Priority > RE: 7.1.2.2.2 Handling Duplicate Regions (Register PDU) > Here you are specifying the precedence of overlapping registrations. > With the order that you specify, the most specific r.region takes > precidence over the piority. I would expect that priority should > come first since it is your overide. If you wanted a larger registration > to take precedence over (and hiding) a smaller region, you should be > able to set the larger region's priority higher so it can take precidence. >(start soapbox) > The registration priority should be something that is set by the user > (system admin) as a runtime parameter or configuration of the SUBAGENT. > This could then be used to modify or overide the default behavior of > registration precedence to fix problems that could occur from conflicting > registrations. At least the system administrator should be able to overide > it if he/she does not like the default behavior. >(end soapbox). Well, I'm really just echoing what I thought was the general consensus. The scenario that was described for using priority was overriding an existing, out of rev subagent. In this case the registered regions would be identical... Also, I think the stated order of processing duplicates will be required for handling row creation. But that's TBD. What you're objecting to is the "watering down" of priorities, right? That is, the system admin can't effect as much change by changing priorities (assuming they were command line options when starting subagents). >4) GETBULK processing > RE: 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU > The subagent should also teminate the processing when it fills its > buffer or has reached the max_iteration count. I think reaching the max count is covered by the 2 "for" loops in the general description. "Running out of buffer" is definitely TBD. We had been discussing this in a thread on transports. >5) VarBind response processing > RE: 7.2.3, step 4 Regarding your comments on view processing: More reason (to me) to remove the specifics of view handling. Thanks for your comments Dave. Mike   Delivery-Date: Thu, 13 Jun 1996 10:12:44 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA07240 for X-agentx-local; Thu, 13 Jun 1996 10:12:43 -0700 (PDT) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA07227 for ; Thu, 13 Jun 1996 10:12:42 -0700 (PDT) Message-Id: <199606131713.AA100216009@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA100216009; Thu, 13 Jun 1996 10:13:29 -0700 Date: Thu, 13 Jun 1996 10:13:29 -0700 From: Randy Presuhn To: agentx@fv.com Subject: Re: 02f Character Set Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9606131421.AA18855@bernie.zk3.dec.com> > To: agentx@fv.com > Subject: Re: 02f Character Set > Date: Thu, 13 Jun 96 10:21:00 -0400 > From: Mike Daniele ... > Clearly the simplest way to handle this in AgentX would be to specify > ASCII to/from the subagent, and let the subagent deal with non-ASCII > issues. ... This sounds reasonable to me. I think character set conversion should be handled in the subagent run-time library to allow whatever API is in use to employ the native character set. This minimizes developer impact, minimizes protocol complexity, and sidesteps two nasty questions: A) If we support multiple character sets in the subagent protocol (ASCII, EBCDIC, and ISO 10646 come to mind), which character set conversions must be supported for an implementation to claim conformance to the specification? B) Both EBCDIC and ISO 10646 contain all sorts of things that don't have obvious ASCII counterparts. Will we be standardizing the mappings? Back in the 1970's (the last time I had to deal with EBCDIC) there were a couple of different flavors. Are we going to specify which ones are supported? > The objections I hear to this idea are: > > 1) This would make (DPI) subagent implementation more difficult. > > 2) If both subagent and master agent are EBCDIC, this forces > both sides to do unnecessary conversions. ... Issue (1) can be handled within a subagent run-time library. A run-time library needs to know DisplayString / OCTET STRING differences anyway. I agree with the need to avoid requiring the application developer to deal with these conversions. I don't understand the reasoning behind (2). For DisplayString variables, only one conversion occurs in any of these approaches. String-encoded OBJECT IDENTIFIERs need to be re-encoded into a usable representation anyway, and there'd be little value in doing a translation to the native character set. The string encoding has several problems: - it does not aid get-next and get-bulk processing: (string comparison of 1.2.3.4 and 1.2.20.4 gives the wrong result for both character sets) - it is not space efficient (it can't take less than twice as much space as the BER encoding; it can take around four times as much space) - it is not processing efficient (generating the string form from the BER is more expensive than the generation of other useful representations) - (a big nit) The use of the dotted decimal form is certainly well- established. However, the dotted string form is not a valid ASN.1 value notation, and the Agentx document should not pretend that it is. (See ASN.1 clause 28.3 for the standardized notation.) If we really do want to use this dotted decimal notation, despite its inefficiency, we should define it. In particular, some DPI implementations have been quite fussy about whether a final trailing "." was required, and there is that old question about leading zeroes (needed if string comparison is going to be made to work.) ----------------------------------------------------------------------------- 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: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 13 Jun 1996 10:43:07 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA14280 for X-agentx-local; Thu, 13 Jun 1996 10:43:07 -0700 (PDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA14276 for ; Thu, 13 Jun 1996 10:43:06 -0700 (PDT) Received: from [171.68.13.6] (c1robo6.cisco.com [171.68.13.6]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id KAA26552; Thu, 13 Jun 1996 10:42:32 -0700 X-Sender: bstewart@puli.cisco.com (Unverified) Message-Id: In-Reply-To: <199606112129.RAA36294@mailhub1.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jun 1996 22:44:05 -0400 To: "Geoff Carpenter (8-862-1970)" , agentx@fv.com From: Bob Stewart Subject: Re: DRAFT agentX text Circa 4:53 PM -0400 6/11/96, Geoff Carpenter (8-862-1970) bitwhacked: >The request is to retain the hooks needed to make >the protocol work on machines with non-ASCII character sets. Beware the slippery slope. We're dancing around the sort of issues that were a reason this whole effort was fought off for a long time. We're down into some fairly deep issues of implementation. In general IETF work doesn't care what sort of machine it's implemented on. When we start caring my alarms go off. Bob   Delivery-Date: Fri, 14 Jun 1996 05:34:15 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA08204 for X-agentx-local; Fri, 14 Jun 1996 05:34:15 -0700 (PDT) Received: from world.bostech.com (world.bostech.com [192.52.71.122]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA08193 for ; Fri, 14 Jun 1996 05:34:11 -0700 (PDT) From: dkeeney@bostech.com Received: from btrd.bostech.com (opus.bostech.com) by world.bostech.com (4.1/SMI-4.1) id AA10668; Fri, 14 Jun 96 08:17:13 EDT Received: from heat.bostech.com by btrd.bostech.com (4.1/SMI-4.0) id AA08496; Fri, 14 Jun 96 08:21:28 EDT Message-Id: <9606141221.AA08496@btrd.bostech.com> Subject: SearchRange To: agentx@fv.com Date: Fri, 14 Jun 1996 08:21:27 -0400 (EDT) Cc: keeney@mv.mv.com X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike, Just to summarize, you are proposing that the SearchRange be as follows: g.requested - Always the requested OID from the SNMP request. It specifies the starting point for the search in the subagent (exclusive). g.limit - ending OID of the range (exclusive). Rules: Change g.requested only when re-dispatching and then change it to a previously received value (needed for GETBULK and possibly views). I think the SearchRange should be defined (as used in eSNMP) as follows: g.start - starting OID of the search range g.flag - a flag indicating that g.start should be included or excluded from the range. g.limit - ending OID of the range (exclusive). Rules: Never dispatch an OID range that is outside a region that the subagent has registered. Here is another example of where your proposed method does not work (something not involving views): Subagent A registers region A and has instances at OID's a1 and a3. Subagent B registers region B and lets say the conditions are such that B's registration has precedence over region A. a1 a2 a3 | | | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBB | Requested OID -----' Now, lets say on a GETNEXT request for the "Requested OID", that region B contains no instances that subagent B can return (its near the end of the range or something). So, the master agent re-dispatches it to subagent A where it should start searching at OID a2 and return its first instance at a3. Using your approach it would return the instance at a1. I would consider that a bug because a1 exists in a range for which B has precedence and therefore should be allowed to mask the instance at a1. To allow the master to get instances in this way could lead to inconsistant data. In addition, your new approach assumes that each subagent must keep track of which ranges it has registered. Lets keep the subagent as simple as possible. Assume the most general case and that is that the subagent has a single object table (or case of method routines) containing all of the objects it implements. It may contain objects that it has implemented but not registered. (it knows a driver was not loaded or something). With the eSNMP approach the subagent does not need to duplicate the bookkeeping maintained by the master agent as to which regions are currently active. The eSNMP approach has one more thing in its favor, it has an implimentation in the field. Dave.   Delivery-Date: Fri, 14 Jun 1996 05:52:38 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA11943 for X-agentx-local; Fri, 14 Jun 1996 05:52:37 -0700 (PDT) Received: from world.bostech.com (world.bostech.com [192.52.71.122]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA11935 for ; Fri, 14 Jun 1996 05:52:34 -0700 (PDT) From: dkeeney@bostech.com Received: from btrd.bostech.com (opus.bostech.com) by world.bostech.com (4.1/SMI-4.1) id AA10786; Fri, 14 Jun 96 08:44:15 EDT Received: from heat.bostech.com by btrd.bostech.com (4.1/SMI-4.0) id AA09722; Fri, 14 Jun 96 08:48:30 EDT Message-Id: <9606141248.AA09722@btrd.bostech.com> Subject: RE: Registration Priority To: agentx@fv.com Date: Fri, 14 Jun 1996 08:48:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike, >>3) Priority >> RE: 7.1.2.2.2 Handling Duplicate Regions (Register PDU) >> Here you are specifying the precedence of overlapping registrations. >> With the order that you specify, the most specific r.region takes >> precidence over the piority. I would expect that priority should >> come first since it is your overide. If you wanted a larger registration >> to take precedence over (and hiding) a smaller region, you should be >> able to set the larger region's priority higher so it can take precidence. >>(start soapbox) >> The registration priority should be something that is set by the user >> (system admin) as a runtime parameter or configuration of the SUBAGENT. >> This could then be used to modify or overide the default behavior of >> registration precedence to fix problems that could occur from conflicting >> registrations. At least the system administrator should be able to >> overide it if he/she does not like the default behavior. >>(end soapbox). >Well, I'm really just echoing what I thought was the general consensus. >The scenario that was described for using priority was overriding an >existing, out of rev subagent. In this case the registered regions would >be identical... Maybe not. Look at Digital Unix where some of the routing table stuff is implemented in the os_mibs subagent (an eSNMP subagent which covers most of MIB II). If you ran gated rather than routed, the eSNMP agent in gated expects to overide the default registrations in the os_mibs subagent. Those registrations were not identical... >Also, I think the stated order of processing duplicates will be required >for handling row creation. But that's TBD. >What you're objecting to is the "watering down" of priorities, right? >That is, the system admin can't effect as much change by changing >priorities (assuming they were command line options when starting >subagents). Yes. Using "most specific" or "most resent" as a way to resolve overlapping registrations is fine in those cases that do not matter as long as there is consistant behavior. But when it does matter and the default resolution gets it wrong, we need a way to manually overide it. There is nothing about "most specific" or "most resent" that makes one subagent "Better" than another subagent. Why wouldn't the "least specific" registration be just as good a criteria? It would be more efficent. Dave.   Delivery-Date: Fri, 14 Jun 1996 08:52:00 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA21766 for X-agentx-local; Fri, 14 Jun 1996 08:51:59 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA21757 for ; Fri, 14 Jun 1996 08:51:58 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA12063; Fri, 14 Jun 1996 10:12:13 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA31802; Fri, 14 Jun 1996 10:12:13 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA19516; Fri, 14 Jun 1996 10:13:28 -0400 Message-Id: <9606141413.AA19516@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: SearchRange In-Reply-To: Your message of "Fri, 14 Jun 96 08:21:27 EDT." <9606141221.AA08496@btrd.bostech.com> Date: Fri, 14 Jun 96 10:13:27 -0400 From: Mike Daniele X-Mts: smtp Hi Dave, >Subagent A registers region A and has instances at >OID's a1 and a3. >Subagent B registers region B and lets say the conditions >are such that B's registration has precedence over region A. > a1 a2 a3 > | | | > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > BBBBBBBBBBBBBBBBBBBBBBBBBBBB > | > Requested OID -----' This is ambiguous (at least to me). Can we instead use the example from the draft? S2 registered 1.3.6.1.2.1.4 S1 registered 1.3.6.1.2.1.4.22 S3 registered 1.3.6.1.2.1 we have 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) >Now, lets say on a GETNEXT request for the "Requested OID", >that region B contains no instances that subagent B can return >(its near the end of the range or something). OK, let's assume getnext( 1.3.6.1.2.1.4.22.something ) Further, assume default priorities used by all subagents. Then the order of precedence (by regionspecifier length) is S1, S2, S3. If S1 returns endofmibview, from 7.2.3: 5) After all expected response PDUs have been processed, if any variable bindings still contain the value `endOfMibView', processing must continue: - For each such variable binding, a target region is identified which is the lexicographical successor to the target region for this variable binding on the last iteration. The target subagent is the one that registered the target region. This would be 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 and S2 has precedence. ... - Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. The variable binding's name is copied to g.requested. g.limit is set to So S2 sees getnext( 1.3.6.1.2.1.4.22.something ). And in this case it could possibly return data from the previous region (for which it does not have precedence). You are correct. The question then is "does that matter"? I agree with you, I think it does, and that this should be tightened. Given that, and in light of the recent arguments about narrowing view scope, I think we do need to indicate a starting oid in the searchrange that may or may not be the same as the requested oid. (and that requires an include/exclude flag). > g.start - starting OID of the search range > g.flag - a flag indicating that g.start should > be included or excluded from the range. > g.limit - ending OID of the range (exclusive). > Rules: Never dispatch an OID range that is outside > a region that the subagent has registered. I had relaxed this rule (the use of g.limit) to let the subagent return data from any of the consecutive regions for which it has precedence, as opposed to limiting it to the specific target region. I still think this relaxation is useful and valid. Why do you feel the g.limit rule needs to be more restrictive? Is it because of > In addition, your new approach assumes that each subagent >must keep track of which ranges it has registered. >Lets keep the subagent as simple as possible. Assume >the most general case and that is that the subagent has a >single object table (or case of method routines) containing >all of the objects it implements. >It may contain objects that it has implemented but not >registered. (it knows a driver was not loaded or something). I think it's reasonable to expect the subagent be able to respond to "return the variable > or >= g.start, and < g.limit" regardless of what regions it registered, and where g.limit falls wrt registered regions. >With the eSNMP approach the subagent does not need to >duplicate the bookkeeping maintained by the master >agent as to which regions are currently active. Nor does the subagent here. g.limit is set by the master agent to ensure the subagent does not return something from a region for which it does not have precedence. I think I'm missing your point. Thanks, Mike   Delivery-Date: Fri, 14 Jun 1996 09:57:26 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA07292 for X-agentx-local; Fri, 14 Jun 1996 09:57:26 -0700 (PDT) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA07276 for ; Fri, 14 Jun 1996 09:57:24 -0700 (PDT) Message-Id: <199606141658.AA104691488@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA104691488; Fri, 14 Jun 1996 09:58:08 -0700 Date: Fri, 14 Jun 1996 09:58:08 -0700 From: Randy Presuhn To: agentx@fv.com Subject: RE: Registration Priority Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: dkeeney@bostech.com > Message-Id: <9606141248.AA09722@btrd.bostech.com> > Subject: RE: Registration Priority > To: agentx@fv.com > Date: Fri, 14 Jun 1996 08:48:27 -0400 (EDT) ... > Yes. Using "most specific" or "most resent" as a way to resolve > overlapping registrations is fine in those cases that do not matter > as long as there is consistant behavior. But when it does matter > and the default resolution gets it wrong, we need a way to manually > overide it. Agreed. > There is nothing about "most specific" or "most resent" that makes > one subagent "Better" than another subagent. Why wouldn't the > "least specific" registration be just as good a criteria? It would > be more efficent. ... Giving priority to the "least specific" registration causes problems where multiple subagents are resposible for different rows of a table and there is also a need to support row creation. The subagent that will handle the row creation requests will necessarily have a "less specific" registration than the subagents resposible for rows that already exist. >From an implementation perspective, I believe it is simplest and most efficient to treat the requested / assigned priority of registrations as a "tie breaker". In the case where a registration request requests the same priority and subtree as an existing registration, we have two options to choose from that keep implementation simple and predictable: 1) reject the registration 2) accept the registration, assigning a different priority from the one that was requested. The choices: a) later gets better a) later gets worse. It sounds like option 2a is probably the one most useful and intuitive. ----------------------------------------------------------------------------- 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: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 14 Jun 1996 14:44:24 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA15079 for X-agentx-local; Fri, 14 Jun 1996 14:44:23 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA15073 for ; Fri, 14 Jun 1996 14:44:21 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id RAA27230; Fri, 14 Jun 1996 17:44:20 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06127; Fri, 14 Jun 1996 17:43:04 -0400 Date: Fri, 14 Jun 1996 17:47:39 EDT From: Bob Natale Subject: AgentX WG Agenda for Montreal To: agenda@ietf.org Cc: agentx@fv.com, kostick@qsun.ho.att.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I am very sorry...I was fairly certain I had submitted this info much earlier in the process...it appears I was mistaken. BobN ------------------------------------------------------------- AgentX Agenda for Montreal IETF Meetings Tue, June 25: 0900 - 1100 Wed, June 26: 1300 - 1500 ------------------------- 1. Agenda Bashing 2. Review of Charter, Milestones 3. Summary of Progress-to-Date 4. Detailed discussion of AgentX Protocol I-D (this may take the bulk of both meetings and is the top priority topic at this time) 5. Review of status wrt API I-D 6. Review of status wrt MIB I-D (#5/6 may be scratched if #4 requires the time) 7. Prepared presentations (will be accommodated and may be scheduled into earlier points if indicated by topic) 8. "Open mike" (throughout, no doubt!) 9. Review of remaining/new action items 10. Action item workplan   Delivery-Date: Sun, 16 Jun 1996 04:33:06 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA06181 for X-agentx-local; Sun, 16 Jun 1996 04:33:06 -0700 (PDT) Received: from hammurabi.nh.ultra.net (hammurabi.nh.ultra.net [205.162.79.24]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id EAA06119 for ; Sun, 16 Jun 1996 04:33:01 -0700 (PDT) Received: from keeney (dek.bluefin.net [205.162.68.223]) by hammurabi.nh.ultra.net (8.7.4/dae0.6) with SMTP id HAA17995 for ; Sun, 16 Jun 1996 07:32:58 -0400 (EDT) Date: Sun, 16 Jun 1996 07:32:58 -0400 (EDT) Message-Id: <199606161132.HAA17995@hammurabi.nh.ultra.net> X-Sender: keeney@pop.nh.ultranet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: David Keeney Subject: Re: SearchRange Mike, ...lots of good stuff removed talking about a case where the proposed searchrange would not work..... >And in this case it could possibly return data from the previous >region (for which it does not have precedence). > >You are correct. The question then is "does that matter"? > >I agree with you, I think it does, and that this should be tightened. Good. I am glad you could follow my example in spite of the poor description. > >Given that, and in light of the recent arguments about narrowing >view scope, I think we do need to indicate a starting oid in the >searchrange that may or may not be the same as the requested oid. >(and that requires an include/exclude flag). OK, we agree on g.start and g.flag then. > >> g.start - starting OID of the search range >> g.flag - a flag indicating that g.start should >> be included or excluded from the range. >> g.limit - ending OID of the range (exclusive). > >> Rules: Never dispatch an OID range that is outside >> a region that the subagent has registered. > >I had relaxed this rule (the use of g.limit) to let the >subagent return data from any of the consecutive regions for >which it has precedence, as opposed to limiting it to the specific >target region. > >I still think this relaxation is useful and valid. Why do you >feel the g.limit rule needs to be more restrictive? > >Is it because of > >> In addition, your new approach assumes that each subagent >>must keep track of which ranges it has registered. >>Lets keep the subagent as simple as possible. Assume >>the most general case and that is that the subagent has a >>single object table (or case of method routines) containing >>all of the objects it implements. > >>It may contain objects that it has implemented but not >>registered. (it knows a driver was not loaded or something). > >I think it's reasonable to expect the subagent be able to >respond to "return the variable > or >= g.start, and < g.limit" >regardless of what regions it registered, and where g.limit >falls wrt registered regions. > >>With the eSNMP approach the subagent does not need to >>duplicate the bookkeeping maintained by the master >>agent as to which regions are currently active. > >Nor does the subagent here. g.limit is set by the master agent >to ensure the subagent does not return something from a region >for which it does not have precedence. > The subagent may contain method routines and object tables for elements that it has not registered (perhaps some option not enabled or whatever). These may fall between regions that are registered by this subagent. Let me draw my pictures again. subagent has registered regions A and B but not C AAAAAA CCCC BBBBBBBB The in-between C elements may be implemented by the subagent but not registered. The master agent with the relaxed g.limit may think it is OK to ask for a single range that covers both A's and B's. But what this means is that the subagent must check the ranges requested from the master agent to see if it has registered it to prevent itself from returning one of the unregistered in-between C elements. With the tighter g.limit the searchrange will never span a registration and therefore the subagent does not need to check. I agree that this is a minor thing perhaps but it would help keep things simple in the subagent. Does anyone else have any feelings about this? Dave. ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Sun, 16 Jun 1996 04:33:07 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA06188 for X-agentx-local; Sun, 16 Jun 1996 04:33:07 -0700 (PDT) Received: from hammurabi.nh.ultra.net (hammurabi.nh.ultra.net [205.162.79.24]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id EAA06179 for ; Sun, 16 Jun 1996 04:33:06 -0700 (PDT) Received: from keeney (dek.bluefin.net [205.162.68.223]) by hammurabi.nh.ultra.net (8.7.4/dae0.6) with SMTP id HAA17595 for ; Sun, 16 Jun 1996 07:33:02 -0400 (EDT) Date: Sun, 16 Jun 1996 07:33:02 -0400 (EDT) Message-Id: <199606161133.HAA17595@hammurabi.nh.ultra.net> X-Sender: keeney@pop.nh.ultranet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: David Keeney Subject: RE: Registration Priority Randy, >Giving priority to the "least specific" registration causes problems >where multiple subagents are resposible for different rows of a table >and there is also a need to support row creation. The subagent that >will handle the row creation requests will necessarily have a "less >specific" registration than the subagents resposible for rows that >already exist. > >From an implementation perspective, I believe it is simplest and most >efficient to treat the requested / assigned priority of registrations >as a "tie breaker". In the case where a registration request requests >the same priority and subtree as an existing registration, we have two >options to choose from that keep implementation simple and predictable: > 1) reject the registration > 2) accept the registration, assigning a different priority > from the one that was requested. The choices: > a) later gets better > a) later gets worse. > >It sounds like option 2a is probably the one most useful and intuitive. I understand what you are saying. If we decide to use precedence as part of the facility for handling row creation then "least specific" being considered first is reasonable. But in so doing, for other types of registrations you lose the ability to manually force a "most specific" registration to have precedence in order to solve a conflict problem. Perhaps the tie-breaker priority within a shared table could be a different type of priority. I have not implemented a row creation facility so I will have to bow to those that have spent lots of time thinking about this issue. Could you give us some more details on how you think the shared table could be handled? Dave. ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Mon, 17 Jun 1996 11:22:02 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA18431 for X-agentx-local; Mon, 17 Jun 1996 11:22:01 -0700 (PDT) Received: from IETF.cnri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA18393 for ; Mon, 17 Jun 1996 11:21:59 -0700 (PDT) Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24354; 17 Jun 96 14:12 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: agentx@fv.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-agentx-ext-pro-00.txt Date: Mon, 17 Jun 96 14:12:30 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9606171412.aa24354@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Agent Extensibility Working Group of the IETF. Title : Agent Extensibility (AgentX) Protocol Version 1 Author(s) : M. Daniele, D. Francisco Filename : draft-ietf-agentx-ext-pro-00.txt Pages : 27 Date : 06/14/1996 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. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-agentx-ext-pro-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-ext-pro-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-agentx-ext-pro-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960614164721.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-ext-pro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-ext-pro-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960614164721.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Delivery-Date: Wed, 19 Jun 1996 10:06:34 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA28558 for X-agentx-local; Wed, 19 Jun 1996 10:06:33 -0700 (PDT) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA28532 for ; Wed, 19 Jun 1996 10:06:32 -0700 (PDT) Message-Id: <199606191707.AA160604029@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA160604029; Wed, 19 Jun 1996 10:07:09 -0700 Date: Wed, 19 Jun 1996 10:07:09 -0700 From: Randy Presuhn To: agentx@fv.com Subject: RE: Registration Priority Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - | Date: Sun, 16 Jun 1996 07:33:02 -0400 (EDT) | Message-Id: <199606161133.HAA17595@hammurabi.nh.ultra.net> | To: agentx@fv.com | From: David Keeney | Subject: RE: Registration Priority ... | Could you give us some more details on how you think the shared table | could be handled? ... Let's start by supposing that the following rules are used to determine which subagent is responsible for a mib region: - the longest matching registration wins - ties are broken by the "priority" assigned to the registration - the registration algorithm does not allow multiple registrations of the same subtree with the same priority Let's suppose that the resources to be managed are processes on hot-swapped cards, and that each one is to be given a row in a table, indexed by card. Furthermore, let's support provisioning, i.e., management can configure what is supposed to be installed in a slot at some time in the future. A possible implementation strategy would use two kinds of subagent: - a "rack supervisor" that claims responsibility for the table. this subagent would field requests for creation of new rows and requests for rows for cards which have been pulled out. Note that processing row creation and deletion does NOT require any registration activity with the master agent. - a "card subagent" on each card would claim responsibility for the relevant row. When the card is insterted, the card would register its row with the master agent. (De-registration of the row could be orderly on card shutdown, or handled when the loss of subagent connectivity is detected.) ----------------------------------------------------------------------------- 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: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Wed, 19 Jun 1996 12:08:18 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA26912 for X-agentx-local; Wed, 19 Jun 1996 12:08:17 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA26903 for ; Wed, 19 Jun 1996 12:08:13 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA06030; Wed, 19 Jun 1996 14:59:00 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA29744; Wed, 19 Jun 1996 14:58:23 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA22392; Wed, 19 Jun 1996 15:00:18 -0400 Message-Id: <9606191900.AA22392@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Registration Priority In-Reply-To: Your message of "Wed, 19 Jun 96 10:07:09 PDT." <199606191707.AA160604029@dorothy.peer.com> Date: Wed, 19 Jun 96 15:00:18 -0400 From: Mike Daniele X-Mts: smtp Hi Randy, >Let's start by supposing that the following rules are used to determine >which subagent is responsible for a mib region: > - the longest matching registration wins > - ties are broken by the "priority" assigned to the registration > - the registration algorithm does not allow multiple registrations > of the same subtree with the same priority That draft uses the idea that "longest original registration wins", -------- since registered regions get broken up based on subsequent registrations. A nit... >A possible implementation strategy would use two kinds of subagent: > - a "rack supervisor" that claims responsibility for the table. > this subagent would field requests for creation of new rows and > requests for rows for cards which have been pulled out. Note > that processing row creation and deletion does NOT require > any registration activity with the master agent. > - a "card subagent" on each card would claim responsibility for > the relevant row. When the card is insterted, the card would > register its row with the master agent. (De-registration of > the row could be orderly on card shutdown, or handled when the > loss of subagent connectivity is detected.) Assuming all registrations used the default priority, this strategy would also work if the rules were - highest priority of original registration wins - ties are broken by longest original registration But now suppose your implementation strategy was - a "rack supervisor" that claims responsibility not just for for the table, but for the entire MIB in which this table is defined. - a "card subagent" as described above. This still works as intended given either set of region responsibility rules (again assuming default priorities). But what if some other subagent which understands nothing of your strategy or the card subagents, now registers the table. Under the first set of rules ("your" rules :-) you can never "fix" this by adjusting priorities. Under the second set of rules, you can. Since neither set of rules is a safeguard against stupid or malicious registrations, and using priority as the first tiebreaker seems more flexible, that's what we ended up using in eSNMP (and what Dave is arguing for, I believe). Regards, Mike   Delivery-Date: Wed, 19 Jun 1996 14:16:17 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA24243 for X-agentx-local; Wed, 19 Jun 1996 14:16:17 -0700 (PDT) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA24234 for ; Wed, 19 Jun 1996 14:16:15 -0700 (PDT) Message-Id: <199606192117.AA187019023@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA187019023; Wed, 19 Jun 1996 14:17:03 -0700 Date: Wed, 19 Jun 1996 14:17:03 -0700 From: Randy Presuhn To: agentx@fv.com Subject: Re: Registration Priority Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9606191900.AA22392@bernie.zk3.dec.com> > To: agentx@fv.com > Subject: Re: Registration Priority > Date: Wed, 19 Jun 96 15:00:18 -0400 > From: Mike Daniele ... > That draft uses the idea that "longest original registration wins", > -------- > since registered regions get broken up based on subsequent registrations. ... I had assumed that the draft was just describing one possible implementation strategy, rather than actually requiring "break ups". It's important to demonstrate the soundness of the protocol design by giving existance proofs for algorithms that exhibit the desired behaviour. However, these proofs should not resulting in of decisions that should be left up to implementors being enshrined in the specification. > >A possible implementation strategy would use two kinds of subagent: > > - a "rack supervisor" that claims responsibility for the table. > > this subagent would field requests for creation of new rows and > > requests for rows for cards which have been pulled out. Note > > that processing row creation and deletion does NOT require > > any registration activity with the master agent. > > - a "card subagent" on each card would claim responsibility for > > the relevant row. When the card is insterted, the card would > > register its row with the master agent. (De-registration of > > the row could be orderly on card shutdown, or handled when the > > loss of subagent connectivity is detected.) > > Assuming all registrations used the default priority, this strategy > would also work if the rules were > > - highest priority of original registration wins > - ties are broken by longest original registration The cost of searching a space orgnized in this manner will be higher than the alternative. If searching a space of OID trees of equal priority is O(log2(N)), the first approach, where priority is the tie breaker, search is still O(log2(N)) with a (very small) increased comparison operation cost. The approach of organizing the information into a prioritized set of M spaces would result in a cost O(M) * O(log2(N/M)). Clearly the first alternative scales better, and the more efficient the OID space search algorithm, the more striking the result. The cross-over point to favor the second algorithm is for OID searches requiring O(N) operations -- linear search. > But now suppose your implementation strategy was > > - a "rack supervisor" that claims responsibility not just for > for the table, but for the entire MIB in which this table > is defined. > - a "card subagent" as described above. > > This still works as intended given either set of region responsibility > rules (again assuming default priorities). > > But what if some other subagent which understands nothing of your > strategy or the card subagents, now registers the table. > > Under the first set of rules ("your" rules :-) you can never > "fix" this by adjusting priorities. If there is a registration mib accessible to management, adjusting priority is not necessarily the only way (or even a feasible way) of achieving this goal. For example, in RFC 1227, setting smuxTstatus to invalid(2) would be an effective way of excising the miscreant (without letting it know so that it could turn around and re-register). > Under the second set of rules, you can. When we're dealing with multi-card or multi-processor situations, it's best to not be overly dependent on the components coming up in any particular order. With the first rule set, the case you described produces the same results no matter in what order the cards are inserted. With the second rule set, the algorithm for default priority assignment becomes critically important. > Since neither set of rules is a safeguard against stupid or malicious > registrations, and using priority as the first tiebreaker seems more > flexible, that's what we ended up using in eSNMP (and what Dave is > arguing for, I believe). ... It's not clear to me whether this last bit of flexibility, going beyond the established protocols, is worth the potential performance cost. Of course, if you have some nifty algorithm that will search a prioritized set of OID spaces with reasonable GET-NEXT behaviour, I'm willing to be persuaded. :-) ----------------------------------------------------------------------------- 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: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Wed, 19 Jun 1996 14:37:39 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA29204 for X-agentx-local; Wed, 19 Jun 1996 14:37:38 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA29195 for ; Wed, 19 Jun 1996 14:37:36 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id RAA13478; Wed, 19 Jun 1996 17:37:31 -0400 Received: from remppp by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA27027; Wed, 19 Jun 1996 17:36:07 -0400 Date: Wed, 19 Jun 1996 17:38:12 EDT From: Bob Natale Subject: Re: Agenda Conflicts To: Dave Fowler Cc: kostick@qsun.ho.att.com, agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Dave Fowler > Date: Wed, 19 Jun 1996 14:23:44 -0400 Hi Dave, > I'm sure this is way too late, but I think that both of the agentx meetings > are at inconvenient times. One session is opposite atommib and the other is > opposite ifmib. > > In the case of Tuesday 9am, I propose Monday 3:30 opposite > ipacad, applmib, ire, idr, nimrod, otp, and mmusic. I will not arrive until late Monday afternoon. However, if it works best for the majority, I have no problem with the initial meeting starting/completing w/o me...Mike Daniele or Bert Wijnen or Dale Francisco could chair the meeting in my absence. However, I suspect that others have already made some travel plans dependant upon the Tuesday morning first meeting. > In the case of Wedneday 1:00, I propose Wednesday 3:30 opposite > asid, dhc, raidmib, idmr, ipsec, and intserv. No problem for me. I will only be in Montreal from late Monday afternoon until early Thursday morning...so Tuesday and Wednesday are the only full days I have for meetings. > I don't think I'm the only one with these conflicts. > I think I've seen Maria Greene and Bob Stewart at atommib, ifmib, and agentx. Yes, I know. I've been very worried about this. In general, I think we're over-booked in the NMArea...particularly wrt the available senior people and the (relatively) limited number of active, productive contributors. > Is there anything that we can do? I will defer to any decisions in this matter that Deirdre wants to make. I am also cc'ing the agentx list on this, primarily for "heads-up" purposes in case Deirdre elects to change the schedule... in general, it won't be too helpful to have a lot of people submit their individual schedule preferences at this point (I think). Cordially, BobN ---------------- WinSNMP DLL, SDK, and Applications ------------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (tm) "FCAPS" Applications ------------   Delivery-Date: Wed, 19 Jun 1996 15:33:19 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA11885 for X-agentx-local; Wed, 19 Jun 1996 15:33:18 -0700 (PDT) Received: from cbgw1.att.com (gw1.att.com [192.20.239.133]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA11879 for ; Wed, 19 Jun 1996 15:33:18 -0700 (PDT) Received: from qsun.ho.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id SAA22435; Wed, 19 Jun 1996 18:28:42 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA07288; Wed, 19 Jun 96 18:32:59 EDT Received: from kostick.qsun.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA21738; Wed, 19 Jun 1996 18:31:48 -0400 Message-Id: <31C87FEA.6B65@qsun.att.com> Date: Wed, 19 Jun 1996 18:32:11 -0400 From: Deirdre Kostick Reply-To: kostick@qsun.ho.att.com X-Mailer: Mozilla 3.0b3 (Win95; I) Mime-Version: 1.0 To: Bob Natale Cc: Dave Fowler , agentx@fv.com Subject: Re: Agenda Conflicts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave - It's really too late to start re-arranging the agenda. Folks have finalized their travel plans, etc. The scheduling effort began weeks ago taking into account multiple variables, including a maximum number of WG sessions per slot. The WG chairs & I work with the IETF Secretariat to minimize wg conflicts, but we still have overlapping sessions. As Bob notes, the NM Area has a lot of work & a limited number of resources. On the positive side, we're wrapping up several work efforts which frees up resources to focus on new, important (& interesting) work. The NM Area is also growing its pool of talented, experienced resources. Regards, Deirdre   Delivery-Date: Thu, 20 Jun 1996 15:46:51 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA05897 for X-agentx-local; Thu, 20 Jun 1996 15:46:50 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA05857 for ; Thu, 20 Jun 1996 15:46:39 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA23814; Thu, 20 Jun 96 15:46:36 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA27766; Thu, 20 Jun 96 15:46:34 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA15661; Thu, 20 Jun 96 15:46:33 PDT Date: Thu, 20 Jun 96 15:46:33 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606202246.AA15661@santa.strata.com> To: agentx@fv.com Subject: Editor's note on Revision 1 of AgentX draft I'm sending in a single following post the first revision of the proposed AgentX Protocol internet draft. This revision incorporates changes by Mike Daniele meant to clarify certain technical points that have come up in discussion on the list, as well as some minor style and formatting changes by me. Below are the diffs between the original draft document and rev 1. Thanks, Dale Francisco Editor, AgentX WG dfrancisco@strata.com voice: (805) 961-3642 fax: (805) 961-3600 76c76,77 < 7.2.4 Sending the SNMP Response PDU --- > 7.2.4 MIB Views > 7.2.5 Sending the SNMP Response PDU 253a255,256 > - Forwards Traps on behalf of subagents. > 255a259,260 > - Initiates a logical connection with the master agent. > 287,289c292 < Strings are represented in the native character set of the system on < which the subagent resides. If this is not ASCII, the master agent < must perform any required conversions. --- > Strings are represented in ASCII. 319c322 < | 129 | SNMP_TYPE_Integer32 | --- > | 1 | SNMP_TYPE_Integer32 | 329c332 < | 134 | SNMP_TYPE_Counter32 | --- > | 6 | SNMP_TYPE_Counter32 | 331c334 < | 135 | SNMP_TYPE_Gauge32 | --- > | 7 | SNMP_TYPE_Gauge32 | 333c336 < | 136 | SNMP_TYPE_TimeTicks (1/100ths seconds) | --- > | 8 | SNMP_TYPE_TimeTicks (1/100ths seconds) | 335c338 < | 9 | SNMP_TYPE_DisplayString | --- > | 10 | SNMP_TYPE_Counter64 | 337c340 < | 13 | SNMP_TYPE_Counter64 | --- > | 11 | SNMP_TYPE_Opaque | 339c342 < | 14 | SNMP_TYPE_Opaque | --- > | 12 | SNMP_TYPE_noSuchObject | 341c344 < | 15 | SNMP_TYPE_noSuchObject | --- > | 13 | SNMP_TYPE_noSuchInstance | 343c346 < | 16 | SNMP_TYPE_noSuchInstance | --- > | 14 | SNMP_TYPE_endOfMibView | 345,346d347 < | 17 | SNMP_TYPE_endOfMibView | < +-------+---------------------------------------------------------+ 359c360 < - Object Identifiers are NULL terminated strings in the selected --- > - Object Identifiers are NULL terminated strings in the ASCII 361,364c362,363 < The length includes the terminating NULL. Example ASCII: < '312e332e362e312e322e312e312e312e3000'h represents < "1.3.6.1.2.1.1.1.0" which is sysDescr.0. Example EBCDIC: < 'f14bf34bf64bf14bf24bf14bf14bf14bf000'h represents --- > The length includes the terminating NULL. > For example, '312e332e362e312e322e312e312e312e3000'h represents 367,371d365 < - DisplayStrings are in the selected character set. The length < specifies the length of the string. Example ASCII: < '6162630d0a'h represents "abc\r\n", no NULL. Example EBCDIC: < '8182830d25'h represents "abc\r\n", no NULL. < 380,385d373 < - BIT_STRING is an OCTET_STRING of the form uubbbb...bb, where < the first octet (uu) is 0x00-0x07 and indicates the number of < unused bits in the last octet (bb). The bb octets represent < the bit string itself, where bit zero (0) comes first and so < on. < 403c391 < [TBD] --- > NamingScope 404a393,412 > +--------+------+----------------------------------------+ > | OFFSET | SIZE | FIELD | > +--------+------+----------------------------------------+ > ... > +--------+------+--------------------------------------------+ > | X | 2 | n.length | > +--------+------+--------------------------------------------+ > | X+2 | var | n.body | > +--------+------+--------------------------------------------+ > > The NamingScope is represented by two fields, n.body and n.length. > > n.body, which is of variable length, contains the actual context > specifier. (For the SNMPv1 framework, this field should contain the > community name.) > > n.length is the length in octets of the entire NamingScope > representation (n.length and n.body). The value of n.length is > referred to as "NL" in the packet format diagrams below. > 414c422 < | X | var | g.requested (null-terminated OID, len L) | --- > | X | var | g.start (null-terminated OID, len L) | 416c424 < | X+L+1 | var | g.limit (null-terminated OID) | --- > | X+L+1 | 1 | g.include | 417a426,427 > | X+L+2 | var | g.end (null-terminated OID) | > +--------+------+--------------------------------------------+ 419c429,431 < g.requested is the name of a requested variable binding. --- > g.start is the object identifier indicating the beginning of the > range. It is frequently (but not necessarily) the name of a > requested variable binding. 421,422c433,434 < g.limit is an optional object identifier derived by the master < agent to limit the search done by a subagent. --- > g.include is a boolean indicating whether or not g.start is included > in the range. 423a436,438 > g.end is the object identifier indicating the non-inclusive end of > the range. > 435c450 < | 2 | 4 | h.ID (MSB first) | --- > | 4 | 4 | h.ID (MSB first) | 437c452 < | 8 | 1 | h.major | --- > | 8 | 4 | h.snmp_version | 439c454 < | 9 | 1 | h.minor | --- > | 12 | 1 | h.major | 441c456 < | 10 | 1 | h.flags | --- > | 13 | 1 | h.minor | 443c458,460 < | 11 | 1 | h.type | --- > | 14 | 1 | h.flags | > +--------+------+----------------------------------------+ > | 15 | 1 | h.type | 447c464 < header. (HL is the length of the header itself.) --- > header. (HL is the length of the header itself, 16 octets.) 451a469,473 > h.snmp_version is the value of the version component of the received > SNMP message. The subagent uses this value to interpret the > contents of the NamingScope field, and to bind RegionSpecifiers to > variables whose syntax is suitable to the SMI of that version. > 461,465c483,486 < Bits Contain < ---- ------- < 0-3 SNMP version < 4 Alone < 5-7 reserved --- > Bits Definition > ---- ---------- > 0 Alone (used during Set processing) > 1-7 Undefined 496c517 < | 12 | AGENTX_GETBULK | --- > | 12 | AGENTX_END | 498c519 < | 13 | AGENTX_TRAPV2 (not yet used) | --- > | 13 | AGENTX_GETBULK | 500c521 < | 14 | AGENTX_INFORM (not yet used) | --- > | 14 | AGENTX_TRAPV2 | 502c523 < | 15 | AGENTX_ARE_YOU_THERE | --- > | 15 | AGENTX_INFORM | 503a525,526 > | 16 | AGENTX_ARE_YOU_THERE | > +-------+---------------------------------------------------------+ 547c570 < | HL | var | g.context (NamingScope, length L) | --- > | HL | var | g.context (NamingScope) | 549c572 < | HL+L+1 | var | SearchRangeList | --- > | HL+NL | var | SearchRangeList | 559c582 < | HL | var | g.context (NamingScope, length L) | --- > | HL | var | g.context (NamingScope) | 561c584 < | HL+L+1 | var | SearchRangeList | --- > | HL+NL | var | SearchRangeList | 576c599 < | HL+8 | var | g.context (NamingScope, length L) | --- > | HL+8 | var | g.context (NamingScope) | 578c601 < |HL+8+L+1| var | SearchRangeList | --- > |HL+8+NL | var | SearchRangeList | 652,653c675,676 < objects require a context to differentiate them. A null < string indicates the default context. --- > objects require a context to differentiate them. A zero-length > NamingScope indicates the default context. 660c683 < - r.timeout is the length of time, in centiseconds, that a master --- > - r.timeout is the length of time, in seconds, that a master 744,747c767,768 < 1) Choose the one whose original Register-PDU r.region contained < the most subids, i.e., the most specific r.region. Note: A < range subid is no "longer" (more specific) than a single < subid. --- > 1) Choose the one whose original Register-PDU specified the > highest priority. 750c771,773 < specified the highest priority. --- > r.region contained the most subids, i.e., the most specific > r.region. Note: A range subid is no "longer" (more specific) > than a single subid. 755d777 < 831a854,863 > Note: In the following procedures, an object identifier is said to > be "contained" within a registered region when both of the following > are true: > > - the object identifier does not lexicographically precede the > region specifier > > - the object identifier lexicographically precedes the end of the > region > 843c875 < (2) Within a list of regions registered within the context indicated --- > Within a list of regions registered within the context indicated 845,846c877 < RegionSpecifier, locate the RegionSpecifier that is identical to < or is the closest lexicographical predecessor to the variable --- > RegionSpecifier, locate the region that contains the variable 849c880 < (3) If no such region exists the variable binding is not processed --- > (2) If no such region exists the variable binding is not processed 852c883 < (4) Identify the target subagent, which is the one that registered --- > (3) Identify the target subagent, which is the one that registered 855c886 < (5) If this is the first variable binding to be dispatched to the --- > (4) If this is the first variable binding to be dispatched to the 860c891 < (6) Add a SearchRange to the end of the target subagent's Get-PDU --- > (5) Add a SearchRange to the end of the target subagent's Get-PDU 863c894 < (7) The variable binding's name is copied to g.requested. --- > - The variable binding's name is copied to g.start. 865c896 < (8) g.limit is set to null. --- > - g.end is set to null. 878c909 < (2) Within a list of regions registered within the context indicated --- > Within a list of regions registered within the context indicated 880,882c911,915 < RegionSpecifier, locate the longest RegionSpecifier of which the < variable binding's name is a subtree. If no such region exists, < locate the RegionSpecifier which is the first lexicographical --- > RegionSpecifier, locate > > a) the region that contains the variable binding's name, or > > b) the region whose RegionSpecifier is the first lexicographical 885c918 < (3) If no such region exists the variable binding is not processed --- > (2) If no such region exists the variable binding is not processed 888c921 < (4) Identify the target subagent, which is the one that registered --- > (3) Identify the target subagent, which is the one that registered 891c924 < (5) If this is the first variable binding to be dispatched to the --- > (4) If this is the first variable binding to be dispatched to the 896c929 < (6) Add a SearchRange to the end of the target subagent's GetNext-PDU --- > (5) Add a SearchRange to the end of the target subagent's GetNext-PDU 899c932,933 < (7) The variable binding's name is copied to g.requested. --- > - if 1a) applies, the variable binding's name is copied > to g.start, and g.include is set to 0. 901,904c935,936 < (8) g.limit is set to the RegionSpecifier that is the first < lexicographical successor to the target Regionspecifier, and that < was not registered by the target subagent. If no such < RegionSpecifier exists, g.limit is set to null. --- > - if 1b) applies, the target RegionSpecifier is copied > to g.start, and g.include is set to 1. 905a938,942 > - g.end is set to the RegionSpecifier that is the first > lexicographical successor to the target RegionSpecifier, and > that was not registered by the target subagent. If no such > RegionSpecifier exists, g.end is set to null. > 984c1021 < 1) g.requested is copied to v.name. --- > 1) g.start is copied to v.name. 986c1023 < 2) If the value of g.requested exactly matches the name of a --- > 2) If the value of g.start exactly matches the name of a 991,993c1028,1030 < If the resulting VarBind's type is not part of the SNMPv1 SMI, < and h.flags indicate this is an SNMPv1-style request, v.type is < set to `noSuchObject', and v.length to 0. --- > 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. 995c1032 < 3) Otherwise, if the value of g.requested does not match the OBJECT --- > 3) Otherwise, if the value of g.start does not match the OBJECT 1013,1014c1050,1051 < - The variable's name is the closest lexicographical successor < to g.requested. --- > - if g.include is 0, the variable's name is the closest > lexicographical successor to g.start. 1016,1017c1053,1054 < - If g.limit is not null, the variable's name lexicographically < precedes g.limit. --- > - if g.include is 1, the variable's name is either equivalent > to, or the closest lexicographical successor to, g.start. 1019,1020c1056,1057 < - If h.flags indicates this is an SNMPv1 request, the < variable's syntax is part of the SNMPv1 SMI. --- > - If g.end is not null, the variable's name lexicographically > precedes g.end. 1021a1059,1061 > - The variable's syntax is compatible with the SMI for the SNMP > framework of the version specified in h.snmp_version. > 1027c1067 < 2) If no such variable exists, v.name is set to g.requested, --- > 2) If no such variable exists, v.name is set to g.start, 1060,1061c1100,1102 < - If g.limit is not null, the variable's name < lexicographically precedes g.limit. --- > (Note that if i is 0 and g.include is 1, the variable's name > may be equivalent to, or the first lexicographical successor > to, the (N+s)-th requested OID.) 1063,1064c1104,1105 < - If h.flags indicates this is an SNMPv1 request, the < variable's syntax is part of the SNMPv1 SMI. --- > - If g.end is not null, the variable's name > lexicographically precedes g.end. 1065a1107,1109 > - The variable's syntax is compatible with the SMI for the > SNMP framework of the version specified in h.snmp_version. > 1073,1074c1117,1118 < (N+((i-2)*R)+s)-th VarBind unless i is currently one, in which < case it is set the value of g.requested in the (N+s)-th --- > (N+((i-2)*R)+s)-th VarBind unless i is currently 1, in which > case it is set to the value of g.start in the (N+s)-th 1118,1119c1162,1164 < 4) Otherwise, the VarBinds in the RESPONSE PDU are processed as < follows: --- > 4) Otherwise, the content of each VarBind in the RESPONSE PDU is used > to update the corresponding variable binding in the SNMP > Response-PDU. 1121,1139c1166 < Get < < If v.name is not within the relevant MIB view, the VarBind is < ignored. (This determination is implementation-specific.) < < Otherwise, the name and value of the corresponding variable < binding in the SNMP Response-PDU are updated with the contents < of the VarBind. < < GetNext < < If v.name is not within the relevant MIB view, the VarBind is < ignored. (This determination is implementation-specific.) < < Otherwise, the name and value of the corresponding variable < binding in the SNMP Response-PDU are updated with the contents < of the VarBind. < < 5) After all expected response PDUs have been processed, if any --- > After all expected response PDUs have been processed, if any 1143c1170 < - For each such variable binding, a target region is --- > 5) For each such variable binding, a target region is 1149c1176 < - If this is the first variable binding to be dispatched to --- > 6) If this is the first variable binding to be dispatched to 1151,1153c1178,1180 < AgentX GetNext-PDU for the subagent, with the header < fields initialized as described in section 6.1.3 and the < context in the Request-PDU encoded into g.context. --- > AgentX GetNext-PDU or GetBulk-PDU for the subagent, with > the header fields initialized as described in section 6.1.3 > and the context in the Request-PDU encoded into g.context. 1155,1161c1182 < - Add a SearchRange to the end of the target subagent's < GetNext-PDU for this variable binding. The variable < binding's name is copied to g.requested. g.limit is set to < the RegionSpecifier that is the first lexicographical < successor to the target Regionspecifier, and that was not < registered by the target subagent. If no such < RegionSpecifier exists, g.limit is set to null. --- > For Get-Next PDUs: 1163,1164c1184,1191 < - The AgentX PDUs are sent, received, and processed < according to section 7.2.3. --- > 7) Add a SearchRange to the end of the target subagent's > GetNext-PDU for this variable binding. The target > RegionSpecifier is copied to g.start, and g.include is > set to 1. g.end is set to the RegionSpecifier that is > the first lexicographical successor to the target > RegionSpecifier, and that was not registered by the target > subagent. If no such RegionSpecifier exists, g.end is set to > null. 1166,1168c1193 < - This process continues iteratively until a complete SNMP < Response-PDU has been built, or until there remain no < target region lexicographical successors. --- > For Get-Bulk PDUs: 1170,1196c1195 < < GetBulk < < If v.name is not within the relevant MIB view, the VarBind is < ignored. (This determination is implementation-specific.) < < Otherwise, the name and value of the corresponding variable < binding in the SNMP Response-PDU are updated with the contents < of the VarBind. < < 5) If after all expected RESPONSE PDUs have been processed, any < variable bindings still contain the value `endOfMibView', < processing must continue: < < - For each such variable binding, a target region is < identified which is the lexicographical successor to the < target region for this variable binding on the last < iteration. The target subagent is the one that registered < the target region. < < - If this is the first variable binding to be dispatched to < the target subagent (during this iteration), create an < AgentX GetBulk-PDU for the subagent, with the header fields < initialized as described in section 6.1.3 and the context < from the Request-PDU encoded into g.context. < < - Set the value of g.non_repeaters and g.max_repetitions --- > 7) Set the value of g.non_repeaters and g.max_repetitions 1199,1200c1198,1205 < - Add a SearchRange to the end of the target subagent's < GetBulk-PDU for this variable binding. --- > 8) Add a SearchRange to the end of the target subagent's > GetBulk-PDU for this variable binding. The target > RegionSpecifier is copied to g.start, and g.include is > set to 1. g.end is set to the RegionSpecifier that is > the first lexicographical successor to the target > RegionSpecifier, and that was not registered by the target > subagent. If no such RegionSpecifier exists, g.end is set to > null. 1202,1211c1207 < - g.requested is set to v.name of the (last repeating) < VarBind that was returned for this variable binding on the < previous iteration. < < g.limit is set to the RegionSpecifier that is the first < lexicographical successor to the target Regionspecifier, < and that was not registered by the target subagent. If no < such RegionSpecifier exists, g.limit is set to null. < < If the variable binding was within the non_repeaters range --- > 9) If the variable binding was within the non_repeaters range 1220,1221c1216,1217 < - The AgentX PDUs are sent, received, and processed < according to the procedures in section 7.2.3. --- > 10) The AgentX PDUs are sent, received, and processed > according to section 7.2.3. 1223,1225c1219,1221 < - This process continues iteratively until a complete SNMP < response PDU has been built, or until there are no target < region lexicographical successors. --- > 11) This process continues iteratively until a complete SNMP > Response-PDU has been built, or until there remain no > target region lexicographical successors. 1227,1228c1223 < [Would it be a good idea to include an example of say, bulk request < processing that causes this kind of rollover between subagents?] --- > [Include examples, TBD] 1229a1225 > 7.2.4 MIB Views 1231c1227,1228 < 7.2.4. Sending the SNMP Response PDU --- > AgentX subagents are not aware of MIB views, since view information > is not contained in AgentX PDUs. 1232a1230,1241 > As stated above, the descriptions of procedures in section 7 of this > memo are not intended to constrain the internal architecture of any > conformant implementation. In particular, the master agent > 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 g.start and g.end may be used in such optimizations. > > 7.2.5. Sending the SNMP Response PDU > 1239,1240c1248,1250 < Note that this may also involve altering the PDU contents for agents < that support the SNMP version 1 framework. --- > Note that this may involve altering the PDU contents for agents > that support the SNMP version 1 framework, or when returning > an error response. 1299d1308 <   Delivery-Date: Thu, 20 Jun 1996 16:20:21 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA12837 for X-agentx-local; Thu, 20 Jun 1996 16:20:19 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA12833 for ; Thu, 20 Jun 1996 16:20:15 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA24224; Thu, 20 Jun 96 16:20:13 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA29441; Thu, 20 Jun 96 16:20:11 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA22570; Thu, 20 Jun 96 16:20:08 PDT Date: Thu, 20 Jun 96 16:20:08 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606202320.AA22570@santa.strata.com> To: agentx@fv.com Subject: Revision 1 of AgentX draft 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). Table of Contents 1. Introduction 2. The SNMP framework 2.1 A Note on Terminology 3. Extending the MIB 3.1 Motivation For AgentX 4. The AgentX Framework 4.1 AgentX Roles 5. AgentX Encodings 5.1 Character Set Selection 5.2 Value Representation 6. Protocol Definitions 6.1 Common Constructs 6.1.1 RegionSpecifier 6.1.2 NamingScope 6.1.3 SearchRange 6.1.4 AgentX PDU Header 6.2 AgentX PDUs 7. Elements of Procedure 7.1 AgentX Administrative PDUs 7.1.1 The Open-PDU 7.1.2 The Register-PDU 7.1.2.1 Register-PDU Fields 7.1.2.2 Processing the Register-PDU 7.1.2.2.1 The AddRegion Procedure 7.1.2.2.2 Handling Duplicate Regions 7.1.3 The Unregister-PDU 7.1.3.1 Unregister-PDU Fields 7.1.3.2 Processing the Unregister-PDU 7.1.4 The Close-PDU 7.2 Processing Received SNMP Protocol Messages 7.2.1 Dispatching AgentX PDUs 7.2.1.1 GetRequest-PDU 7.2.1.2 GetNextRequest-PDU 7.2.1.3 GetBulkRequest-PDU 7.2.2 Subagent Processing of AgentX PDUs 7.2.2.1 Subagent Processing of the AgentX Get-PDU 7.2.2.2 Subagent Processing of the AgentX GetNext-PDU 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU 7.2.3 Master Agent Processing AgentX Responses 7.2.4 MIB Views 7.2.5 Sending the SNMP Response PDU 8. Master Agent Transport Mappings 9. Security Considerations 10. Acknowledgements 11. References 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 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. 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. 4. AgentX Framework A managed node contains a processing entity, called an agent, which has access to management information. Within the AgentX framework, an agent consists of both - a single processing entity called the master agent, which sends 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 access to management information. - 0 or more processing entities called subagents, which do not send or receive SNMP protocol messages, but which have access to management information. The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. While some of these protocol messages appear similar in syntax and semantics to the SNMP, it is important to remember that AgentX subagents are not themselves SNMP protocol entities. 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. - Forwards Traps 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 traps. 5. AgentX Encodings AgentX PDUs consist of a common, fixed-format header; an optional PDU-specific subheader; and optional, possibly variable-length data. The PDUs are not encoded using the BER [1], but are represented as a simple byte stream. Within the header and subheaders, numeric data is always encoded most significant byte (MSB) first. The length of this data is not transmitted explicitly since it is known by the packet format. Variable-length data within the subheaders is transmitted as null-terminated strings. The length of this data is not transmitted explicitly since it may be determined by the string's length. Object identifiers are represented within the subheaders as null-terminated, ASN.1 dotted notation strings. 5.1. Character Set Selection Strings are represented in ASCII. 5.2. Value Representation Variable bindings may be transmitted within the variable-length portion of some PDUs. This representation (called a VarBind) is as follows: VarBind +--------+------+--------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+--------------------------------------------+ | X | var | v.name (OID, null-terminated, length L) | +--------+------+--------------------------------------------+ | X+L+1 | 1 | v.type | +--------+------+--------------------------------------------+ | X+L+2 | 2 | v.length (MSB first) | +--------+------+--------------------------------------------+ | X+L+4 | var | v.data (format depends on data type) | +--------+------+--------------------------------------------+ v.type indicates the variable binding's syntax, and must be one of the following values: +-----------------------------------------------------------------+ | Table 17. Valid values for the Value Type field | +-------+---------------------------------------------------------+ | VALUE | VALUE TYPE | +-------+---------------------------------------------------------+ | 1 | SNMP_TYPE_Integer32 | +-------+---------------------------------------------------------+ | 2 | SNMP_TYPE_OCTET_STRING | +-------+---------------------------------------------------------+ | 3 | SNMP_TYPE_OBJECT_IDENTIFIER | +-------+---------------------------------------------------------+ | 4 | SNMP_TYPE_NULL (empty, no value) | +-------+---------------------------------------------------------+ | 5 | SNMP_TYPE_IpAddress | +-------+---------------------------------------------------------+ | 6 | SNMP_TYPE_Counter32 | +-------+---------------------------------------------------------+ | 7 | SNMP_TYPE_Gauge32 | +-------+---------------------------------------------------------+ | 8 | SNMP_TYPE_TimeTicks (1/100ths seconds) | +-------+---------------------------------------------------------+ | 10 | SNMP_TYPE_Counter64 | +-------+---------------------------------------------------------+ | 11 | SNMP_TYPE_Opaque | +-------+---------------------------------------------------------+ | 12 | SNMP_TYPE_noSuchObject | +-------+---------------------------------------------------------+ | 13 | SNMP_TYPE_noSuchInstance | +-------+---------------------------------------------------------+ | 14 | SNMP_TYPE_endOfMibView | +-------+---------------------------------------------------------+ v.length is a 2-byte integer, MSB first, which indicates the number of octets of v.data. v.data is the actual value, and is encoded as follows: - 32-bit integers are 4-byte elements, MSB first. Example: '00000001'h represents 1. - 64-bit integers are 8-byte elements, MSB first. Example: '0000000100000001'h represents 4,294,967,297. - Object Identifiers are NULL terminated strings in the ASCII character set, representing the OID in ASN.1 dotted notation. The length includes the terminating NULL. For example, '312e332e362e312e322e312e312e312e3000'h represents "1.3.6.1.2.1.1.1.0" which is sysDescr.0. - IpAddress, NsapAddress and Opaque are implicit OCTET_STRING, so they are octets (e.g. IpAddress in network byte order). - NULL has a zero length for the value, and no value data. - noSuchObject, noSuchInstance and endOfMibView are implicit NULL and represented as such. VarBindList is a contiguous list of VarBinds. 6. Protocol Definitions 6.1. Common Constructs 6.1.1. RegionSpecifier A RegionSpecifier is an object identifier that may optionally contain a range in place of exactly one of its sub-identifiers. The range is represented as "[" lower-bound "-" upper-bound "]". For example, "1.2.3.[4-7].8" is a valid RegionSpecifier. 6.1.2. NamingScope NamingScope +--------+------+----------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------+ ... +--------+------+--------------------------------------------+ | X | 2 | n.length | +--------+------+--------------------------------------------+ | X+2 | var | n.body | +--------+------+--------------------------------------------+ The NamingScope is represented by two fields, n.body and n.length. n.body, which is of variable length, contains the actual context specifier. (For the SNMPv1 framework, this field should contain the community name.) n.length is the length in octets of the entire NamingScope representation (n.length and n.body). The value of n.length is referred to as "NL" in the packet format diagrams below. 6.1.3. SearchRange SearchRange +--------+------+----------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------+ ... +--------+------+--------------------------------------------+ | X | var | g.start (null-terminated OID, len L) | +--------+------+--------------------------------------------+ | X+L+1 | 1 | g.include | +--------+------+--------------------------------------------+ | X+L+2 | var | g.end (null-terminated OID) | +--------+------+--------------------------------------------+ g.start is the object identifier indicating the beginning of the range. It is frequently (but not necessarily) the name of a requested variable binding. g.include is a boolean indicating whether or not g.start is included in the range. g.end is the object identifier indicating the non-inclusive end of the range. SearchRangeList is a contiguous list of SearchRanges. 6.1.4. AgentX PDU Header Header +--------+------+----------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------+ | 0 | 4 | h.length (MSB first) | +--------+------+----------------------------------------+ | 4 | 4 | h.ID (MSB first) | +--------+------+----------------------------------------+ | 8 | 4 | h.snmp_version | +--------+------+----------------------------------------+ | 12 | 1 | h.major | +--------+------+----------------------------------------+ | 13 | 1 | h.minor | +--------+------+----------------------------------------+ | 14 | 1 | h.flags | +--------+------+----------------------------------------+ | 15 | 1 | h.type | +========+======+========================================+ h.length is the size in octets of the entire PDU, including the header. (HL is the length of the header itself, 16 octets.) h.ID is a monotonically increasing packet id that should be kept unique by the sending entity. h.snmp_version is the value of the version component of the received SNMP message. The subagent uses this value to interpret the contents of the NamingScope field, and to bind RegionSpecifiers to variables whose syntax is suitable to the SMI of that version. h.major is the protocol major version. This memo specifies a value of 0. h.minor is the protocol minor version number. This memo specifies a value of 0. h.flags is a one-octet bitmask, bit 0 first, etc. Bit definitions are Bits Definition ---- ---------- 0 Alone (used during Set processing) 1-7 Undefined h.type is the PDU type, and must be one of the following values: +-----------------------------------------------------------------+ | Table 16. Valid values for the packet type field | +-------+---------------------------------------------------------+ | VALUE | PACKET TYPE | +-------+---------------------------------------------------------+ | 1 | AGENTX_GET | +-------+---------------------------------------------------------+ | 2 | AGENTX_GETNEXT | +-------+---------------------------------------------------------+ | 3 | AGENTX_SET | +-------+---------------------------------------------------------+ | 4 | AGENTX_TRAP | +-------+---------------------------------------------------------+ | 5 | AGENTX_RESPONSE | +-------+---------------------------------------------------------+ | 6 | AGENTX_REGISTER | +-------+---------------------------------------------------------+ | 7 | AGENTX_UNREGISTER | +-------+---------------------------------------------------------+ | 8 | AGENTX_OPEN | +-------+---------------------------------------------------------+ | 9 | AGENTX_CLOSE | +-------+---------------------------------------------------------+ | 10 | AGENTX_COMMIT | +-------+---------------------------------------------------------+ | 11 | AGENTX_UNDO | +-------+---------------------------------------------------------+ | 12 | AGENTX_END | +-------+---------------------------------------------------------+ | 13 | AGENTX_GETBULK | +-------+---------------------------------------------------------+ | 14 | AGENTX_TRAPV2 | +-------+---------------------------------------------------------+ | 15 | AGENTX_INFORM | +-------+---------------------------------------------------------+ | 16 | AGENTX_ARE_YOU_THERE | +-------+---------------------------------------------------------+ 6.2. AgentX PDUs Register-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 2 | r.priority (MSB first) | +--------+------+----------------------------------------------+ | HL+2 | 2 | r.timeout (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | var | r.region (RegionSpecifier, length L) | +--------+------+----------------------------------------------+ |HL+4+L+1| var | r.context (NamingScope) | +--------+------+----------------------------------------------+ Unregister-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 1 | u.reason code | +--------+------+----------------------------------------------+ | HL+1 | var | u.region (RegionSpecifier, length L) | +--------+------+----------------------------------------------+ |HL+1+L+1| var | u.context (NamingScope) | +--------+------+----------------------------------------------+ Get-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | var | g.context (NamingScope) | +--------+------+----------------------------------------------+ | HL+NL | var | SearchRangeList | +--------+------+----------------------------------------------+ GetNext-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | var | g.context (NamingScope) | +--------+------+----------------------------------------------+ | HL+NL | var | SearchRangeList | +--------+------+----------------------------------------------+ GetBulk-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 4 | g.non_repeaters (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | 4 | g.max_repetitions (MSB first) | +--------+------+----------------------------------------------+ | HL+8 | var | g.context (NamingScope) | +--------+------+----------------------------------------------+ |HL+8+NL | var | SearchRangeList | +--------+------+----------------------------------------------+ Response-PDU +--------+------+----------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+----------------------------------------------+ | 0 | | Header | +--------+------+----------------------------------------------+ | HL | 4 | res.error_code (MSB first) | +--------+------+----------------------------------------------+ | HL+4 | 4 | res.error_index (MSB first) | +--------+------+----------------------------------------------+ | HL+8 | var | VarBindList | +--------+------+----------------------------------------------+ 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: processing AgentX administrative messages (e.g, connection requests from a subagent to a master agent); and processing SNMP messages (e.g., the coordinated actions of a master agent and one or more subagents in processing a received SNMP GetRequest-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 connection between a subagent and a master agent, and those by which a subagent communicates to a master agent which MIB subtrees it supports. 7.1.1. The Open-PDU [TBD] 7.1.2. The Register-PDU A Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within a specific context) that it wishes to support. 7.1.2.1. Register-PDU Fields A Register-PDU contains the following fields: - r.region 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 perform management operations only on particular rows of a conceptual table. Note that the RegionSpecifier syntax (see 6.1.1) permits registering a conceptual row in a single operation. For instance, "1.3.6.1.2.1.2.2.1.[1-22].7" would register row 7 of the RFC 1573 ifTable. - r.context is used by the subagent when identically named objects require a context to differentiate them. A zero-length NamingScope indicates the default context. - r.priority is used by cooperating subagents to achieve a desired configuration when registering identical regions. The default value is 0 (no priority indicated). Higher numbers indicate higher priority. - r.timeout is 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). 7.1.2.2. Processing the Register-PDU When the master agent receives a Register-PDU, it processes it as follows: If an Open-PDU has not been received and successfully processed for this subagent, ignore the message [or send back error?]. Otherwise, the master agent adds this region to its registered OID space for that context, to be considered during the dispatching phase for subsequently received SNMP protocol messages. 7.1.2.2.1. The AddRegion Procedure In this region addition phase, RegionSpecifiers that contain subid ranges are processed as if the master agent had received multiple registrations, each containing no subid ranges. (For instance, "1.2.3.[4-6].7" is processed as if the master had received registrations whose RegionSpecifiers where "1.2.3.4.7", "1.2.3.5.7", and "1.2.3.6.7".) 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 regions (the registered OID space). Note: Though newly-added regions 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 regions (R1a, R1b, R1c) such that R1b is an exact duplicate of R2. Add R1b and R2 into the lexicographically ordered set of regions. Apply the AddRegion operation 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 regions 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 registered region with the information contained in its original Register-PDU. 7.1.2.2.2. Handling Duplicate Regions As a result of this registration algorithm there are likely to be duplicate regions (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 region, the determination of which one to use proceeds as follows: 1) Choose the one whose original Register-PDU specified the highest priority. 2) If still ambiguous, choose the one whose original Register-PDU r.region contained the most subids, i.e., the most specific r.region. Note: A range subid is no "longer" (more specific) than a single subid. 3) If still ambiguous, choose the one whose original Register-PDU was received most recently. 7.1.3. The Unregister-PDU The Unregister-PDU is sent by a subagent to remove a previously registered RegionSpecifier from the master agent's OID space. 7.1.3.1. Unregister-PDU Fields An Unregister-PDU contains the following fields: - u.reason - 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 used by the subagent when identically named objects require a context to differentiate them. A null string indicates the default context. 7.1.3.2. Processing the Unregister-PDU If u.region and u.context do not exactly match the values of r.region and r.context of a previously processed Register-PDU which was sent from this subagent, the request is rejected with an appropriate error response. Otherwise the master agent removes u.region from its registered OID space for u.context. If the original region had been split, all such related regions are removed. If this removal results in any contiguous regions that share a common original Register-PDU, they are agglomerated into a single region. 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) 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 effect at the managed node. In particular, the master agent implements the Elements of Procedure defined in section 4.1 of [6] that apply to receiving entities. [We can't refer to 1901, or v2u/v2* ?] If this processing 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 1 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 a registered region when both of the following are true: - the object identifier does not lexicographically precede the region specifier - the object identifier lexicographically precedes the end of the region 7.2.1.1 GetRequest-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 region. Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate the region that contains the variable binding's name. (2) If no such region exists the variable binding is not processed further. (3) Identify the target subagent, which is the one that registered the target region. (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 in section 6.1.3, and the context in the Request-PDU encoded into g.context. (5) Add a SearchRange to the end of the target subagent's Get-PDU for this variable binding. - The variable binding's name is copied to g.start. - g.end is set to null. 7.2.1.2. GetNextRequest-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 region. Within a list of regions registered within the context indicated in the request PDU, and lexicographically ordered by RegionSpecifier, locate a) the region that contains the variable binding's name, or b) the region whose RegionSpecifier is the first lexicographical successor to the variable binding's name. (2) If no such region exists the variable binding is not processed further. (3) Identify the target subagent, which is the one that registered the target region. (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 in section 6.1.3 and the context in the Request-PDU encoded into g.context. (5) Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. - if 1a) applies, the variable binding's name is copied to g.start, and g.include is set to 0. - if 1b) applies, the target RegionSpecifier is copied to g.start, and g.include is set to 1. - g.end is set to the RegionSpecifier that is the first lexicographical successor to the target RegionSpecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.end is set to null. 7.2.1.3. GetBulkRequest-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 region and target subagent, exactly as described for the GetNextRequest-PDU (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 in section 6.1.3 and the context and max_repetitions value in the request PDU encoded into g.context and g.max_repetitions. Set g.non_repeaters to 0. (3) Add a SearchRange to the end of the target subagent's GetBulk-PDU for this variable binding, as described for the GetNext-PDU. If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. When all variable bindings have been processed, send any AgentX PDUs to their respective target subagents (at the transport endpoint used to initiate the subagent's logical connection). 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 Request PDUs When a subagent receives an AgentX Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns a response PDU. The 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_code 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 added to the response PDU as described below. If processing should fail for any reason not described below, res.error_code is set to `genError', res.error_index to the index of the failed SearchRange, the VarBindList is reset to null, and this 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 variable binding in the request is processed in order as follows: 1) g.start is copied to v.name. 2) If the value of g.start 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 in section 5.2. 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 value of g.start 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 variable binding 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 g.include is 0, the variable's name is the closest lexicographical successor to g.start. - if g.include is 1, the variable's name is either equivalent to, or the closest lexicographical successor to, g.start. - If g.end is not null, the variable's name lexicographically precedes g.end. - 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 in section 5.2. 2) If no such variable exists, v.name is set to g.start, v.type is set to `endOfMibView', and v.length to 0. 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 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 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 g.include is 1, the variable's name may be equivalent to, or the first lexicographical successor to, the (N+s)-th requested OID.) - If g.end is not null, the variable's name lexicographically precedes g.end. - 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 in section 5.2. 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 g.start in the (N+s)-th SearchRange. Note that further iterative processing should stop if for any iteration i, all s values of v.type are `EndofMibView'. When the AgentX response PDU has been generated, it is sent back to the master agent's transport endpoint from which the request was sent. 7.2.3. Master Agent Processing of AgentX Responses The master agent now marshals all subagent response PDUs and builds an SNMP response PDU. To do so, the master agent must be able to determine the corresponding variable binding (or error_index value) in the SNMP Response-PDU for each received AgentX VarBind (or res.error_index value). (Note in particular that a response PDU may contain more VarBinds than are required to complete the SNMP Response-PDU.) 1) If any subagent did not respond within its allotted time period, the SNMP Response PDU's error code is set to `genError' and its error index to the index of the variable binding corresponding to the first VarBind in the request PDU that was sent to this subagent. All other subagent response PDUs received due to processing this SNMP request are ignored. Processing is complete; the SNMP response PDU is sent. 2) Otherwise, if the h.ID field of the AgentX response PDU does not match that of the request PDU sent to this subagent, the PDU is ignored. 3) Otherwise, if res.error code 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 response PDU. All other response PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response PDU is sent. 4) Otherwise, the content of each VarBind in the RESPONSE PDU is used to update the corresponding variable binding in the SNMP Response-PDU. After all expected response PDUs have been processed, if any variable bindings still contain the value `endOfMibView', processing must continue: 5) For each such variable binding, a target region is identified which is the lexicographical successor to the target region for this variable binding on the last iteration. The target subagent is the one that registered the target region. 6) If this is the first variable binding to be dispatched to the target subagent (during this iteration), create an AgentX GetNext-PDU or GetBulk-PDU for the subagent, with the header fields initialized as described in section 6.1.3 and the context in the Request-PDU encoded into g.context. For Get-Next PDUs: 7) Add a SearchRange to the end of the target subagent's GetNext-PDU for this variable binding. The target RegionSpecifier is copied to g.start, and g.include is set to 1. g.end is set to the RegionSpecifier that is the first lexicographical successor to the target RegionSpecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.end is set to null. For Get-Bulk PDUs: 7) Set the value of g.non_repeaters and g.max_repetitions to 0. 8) Add a SearchRange to the end of the target subagent's GetBulk-PDU for this variable binding. The target RegionSpecifier is copied to g.start, and g.include is set to 1. g.end is set to the RegionSpecifier that is the first lexicographical successor to the target RegionSpecifier, and that was not registered by the target subagent. If no such RegionSpecifier exists, g.end is set to null. 9) 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. 10) The AgentX PDUs are sent, received, and processed according to section 7.2.3. 11) This process continues iteratively until a complete SNMP Response-PDU has been built, or until there remain no target region lexicographical successors. [Include examples, TBD] 7.2.4 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 conformant implementation. In particular, the master agent 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 g.start and g.end may be used in such optimizations. 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, or when returning an error response. [Do we need to mention explicit mappings? For instance, for v2 Set error codes?] 8. Master Agent Transport Mappings [TBD] 9. Security Considerations Security issues are not discussed in this memo. 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. 11. 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 S. Waldbusser, "Structure of Management Information for Version 2 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 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.   Delivery-Date: Fri, 21 Jun 1996 05:25:09 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA04628 for X-agentx-local; Fri, 21 Jun 1996 05:25:09 -0700 (PDT) Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA04624 for ; Fri, 21 Jun 1996 05:25:07 -0700 (PDT) X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 21 Jun 1996 08:25:01 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 21 Jun 1996 08:24:51 -0400 X400-Received: by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Fri, 21 Jun 1996 08:24:50 -0400 Date: Fri, 21 Jun 1996 12:24:50 +0000 X400-Originator: /dd.id=psd52384/g=usenet/i=u/s=support/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<4qe4ai$7kq@bcarh8ab.bnr.ca>] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Revision ... From: "glenn (g.) waters" Message-ID: <4qe4ai$7kq@bcarh8ab.bnr.ca> To: agentx@fv.com References: <9606202320.AA22570@santa.strata.com> Subject: Re: Revision 1 of AgentX draft Reply-To: " (Glenn Waters)" Path: not-for-mail Newsgroups: nortel.list.agentx Organization: Nortel Lines: 8 Nntp-Posting-Host: bcarhf15.bnr.ca it's good to see the revisions! can we get a copy with page numbers. it makes it a lot easier to reference the document in the WG meetings. thanks, glenn. -- /Glenn W. Waters, gwaters@nortel.ca, Nortel, +1 613 763 3933   Delivery-Date: Mon, 24 Jun 1996 12:23:22 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA09642 for X-agentx-local; Mon, 24 Jun 1996 12:23:21 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA09594 for ; Mon, 24 Jun 1996 12:23:11 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA16650; Sun, 23 Jun 96 17:15:23 PDT Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA18513; Sun, 23 Jun 96 17:15:21 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA15594; Sun, 23 Jun 96 17:15:19 PDT Date: Sun, 23 Jun 96 17:15:19 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9606240015.AA15594@santa.strata.com> To: agentx@zloty.fv.com Subject: Paginated version of agentx draft (rev 1) ^M ^M ^M ^M Agent Extensibility (AgentX) Protocol^M Version 1^M ^M ^M ^M Mike Daniele^M Digital Equipment Corporation^M daniele@zk3.dec.com^M ^M Dale Francisco (editor)^M StrataCom^M dfrancisco@strata.com^M ^M ^M Status of this Memo^M ^M This document is an Internet-Draft. Internet-Drafts are working^M documents of the Internet Engineering Task Force (IETF), its areas,^M and its working groups. Note that other groups may also distribute^M working documents as Internet-Drafts.^M ^M Internet-Drafts are draft documents valid for a maximum of six^M months and may be updated, replaced, or obsoleted by other documents^M at any time. It is inappropriate to use Internet-Drafts as^M reference material or to cite them other than as ``work in^M progress.''^M ^M To learn the current status of any Internet-Draft, please check the^M ``1id-abstracts.txt'' listing contained in the Internet-Drafts^M Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net^M (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific^M Rim).^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 1]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M Table of Contents^M ^M 1. Introduction^M 2. The SNMP framework^M 2.1 A Note on Terminology^M 3. Extending the MIB^M 3.1 Motivation For AgentX^M 4. The AgentX Framework^M 4.1 AgentX Roles^M 5. AgentX Encodings^M 5.1 Character Set Selection^M 5.2 Value Representation^M 6. Protocol Definitions^M 6.1 Common Constructs^M 6.1.1 RegionSpecifier^M 6.1.2 NamingScope^M 6.1.3 SearchRange^M 6.1.4 AgentX PDU Header^M 6.2 AgentX PDUs^M 7. Elements of Procedure^M 7.1 AgentX Administrative PDUs^M 7.1.1 The Open-PDU^M 7.1.2 The Register-PDU^M 7.1.2.1 Register-PDU Fields^M 7.1.2.2 Processing the Register-PDU^M 7.1.2.2.1 The AddRegion Procedure^M 7.1.2.2.2 Handling Duplicate Regions^M 7.1.3 The Unregister-PDU^M 7.1.3.1 Unregister-PDU Fields^M 7.1.3.2 Processing the Unregister-PDU^M 7.1.4 The Close-PDU^M 7.2 Processing Received SNMP Protocol Messages^M 7.2.1 Dispatching AgentX PDUs^M 7.2.1.1 GetRequest-PDU^M 7.2.1.2 GetNextRequest-PDU^M 7.2.1.3 GetBulkRequest-PDU^M 7.2.2 Subagent Processing of AgentX PDUs^M 7.2.2.1 Subagent Processing of the AgentX Get-PDU^M 7.2.2.2 Subagent Processing of the AgentX GetNext-PDU^M 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU^M 7.2.3 Master Agent Processing AgentX Responses^M 7.2.4 MIB Views^M 7.2.5 Sending the SNMP Response PDU^M 8. Master Agent Transport Mappings^M 9. Security Considerations^M 10. Acknowledgements^M 11. References^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 2]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 1. Introduction^M ^M This memo defines a framework for extensible SNMP agents. It defines^M processing entities called master agents and subagents, a protocol^M (AgentX) used to communicate between them, and the elements of^M procedure by which the extensible agent processes SNMP protocol^M messages.^M ^M ^M 2. The SNMP Framework^M ^M A management system contains: several (potentially many) nodes,^M each with a processing entity, termed an agent, which has access to^M management instrumentation; at least one management station; and, a^M management protocol, used to convey management information between^M the agents and management stations. Operations of the protocol are^M carried out under an administrative framework which defines^M authentication, authorization, access control, and privacy^M policies.^M ^M Management stations execute management applications which monitor^M and control managed elements. Managed elements are devices such as^M hosts, routers, terminal servers, etc., which are monitored and^M controlled via access to their management information.^M ^M Management information is viewed as a collection of managed objects,^M residing in a virtual information store, termed the Management^M Information Base (MIB). Collections of related objects are defined^M in MIB modules. These modules are written using a subset of OSI's^M Abstract Syntax Notation One (ASN.1) [1], termed the Structure of^M Management Information (SMI) [2].^M ^M 2.1. A Note on Terminology^M ^M The term "variable" refers to an instance of a non-aggregate object^M type defined according to the conventions set forth in the SMI [2]^M or the textual conventions based on the SMI [3]. The term "variable^M binding" normally refers to the pairing of the name of a variable^M and its associated value. However, if certain kinds of exceptional^M conditions occur during processing of a retrieval request, a^M variable binding will pair a name and an indication of that^M exception.^M ^M A variable-binding list is a simple list of variable bindings.^M ^M The name of a variable is an OBJECT IDENTIFIER, which is the^M concatenation of the OBJECT IDENTIFIER of the corresponding object^M type together with an OBJECT IDENTIFIER fragment identifying the^M instance. The OBJECT IDENTIFIER of the corresponding object-type is^M called the OBJECT IDENTIFIER prefix of the variable.^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 3]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M For the purpose of exposition, the original Internet-standard^M Network Management Framework, as described in RFCs 1155 (STD 16),^M 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1^M framework (SNMPv1). The current framework, as described in RFCs^M 1902-1908, is termed the SNMP version 2 framework (SNMPv2).^M ^M ^M 3. Extending the MIB^M ^M New MIB modules that extend the Internet-standard MIB are^M continuously being defined as the output of various IETF working^M groups. It is also common for enterprises or individuals to^M create or extend enterprise-specific or experimental MIBs.^M ^M As a result, managed devices are frequently complex collections of^M manageable components that have been independently installed on a^M managed node. Each component provides instrumentation for the^M managed objects defined in the MIB module(s) it implements.^M ^M Neither the SNMP version 1 or version 2 framework address how^M managed objects may be dynamically added to or removed from the^M agent view within a particular managed node.^M ^M 3.1. Motivation for AgentX^M ^M This very real need to dynamically extend the management objects^M within a node has given rise to a variety of "extensible agents",^M which typically comprise^M ^M - a "master" agent that is available on the standard transport^M address and that accepts SNMP protocol messages^M ^M - a set of "subagents" that each contain management^M instrumentation^M ^M - a protocol that operates between the master agent and subagents,^M permitting subagents to "connect" to the master agent, and the^M master agent to multiplex received SNMP protocol messages^M amongst the subagents.^M ^M - a set of tools to aid subagent development, and a runtime (API)^M environment that hides much of the protocol operation between a^M subagent and the master agent.^M ^M The wide deployment of extensible SNMP agents, coupled with the^M lack of Internet standards in this area, makes it difficult to field^M SNMP-manageable applications. A vendor may have to support several^M different subagent environments (APIs) in order to support different^M target platforms.^M ^M It can also become quite cumbersome to configure subagents and^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 4]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M (possibly multiple) master agents on a particular managed node.^M ^M Specifying a standard protocol for agent extensibility (AgentX)^M provides the technical foundation required to solve both of^M these problems. Independently developed AgentX-capable master^M agents and subagents will be able to interoperate at the protocol^M level. Vendors can continue to differentiate their products^M in all other respects.^M ^M ^M 4. AgentX Framework^M ^M A managed node contains a processing entity, called an agent, which^M has access to management information.^M ^M Within the AgentX framework, an agent consists of both^M ^M - a single processing entity called the master agent, which sends^M and receives SNMP protocol messages in an agent role (as^M specified by the SNMP version 1 and version 2 framework^M documents) but typically has little or no access to management^M information.^M ^M - 0 or more processing entities called subagents, which do not^M send or receive SNMP protocol messages, but which have access^M to management information.^M ^M The master and subagent entities communicate via AgentX protocol^M messages, as specified in this memo. While some of these^M protocol messages appear similar in syntax and semantics to the^M SNMP, it is important to remember that AgentX subagents are not^M themselves SNMP protocol entities.^M ^M The internal operations of AgentX are invisible to an SNMP entity^M operating in a manager role. To the manager, the agent behaves^M exactly as would a non-extensible (monolithic) agent that had access^M to the same management instrumentation.^M ^M This transparency to managers is a fundamental requirement of^M AgentX, and is what differentiates AgentX subagents from SNMP proxy^M agents.^M ^M 4.1. AgentX Roles^M ^M An entity acting in a master agent role performs the following^M functions:^M ^M - Accepts logical connection requests from subagents.^M ^M - Accepts registration of MIB regions by subagents.^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 5]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M - Sends and accepts SNMP protocol messages on the agent's^M specified transport addresses.^M ^M - Implements the agent role Elements of Procedure specified for^M the administrative framework applicable to the SNMP protocol^M message, except where they specify performing management^M operations. (The application of MIB views, and the access^M control policy for the managed node, are implemented by the^M master agent.)^M ^M - Provides instrumentation for the MIB objects defined in [5],^M and for any MIB objects relevant to any administrative^M framework it supports.^M ^M - Sends and receives AgentX protocol messages to access^M management information, based on the current registry of MIB^M regions.^M ^M - Forwards Traps on behalf of subagents.^M ^M An entity acting in a subagent role performs the following functions:^M ^M - Initiates a logical connection with the master agent.^M ^M - Registers MIB regions with the master agent.^M ^M - Instantiates managed objects.^M ^M - Binds MIB region OIDs (contained in AgentX protocol messages)^M to actual variable names.^M ^M - Performs management operations on variables.^M ^M - Initiates traps.^M ^M ^M 5. AgentX Encodings^M ^M AgentX PDUs consist of a common, fixed-format header; an optional^M PDU-specific subheader; and optional, possibly variable-length data.^M The PDUs are not encoded using the BER [1], but are represented as^M a simple byte stream.^M ^M Within the header and subheaders, numeric data is always encoded^M most significant byte (MSB) first. The length of this data is^M not transmitted explicitly since it is known by the packet format.^M Variable-length data within the subheaders is transmitted as^M null-terminated strings. The length of this data is not transmitted^M explicitly since it may be determined by the string's length.^M ^M Object identifiers are represented within the subheaders as^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 6]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M null-terminated, ASN.1 dotted notation strings.^M ^M 5.1. Character Set Selection^M ^M Strings are represented in ASCII.^M ^M 5.2. Value Representation^M ^M Variable bindings may be transmitted within the variable-length^M portion of some PDUs. This representation (called a VarBind) is^M as follows:^M ^M VarBind^M ^M +--------+------+--------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+--------------------------------------------+^M | X | var | v.name (OID, null-terminated, length L) |^M +--------+------+--------------------------------------------+^M | X+L+1 | 1 | v.type |^M +--------+------+--------------------------------------------+^M | X+L+2 | 2 | v.length (MSB first) |^M +--------+------+--------------------------------------------+^M | X+L+4 | var | v.data (format depends on data type) |^M +--------+------+--------------------------------------------+^M ^M v.type indicates the variable binding's syntax, and must be one of^M the following values:^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 7]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M +-----------------------------------------------------------------+^M | Table 17. Valid values for the Value Type field |^M +-------+---------------------------------------------------------+^M | VALUE | VALUE TYPE |^M +-------+---------------------------------------------------------+^M | 1 | SNMP_TYPE_Integer32 |^M +-------+---------------------------------------------------------+^M | 2 | SNMP_TYPE_OCTET_STRING |^M +-------+---------------------------------------------------------+^M | 3 | SNMP_TYPE_OBJECT_IDENTIFIER |^M +-------+---------------------------------------------------------+^M | 4 | SNMP_TYPE_NULL (empty, no value) |^M +-------+---------------------------------------------------------+^M | 5 | SNMP_TYPE_IpAddress |^M +-------+---------------------------------------------------------+^M | 6 | SNMP_TYPE_Counter32 |^M +-------+---------------------------------------------------------+^M | 7 | SNMP_TYPE_Gauge32 |^M +-------+---------------------------------------------------------+^M | 8 | SNMP_TYPE_TimeTicks (1/100ths seconds) |^M +-------+---------------------------------------------------------+^M | 10 | SNMP_TYPE_Counter64 |^M +-------+---------------------------------------------------------+^M | 11 | SNMP_TYPE_Opaque |^M +-------+---------------------------------------------------------+^M | 12 | SNMP_TYPE_noSuchObject |^M +-------+---------------------------------------------------------+^M | 13 | SNMP_TYPE_noSuchInstance |^M +-------+---------------------------------------------------------+^M | 14 | SNMP_TYPE_endOfMibView |^M +-------+---------------------------------------------------------+^M ^M v.length is a 2-byte integer, MSB first, which indicates the number^M of octets of v.data.^M ^M v.data is the actual value, and is encoded as follows:^M ^M - 32-bit integers are 4-byte elements, MSB first. Example:^M '00000001'h represents 1.^M ^M - 64-bit integers are 8-byte elements, MSB first. Example:^M '0000000100000001'h represents 4,294,967,297.^M ^M - Object Identifiers are NULL terminated strings in the ASCII^M character set, representing the OID in ASN.1 dotted notation.^M The length includes the terminating NULL.^M For example, '312e332e362e312e322e312e312e312e3000'h represents^M "1.3.6.1.2.1.1.1.0" which is sysDescr.0.^M ^M - IpAddress, NsapAddress and Opaque are implicit OCTET_STRING,^M so they are octets (e.g. IpAddress in network byte order).^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 8]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M - NULL has a zero length for the value, and no value data.^M ^M - noSuchObject, noSuchInstance and endOfMibView are implicit^M NULL and represented as such.^M ^M VarBindList is a contiguous list of VarBinds.^M ^M ^M 6. Protocol Definitions^M ^M 6.1. Common Constructs^M ^M 6.1.1. RegionSpecifier^M ^M A RegionSpecifier is an object identifier that may optionally contain^M a range in place of exactly one of its sub-identifiers. The range^M is represented as "[" lower-bound "-" upper-bound "]".^M ^M For example, "1.2.3.[4-7].8" is a valid RegionSpecifier.^M ^M 6.1.2. NamingScope^M ^M NamingScope^M ^M +--------+------+----------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------+^M ...^M +--------+------+--------------------------------------------+^M | X | 2 | n.length |^M +--------+------+--------------------------------------------+^M | X+2 | var | n.body |^M +--------+------+--------------------------------------------+^M ^M The NamingScope is represented by two fields, n.body and n.length.^M ^M n.body, which is of variable length, contains the actual context^M specifier. (For the SNMPv1 framework, this field should contain the^M community name.)^M ^M n.length is the length in octets of the entire NamingScope^M representation (n.length and n.body). The value of n.length is^M referred to as "NL" in the packet format diagrams below.^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 9]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 6.1.3. SearchRange^M ^M SearchRange^M ^M +--------+------+----------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------+^M ...^M +--------+------+--------------------------------------------+^M | X | var | g.start (null-terminated OID, len L) |^M +--------+------+--------------------------------------------+^M | X+L+1 | 1 | g.include |^M +--------+------+--------------------------------------------+^M | X+L+2 | var | g.end (null-terminated OID) |^M +--------+------+--------------------------------------------+^M ^M g.start is the object identifier indicating the beginning of the^M range. It is frequently (but not necessarily) the name of a^M requested variable binding.^M ^M g.include is a boolean indicating whether or not g.start is included^M in the range.^M ^M g.end is the object identifier indicating the non-inclusive end of^M the range.^M ^M SearchRangeList is a contiguous list of SearchRanges.^M ^M 6.1.4. AgentX PDU Header^M ^M Header^M ^M +--------+------+----------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------+^M | 0 | 4 | h.length (MSB first) |^M +--------+------+----------------------------------------+^M | 4 | 4 | h.ID (MSB first) |^M +--------+------+----------------------------------------+^M | 8 | 4 | h.snmp_version |^M +--------+------+----------------------------------------+^M | 12 | 1 | h.major |^M +--------+------+----------------------------------------+^M | 13 | 1 | h.minor |^M +--------+------+----------------------------------------+^M | 14 | 1 | h.flags |^M +--------+------+----------------------------------------+^M | 15 | 1 | h.type |^M +========+======+========================================+^M ^M h.length is the size in octets of the entire PDU, including the^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 10]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M header. (HL is the length of the header itself, 16 octets.)^M ^M h.ID is a monotonically increasing packet id that should be kept^M unique by the sending entity.^M ^M h.snmp_version is the value of the version component of the received^M SNMP message. The subagent uses this value to interpret the^M contents of the NamingScope field, and to bind RegionSpecifiers to^M variables whose syntax is suitable to the SMI of that version.^M ^M h.major is the protocol major version. This memo specifies a value^M of 0.^M ^M h.minor is the protocol minor version number. This memo specifies^M a value of 0.^M ^M h.flags is a one-octet bitmask, bit 0 first, etc.^M Bit definitions are^M ^M Bits Definition^M ---- ----------^M 0 Alone (used during Set processing)^M 1-7 Undefined^M ^M h.type is the PDU type, and must be one of the following values:^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 11]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M +-----------------------------------------------------------------+^M | Table 16. Valid values for the packet type field |^M +-------+---------------------------------------------------------+^M | VALUE | PACKET TYPE |^M +-------+---------------------------------------------------------+^M | 1 | AGENTX_GET |^M +-------+---------------------------------------------------------+^M | 2 | AGENTX_GETNEXT |^M +-------+---------------------------------------------------------+^M | 3 | AGENTX_SET |^M +-------+---------------------------------------------------------+^M | 4 | AGENTX_TRAP |^M +-------+---------------------------------------------------------+^M | 5 | AGENTX_RESPONSE |^M +-------+---------------------------------------------------------+^M | 6 | AGENTX_REGISTER |^M +-------+---------------------------------------------------------+^M | 7 | AGENTX_UNREGISTER |^M +-------+---------------------------------------------------------+^M | 8 | AGENTX_OPEN |^M +-------+---------------------------------------------------------+^M | 9 | AGENTX_CLOSE |^M +-------+---------------------------------------------------------+^M | 10 | AGENTX_COMMIT |^M +-------+---------------------------------------------------------+^M | 11 | AGENTX_UNDO |^M +-------+---------------------------------------------------------+^M | 12 | AGENTX_END |^M +-------+---------------------------------------------------------+^M | 13 | AGENTX_GETBULK |^M +-------+---------------------------------------------------------+^M | 14 | AGENTX_TRAPV2 |^M +-------+---------------------------------------------------------+^M | 15 | AGENTX_INFORM |^M +-------+---------------------------------------------------------+^M | 16 | AGENTX_ARE_YOU_THERE |^M +-------+---------------------------------------------------------+^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 12]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 6.2. AgentX PDUs^M ^M ^M Register-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | 2 | r.priority (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+2 | 2 | r.timeout (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+4 | var | r.region (RegionSpecifier, length L) |^M +--------+------+----------------------------------------------+^M |HL+4+L+1| var | r.context (NamingScope) |^M +--------+------+----------------------------------------------+^M ^M ^M Unregister-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | 1 | u.reason code |^M +--------+------+----------------------------------------------+^M | HL+1 | var | u.region (RegionSpecifier, length L) |^M +--------+------+----------------------------------------------+^M |HL+1+L+1| var | u.context (NamingScope) |^M +--------+------+----------------------------------------------+^M ^M ^M Get-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | var | g.context (NamingScope) |^M +--------+------+----------------------------------------------+^M | HL+NL | var | SearchRangeList |^M +--------+------+----------------------------------------------+^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 13]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M GetNext-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | var | g.context (NamingScope) |^M +--------+------+----------------------------------------------+^M | HL+NL | var | SearchRangeList |^M +--------+------+----------------------------------------------+^M ^M ^M GetBulk-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | 4 | g.non_repeaters (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+4 | 4 | g.max_repetitions (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+8 | var | g.context (NamingScope) |^M +--------+------+----------------------------------------------+^M |HL+8+NL | var | SearchRangeList |^M +--------+------+----------------------------------------------+^M ^M ^M Response-PDU^M ^M +--------+------+----------------------------------------------+^M | OFFSET | SIZE | FIELD |^M +--------+------+----------------------------------------------+^M | 0 | | Header |^M +--------+------+----------------------------------------------+^M | HL | 4 | res.error_code (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+4 | 4 | res.error_index (MSB first) |^M +--------+------+----------------------------------------------+^M | HL+8 | var | VarBindList |^M +--------+------+----------------------------------------------+^M ^M ^M 7. Elements of Procedure^M ^M This section describes the actions of protocol entities (master^M agents and subagents) implementing the AgentX protocol. Note,^M however, that it is not intended to constrain the internal^M architecture of any conformant implementation.^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 14]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M The actions of AgentX protocol entities can be broadly categorized^M under two headings: processing AgentX administrative messages (e.g,^M connection requests from a subagent to a master agent); and^M processing SNMP messages (e.g., the coordinated actions of a master^M agent and one or more subagents in processing a received SNMP^M GetRequest-PDU).^M ^M 7.1. Processing AgentX Administrative Messages^M ^M This subsection describes the actions of AgentX protocol entities in^M processing AgentX administrative messages. Such messages include^M those involved in establishing and terminating a connection between^M a subagent and a master agent, and those by which a subagent^M communicates to a master agent which MIB subtrees it supports.^M ^M 7.1.1. The Open-PDU^M ^M [TBD]^M ^M 7.1.2. The Register-PDU^M ^M A Register-PDU is generated by a subagent for each region of the^M MIB variable naming tree (within a specific context) that it wishes^M to support.^M ^M 7.1.2.1. Register-PDU Fields^M ^M A Register-PDU contains the following fields:^M ^M - r.region indicates a region of the MIB that a subagent^M wishes to support. It may be a fully-qualified instance name,^M a partial instance name, a MIB table or group, or ranges of^M any of these.^M ^M The choice of what to register is implementation-specific; this^M memo does not specify permissible values. Standard practice^M however is for a subagent to register at the highest level of^M the naming tree that makes sense. Registration of^M fully-qualified instances is typically done only when a^M subagent can perform management operations only on particular^M rows of a conceptual table.^M ^M Note that the RegionSpecifier syntax (see 6.1.1) permits^M registering a conceptual row in a single operation. For^M instance, "1.3.6.1.2.1.2.2.1.[1-22].7" would register row 7 of^M the RFC 1573 ifTable.^M ^M - r.context is used by the subagent when identically named^M objects require a context to differentiate them. A zero-length^M NamingScope indicates the default context.^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 15]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M - r.priority is used by cooperating subagents to achieve a^M desired configuration when registering identical regions.^M The default value is 0 (no priority indicated). Higher^M numbers indicate higher priority.^M ^M - r.timeout is the length of time, in seconds, that a master^M agent should allow to elapse after dispatching a message to a^M subagent before it regards the subagent as not responding.^M r.timeout applies only to messages that concern MIB objects^M within r.region. It overrides both the subagent-wide value (if^M any) indicated when the logical connection with the master^M agent was established, and the master agent's default timeout.^M The default value for r.timeout is 0 (no override).^M ^M 7.1.2.2. Processing the Register-PDU^M ^M When the master agent receives a Register-PDU, it processes it^M as follows:^M ^M If an Open-PDU has not been received and successfully processed for^M this subagent, ignore the message [or send back error?].^M ^M Otherwise, the master agent adds this region to its registered OID^M space for that context, to be considered during the dispatching^M phase for subsequently received SNMP protocol messages.^M ^M 7.1.2.2.1. The AddRegion Procedure^M ^M In this region addition phase, RegionSpecifiers that contain subid^M ranges are processed as if the master agent had received multiple^M registrations, each containing no subid ranges. (For instance,^M "1.2.3.[4-6].7" is processed as if the master had received^M registrations whose RegionSpecifiers where "1.2.3.4.7", "1.2.3.5.7",^M and "1.2.3.6.7".)^M ^M If r.region (R1) is a subtree of a currently registered region (R2),^M split R2 into 3 new regions (R2a, R2b, and R2c) such that R2b is an^M exact duplicate of R1. Now remove R2 and add R1, R2a, R2b, and R2c^M to the master agent's lexicographically ordered set of regions (the^M registered OID space). Note: Though newly-added regions R1 and^M R2b are identical in terms of the MIB objects they contain, they are^M registered by different subagents, possibly at different priorities.^M ^M For instance, if subagent S2 registered `ip' (R2 is 1.3.6.1.2.1.4)^M and subagent S1 subsequently registered `ipNetToMediaTable' (R1 is^M 1.3.6.1.2.1.4.22), the resulting set of registered regions would be:^M ^M 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1)^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 16]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2)^M ^M If r.region (R1) overlaps one or more currently registered^M regions, then for each overlapped region (R2) split R1 into 3 new^M regions (R1a, R1b, R1c) such that R1b is an exact duplicate of^M R2. Add R1b and R2 into the lexicographically ordered set of^M regions. Apply the AddRegion operation to R1a and R1c (since^M they may overlap, or be subtrees of, other regions).^M ^M For instance, given the currently registered regions in the example^M above, if subagent S3 now registers mib-2 (R1 is 1.3.6.1.2.1) the^M resulting set of regions would be:^M ^M 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3)^M 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2)^M 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3)^M 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2)^M 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3)^M 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3)^M ^M Note that at registration time a region may be split into multiple^M regions due to pre-existing registrations, or as a result of any^M subsequent registration. This region splitting is transparent to^M subagents. Hence the master agent must always be able to associate^M any registered region with the information contained in its original^M Register-PDU.^M ^M 7.1.2.2.2. Handling Duplicate Regions^M ^M As a result of this registration algorithm there are likely to be^M duplicate regions (regions of identical MIB objects registered to^M different subagents) in the master agent's registered OID space.^M Whenever the master agent's dispatching algorithm (see 7.2.1,^M Dispatching AgentX PDUs) selects a duplicate region, the^M determination of which one to use proceeds as follows:^M ^M 1) Choose the one whose original Register-PDU specified the^M highest priority.^M ^M 2) If still ambiguous, choose the one whose original Register-PDU^M r.region contained the most subids, i.e., the most specific^M r.region. Note: A range subid is no "longer" (more specific)^M than a single subid.^M ^M 3) If still ambiguous, choose the one whose original Register-PDU^M was received most recently.^M ^M 7.1.3. The Unregister-PDU^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 17]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M The Unregister-PDU is sent by a subagent to remove a previously^M registered RegionSpecifier from the master agent's OID space.^M ^M 7.1.3.1. Unregister-PDU Fields^M ^M An Unregister-PDU contains the following fields:^M ^M - u.reason^M ^M - u.region indicates a previously-registered region of the MIB^M that a subagent no longer wishes to support. It may be a^M fully-qualified instance name, a partial instance name, a MIB^M table or group, or ranges of any of these.^M ^M - u.context is used by the subagent when identically named^M objects require a context to differentiate them. A null^M string indicates the default context.^M ^M 7.1.3.2. Processing the Unregister-PDU^M ^M If u.region and u.context do not exactly match the values of^M r.region and r.context of a previously processed Register-PDU which^M was sent from this subagent, the request is rejected with an^M appropriate error response.^M ^M Otherwise the master agent removes u.region from its registered OID^M space for u.context. If the original region had been split, all^M such related regions are removed. If this removal results in any^M contiguous regions that share a common original Register-PDU, they^M are agglomerated into a single region.^M ^M For instance, given the example registry above, if subagent S2^M unregisters `ip', the resulting registry would be:^M ^M 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3)^M 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3)^M 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3)^M 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3)^M ^M and after agglomeration;^M ^M 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4.22 (by S3)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1)^M 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3)^M 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.2 (by S3)^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 18]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 7.2. Processing Received SNMP Protocol Messages^M ^M When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or^M SetRequest protocol message is received by the master agent, the^M master agent implements the access control policy in effect at the^M managed node.^M ^M In particular, the master agent implements the Elements of Procedure^M defined in section 4.1 of [6] that apply to receiving entities.^M ^M [We can't refer to 1901, or v2u/v2* ?]^M ^M If this processing results in a valid SNMP request PDU, then an SNMP^M response PDU is constructed from information gathered in the^M exchange of AgentX PDUs between the master agent and 1 or more^M subagents. Upon receipt and initial validation of an SNMP request^M PDU, a master agent uses the procedures described below to dispatch^M AgentX PDUs to the proper subagents, marshal the subagent responses,^M and construct an SNMP response PDU.^M ^M 7.2.1 Dispatching AgentX PDUs^M ^M Upon receipt and initial validation of an SNMP request PDU, a master^M agent uses the procedures described below to dispatch AgentX PDUs to^M the proper subagents.^M ^M Note: In the following procedures, an object identifier is said to^M be "contained" within a registered region when both of the following^M are true:^M ^M - the object identifier does not lexicographically precede the^M region specifier^M ^M - the object identifier lexicographically precedes the end of the^M region^M ^M 7.2.1.1 GetRequest-PDU^M ^M An SNMP Response-PDU is constructed whose fields all contain the^M same values as in the SNMP Request-PDU, except that the value of^M each variable binding is set to 'noSuchObject'.^M ^M Each variable binding in the Request-PDU is processed in order, as^M follows:^M ^M (1) Identify the target region.^M ^M Within a list of regions registered within the context indicated^M in the request PDU, and lexicographically ordered by^M RegionSpecifier, locate the region that contains the variable^M binding's name.^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 19]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M (2) If no such region exists the variable binding is not processed^M further.^M ^M (3) Identify the target subagent, which is the one that registered^M the target region.^M ^M (4) If this is the first variable binding to be dispatched to the^M target subagent, create an AgentX Get-PDU for the subagent, with^M the header fields initialized as described in section 6.1.3, and^M the context in the Request-PDU encoded into g.context.^M ^M (5) Add a SearchRange to the end of the target subagent's Get-PDU^M for this variable binding.^M ^M - The variable binding's name is copied to g.start.^M ^M - g.end is set to null.^M ^M 7.2.1.2. GetNextRequest-PDU^M ^M An SNMP Response-PDU is constructed whose fields all contain the same^M values as in the SNMP Request-PDU, except that the value of each^M variable binding is set to 'endOfMibView'.^M ^M Each variable binding in the Request-PDU is processed in order, as^M follows:^M ^M (1) Identify the target region.^M ^M Within a list of regions registered within the context indicated^M in the request PDU, and lexicographically ordered by^M RegionSpecifier, locate^M ^M a) the region that contains the variable binding's name, or^M ^M b) the region whose RegionSpecifier is the first lexicographical^M successor to the variable binding's name.^M ^M (2) If no such region exists the variable binding is not processed^M further.^M ^M (3) Identify the target subagent, which is the one that registered^M the target region.^M ^M (4) If this is the first variable binding to be dispatched to the^M target subagent, create an AgentX GetNext-PDU for the subagent,^M with the header fields initialized as described in section 6.1.3^M and the context in the Request-PDU encoded into g.context.^M ^M (5) Add a SearchRange to the end of the target subagent's GetNext-PDU^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 20]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M for this variable binding.^M ^M - if 1a) applies, the variable binding's name is copied^M to g.start, and g.include is set to 0.^M ^M - if 1b) applies, the target RegionSpecifier is copied^M to g.start, and g.include is set to 1.^M ^M - g.end is set to the RegionSpecifier that is the first^M lexicographical successor to the target RegionSpecifier, and^M that was not registered by the target subagent. If no such^M RegionSpecifier exists, g.end is set to null.^M ^M 7.2.1.3. GetBulkRequest-PDU^M ^M (Note: The outline of the following procedure is based closely on^M section 4.2.3, "The GetBulkRequest-PDU" of [4]. Please refer to it^M for details on the format of the SNMP GetBulkRequest-PDU itself.)^M ^M An SNMP Response-PDU is constructed whose fields all contain the same^M values as in the SNMP Request-PDU. The SNMP Response-PDU contains^M N + (M * R) variable bindings whose values are set to `EndOfMibView',^M where^M ^M N ("non-repeaters") is the minimum of:^M a) the value of the non-repeaters field in the request, and^M b) the number of variable bindings in the request^M ^M M ("max-repetitions") is the value of the max-repetitions field^M in the request^M ^M R ("repeaters") is the maximum of:^M a) number of variable bindings in the request - N, and^M b) zero^M ^M Each variable binding in the Request-PDU is processed in order, as^M follows:^M ^M (1) Identify the target region and target subagent, exactly as^M described for the GetNextRequest-PDU (7.2.1.2).^M ^M (2) If this is the first variable binding to be dispatched to the^M target subagent during the processing of this Request-PDU, create^M an AgentX GetBulk-PDU for the subagent, with the header fields^M initialized as described in section 6.1.3 and the context and^M max_repetitions value in the request PDU encoded into g.context^M and g.max_repetitions. Set g.non_repeaters to 0.^M ^M (3) Add a SearchRange to the end of the target subagent's GetBulk-PDU^M for this variable binding, as described for the GetNext-PDU. If^M the variable binding was within the non_repeaters range in the^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 21]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M original Request-PDU, increment the value of g.non_repeaters.^M ^M When all variable bindings have been processed, send any AgentX PDUs^M to their respective target subagents (at the transport endpoint used^M to initiate the subagent's logical connection).^M ^M Calculate a timeout value for each target subagent that is the^M maximum of:^M ^M - The master agent's default.^M ^M - The subagent's default, as indicated by the subagent at^M connection establishment.^M ^M - Any region-specific timeout values, as indicated by the^M subagent at registration.^M ^M 7.2.2. Subagent Processing of AgentX Request PDUs^M ^M When a subagent receives an AgentX Get-, GetNext-, or GetBulk-PDU, it^M performs the indicated management operations and returns a response^M PDU.^M ^M The response PDU header fields are identical to the received^M request PDU except that, at the start of processing, the subagent^M initializes h.type to RESPONSE, res.error_code to `noError',^M res.error_index to 0, and the VarbindList to null.^M ^M Each SearchRange in the request PDU is then processed in order, and^M a corresponding VarBind added to the response PDU as described^M below. If processing should fail for any reason not described^M below, res.error_code is set to `genError', res.error_index to the^M index of the failed SearchRange, the VarBindList is reset to null,^M and this response PDU is returned to the master agent.^M ^M 7.2.2.1. Subagent Processing of the AgentX Get-PDU^M ^M Upon the subagent's receipt of an AgentX Get-PDU, each variable^M binding in the request is processed in order as follows:^M ^M 1) g.start is copied to v.name.^M ^M 2) If the value of g.start exactly matches the name of a^M variable instantiated by this subagent within the indicated^M context, v.type, v.length, and v.data are encoded to represent^M the variable's syntax and value, as described in section 5.2.^M ^M If the resulting VarBind's type is not compatible with the SMI^M for the SNMP framework of the version specified in h.snmp_version,^M v.type is set to `noSuchObject', and v.length to 0.^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 22]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M 3) Otherwise, if the value of g.start does not match the OBJECT^M IDENTIFIER PREFIX of any variable instantiated within the^M indicated context, v.type is set to `noSuchObject' and v.length^M to 0.^M ^M 4) Otherwise, v.type is set to `noSuchInstance' and v.length to 0.^M ^M 7.2.2.2. Subagent Processing of the AgentX GetNext-PDU^M ^M Upon the subagent's receipt of an AgentX GetNext-PDU, each variable^M binding in the request is processed in order as follows:^M ^M 1) The subagent searches for a variable within the^M lexicographically ordered list of variable names for all^M variables it instantiates (without regard to registration of^M regions) within the indicated context, for which the following^M are all true:^M ^M - if g.include is 0, the variable's name is the closest^M lexicographical successor to g.start.^M ^M - if g.include is 1, the variable's name is either equivalent^M to, or the closest lexicographical successor to, g.start.^M ^M - If g.end is not null, the variable's name lexicographically^M precedes g.end.^M ^M - The variable's syntax is compatible with the SMI for the SNMP^M framework of the version specified in h.snmp_version.^M ^M If all of these conditions are met, v.name is set to the^M located variable's name. v.type, v.length, and v.data are^M encoded to represent the variable's syntax and value, as^M described in section 5.2.^M ^M 2) If no such variable exists, v.name is set to g.start,^M v.type is set to `endOfMibView', and v.length to 0.^M ^M ^M 7.2.2.3. Subagent Processing of the AgentX GetBulk-PDU^M ^M A maximum of N + (M * R) VarBinds are returned, where^M ^M N equals g.non_repeaters,^M ^M M equals g.max_repetitions, and^M ^M R is (number of SearchRanges in the GETBULK request) - N.^M ^M The first N SearchRanges are processed exactly as for the GetNext^M PDU.^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 23]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M ^M If M and R are both non-zero, the remaining R SearchRanges are^M processed iteratively to produce potentially many VarBinds. For^M each iteration i, such that i is greater than zero and less than or^M equal to M, and for each repeated SearchRange s, such that s is^M greater than zero and less than or equal to R, the^M (N+((i-1)*R)+s)-th VarBind is added to the response PDU as follows:^M ^M 1) The subagent searches for a variable within the^M lexicographically ordered list of variable names for all^M variables it instantiates (without regard to registration of^M regions) within the indicated context, for which the following^M are all true:^M ^M - The variable's name is the (i)-th lexicographical successor^M to the (N+s)-th requested OID.^M ^M (Note that if i is 0 and g.include is 1, the variable's name^M may be equivalent to, or the first lexicographical successor^M to, the (N+s)-th requested OID.)^M ^M - If g.end is not null, the variable's name^M lexicographically precedes g.end.^M ^M - The variable's syntax is compatible with the SMI for the^M SNMP framework of the version specified in h.snmp_version.^M ^M If all of these conditions are met, v.name is set to the^M located variable's name. v.type, v.length, and v.data are^M encoded to represent the variable's syntax and value, as^M described in section 5.2.^M ^M 2) If no such variable exists, v.type is set to `endOfMibView'^M and v.length to 0. v.name is set to v.name of the^M (N+((i-2)*R)+s)-th VarBind unless i is currently 1, in which^M case it is set to the value of g.start in the (N+s)-th^M SearchRange.^M ^M Note that further iterative processing should stop if for any^M iteration i, all s values of v.type are `EndofMibView'.^M ^M When the AgentX response PDU has been generated, it is sent back to^M the master agent's transport endpoint from which the request was^M sent.^M ^M 7.2.3. Master Agent Processing of AgentX Responses^M ^M The master agent now marshals all subagent response PDUs and builds^M an SNMP response PDU. To do so, the master agent must be able to^M determine the corresponding variable binding (or error_index value)^M in the SNMP Response-PDU for each received AgentX VarBind (or^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 24]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M res.error_index value).^M ^M (Note in particular that a response PDU may contain more VarBinds^M than are required to complete the SNMP Response-PDU.)^M ^M 1) If any subagent did not respond within its allotted time period,^M the SNMP Response PDU's error code is set to `genError' and^M its error index to the index of the variable binding^M corresponding to the first VarBind in the request PDU that was^M sent to this subagent.^M ^M All other subagent response PDUs received due to processing this^M SNMP request are ignored. Processing is complete; the SNMP^M response PDU is sent.^M ^M 2) Otherwise, if the h.ID field of the AgentX response PDU does not^M match that of the request PDU sent to this subagent, the PDU is^M ignored.^M ^M 3) Otherwise, if res.error code is not `noError', the SNMP response^M PDU's error code is set to this value, and its error index to the^M index of the variable binding corresponding to the failed VarBind^M in the subagent's response PDU.^M ^M All other response PDUs received due to processing this SNMP^M Request are ignored. Processing is complete; the SNMP Response^M PDU is sent.^M ^M 4) Otherwise, the content of each VarBind in the RESPONSE PDU is used^M to update the corresponding variable binding in the SNMP^M Response-PDU.^M ^M After all expected response PDUs have been processed, if any^M variable bindings still contain the value `endOfMibView',^M processing must continue:^M ^M 5) For each such variable binding, a target region is^M identified which is the lexicographical successor to the^M target region for this variable binding on the last^M iteration. The target subagent is the one that registered^M the target region.^M ^M 6) If this is the first variable binding to be dispatched to^M the target subagent (during this iteration), create an^M AgentX GetNext-PDU or GetBulk-PDU for the subagent, with^M the header fields initialized as described in section 6.1.3^M and the context in the Request-PDU encoded into g.context.^M ^M For Get-Next PDUs:^M ^M 7) Add a SearchRange to the end of the target subagent's^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 25]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M GetNext-PDU for this variable binding. The target^M RegionSpecifier is copied to g.start, and g.include is^M set to 1. g.end is set to the RegionSpecifier that is^M the first lexicographical successor to the target^M RegionSpecifier, and that was not registered by the target^M subagent. If no such RegionSpecifier exists, g.end is set to^M null.^M ^M For Get-Bulk PDUs:^M ^M 7) Set the value of g.non_repeaters and g.max_repetitions^M to 0.^M ^M 8) Add a SearchRange to the end of the target subagent's^M GetBulk-PDU for this variable binding. The target^M RegionSpecifier is copied to g.start, and g.include is^M set to 1. g.end is set to the RegionSpecifier that is^M the first lexicographical successor to the target^M RegionSpecifier, and that was not registered by the target^M subagent. If no such RegionSpecifier exists, g.end is set to^M null.^M ^M 9) If the variable binding was within the non_repeaters range^M in the original Request-PDU, increment the value of^M g.non_repeaters.^M ^M Otherwise, set the value of g.max_repetitions to the^M maximum of its current value, or the number of response^M variable bindings still required for this requested^M variable binding.^M ^M 10) The AgentX PDUs are sent, received, and processed^M according to section 7.2.3.^M ^M 11) This process continues iteratively until a complete SNMP^M Response-PDU has been built, or until there remain no^M target region lexicographical successors.^M ^M [Include examples, TBD]^M ^M 7.2.4 MIB Views^M ^M AgentX subagents are not aware of MIB views, since view information^M is not contained in AgentX PDUs.^M ^M As stated above, the descriptions of procedures in section 7 of this^M memo are not intended to constrain the internal architecture of any^M conformant implementation. In particular, the master agent^M procedures described in sections 7.2.1 and 7.2.3 may be altered so^M as to optimize AgentX exchanges when implementing MIB views.^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 26]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M Such optimizations are beyond the scope of this memo. But note that^M section 7.2.3 defines subagent behavior in such a way that alteration^M of g.start and g.end may be used in such optimizations.^M ^M 7.2.5. Sending the SNMP Response PDU^M ^M Once the processing described in sections 7.2.1 - 7.2.3 is^M complete, there is an SNMP response PDU available. The master agent^M now implements the Elements of Procedure for the applicable version^M of the SNMP protocol in order to encapsulate the PDU into a message,^M and transmit it to the originator of the SNMP management request.^M ^M Note that this may involve altering the PDU contents for agents^M that support the SNMP version 1 framework, or when returning^M an error response.^M ^M [Do we need to mention explicit mappings? For instance, for v2^M Set error codes?]^M ^M ^M 8. Master Agent Transport Mappings^M ^M [TBD]^M ^M ^M 9. Security Considerations^M ^M Security issues are not discussed in this memo.^M ^M ^M 10. Acknowledgements^M ^M The initial draft of this memo was heavily influenced by the DPI^M 2.0 specification [7].^M ^M This document was produced by the IETF Agent Extensibility^M (AgentX) Working Group.^M ^M ^M 11. References^M ^M [1] Information processing systems - Open Systems Interconnection -^M Specification of Abstract Syntax Notation One (ASN.1),^M International Organization for Standardization. International^M Standard 8824, (December, 1987).^M ^M [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and^M S. Waldbusser, "Structure of Management Information for Version 2^M of the Simple Network Management Protocol (SNMPv2)", RFC 1902,^M January 1996.^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 27]^M ^L^M Draft Agent Extensibility (AgentX) Protocol June 1996^M ^M ^M [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and^M S. Waldbusser, "Textual Conventions for Version 2 of the Simple^M Network Management Protocol (SNMPv2)", RFC 1903, January 1996.^M ^M [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and^M S. Waldbusser, "Protocol Operations for Version 2 of the Simple^M Network Management Protocol (SNMPv2)", RFC 1905, January 1996.^M ^M [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and^M S. Waldbusser, "Management Information Base for Version 2 of the^M Simple Network Management Protocol (SNMPv2)", RFC 1907,^M January 1996.^M ^M [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network^M Management Protocol", STD 15, RFC 1157, SNMP Research, Performance^M Systems International, MIT Laboratory for Computer Science, May^M 1990.^M ^M [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters,^M "Simple Network Management Protocol: Distributed Protocol^M Interface, Version 2.0", RFC 1592, T.J. Watson Research Center,^M IBM Corp., Bell Northern Research, Ltd., March 1994.^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M Daniele/Francisco Expires December 1996 [Page 28]^M