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]