Internet Draft Dave Shield Expires: February 2003 University of Liverpool August 2002 SNMP Extended Capability Negotiation draft-shield-eos-capabilities-00.txt 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. 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]. Abstract This draft discusses mechanisms for supporting future changes to the functionality and behaviour of SNMP, without needing to introduce new versions of the protocol, or completely new protocol operations. It defines a Management Information Base (MIB) for advertising support for various extensions to traditional SNMP protocol capabilities, and proposes a mechanism for negotiating the use of such extensions on a per-request basis. Dave Shield [Page 1] Internet Draft SNMP Extended Capability Negotiation August 2002 Table of Contents 1. Introduction.............................. 2 2. Capability Negotiation.................... 2 3. Selecting Capabilities.................... 3 4. Varbind-based capability negotiation...... 5 4.1 Range signalling.......................... 5 4.2 Capability signalling..................... 6 5. Implementation Concerns................... 7 6. IANA Considerations....................... 8 7. MIB Definitions........................... 9 8. Security Considerations................... 13 9. References................................ 14 10. Full Copyright Statement ................. 15 1. Introduction Practical experience with SNMP over the years has revealed a number of limitations with the system, and opportunities for improvements. Recently, a number of proposals have been put forward to address some of these concerns (e.g. GetCols [1], RowOps [2], Row Aggregation [3], OOPS [4], etc). Most of these proposals involve one or more new protocol operations, and may include a number of new features which are only available to these particular operations. However, many of these features could usefully be applied more widely, benefitting existing protocol operations as well as the new proposals. SNMP has also traditionally been a 'fixed' framework, providing a clearly defined set of operations and features, with no easy mechanism for extending these (short of declaring a competely new version). The Architecture for SNMP Frameworks [RFC2571] introduced the concept of a "Message Processing Model", but this is still a relatively coarse- grained approach to supporting extended features. Such an approach encourages compatability between systems, but lacks a certain flexibility. Other network services have faced similar challenges, and one common solution has been to introduce the idea of a list of defined "extensions" or "options", together with a mechanism for negotiating which of these should be used for any particular service transaction (e.g. SMTP Service Extensions [RFC1651], or Telnet Protocol Specificaion [RFC854], Telnet Option Specification [RFC855] and Telnet Extended Options [RFC861]). This draft proposes a similar mechanism for use with SNMP. 2. Capability Negotiation Many network services are connection-oriented, so can negotiate the appropriate set of capabilities during the initial connection handshake. However, SNMP fundamentally works on a "single shot" model, so doesn't have this sort of connection setup. It would be a retrograde step to require multiple request/response transactions in order to retrieve a single item of management information. A different approach is needed. Dave Shield [Page 2] Internet Draft SNMP Extended Capability Negotiation August 2002 There are three aspects to negotiating the use of such extended capabilities: - advertising the capabilities supported by an agent - requesting a subset of these capabilities for a particular request - acknowledging the use of these requested capabilities. Advertising the capabilities supported by an agent could be handled using a standard MIB module, such as the proposed SNMP Extended Protocol MIB [5]. This draft defines a similar 'Extended Capability Table', modelled on the Extended Protocol MIB. The main difference between the two is that the Extended Protocol MIB is specifically concerned with protocol operations (i.e. PDU request types). This draft applies a wider concept of capabilities, to include such features as OID compression ([3], [6]), filling of holes in tables ([1], [3], [4]), extended error reporting ([4]), etc. The semantics and precise behaviour of individual capabilities is outside the scope of the extCapTable (and this draft as a whole). Given a suitable list of named capabilities, an agent should be able to use the eCapTable to advertise support for any or all of these. This table, or some equivalent means of configuration, SHOULD be used by any command generator to validate that the command responder supports a particular enhanced capability, before attempting to use that capability in a request. On receipt of a request using a non- supported capability, a command responder MAY return an indication of the error, or drop the request with no further processing (depending on the capability concerned). The specification for a particular extended capability MUST(?) define the appropriate behaviour in such circumstances. The main thrust of the rest of this draft is concerned with mechanisms for specifying which of these advertised capabilities should be used for a particular management request, and acknowledging the use (or otherwise) of these in the response. 3. Selecting Capabilities There are (at least) five possible mechanisms for specifying the use of extended capabilities, and/or selecting which capabilities are required for a particular management request. * Protocol Version/Message Processing Model A completely new version of SNMP could be defined, with a distinct version number (or Message Processing Model number, using the SNMPv3 framework [RFC2571]). This is the approach that has been used in the past (v1->v2(various)->v3) and may well be the most appropriate mechanism to indicate that (some form of) extended capabilities should be used. Dave Shield [Page 3] Internet Draft SNMP Extended Capability Negotiation August 2002 However, using the version (or MPM field) to indicate which extended capabilities should be used is not a particularly flexible or scalable approach. Each additional capability (or group of capabilities) would require defining a new version, and selecting subsets of the full range of capabilities would require even more version values. Such an approach would strongly discourage the introduction of new capabilities. * Header Flags The structure of an SNMPv3 message ([RFC2572]) includes a 'flags' field in the main msgGlobalData header structure, with only 3 bits currently defined. This could provide an alternative mechanism for indicating that (some form of) extended capabilities should be used, by using one of the currently unused flag bits. However, this is even less well suited than the version field to specifying which extended capabilities were required for a particular request, due to the limited number of flag bits available. Neither the SNMPv1 nor SNMPv2 message formats include any equivalent flag field. Given the indications to advocate the use of SNMPv3 wherever possible, this may not be of concern. The other three approaches are much more appropriate to the task of specifying the use of individual extended capabilities, and it is likely that any or all of these might be used in practise - depending on the precise requirements of a particularl capability. * Protocol operations Most of the recent extension proposals defined new protocol operations to support their new capabilities. In many cases this may well be the most appropriate mechanism. Certainly, this would be the obvious approach where a completely new operation is being introduced (e.g. support for 'transactions'). In such a situation, the new capability (/operation) is specified quite naturally at the start of the PDU, and the acknowledgment would take the form of the appropriate response PDU (indicating the success or failure of the operation itself). An unsupported protocol operation would simply be dropped (and the snmpInASNParseErrs counter incremented) with no response returned, in line with [RFC2572]. An example of such a capability might be the GetObjects request ([4]). * Type Tags Some extended capabilities involve the introduction of new data types (or variations of existing types). In such a situation, the ASN.1 tag field could be used to specify the use of the new capability (in either request or response PDU). As with new protocol operations, the normal request/response exchange would indicate acknowledgement of the requested capability. Use of an unsupported capability in a request PDU would result in this being dropped (and the snmpInASNParseErrs counter being incremented) with no response returned, in line with [RFC2572]. Dave Shield [Page 4] Internet Draft SNMP Extended Capability Negotiation August 2002 Recent examples of such a capability might include the two OID compression proposals([3],[6]). * Varbind signalling However, some extended capabilities may not involve distinctive data types, and may not necessarily be linked to specific new protocol operations. Examples of such capabilities include the filling-in of holes in tables ([1],[3],[4]), or more informative error reporting ([4]). Ideally, there should be a general mechanism for specifying such capabilities, flexible enough to be usable with existing protocol operations, and sufficiently extensible to accomodate new capabilities in the future. The obvious vehicle for such a general mechanism is the varbind list, present in both request and response PDUs (in all existing versions of SNMP), and capable of accomodating a significant number of capability requests (possibly at the expense of management information payload). Such a mechanism is proposed in this draft. 4. Varbind-based capability negotiation 4.1 Range signalling The core element of this proposal is that the first varbind (or varbinds) of an extended capability request PDU should indicate which capabilities were being selected. The first varbind (or varbinds) of the response PDU could then be used to acknowledge the acceptance of these requested capabilities, or signal refusal. It would not be uncommon to select more than one such capability, and this could be handled either by using multiple varbinds (one per capability), or by using enumerated BITS values for the individual capabilities (following the model proposed in the SNMP Extended Protocol MIB [5]). It would be appropriate for the same approach (and set of values) to be used for both capability negotiation, and advertising of capabilities. The first approach is less space efficient, but would essentially delegate the process of defining new capabilities (particularly if OID values were used). This might also allow such capabilities to be described in more detail, including reference to the full specifications. The second approach would be more compact, though would presumably require IANA to administer the list of defined capabilities. This second approach has provisionally been adopted for the remainder of this draft. Dave Shield [Page 5] Internet Draft SNMP Extended Capability Negotiation August 2002 For maximum flexibility, it should ideally be possible to request that a particular capability should be applied to a subset of the ("normal") varbinds in a given request. To support this, the Extended Capabilities MIB defines three MIB objects for use when requesting particular extended capabilities: - eReqCapRangeStart Request the specified capabilities for a range of varbinds, starting from the one indicated. - eReqCapRangeEnd Request the specified capabilities for a range of varbinds, ending with the one indicated. - eReqCapVarBind Request the specified capabilities for a single varbind The two range objects can be used in combination (to indicate an "internal" range of varbinds), or individually (with the range extending to the end of the varbind list, or starting from the first varbind, respectively). These objects are defined within a MIB table structure, and the first index subidentifier is used to specify which varbind in the varbind list is being indicated. In all cases, an index value of one refers to the first "normal" varbind - i.e. excluding the extended capability varbinds. Note that this means that an extended capability request using the object instance 'eReqCapRangeStart.1' (with no other relevant extended capability signalling varbinds) would indicate that the corresponding capabilit(ies) should apply to the whole of the varbind list. For efficiency, the table includes a fourth MIB object 'eReqCapAllBar', to indicate that the requested capabilit(ies) should apply to all varbinds _except_ the one specified. Multiple occurances of this object, specifying different varbinds (but the same set of capabilities) should be interpreted together, resulting in the requested capabilit(ies) being applied to all varbinds except the list of those specified (rather than each setting overriding the one before). 4.2 Capability signalling That covers the task of indicating which varbind(s) should have extended capabilities applied to them. There still remains the question of specifying which capabilities should be applied. There are two possible approaches to this: - value-based i.e. eReqCapRangeStart.1 = someCap - index-based i.e. eReqCapRangeStart.1.someCap (= NULL) Value-based signalling feels a more natural approach, but means that extended capability signalling varbinds would have the form "name = value", even when being used within an information retrieval request (Get et al). This would contrast with the "normal" information varbinds, which would invariably have NULL values in such requests. Such a discrepancy might cause some implementation problems. Dave Shield [Page 6] Internet Draft SNMP Extended Capability Negotiation August 2002 Index-based signalling would avoid such concerns, and would also allow the values of the corresponding capability signalling varbinds in the response to indicate the acceptability or otherwise of the requested capabilities. (e.g. an enumeration such as 'accepted(1)', 'rejected(2)', 'unused(3)', etc). Index-based signalling has provisionally been adopted for this draft. The example above uses indexes of the form "varbind, capability". The order of these could easily be reversed, and signalled using "capability, varbind". Such an ordering might well prove more appropriate, particularly if capability request varbinds relating to the same capabilit(ies) were grouped together in the capability request list. However, placing the BITS index second, means that the length of this index can be IMPLIED, thus reducing the length of the overall OID by one sub-identifier. This is a subject for future investigation, and the "varbind, capability" ordering has been used in this draft. It is suggested that when defining internal ranges, the matching eReqCapRange{Start,End} pairs SHOULD (or even MUST?) appear together in the capability request list, and with the RangeStart varbind first. i.e. .... RangeStart.2.cap1 RangeEnd.4.cap1 .... not .... RangeEnd.4.cap1 RangeStart.2.cap1 .... or .... RangeStart.2.cap1 RangeStart.1.cap2 RangeEnd.4.cap1 .... 5. Implementation Concerns There are two main aspects of this proposal that may have implications for a typical implementation strategy (not including the implementation of any particular capability itself, or the use of value-based signalling). Firstly, an unsuccessful request should ignore the extended capability varbinds when calculating the appropriate error index value. So a problem with the first "normal" varbind would still result in an error index of 1, regardless of whether extended capabilities were being used or not. This, together with the capability varbind indexing also starting from the first "normal" varbind, implies that an implementation might typically remove the extended capability varbinds from the PDU varbind list before processing the request. Secondly, the list of extended capability varbinds in the response need not match the original list, either in order or number. If a requested capability was not actually required in processing the request (e.g. requesting holes to be filled in a table that didn't contain any), then it is implementation dependent as to whether this capability is included in the response varbind list. Similarly, a partially-supported capability might result in a single capability varbind in the original request, being split into two or more such capability varbinds in the response. Dave Shield [Page 7] Internet Draft SNMP Extended Capability Negotiation August 2002 This draft does not seek to mandate any particular implementation strategy regarding how to handle or report unused or unsupported capabilities. 6. IANA Considerations If the list of extended capabilities is defined as a series of enumerated BITS, this list would need to be administered by IANA. The following MIB module is provided as an initial provisional definition, for purposes of illustration and discussion. A standardised equivalent of this, and supsequent revised and updated versions of it would need to be published by (or on behalf of) IANA, as new extended capabilities were defined and agreed. EXTENDED-CAPABILITIES-TC DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, enterprises FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; extendedCapabilitiesList MODULE-IDENTITY LAST-UPDATED "200208170000Z" ORGANIZATION "University of Liverpool" CONTACT-INFO "Postal: Dave Shield Computer Science University of Liverpool Peach Street Liverpool L69 7ZF United Kingdom E-Mail: D.T.Shield@csc.liv.ac.uk" DESCRIPTION "This MIB module defines a provisional textual convention for identifying extended SNMP capabilities." ::= { enterprises liv(1579) compsci(42) dts(1) eCap(3) 1 } ExtendedCapabilities ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Provisional list of extended SNMP capabilities." SYNTAX BITS { oidDeltaCompression (0), oidPrefixCompression(1), fillHolesInTables (2), dontColumnWrap (3), errorString (4) } END Dave Shield [Page 8] Internet Draft SNMP Extended Capability Negotiation August 2002 7. MIB Definitions The following module defines one MIB table for advertising which capabilities an agent supports, and a second for requesting the use of such capabilities. Note that this second table does not "exist" in the agent in the conventional sense, and would not appear in a walk of the agent's full MIB tree. EXTENDED-CAPABILITIES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI ExtendedCapabilities FROM EXTENDED-CAPABILITIES-TC MODULE-COMPLIANCE, TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP FROM SNMPv2-CONF; extendedCapabilitiesMib MODULE-IDENTITY LAST-UPDATED "200208170000Z" ORGANIZATION "University of Liverpool" CONTACT-INFO "Postal: Dave Shield Computer Science University of Liverpool Peach Street Liverpool L69 7ZF United Kingdom E-Mail: D.T.Shield@csc.liv.ac.uk" DESCRIPTION "This MIB module defines a framework for advertising and negotiating the use of extended SNMP capabilities." ::= { enterprises liv(1579) compsci(42) dts(1) eCap(3) 2 } eCapObjects OBJECT IDENTIFIER ::= { extendedCapabilitiesMib 1 } eCapConformance OBJECT IDENTIFIER ::= { extendedCapabilitiesMib 2 } -- -- MIB objects to advertise support for extended capabilities -- eCapGeneral OBJECT-TYPE SYNTAX ExtendedCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "The basic set of extended capabilities supported by an agent as a whole. The eCapTable can be used to override this setting for individual MIB subtrees." ::= { eCapObjects 1 } Dave Shield [Page 9] Internet Draft SNMP Extended Capability Negotiation August 2002 eCapTable OBJECT-TYPE SYNTAX SEQUENCE OF ECapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of alternative sets of extended capabilities, supported by particular MIB subtrees of the agent." ::= { eCapObjects 2 } eCapEntry OBJECT-TYPE SYNTAX ECapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { eCapIndex } ::= { eCapTable 1 } ECapEntry ::= SEQUENCE { eCapIndex Unsigned32, eCapSubtree OBJECT IDENTIFIER, eCapSettings ExtendedCapabilities } eCapIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index into the eCapTable." ::= { eCapEntry 1 } eCapSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The OID that identifies the root of a MIB subtree, supporting different extended capabilities to the agent as a whole." ::= { eCapEntry 2 } eCapSettings OBJECT-TYPE SYNTAX ExtendedCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "The set of extended capabilities supported by the agent for the MIB subtree rooted at eCapSubtree. This value replaces the eCapGeneral for objects within this subtree." ::= { eCapEntry 3 } Dave Shield [Page 10] Internet Draft SNMP Extended Capability Negotiation August 2002 -- -- MIB objects to negotiate use of extended capabilities -- eReqCapTable OBJECT-TYPE SYNTAX SEQUENCE OF EReqCapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 'pseudo-table', used to indicate which varbinds in a request should involve particular extended capabilities. This is not a conventional MIB table, and will not appear in the output of walking the agent." ::= { eCapObjects 3 } eReqCapEntry OBJECT-TYPE SYNTAX EReqCapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { eReqCapVBIndex, IMPLIED eReqCapability } ::= { eReqCapTable 1 } EReqCapEntry ::= SEQUENCE { eReqCapVBIndex Unsigned32, eReqCapabilities ExtendedCapabilities eReqCapRangeStart INTEGER eReqCapRangeEnd INTEGER eReqCapVarBind INTEGER eReqCapAllBar INTEGER } eReqCapIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of a particular VarBind in the request list, indicating the range of varbinds to which the specified extended capabilit(ies) should be applied." ::= { eReqCapEntry 1 } eReqCapabilities OBJECT-TYPE SYNTAX ExtendedCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "The extended capabilit(ies) that should be applied to the indicated range of varbinds in the request list." ::= { eReqCapEntry 2 } Dave Shield [Page 11] Internet Draft SNMP Extended Capability Negotiation August 2002 eReqCapRangeStart OBJECT-TYPE SYNTAX INTEGER { other(1), supported(2), unsupported(3), notUsed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates that the specified extended capabilit(ies) should be applied to all varbinds in the request list from the indicated varbind, up to and including the varbind indicated by the corresponding eReqCapRangeEnd (or the end of the varbind list). The value returned in the response may indicate whether this capability was supported and/or used in processing the request." ::= { eReqCapEntry 3 } eReqCapRangeEnd OBJECT-TYPE SYNTAX INTEGER { other(1), supported(2), unsupported(3), notUsed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates that the specified extended capabilit(ies) should be applied to all varbinds in the request list up to and including the indicated varbind, starting from the varbind indicated by the corresponding eReqCapRangeStart (or the beginning of the varbind list). The value returned in the response may indicate whether this capability was supported and/or used in processing the request." ::= { eReqCapEntry 4 } eReqCapVarBind OBJECT-TYPE SYNTAX INTEGER { other(1), supported(2), unsupported(3), notUsed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates that the specified extended capabilit(ies) should be applied to the indicated varbind. The value returned in the response may indicate whether the capability was supported and/or used in processing the request." ::= { eReqCapEntry 5 } Dave Shield [Page 12] Internet Draft SNMP Extended Capability Negotiation August 2002 eReqCapAllBar OBJECT-TYPE SYNTAX INTEGER { other(1), supported(2), unsupported(3), notUsed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates that the specified extended capabilit(ies) should be applied to all varbinds in the request list except the indicated varbind(s). The value returned in the response may indicate whether the capability was supported and/or used in processing the request." ::= { eReqCapEntry 6 } -- -- MIB objects to advertise support for extended capabilities -- eCapGroups OBJECT IDENTIFIER ::= { eCapConformance 1 } eCapGeneralGroup OBJECT-GROUP OBJECTS { eCapGeneral } STATUS current DESCRIPTION "Advertising of core extended capabilities." ::= { eCapGroups 1} eCapSubtreeGroup OBJECT-GROUP OBJECTS { eCapSubtree, eCapSettings } STATUS current DESCRIPTION "Advertising of subtree-specific extended capabilities." ::= { eCapGroups 2} eCapRequetGroup OBJECT-GROUP OBJECTS { eReqCapRangeStart, eReqCapRangeEnd, eReqCapVarBind, eReqCapAllBar } STATUS current DESCRIPTION "Negotiation of extended capabilities to use." ::= { eCapGroups 3} END 8. Security Considerations The main security considerations with respect to the use of extended capabilities, are as regards to the behaviour of an agent when it receives a request for a capability that it does not support. Dave Shield [Page 13] Internet Draft SNMP Extended Capability Negotiation August 2002 In the case of new protocol operations, or new data types, then the agent will typically discard the request without responding, and increment the appropriate error counter. It is the responsibility of the command generator application to determine whether the agent can handle the requested capabilit(ies) before attempting to use them. It is outside the scope of this draft to define APIs or user interface algorithms for doing this. Two obvious approaches would be an automatic query of the Extended Capability Table, or the use of manual configuration settings (e.g. command line options). Use of 'transparent' extended capabilities is indicated using the extended capability varbinds described earlier. Attempting to use an unrecognised capability should result in a response PDU that includes an indication that this particular capability is not supported (or not supported for that particular portion of the overall MIB tree). It is implementation dependent as to whether the agent attempts to process the request anyway, ignoring the unsupported capability. Attempting to use extended capabilities with an agent that does not implement the capability varbind signalling mechanism at all will result in a noSuchObject exception for each of the extended capability varbinds. (Though such an agent would presumably drop the request with unknownVersion or unknownProcessingModel anyway) 9. References [RFC854] Postel, J., and Reynolds, J., "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC855] Postel, J., and Reynolds, J., "Telnet Option Specifications", RFC 855, May 1983. [RFC861] Postel, J., and Reynolds, J., "Telnet Extended Options - List Option", STD 32, RFC 861, May 1983. [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extensions", RFC 1651, July 1994. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3" BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2571] Harrington, D., Presuhn, R., and Wijnen, B., "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington, D., Presuhn, R., and Wijnen, B., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Dave Shield [Page 14] Internet Draft SNMP Extended Capability Negotiation August 2002 [1] Chandragiri, S., "Efficient Transfer of Bulk SNMP Data", Internet Draft draft-ietf-eos-snmpbulk-00.txt, expired October 2001. [2] Heintz, L., "SNMP Row Operations Extensions", Internet Draft draft-ietf-eos-snmp-rowops-01.txt, expired October 2001. [3] McLeod, S., Partain, D., White, M., "SNMP Object Identifier Compression", Internet Draft draft-ietf-eos-oidcompression-00.txt, expired October 2001. [4] Hardaker, W., "Object Oriented PDUs for SNMP", Internet Draft draft-hardaker-eos-oops-00.txt, expires December 2002. [5] Chisholm, C., "SNMP Extended Protocol MIB", Internet Draft draft-ietf-eos-snmpxproto-mib-02.txt, expires August 2002. [6] Schoenwaelder, J., "SNMP Payload Compression", Internet Draft draft-irtf-nmrg-snmp-compression-01.txt, expired October 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). 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. This Internet Draft expires: February 2003 Dave Shield [Page 15]