INTERNET-DRAFT L. Heintz Cisco Systems, Inc. 19 April 2001 SNMP Row Operations Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes a set of extensions (protocol operations and textual conventions) to the existing SNMP framework architecture as defined in RFC2571. These extensions provide mechanisms for efficient creation, modification, deletion and retrieval of table rows. Table of Contents 1. The SNMP Network Management Framework ....................... 3 2. Overview .................................................... 4 2.1. Terms ..................................................... 4 2.2. Motivations for the Extensions ............................ 4 2.3. Design Goals .............................................. 5 EOS Working Group Expires October 2001 [Page 1] Internet Draft SNMP Row Operations Extensions 19 April 2001 3. The Extensions .............................................. 6 3.1. RowState .................................................. 6 3.2. Row Operations ............................................ 8 3.2.1. The rowIdentifier ....................................... 9 3.2.2. The operands ............................................ 12 3.2.3. Distinguishing rowIdentifiers from operands ............. 13 3.2.4. RowState and RowStatus Considerations ................... 13 3.2.5. Granularity of Success/Fail ............................. 14 3.2.6. Response PDUs ........................................... 14 4. Elements of Procedure ....................................... 14 4.1. CreateRow Request Processing .............................. 14 4.2. DeleteRow Request Processing .............................. 14 4.3. EditRow Request Processing ................................ 15 4.4. GetRow Request Processing ................................. 15 4.5. GetNextRow Request Processing ............................. 15 4.6. Response-PDU Processing ................................... 15 5. Coexistence and Transition .................................. 15 6. Protocol Operations Definitions ............................. 17 7. Managed Object Definitions .................................. 18 8. IANA Considerations ......................................... 19 9. Intellectual Property ....................................... 19 10. Acknowledgements ........................................... 19 11. Security Considerations .................................... 20 12. References ................................................. 20 13. Editor's Addresses ......................................... 23 A. Impact to SNMP and other Protocols .......................... 24 A.1. SNMPv3 .................................................... 24 A.2. AgentX .................................................... 24 B. Alternative Approaches ...................................... 24 C. Examples of Row Operations .................................. 25 C.1. CreateRow with RowStatus .................................. 25 C.2. CreateRow with RowState ................................... 26 C.3. DeleteRow ................................................. 27 C.4. GetRow and GetNextRow ..................................... 28 D. Known issues ................................................ 29 E. Full Copyright Statement .................................... 31 EOS Working Group Expires October 2001 [Page 2] Internet Draft SNMP Row Operations Extensions 19 April 2001 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [RFC2571]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. - A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the EOS Working Group Expires October 2001 [Page 3] Internet Draft SNMP Row Operations Extensions 19 April 2001 MIB. 2. Overview This document describes a set of SNMP extensions to current protocol operations [RFC1905] to provide for efficient row operations (i.e. creating, modifying, deleting and retrieving table rows). In addition, a new textual convention, RowState, is defined to replace RowStatus in future MIBs. RowState maintains the ability to report the state of a row, but does not attempt to provide a mechanism to create or delete a row. APPENDIX A discusses some of the known impacts that these extensions may cause to current frameworks or protocols (e.g. AgentX). It is recognized that any one of several other approaches exist that could have been used to meet the design goals of this document. As such, a few of these approaches are briefly discussed in APPENDIX B. 2.1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology such as "leftmost" or "left" indicates a PDU component that is transmitted on the wire prior to other components. Thus, terms such as "rightmost" imply components that have similar, but opposite semantics. Protocol operation refers to a high-level request, such as a SetRequest or GetRequest (or one of the five new requests defined within this document). Row operation refers to one logical operation that affects one specific table row. A protocol operation may contain one or more row operations. The term rowOp refers to the component parts of a protocol operation that comprise a single row operation. 2.2. Motivations for the Extensions Experience has shown that current SNMP protocol operations and management structures are not ideally suited to effect configuration changes within managed devices and when retrieving information. The extensions described in this document are specifically designed to minimize, or provide opportunities to minimize the following problems which inhibit th effectiveness of SNMP: EOS Working Group Expires October 2001 [Page 4] Internet Draft SNMP Row Operations Extensions 19 April 2001 - Requests that contains multiple varbinds that affect one row of a table may contain significant redundancy of information. This is because each varbind contains an object name (i.e. Object Identifier or OID), and these OIDs may differ only in the single subid that designates a specific column. In cases where strings are used as instance identifiers, for example, UDP maximum-message-size constraints may force multiple SetRequests to be used to construct a new, or modify an existing row in a table. Requests containing redundant data are also more costly to encrypt and decrypt. - SetRequests may contain multiple varbinds that actually refer to the same MIB object. For example, varbind one may be attempting to set the object, foo, to the value 1, while varbind two may be attempting to set the same object, foo, to the value 2. In such cases, the SNMP protocol indicates that implementations may make independant decisions as to which varbind will effectively be used as the final result. - SetRequests do not impose any ordering requirements on the varbinds within a single request, even if they affect different objects in the same row of a table. This can cause added complexity in SetRequest processing. - The RowStatus textual convention [RFC1903] provides a mechanism for row management. RowStatus most often requires the implementation of a rather complicated state machine, many of whose transitions are optional and whose target states are at times non-deterministic. RowStatus also confuses the notion of row status with the notion of row fate, which also tends to complicate both the MIB design and the implementation. 2.3. Design Goals Several goals were identified when considering the kinds of extensions that were needed: - allow separate row operations (hereafter referred to as rowOps) to be performed in a single protocol operation. - minimize redundant information in a protocol operation. The extensions should at least make use of OID suppression techniques to meet this goal. Note that OID suppression (largely an issue of how data is stored within a PDU) is not equivalent to OID compression (data compression algorithms). Issues of OID compression are considered out of scope for this document. EOS Working Group Expires October 2001 [Page 5] Internet Draft SNMP Row Operations Extensions 19 April 2001 - eliminate the need for special MIB objects (e.g. RowStatus) that control the creation and deletion of rows. - minimize the impact on existing network management and subagent protocols such as SNMPv3, AgentX, and related applications. - interoperate with legacy MIBs as well as future MIBs. - operate in existing SNMP networks and not disrupt legacy SNMP- capable devices. 3. The Extensions Five new conceptual protocol operations are described in this document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU (aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU (aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of these request types are based on the same PDU structure as originally defined in [RFC1905]. For purposes of discussion, the three requests, CreateRow, DeleteRow and EditRow are more generically referred to as SetRow class requests, while GetRow and GetNextRow are referred to as RetrieveRow class requests. In addition, a RowState textual convention is defined and is intended to replace RowStatus in all future MIB designs. It is not the intention to deprecate RowStatus. Although RowState is not a protocol operation, it does serve to reestablish a distinction between SNMP data types and SNMP operations -- a line which is blurred in the current RowStatus definition. 3.1. RowState As mentioned earlier, this document defines a proposed textual convention, RowState, whose purpose is to replace RowStatus in future MIBs. This convention provides several important improvements over RowStatus: - RowState relaxes some of the row timeout rules that RowStatus suffers from. Such rules inhibit the usefulness of RowStatus as a means of temporarily placing system resources (i.e. table rows) out of service. For example, if an SNMP manager changes a given instance of snmpNotifyRowStatus from Active to NotInService as a means of temporarily disabling one or more notifications, an unintended side-effect of this action on some EOS Working Group Expires October 2001 [Page 6] Internet Draft SNMP Row Operations Extensions 19 April 2001 implementations may be that the row is automatically deleted after some short amount of time has elapsed (typically, a few minutes). - More importantly, RowState separates the notion of reporting row status and the notion of managing row fate (i.e. creation & deletion). Specifically, the purpose of RowState is to enable reporting of row state, while matters of creating and deleting rows are better served by protocol operations. RowState provides three states: NotReady, NotInService and Active, which are very similar to the corresponding RowStatus definitions. Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo or Destroy. Any entity providing a RowState column in a table must instantiate an instance of RowState when one or more other column objects in the same row have been created or instantiated (by whatever means). Using the new protocol operations defined in this document, it is unnecessary to directly set or reference a RowState instance in order to create and activate a new row. The initial state of RowState is determined at the moment of initial row creation according to the semantics specified by the MIB designer (as provided within the Description clause of the RowState object, and much in the same way that RowStatus descriptions customize the semantics of those objects). At the time of row creation, the row creator may explicitly set the RowState object to a desired initial value, but the processing entity refers to this as a kind of "hint" since the final decision as to the initial value can only be determined after the complete row contents within the creation operation have been evaluated. One of the other differences between RowState and RowStatus is that RowState objects can never be automatically deleted from the entity as a result of timeouts when their states are either NotInService or Active. This provides the ability to use RowState objects to indefinitely take a row out of service without the fear of it being automatically deleted. When and whether rows containing RowState objects are added to, or removed from, non-volatile storage are not addressed by RowState. Such behavior must be specified by other means (e.g. StorageType), which is out of scope for this document. In addition, unlike RowStatus, it is permissible to explicitly set RowState objects to the NotReady state as a crude means of allowing traditional SetRequests to delete the row. In this case, deletion occurs as a side effect of a row timeout. As will be shown, the preferred method of deleting any row is via use of the new DeleteRow request, which does not contain any direct reference to any specific EOS Working Group Expires October 2001 [Page 7] Internet Draft SNMP Row Operations Extensions 19 April 2001 row object (such as RowState). The CreateRow request introduces the ability to set either RowStatus or RowState objects without the need to explicitly include a varbind in the request. A CreateRow request by convention contains an implicit operand (i.e. varbind) to set a corresponding RowState object (if any) to the Active value. This implicit varbind can be overridden by the inclusion of an actual RowState varbind. For example, the following two CreateRow requests are logically identical, as both will attempt to create a newly active fooEntry, whose index is 1, and whose fooInt object equals 2: CreateRow (fooEntry.1, fooInt=2); CreateRow (fooEntry.1, fooInt=2, fooRowState=Active); These two requests are NOT logically identical: CreateRow (fooEntry.1, fooInt=2); CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService); Implementations are not required, however, to support such implicit operands within CreateRow requests for RowStatus objects. This is intended to maximize the set of possible transition solutions for vendors of SNMP technology. The RowState textual convention provides full details of its use and operation and is provided in section 6. 3.2. Row Operations The new protocol operations are designed to "fit" in the existing PDU structure as originally defined in [RFC1905]. One of the alternative approaches discussed in the Appendix is the possibility of defining a new PDU structure that allows a more efficient OID suppression strategy than the one described herein. However, the initial approach offered in intended to "look and feel" as close to the current framework as possible. As will be shown, the current PDU structure is quite sufficient to obtain significant (but not optimal) OID suppression benefits. Formal definitions of the new protocol operations are provided in section 5. [RFC1905] provides the PDU definition which these new operations are based on. Although the old PDU structure is maintained for now, this document specifies an evolutionary approach in the way that the new protocol operations are encoded or contained within the PDU. As such, the new EOS Working Group Expires October 2001 [Page 8] Internet Draft SNMP Row Operations Extensions 19 April 2001 requests capitalize on OID suppression techniques to minimize information redundancy and therefore minimize PDU size. Note that the traditional SNMP protocol operations as defined in [RFC1905] are not being changed, either in their semantics, the way data is encoded within them, or the way they are processed. The following general discussion centers on how the varbinds of the new protocol operations are formed or constructed. Other components of the PDU (e.g. error-index) are treated similarly to the current framework. The elements of procedure, section 4, formally describes how the new requests are processed. APPENDIX C provides some high- level examples of the use of these operations. The varbinds in a PDU form one or more independant row operations (rowOps). This allows a single CreateRow request, for example, to create one or more new rows in a single protocol operation. Each rowOp corresponds to one attempt to create a row, in this case, or corresponds to one attempt to delete a row in the case of DeleteRow, and so forth. Note that the three layers in the diagram below do not describe different sections of the PDU, rather, they each represent the same information and structure (at different levels of abstraction). Although the above diagram shows a CreateRow request logically containing three rowOps (i.e. create three rows) with two consecutive varbinds per rowOp, in reality, these requests may contain one, two, or more than two rowOps, each of which may may be comprised of a differing number of varbinds (i.e. zero, one, or more than one). In addition, the above example (and the ones that follow) could have substituted a RetrieveRow class request instead of CreateRow, The varbinds allocatted to a single rowOp serve to function as either a rowIdentifier or as operands. 3.2.1. The rowIdentifier The first varbind in each rowOp provides basic request parameters, and is hereafter referred to as the rowIdentifier parameter of a rowOp. The remaining varbinds in a given rowOp provide the individual operands (i.e. the affected row objects), which are hereafter referred to as operands. In the diagram above, the 1st, 3rd and 5th varbinds are therefore rowIdentifiers while the 2nd, 4th and EOS Working Group Expires October 2001 [Page 9] Internet Draft SNMP Row Operations Extensions 19 April 2001 6th varbinds are operands. The following diagram shows a GetRow request containing a single rowOp that itself is composed of the required rowIdentifier and two operands. In this case, the GetRow request is seeking to retrieve two specific column objects from a specific row. To understand how each rowIdentifier varbind is constructed and what information is contained therein, it is useful to consider how OIDs for table objects are formed. An OID for a given object instance in a table can be broken up into three logical components: OID = If a traditional SetRequest contains two varbinds referring to two different columns in the same row, it is evident that both OIDs differ only in the integer value of the columnPart (a single subid). The other two parts, tableEntryPart and instancePart, therefore, are identical for each varbind present in a request affecting only a single table. A more meaningful representation for rowIdentifier is now possible: rowIdentifier = The vb.type MUST specify a type of OID. This is because the instancePart of an OID is actually comprised of one or more table index values, depending on which table is affected and how many MIB objects comprise the INDEX clause of that table. For example, for a table whose INDEX is comprised of a single integer, instancePart will be a single subid; and for a table whose INDEX is comprised of two or more objects of any kind, the instancePart will be an OID (index1 + index2 + ... + indexN) with each index component representing one or more subids. Because the instancePart always resolves to one or more subids, and because a valid OID must be composed of at least two subids, we prefix the instancePart with the OID value of 0.1. The reason EOS Working Group Expires October 2001 [Page 10] Internet Draft SNMP Row Operations Extensions 19 April 2001 instancePart cannot simply be prefixed with a single subid is that OIDs of the form 0.X, where X > 39, are not legal. Thus, if instancePart resolved to a single subid of 40 (or greater), the value of 0.40 would be illegal. Thus the need to prefix instancePart with two subids that guarantee a valid OID will be formed regardless of how instancePart is resolved. Note that due to ASN.1/BER encoding rules, the first two subids comprise only a single byte within the PDU. The rowIdentifier of each rowOp in a SetRow or RetrieveRow request specifies the exact row affected by the rowOp (but not which column objects are affected in that row). Consider the case of two or more rowOps in, say, a SetRow request that only affects different rows in the same table. In such cases, the varbind names of all the rowIdentifier varbinds will contain identical values. In order to therefore further minimize information redundancy, the OID of 1.0 (hereafter referred to as the inheritance OID, and occupying only a single byte within the resulting PDU) is permitted to be substituted as the varbind name of any rowIdentifier to indicate that the most recent (leftmost) rowIdentifier whose name is dissimilar (not 1.0) contains the OID value intended to be used. In this example, a simplified notation is used to help illustrate how a rowOp (the two middle ones in this case) uses the inheritance OID to minimize PDU size. This example shows four rowOps, each comprised of one rowIdentifier and one operand (op): [] [<1.0>] [<1.0>] [] The following is logically identical to the preceding example (though it forms a larger PDU): [] [] [] [] Of course, this implies that rowOps that affect the same table SHOULD be consecutively placed in the PDU varbind list, and also that the first rowIdentifier in the PDU MUST NOT contain the inheritance OID. Each rowOp is fully independant of any other despite any inheritance it may use. Each rowOp MUST contain a single rowIdentifier varbind, which MUST be the first varbind in each rowOp. The tableEntryPart of a rowIdentifier MUST NOT contain partial OIDs. This means that the tableEntryPart MUST always exactly correspond to a legal table entry definition (if the desired results are to be achieved). The motivation behind this is that all rowOps are performed at the row EOS Working Group Expires October 2001 [Page 11] Internet Draft SNMP Row Operations Extensions 19 April 2001 level. The instancePart within a GetNextRow is not required to be fully formed except that if the value is non-NULL, it MUST at least contain the 0.1 prefix. Also note that GetNextRow requests do not "jump" to the next table. In other words, in the event a GetNextRow rowOp refers to the last row in a given table, the appropriate exception is returned for that rowOp even if other tables follow that contain retrievable rows. In this sense, GetNextRow is limited to operate within the subtree of the targeted table(s). 3.2.2. The operands The remaining varbinds for a given rowOp are referred to as its operands, and are formed as standard SetRequest varbinds except that the name of each varbind is an OID whose length is exactly three subids long. The first two subids MUST be 0.1 and the third subid is taken from the affected column descriptor value whose object instance is affected. The reason three subids are specified (0.1.columnSubid) instead of two (0.columnSubid) is that columnSubid must accept all values in the range from 0 to 4294967295. However, the ASN.1/BER encoding rules do not allow OID values of 0.X where X > 39. Note that typical OIDs formed this way (where columnSubid is small) will be comprised of only two bytes despite the fact that three subids are specified. Each operand contained in the same rowOp will have a varbind name such that varbind N MUST be lexicographically smaller than the name of varbind N+1. In other words, there is a left to right ordering relationship imposed on the rowOp operands to further provide implementation optimization opportunities and to further guarantee that multiple and possibly conflicting operands for the same column object cannot be provided (further minimizes information redundancy and processing ambiguity). For example, the operand with the name of, 0.1.0, MUST be to the left of the operand with the name of, 0.1.1, if they are operands of the same rowOp. Any rowOp may contain zero or more operands, except that the EditRow request MUST contain at least one operand. In case of RetrieveRow requests, if zero operands are provided in a rowOp, this implicitly calls for the retrieval of all instantiated objects in the affected row. Otherwise, only the specified objects are retrieved. In cases of CreateRow, at least one column definition in each of the affected tables must have a MAX-ACCESS of read-create and the the EOS Working Group Expires October 2001 [Page 12] Internet Draft SNMP Row Operations Extensions 19 April 2001 affected rows MUST NOT already exist (in whole or part). If zero operands are provided in a rowOp, then the row must be able to be created in whole or part using only default values. In cases of EditRow, each rowOp contains an operand for each row object whose value is being changed and whose MAX-ACCESS is either read-create or read-write. The affected rows MUST already exist (in whole or part), though the specific operands MAY refer to objects that do not yet exist. In cases of DeleteRow, each rowOp MAY contain operands whose MAX- ACCESS are either read-write or read-create. While it is not essential that operands be included in a DeleteRow request, they may in special cases be useful, for example, when a proxy application translates a DeleteRow request to a conventional SetRequest that requires a RowStatus reference. 3.2.3. Distinguishing rowIdentifiers from operands As described earlier, the varbinds in a rowOp function either as a rowIdentifier (one per rowOp) or as an operand (zero or more per rowOp). By definition, the first varbind in any SetRow or RetrieveRow request MUST be a rowIdentifier. The varbind names of all rowIdentifiers are guaranteed to be OIDs with a minimum of four subids (because current SMIv2 rules and current IANA object registrations preclude the possibility that table entry definitions can have shorter OIDs). One exception to this, is that varbind names for rowIdentifiers may contain the inheritance OID value of, 1.0 (see earlier discussion for how and why this is used). The varbind names of all operands, on the other hand, are OID values with exactly three subids whose first two subids form an OID of 0.1.X. In summary, if a varbind name contains an OID of the form 0.1.X (exactly three subids) then the varbind in question functions as an operand. Otherwise, the varbind functions as a rowIdentifier. 3.2.4. RowState and RowStatus Considerations It is worthwhile to note that SetRow class requests allow new MIBs to be created without requiring use of the RowStatus or RowState textual conventions to allow for either incremental or "big-bang" style (i.e. CreateAndWait or CreateAndGo, resp.) row creation or deletion. RowState is useful only to report the current state of a row -- notwithstanding the slight anomaly that it also allows SetRequests EOS Working Group Expires October 2001 [Page 13] Internet Draft SNMP Row Operations Extensions 19 April 2001 and EditRow requests to explicitly change the state of such objects to NotReady, and thereby cause a row deletion timer to be instantiated. Similarly, traditional SetRequests and SetRow requests can both be used to manage MIBs that incoporate RowStatus columns. For new MIB tables that do not require row state reporting objects, but which do require creation and/or deletion semantics, it is sufficient to omit RowState and RowStatus entirely and instead use a MAX-ACCESS of read-create for all writable objects. Such tables can elegantly support row creation through use of the CreateRow or traditional SetRequest operations, and also support row deletion through use of the DeleteRow operation. 3.2.5. Granularity of Success/Fail In the event a SetRow class request contains two or more rowOps that affect the same row, the elements of procedure (below) indicate that all rowOps in the SetRow request are to be rejected (i.e. all rowOps fail and the entity remains in the state it was in prior to receiving the SetRow request). RetrieveRow class requests can succeed or fail individually or even with each varbind. 3.2.6. Response PDUs This document does not define any new response PDU. Instead, the traditional Response-PDU [RFC1905] is used as the standard response to each of the SetRow and RetrieveRow requests, except that the varbinds are constructed using the same OID suppression techniques as described above. 4. Elements of Procedure 4.1. CreateRow Request Processing TBD 4.2. DeleteRow Request Processing TBD EOS Working Group Expires October 2001 [Page 14] Internet Draft SNMP Row Operations Extensions 19 April 2001 4.3. EditRow Request Processing TBD 4.4. GetRow Request Processing TBD 4.5. GetNextRow Request Processing TBD 4.6. Response-PDU Processing TBD 5. Coexistence and Transition An essential requirement for these operations is that they must operate seamlessly in existing networks and not disrupt legacy SNMP devices. This is satisfied by the fact that the new protocol operations have new and unique ASN.1 tags, which allow older implementations to efficiently and silently drop these new PDU requests. Some entities may only support these extensions for certain tables. For example, different AgentX subagents may or may not support these operations. This requires that the requests fail whenever a table is targeted that cannot support the new operation. The elements of procedure indictate the proper exceptions in these cases. It is also possible that some table implementations may support only some subset of the new operations, for example, the RetrieveRow requests, but not the SetRow requests. It is herein RECOMMENDED that SNMP entities that support at least one operation within a class (i.e. SetRow or RequestRow) for a given table SHOULD support all requests within the same class for that table. Also, it is further RECOMMENDED that if the SetRow class of operations are supported for a given table, then the entity SHOULD also support all the RetrieveRow operations for that table. For any operation not supported by a targeted table (which nevertheless supports other operations), the elements of procedure indicate the proper exceptions that apply. EOS Working Group Expires October 2001 [Page 15] Internet Draft SNMP Row Operations Extensions 19 April 2001 In an ideal world, the extensions herein would be easily translatable to traditional operations. However, this is not the case. Consider, for example, that it is impossible to form an equivalent SetRequest from a DeleteRow request that contains only a rowIdentifier but no operands. In fact, any SetRow or RetrieveRow request containing no operands cannot be translated into an equivalent Set/Get request because at least one operand is needed to convert the rowIdentifier information into a valid object (OID) reference. DeleteRow may optionally include a RowStatus object, which allows such a translation, but then the question arises as to the need for DeleteRow definitions in the first place. Or consider a proxy application that accepts CreateRow or EditRow requests and translates them into an equivalent SetRequest. For example, CreateRow(fooEntry.row1, fooInt=1) is translated into Set(fooEntry.fooInt.row1=1). Note that an EditRow request containing the same varbind info would be translated into the exact same Set request. This implies that proxy applications cannot faithfully translate these two extensions into a SetRequest with the same semantics as the original request. A CreateRow request, after translation, might incorrectly cause an existing row to be modified, whereas an EditRow request might cause a new row to be instantiated. A partial workaround is to explicitly include a RowStatus reference in all CreateRow requests, and to ensure that rows do not exist before issuing EditRow requests, though in multi-manager environments, this latter procedure suffers. The same issues are evident when a master agent needs to translate the extensions into traditional subagent PDU forms. Semantics may be lost in the translation, and only some amount of workaround is possible unless the underlying subagent protocol is itself extended to accomodate the new extensions. While it is possible to develop proxy applications that incorporate simple PDU translation schemes to generally allow EOS-capable devices (as described herein) to interoperate with non-EOS-capable devices, the workarounds that would be needed might in some (but not all) environments mitigate some or all of the benefits in using the new extensions in the first place. In short, with the approach outlined in this document, it is believed that non-EOS-capable devices need to be converted into EOS-capable devices by means other than simple PDU translation schemes. In order to enable a transition strategy that uses simple PDU translation mechanisms, at least some of the earlier stated goals of this document would have to be abandoned (e.g. the goal to replace MIB objects such as RowStatus which confuse the notions of row state with EOS Working Group Expires October 2001 [Page 16] Internet Draft SNMP Row Operations Extensions 19 April 2001 row fate, and perhaps other goals as well). 6. Protocol Operations Definitions SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN IMPORTS PDU SNMPv2-PDU; ROWOP-PDUs ::= CHOICE { create-row-request CreateRowRequest-PDU, delete-row-request DeleteRowRequest-PDU, edit-row-request EditRowRequest-PDU, get-row-request GetRowRequest-PDU, get-next-row-request GetNextRowRequest-PDU } CreateRowRequest-PDU ::= [9] IMPLICIT PDU DeleteRowRequest-PDU ::= [10] IMPLICIT PDU EditRowRequest-PDU ::= [11] IMPLICIT PDU GetRowRequest-PDU ::= [12] IMPLICIT PDU GetNextRowRequest-PDU ::= [13] IMPLICIT PDU EOS Working Group Expires October 2001 [Page 17] Internet Draft SNMP Row Operations Extensions 19 April 2001 END 7. Managed Object Definitions SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpRowopMIB MODULE-IDENTITY LAST-UPDATED "200104191653Z" ORGANIZATION "EOS Working Group" CONTACT-INFO "WG-EMail: eos@ops.ietf.org Subscribe: eos-request@ops.ietf.org Co-Chair: Dale Francisco Cisco Systems, Inc. postal: 80 West Tasman Drive San Jose, CA 95134 USA EMail: dfrancis@cisco.com phone: +1 408-527-9787 Co-Chair: Glenn Waters Nortel Networks postal: USA EMail: gww@nortelnetworks.com phone: Co-editor: Lauren Heintz Cisco Systems, Inc. postal: 130 Baytech Drive San Jose, CA 95134 USA EMail: lheintz@cisco.com phone: +1 408-853-6568 " DESCRIPTION "The SNMP Row Operations MIB" REVISION "200103280000Z" DESCRIPTION "The initial version, published in draft-ietf-eos-snmp-rowops-00.txt. " EOS Working Group Expires October 2001 [Page 18] Internet Draft SNMP Row Operations Extensions 19 April 2001 ::= { snmpModules TBD } -- Textual Conventions RowState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "TBD" SYNTAX INTEGER {TBD} END 8. IANA Considerations This document requires IANASnmpExtendedProtocol values to be reserved for allowing command responders to advertise their ability to support the extensions outlined in this document. IANASnmpExtendedProtocol values are administered by IANA. IANASnmpExtendedProtocol is defined in SNMP-X-PROTOCOL-TC. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Acknowledgements This document is the result of the efforts of the Evolution Of SNMP (EOS) Working Group. Some special thanks are in order to the following EOS WG members: EOS Working Group Expires October 2001 [Page 19] Internet Draft SNMP Row Operations Extensions 19 April 2001 TBD 11. Security Considerations TBD 12. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP- based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol", , April 2001. [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol", , April 2001. [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for the Simple Network Management Protocol", , April 2001. [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", , April 2001. [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, February 1996. [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC 1910, February 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January, 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB." RFC 2863, June 2000. [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", , April 2001. [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", , April 2001. [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", , February 1999. , April 2001. [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP EOS Working Group Expires October 2001 [Page 21] Internet Draft SNMP Row Operations Extensions 19 April 2001 Applications", , April 2001. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", , January 1999. [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", , April 2001. EOS Working Group Expires October 2001 [Page 22] Internet Draft SNMP Row Operations Extensions 19 April 2001 13. Editor's Addresses Lauren Heintz Cisco Systems, Inc. 130 Baytech Drive San Jose, Ca 95134 Phone: +1 408-853-6568 EMail: lheintz@cisco.com EOS Working Group Expires October 2001 [Page 23] Internet Draft SNMP Row Operations Extensions 19 April 2001 APPENDIXES A. Impact to SNMP and other Protocols A.1. SNMPv3 An issue remains whether a new message processing model MUST be specified as part of the SNMPv3 (or later) standard. Otherwise, it is not seen that these extensions pose any impact to other SNMPv3 architectural components (i.e. USM, VACM) because the new protocol operations and their contents contain sufficient information (along with the information provided in whatever version-specific message wrapper they are contined within) to satisfy the abstract service interfaces for those components. However, these extensions are not compatible with the SNMPv3 proxy application (or any legacy SNMP application incorporating a message processing module that receives and processes or forwards SNMP messages). A.2. AgentX These extensions imply that AgentX will have to evolve in order to support the new protocol operations. For example, AgentX does not provide a delete PDU (to support DeleteRow), and neither does its TestSet PDU provide for a standard way to indicate whether the operation being performed maps to a CreateRow or EditRow request. Furthermore, master agents will need to know how to recognize and process the new protocol operations (i.e. distinguish rowIdentifiers from operands, logically expand the targeted object OIDs and map them to subtree registrations). B. Alternative Approaches This section will be deleted before going standards track. This document outlines one approach to achieving the design goals stated earlier. Several other approaches also exist. Here are some hints: - Use the same approach described herein except define a new "RowPDU" to further optimize OID suppression (i.e. get rid of the 0.1.X column subid notation). This may require a new kind of varbind list where each varbind is no longer an OID/value EOS Working Group Expires October 2001 [Page 24] Internet Draft SNMP Row Operations Extensions 19 April 2001 pair, but instead it is an Integer/Value pair. Similarly, this new PDU could contain one or more rowIdentifier items (one per rowOp). - Instead of having five new request types, use only one instead and perhaps have an operator within the request to indicate the nature of the operation. Also, the operator might be included within each rowOp contained within the request so that one protocol operation might contain mixed row operations (i.e. a createRow and deleteRow might co-exist in the same protocol request). - Maintain the same PDU structure, but re-define what a varbind is (i.e. one varbind might actually be able to contain a sequence of objects, all of which pertain to one row operation). You'd still have to define where/how you designate which row(s) and column(s) are affected. - Nix the RowState idea, keep RowStatus, and simply provide traditional protocol operations, perhaps with a way of minimizing overhead. In this case, we would tradeoff feature set richness with the potential of being able to provide easier transition solutions for legacy systems (i.e. the requests might be more easily translatable into conventional requests). - Some combination of the above, or other? C. Examples of Row Operations Each of the following examples assumes that the error-index and error-status fields of the manager initiated request are set to 0 and the request-id contains an appropriate value. C.1. CreateRow with RowStatus This protocol exchange illustrates the use of the CreateRow request to create two new rows in the snmpNotifyTable [RFC2573]. This table uses RowStatus, so we choose to explicitly set its value for each row, as desired (some impls may allow us to instead omit setting RowStatus and rely on implicit support for it). Note that the second rowOp inherits its table OID information from the previous rowOp (because 1.0 instructs this). CreateRow ( EOS Working Group Expires October 2001 [Page 25] Internet Draft SNMP Row Operations Extensions 19 April 2001 -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(SnmpTagValue) = "tag1" vb3.name = 0.1.3 -- snmpNotifyType vb3.value(INT) = 1 -- trap -- skip snmpNotifyStorageType. Use DEFVAL vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value(RowStatus) = createAndGo -- rowOp 2 -- rowIdentifier (table and instance) vb5.name = 1.0 -- inherit snmpNotifyEntry vb5.value(OID) = 0.1.114.111.119.50 -- "row2" vb6.name = 0.1.5 -- snmpNotifyRowStatus vb6.value(RowStatus) = createAndWait ) C.2. CreateRow with RowState This protocol exchange illustrates the use of the CreateRow request to create two new rows in the snmpNotifyTable [RFC2573] except that we pretend here that RowState was used in the design of that table instead of RowStatus. CreateRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(SnmpTagValue) = "tag1" vb3.name = 0.1.3 -- snmpNotifyType vb3.value(INT) = 1 -- trap EOS Working Group Expires October 2001 [Page 26] Internet Draft SNMP Row Operations Extensions 19 April 2001 -- skip snmpNotifyStorageType. Use DEFVAL -- By omitting a RowState varbind, it is the -- same as setting RowState=Active. -- rowOp 2 -- rowIdentifier (table and instance) vb4.name = 1.0 -- inherit snmpNotifyEntry vb4.value(OID) = 0.1.114.111.119.50 -- "row2" -- Explicitly set RowState to an initial -- value because we don't want to go -- active just yet. Even though we hint -- for an initial value of NotInService, -- it's possible that the result might -- show NotReady (if the row as defined -- by CreateRow were not ready to go Active). vb5.name = 0.1.5 -- snmpNotifyRowState vb5.value(RowState) = NotInService ) C.3. DeleteRow This example illustrates how a DeleteRow request containing two row operations is formed to delete the two rows created in either of the two previous examples. Note that the rowIdentifier in the second rowOp does not inherit the table OID from the first rowOp. Although this is legal, it also increases the request PDU size unnecessarily. DeleteRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" -- rowOp 2 -- rowIdentifier (table and instance) vb2.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb2.value(OID) = 0.1.114.111.119.50 -- "row2" ) EOS Working Group Expires October 2001 [Page 27] Internet Draft SNMP Row Operations Extensions 19 April 2001 C.4. GetRow and GetNextRow This example illustrates how a GetRow request with three row operations is used to retrieve row information. Note that rowOp1 retrieves only the snmpNotifyTag from row1, rowOp2 retrieves only the RowStatus value from row2, and rowOp3 retrieves all values from row2. rowOp2 additionally attempts to retrieve an object that does not exist in the table row. The Response PDU is also shown afterward. GetNextRow performs very similarly to GetRow except that the Response PDU will contain the object names and values from the next row in the table (if any), or will contain exceptions as placeholders where the requested objects do not exist. GetRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value = NULL -- rowOp 2 -- rowIdentifier (table and instance) vb3.name = 1.0 -- inherit snmpNotifyEntry vb3.value(OID) = 0.1.114.111.119.50 -- "row2" vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value = NULL vb5.name = 0.1.999 -- doesn't exist, but try anyway vb5.value = NULL -- rowOp 3 -- rowIdentifier (table and instance) vb6.name = 1.0 -- inherit snmpNotifyEntry vb6.value(OID) = 0.1.114.111.119.50 -- "row2" -- omitting all operands indicates "get all" row objects. ) EOS Working Group Expires October 2001 [Page 28] Internet Draft SNMP Row Operations Extensions 19 April 2001 ResponsePdu ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(snmpTagValue) = "tag1" -- rowOp 2 -- rowIdentifier (table and instance) vb3.name = 1.0 -- inherit snmpNotifyEntry vb3.value(OID) = 0.1.114.111.119.50 -- "row2" vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value(RowStatus) = NotInService vb5.name = 0.1.999 -- doesn't exist vb5.value(int) = NoSuchObject -- rowOp 3 -- rowIdentifier (table and instance) vb6.name = 1.0 -- inherit snmpNotifyEntry vb6.value(OID) = 0.1.114.111.119.50 -- "row2" vb7.name = 0.1.2 -- snmpNotifyTag vb7.value(SnmpTagValue) = "" vb8.name = 0.1.3 -- snmpNotifyType vb8.value(INT) = 1 -- trap vb9.name = 0.1.4 -- snmpNotifyStorageType vb9.value(StorageType) = nonVolatile vb10.name = 0.1.5 -- snmpNotifyRowStatus vb10.value(RowStatus) = NotInService ) D. Known issues This section will be deleted before becoming an RFC. These are known issues that need to be resolved before going EOS Working Group Expires October 2001 [Page 29] Internet Draft SNMP Row Operations Extensions 19 April 2001 standards track: - Which SNMP message versions can these rowop PDUs be wrapped in? SNMPv3 only? - It is possible to further optimize the above PDU. For example, the instancePart of the rowIdentifiers can omit the 0.1 prefix if the instancePart contains two or subids whose first two subids are not 0.1. Furthermore, where instancePart resolves to a single subid, we can use vb.type=Unsigned32 instead, and vb.value will contain the instancePart. The cost is added complexity (special case handling). - Another possible optimization is to allow rowIdentifier varbind names to begin with the prefix 0.0 as a substitute for 1.3.6.1. This would save a few bytes per rowOp. - Change the inheritance OID from 1.0 to 0.0? - GetNextRow: Should we disallow use of wildcarding (where no operand means get all operands)? Also, requiring a complete table entry OID (instead of a partial OID) is too strict? The argument for maintaining this strictness is that this document is trying to define efficient, predictable protocol operations. Also, the OID provided cannot appear to be an operand of the previous rowOp (if any). Traditional SetRequests provide plenty of opportunity for expressiveness, if one desires such flexibility and inefficiency. This strictness, for example, may allow master agents to minimize the number of subagent protocol operations needed to fulfill a GetNextRowRequest. - Should it be a requirement that all the new proto-ops are "translatable" into traditional SNMP requests? If so, DeleteRow is not translatable, so should it be deleted? Alternatively, we can allow DeleteRow to contain one optional operand so that a RowState (or RowStatus) operand can be included. In this way, DeleteRow requests can also be translated by, for example, proxies and master agents. Also, a CreateRow request cannot be translated into a SetRequest because there is no way to convey the "create-only-if-not- exists" semantic unless a RowStatus-like object is explicitly included in the request. If this is a requirement, we may need to instead adopt the kind of approach where we nix the RowState idea and simply provide traditional protocol operations that instead make use of OID suppression or compression techniques. Cognizant SNMP entities would need to be able to distinguish such requests from traditional request formats while non- cognizant entities would predictably reject the request in some EOS Working Group Expires October 2001 [Page 30] Internet Draft SNMP Row Operations Extensions 19 April 2001 way. Cognizant entities such as proxies and master agents could then translate the requests as is appropriate (though again, many of the original motivations and goals stated earlier may not be achieved with such a solution). - Are the names for RowState and its values appropriate? Perhaps the values should be something like: Undefined, Unlocked and Locked, and the TC name should be RowLock! - Do we need a GetBulkRow request that makes use of similar OID suppression techniques as defined herein? It might be argued this would be the most effective use of OID suppression. - Should the coexistence and transition section be moved to a different document? - Should we remove the comments about the timeout issues with RowStatus from the meat of the document? E. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. EOS Working Group Expires October 2001 [Page 31] Internet Draft SNMP Row Operations Extensions 19 April 2001 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. EOS Working Group Expires October 2001 [Page 32]