draft-ietf-eos-snmp-rowops-00.txt   draft-ietf-eos-snmp-rowops-01.txt 
INTERNET-DRAFT L. Heintz INTERNET-DRAFT L. Heintz
Cisco Systems, Inc. Cisco Systems, Inc.
SNMP Row Operations Extensions SNMP Row Operations Extensions
<draft-ietf-eos-snmp-rowops-00.txt> <draft-ietf-eos-snmp-rowops-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes a set of extensions (protocol operations and This document describes a set of extensions (protocol operations and
textual conventions) to the existing SNMP framework architecture as textual conventions) to the existing SNMP framework architecture
defined in RFC2571. These extensions provide mechanisms for [RFC2571]. These extensions provide mechanisms for efficient
efficient creation, modification, deletion and retrieval of table creation, modification, deletion and retrieval of table rows and
rows. other information.
Table of Contents Table of Contents
1. The SNMP Network Management Framework ....................... 3 1. The SNMP Network Management Framework ....................... 3
2. Overview .................................................... 4 2. Overview .................................................... 4
2.1. Terms ..................................................... 4 2.1. Terms ..................................................... 4
2.2. Motivations for the Extensions ............................ 4 2.2. Motivations for the Extensions ............................ 4
2.3. Design Goals .............................................. 5 2.3. Design Goals .............................................. 5
3. The Extensions .............................................. 6 3. The Extensions .............................................. 6
3.1. RowState .................................................. 6 3.1. RowState .................................................. 7
3.2. Row Operations ............................................ 8 3.2. Protocol Operations ....................................... 7
3.2.1. The rowIdentifier ....................................... 9 3.2.1. Singletons .............................................. 8
3.2.2. The operands ............................................ 12 3.2.2. The RowOp ............................................... 9
3.2.3. Distinguishing rowIdentifiers from operands ............. 13 3.2.3. The RowIdentifier ....................................... 10
3.2.4. RowState and RowStatus Considerations ................... 13 3.2.4. RowIdentifiers in GetBulkRow Requests ................... 11
3.2.5. Granularity of Success/Fail ............................. 14 3.2.5. RowIdentifier Inheritance ............................... 12
3.2.6. Response PDUs ........................................... 14 3.2.6. The Operands ............................................ 13
4. Elements of Procedure ....................................... 14 3.2.7. Extended Error Codes .................................... 14
4.1. CreateRow Request Processing .............................. 14 3.2.8. RowOps and Group Scalar Objects. ....................... 16
4.2. DeleteRow Request Processing .............................. 14 3.2.9. Three-Phase Sets ........................................ 17
4.3. EditRow Request Processing ................................ 15 3.2.10. Response PDUs .......................................... 17
4.4. GetRow Request Processing ................................. 15 3.2.11. Determining Varbind Roles .............................. 18
4.5. GetNextRow Request Processing ............................. 15 4. Elements of Procedure ....................................... 19
4.6. Response-PDU Processing ................................... 15 4.1. CreateRow Request Processing .............................. 19
5. Coexistence and Transition .................................. 15 4.2. DeleteRow Request Processing .............................. 19
6. Protocol Operations Definitions ............................. 17 4.3. EditRow Request Processing ................................ 19
7. Managed Object Definitions .................................. 18 4.4. GetRow Request Processing ................................. 19
8. IANA Considerations ......................................... 19 4.5. GetNextRow Request Processing ............................. 19
9. Intellectual Property ....................................... 19 4.6. GetBulkRow Request Processing ............................. 20
10. Acknowledgements ........................................... 19 4.7. Response-PDU Processing ................................... 20
11. Security Considerations .................................... 20 5. Coexistence and Transition .................................. 20
12. References ................................................. 20 6. Protocol Operations Definitions ............................. 21
13. Editor's Addresses ......................................... 23 7. Managed Object Definitions .................................. 22
A. Impact to SNMP and other Protocols .......................... 24 8. IANA Considerations ......................................... 26
A.1. SNMPv3 .................................................... 24 9. Intellectual Property ....................................... 26
A.2. AgentX .................................................... 24 10. Acknowledgements ........................................... 27
B. Alternative Approaches ...................................... 24 11. Security Considerations .................................... 27
C. Examples of Row Operations .................................. 25 12. References ................................................. 27
C.1. CreateRow with RowStatus .................................. 25 13. Editor's Addresses ......................................... 30
C.2. CreateRow with RowState ................................... 26 A. Impact to SNMP and other Protocols .......................... 31
C.3. DeleteRow ................................................. 27 A.1. SNMPv3 .................................................... 31
C.4. GetRow and GetNextRow ..................................... 28 A.2. AgentX .................................................... 31
D. Known issues ................................................ 29 B. Examples of Row Operations .................................. 31
E. Full Copyright Statement .................................... 31 B.1. CreateRow ................................................. 31
B.2. DeleteRow ................................................. 35
B.3. GetRow .................................................... 36
B.4. GetNextRow ................................................ 39
B.5. GetBulkRow ................................................ 41
B.6. EditRow ................................................... 48
C. Known issues ................................................ 50
D. Full Copyright Statement .................................... 51
1. The SNMP Network Management Framework 1. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
- An overall architecture, described in RFC 2571 [RFC2571]. - An overall architecture, described in RFC 2571 [RFC2571].
- Mechanisms for describing and naming objects and events for the - Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
skipping to change at page 4, line 9 skipping to change at page 4, line 10
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the readable information is not considered to change the semantics of the
MIB. MIB.
2. Overview 2. Overview
This document describes a set of SNMP extensions to current protocol This document describes a set of SNMP extensions to current protocol
operations [RFC1905] to provide for efficient row operations (i.e. operations [RFC1905] to provide for efficient management operations
creating, modifying, deleting and retrieving table rows). In (i.e. creating, modifying, deleting and retrieving table rows and
addition, a new textual convention, RowState, is defined to replace other MIB data). In addition, a new textual convention, RowState, is
RowStatus in future MIBs. RowState maintains the ability to report defined to replace RowStatus in future MIBs. RowState maintains the
the state of a row, but does not attempt to provide a mechanism to ability to report the state of a row, but does not provide a
create or delete a row. 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 2.1. Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Terminology such as "leftmost" or "left" indicates a PDU component Terminology such as "leftmost" or "left" indicates a PDU component
that is transmitted on the wire prior to other components. Thus, that is transmitted on the wire prior to other components. Thus,
terms such as "rightmost" imply components that have similar, but terms such as "rightmost" imply components that have similar, but
opposite semantics. opposite semantics.
Protocol operation refers to a high-level request, such as a Protocol operation refers to a high-level request, such as a
SetRequest or GetRequest (or one of the five new requests defined SetRequest or GetRequest (or one of the six new requests defined
within this document). Row operation refers to one logical operation within this document). Row operation refers to one logical operation
that affects one specific table row. A protocol operation may contain that affects one specific table row. A protocol operation may contain
one or more row operations. The term rowOp refers to the component one or more row operations. The term RowOp refers to the aggregate
parts of a protocol operation that comprise a single row operation. parts of a protocol operation that comprise a single row operation.
2.2. Motivations for the Extensions 2.2. Motivations for the Extensions
Experience has shown that current SNMP protocol operations and Experience has shown that current SNMP protocol operations and
management structures are not ideally suited to effect configuration management structures are not ideally suited to effect configuration
changes within managed devices and when retrieving information. The changes within managed devices and when retrieving large amounts of
extensions described in this document are specifically designed to information. The extensions described in this document are
minimize, or provide opportunities to minimize the following problems specifically designed to minimize, or provide opportunities to
which inhibit th effectiveness of SNMP: minimize, the following problems which inhibit the effectiveness of
SNMP:
- Requests that contains multiple varbinds that affect one row of - Requests that contain multiple varbinds that affect one row of
a table may contain significant redundancy of information. This a table may contain significant redundancy of information. This
is because each varbind contains an object name (i.e. Object is because each varbind contains an object name (i.e. Object
Identifier or OID), and these OIDs may differ only in the Identifier or OID), and these OIDs may differ only in the
single subid that designates a specific column. In cases where single subid that designates a specific column. In cases where
strings are used as instance identifiers, for example, UDP strings are used as instance identifiers, for example, UDP
maximum-message-size constraints may force multiple SetRequests maximum-message-size constraints may force multiple SetRequests
to be used to construct a new, or modify an existing row in a to be used to construct a new, or modify an existing row in a
table. Requests containing redundant data are also more costly table. Requests containing redundant data are also more costly
to encrypt and decrypt. to encrypt and decrypt.
- SetRequests may contain multiple varbinds that actually refer - SetRequests may contain multiple varbinds that actually refer
to the same MIB object. For example, varbind one may be to the same MIB object. For example, varbind one may be
attempting to set the object, foo, to the value 1, while attempting to set the object, foo, to the value 1, while
varbind two may be attempting to set the same object, foo, to varbind two may be attempting to set the same object, foo, to
the value 2. In such cases, the SNMP protocol indicates that the value 2. In such cases, the SNMP protocol indicates that
implementations may make independant decisions as to which implementations may make independent decisions as to which
varbind will effectively be used as the final result. value will be used.
- SetRequests do not impose any ordering requirements on the - SetRequests do not impose any ordering requirements on the
varbinds within a single request, even if they affect different varbinds within a single request, even if they affect different
objects in the same row of a table. This can cause added objects in the same row of a table. This can cause added
complexity in SetRequest processing. complexity in set request processing.
- The RowStatus textual convention [RFC1903] provides a mechanism - The RowStatus textual convention [RFC1903] provides a mechanism
for row management. RowStatus most often requires the for row management. RowStatus most often requires the
implementation of a rather complicated state machine, many of implementation of a rather complicated state machine, many of
whose transitions are optional and whose target states are at whose transitions are optional and whose target states are at
times non-deterministic. RowStatus also confuses the notion of times non-deterministic. RowStatus also confuses the notion of
row status with the notion of row fate, which also tends to row status with the notion of row fate, which also tends to
complicate both the MIB design and the implementation. complicate both the MIB design and the implementation.
2.3. Design Goals 2.3. Design Goals
Several goals were identified when considering the kinds of Several goals were identified when considering the kind and nature of
extensions that were needed: extensions that were needed:
- allow separate row operations (hereafter referred to as rowOps) - allow separate row operations (hereafter referred to as RowOps)
to be performed in a single protocol operation. to be performed in a single protocol operation.
- allow operations on individual scalar and/or tabular objects in
conjunction with row operations.
- minimize redundant information in a protocol operation. The - minimize redundant information in a protocol operation. The
extensions should at least make use of OID suppression extensions should at least make use of OID suppression
techniques to meet this goal. Note that OID suppression techniques to meet this goal. Note that OID suppression
(largely an issue of how data is stored within a PDU) is not (largely an issue of how data is stored within a PDU) is not
equivalent to OID compression (data compression algorithms). equivalent to OID compression (data compression algorithms).
Issues of OID compression are considered out of scope for this Issues of OID compression are considered out of scope for this
document. document.
- eliminate the need for special MIB objects (e.g. RowStatus) - eliminate the need for special MIB objects (e.g. RowStatus)
that control the creation and deletion of rows. that control the creation and deletion of rows.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
- minimize the impact on existing network management and subagent - minimize the impact on existing network management and subagent
protocols such as SNMPv3, AgentX, and related applications. protocols such as SNMPv3, AgentX, and related applications.
- interoperate with legacy MIBs as well as future MIBs. - interoperate with legacy MIBs as well as future MIBs.
- operate in existing SNMP networks and not disrupt legacy SNMP- - operate in existing SNMP networks and not disrupt legacy SNMP-
capable devices. capable devices.
3. The Extensions 3. The Extensions
Five new conceptual protocol operations are described in this Six new protocol operations are described in this document:
document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU (aka
(aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU (aka
(aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of GetRow), GetNextRowRequest-PDU (aka GetNextRow), and
these request types are based on the same PDU structure as originally GetBulkRowRequest-PDU (aka GetBulkRow). These requests are based on
defined in [RFC1905]. the BulkPDU structure as originally defined in [RFC1905].
Despite the obvious use of the word "row" throughout this document,
these new protocol operations can also be used to create, delete,
modify and retrieve non-row data (i.e. scalars); specific details are
provided later in the document.
For purposes of discussion, the three requests, CreateRow, DeleteRow For purposes of discussion, the three requests, CreateRow, DeleteRow
and EditRow are more generically referred to as SetRow class and EditRow are more generically referred to as SetRow class
requests, while GetRow and GetNextRow are referred to as RetrieveRow requests, and GetRow, GetNextRow and GetBulkRow are referred to as
class requests. RetrieveRow class requests.
In addition, a RowState textual convention is defined and is intended The CreateRow request can only succeed if it is used to create an
to replace RowStatus in all future MIB designs. It is not the aggregate (e.g. row) that doesn't already exist. EditRow has no such
intention to deprecate RowStatus. Although RowState is not a protocol constraints and can be used much in the same way traditional
operation, it does serve to reestablish a distinction between SNMP SetRequests are used. One noteworthy feature of the GetBulkRow
data types and SNMP operations -- a line which is blurred in the request is that it can perform head and/or tail functions on a table.
current RowStatus definition. In addition, all SetRow requests make use of a three-phase processing
model in which a new third phase (retrieve) is added to the
traditional test and commit phases discussed in [RFC1905].
Another extension defined in this document is the RowState textual
convention, which is intended to replace RowStatus in all future MIB
designs. It is not the intention to deprecate RowStatus. RowState
serves to reestablish a distinction between SNMP data types and SNMP
operations -- a line which is blurred in the current RowStatus
definition.
3.1. RowState 3.1. RowState
As mentioned earlier, this document defines a proposed textual The RowState textual convention defined in this document is intended
convention, RowState, whose purpose is to replace RowStatus in future to replace RowStatus in new MIBs and provides several important
MIBs. This convention provides several important improvements over improvements over RowStatus:
RowStatus:
- RowState relaxes some of the row timeout rules that RowStatus - RowState relaxes some of the row timeout rules that RowStatus
suffers from. Such rules inhibit the usefulness of RowStatus as suffers from. Such rules inhibit the usefulness of RowStatus as
a means of temporarily placing system resources (i.e. table a means of temporarily placing system resources (i.e. table
rows) out of service. For example, if an SNMP manager changes rows) out of service. For example, if an SNMP manager changes
a given instance of snmpNotifyRowStatus from Active to a given instance of snmpNotifyRowStatus from Active to
NotInService as a means of temporarily disabling one or more NotInService as a means of temporarily disabling one or more
notifications, an unintended side-effect of this action on some notifications, an unintended side-effect of this action on some
implementations may be that the row is automatically deleted implementations may be that the row is automatically deleted
after some short amount of time has elapsed (typically, a few after some short amount of time has elapsed (typically, a few
minutes). minutes).
- More importantly, RowState separates the notion of reporting - More importantly, RowState separates the notion of reporting
row status and the notion of managing row fate (i.e. creation & row status and the notion of managing row fate (i.e. creation &
deletion). Specifically, the purpose of RowState is to enable deletion). Specifically, the purpose of RowState is to enable
reporting of row state, while matters of creating and deleting reporting of row state, while matters of creating and deleting
rows are better served by protocol operations. rows are better served by protocol operations.
RowState provides three states: NotReady, NotInService and Active, RowState provides three states: NotReady, NotInService and Active,
which are very similar to the corresponding RowStatus definitions. which are very similar to the corresponding RowStatus definitions.
Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo Unlike RowStatus, RowState does not provide CreateAndWait,
or Destroy. CreateAndGo or Destroy.
Any entity providing a RowState column in a table must instantiate an Any entity providing a RowState column in a table must instantiate an
instance of RowState when one or more other column objects in the instance of RowState when one or more other column objects in the
same row have been created or instantiated (by whatever means). Using same row have been created or instantiated (by whatever means). Using
the new protocol operations defined in this document, it is the new protocol operations defined in this document, it is usually
unnecessary to directly set or reference a RowState instance in order unnecessary to directly set or reference a RowState instance in order
to create and activate a new row. The initial state of RowState is to create and activate a new row.
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 3.2. Protocol Operations
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 The new protocol operations are designed to "fit" in the existing
RowState objects to the NotReady state as a crude means of allowing BulkPDU structure [RFC1905]. Formal definitions of the new protocol
traditional SetRequests to delete the row. In this case, deletion operations are provided in section 6.
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
row object (such as RowState).
The CreateRow request introduces the ability to set either RowStatus This document specifies an evolutionary approach in the way the new
or RowState objects without the need to explicitly include a varbind protocol operations are encoded or contained within the BulkPDU. The
in the request. A CreateRow request by convention contains an new requests capitalize on OID suppression techniques to minimize
implicit operand (i.e. varbind) to set a corresponding RowState information redundancy and therefore minimize PDU size. Note that the
object (if any) to the Active value. This implicit varbind can be traditional SNMP protocol operations [RFC1905] are not being changed,
overridden by the inclusion of an actual RowState varbind. For either in their semantics, the way data is encoded within them, or
example, the following two CreateRow requests are logically the way they are processed.
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); The following general discussion centers on how the varbinds of the
CreateRow (fooEntry.1, fooInt=2, fooRowState=Active); new protocol operations and their responses are constructed and
generally used. The elements of procedure formally describes how the
new requests are processed and how the responses are constructed. The
APPENDIX provides high-level examples of protocol exchanges using the
extensions.
These two requests are NOT logically identical: Each varbind in a request serves one of three purposes: as a
Singleton, as a RowIdentifier or as an Operand.
CreateRow (fooEntry.1, fooInt=2); 3.2.1. Singletons
CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService);
Implementations are not required, however, to support such implicit A varbind that serves as a Singleton functions more or less like
operands within CreateRow requests for RowStatus objects. This is varbinds in a traditional SNMP request (e.g. SetRequest, GetRequest).
intended to maximize the set of possible transition solutions for They are encoded in the same manner, and except for prefix-level
vendors of SNMP technology. inheritance (described below), they do not take advantage of OID
suppression techniques. Singletons may exist in any SetRow or
RetrieveRow class request or response, but if they do exist in any
request, they MUST be the first N varbinds in the request, where N is
provided in the non-repeaters field of the request. N may be zero to
indicate that Singletons have not been included in the request. If N
Singletons are included in a request, then the same N Singletons will
also exist in the response, although in a successful response to a
GetBulkRow request, additional Singletons may also be present.
The RowState textual convention provides full details of its use and The set of Singletons contained in a request SHOULD be ordered so
operation and is provided in section 6. that the name of Singleton i is lexicographically smaller than
Singleton i+1, though SNMP applications MUST be prepared to accept
unordered Singletons.
3.2. Row Operations Singletons may be included within a CreateRow or a DeleteRow request.
Such Singletons indicate a specific object instance within an
aggregate (e.g. a row or a group scalar) upon which a creation or
deletion operation is performed. By default, the operation takes
affect on all object instances within the same aggregate; however,
aggregate semantics may be defined (within the relevant description
clauses) as to whether only the directly referenced objects in the
Singletons are instead affected. Usually, Singletons are not
included within CreateRow and DeleteRow requests, but there are cases
when they may be needed (one of the protocol exchange examples in the
APPENDIX illustrates such a case).
The new protocol operations are designed to "fit" in the existing PDU Within any EditRow class request, Singletons function much like
structure as originally defined in [RFC1905]. One of the alternative individual varbinds within a conventional SetRequest, and the name of
approaches discussed in the Appendix is the possibility of defining a any Singleton MUST NOT refer to any other Singleton or to any
new PDU structure that allows a more efficient OID suppression existing (or not) object within any RowOp of the same EditRow
strategy than the one described herein. However, the initial approach request.
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 Within the GetRow request, Singletons function much like individual
section 5. [RFC1905] provides the PDU definition which these new varbinds within a conventional GetRequest.
operations are based on.
Although the old PDU structure is maintained for now, this document Within the GetNextRow request, Singletons function much like
specifies an evolutionary approach in the way that the new protocol individual varbinds within a conventional GetNextRequest.
operations are encoded or contained within the PDU. As such, the new
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 Within the GetBulkRow request, Singletons function much like the
new protocol operations are formed or constructed. Other components non-repeaters varbinds in the conventional GetBulk request; thus,
of the PDU (e.g. error-index) are treated similarly to the current they function as GetNextRequest varbinds.
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 The remaining varbinds in any request form one or more independent
(rowOps). This allows a single CreateRow request, for example, to RowOps with each varbind serving as either a RowIdentifier or as an
create one or more new rows in a single protocol operation. Each Operand component of a RowOp.
rowOp corresponds to one attempt to create a row, in this case, or
3.2.2. The RowOp
The new requests defined in this document may generally contain zero
or more 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, corresponds to one attempt to delete a row in the case of DeleteRow,
and so forth. and so forth.
Note that the three layers in the diagram below do not describe Note that the three layers in the diagram below do not describe
different sections of the PDU, rather, they each represent the same different sections of the request, rather, they each represent the
information and structure (at different levels of abstraction). same information and structure (at different levels of abstraction).
<CreateRow.............> <CreateRow.............>
<rowOp1><rowOp2><rowOp3> <RowOp1><RowOp2><RowOp3>
<vb><vb><vb><vb><vb><vb> <vb><vb><vb><vb><vb><vb>
Although the above diagram shows a CreateRow request logically Although the above diagram shows a CreateRow request logically
containing three rowOps (i.e. create three rows) with two consecutive containing three RowOps (i.e. create three rows) with two consecutive
varbinds per rowOp, in reality, these requests may contain one, two, varbinds per RowOp, in reality, these requests may contain zero to
or more than two rowOps, each of which may may be comprised of a many RowOps, each of which may may be comprised of a differing number
differing number of varbinds (i.e. zero, one, or more than one). In of varbinds.
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 is hereafter referred to as the
RowIdentifier 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 and the
2nd, 4th and 6th varbinds are Operands.
The first varbind in each rowOp provides basic request parameters, 3.2.3. The RowIdentifier
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
6th varbinds are operands.
The following diagram shows a GetRow request containing a single The following diagram shows a GetRow request containing a single
rowOp that itself is composed of the required rowIdentifier and two RowOp that itself is composed of the required RowIdentifier and two
operands. Operands. In this case, the GetRow request is seeking to retrieve
two specific column objects from a specific row.
<GetRow.......................................> <GetRow.......................................>
<rowOp........................................> <RowOp........................................>
<vb1-rowIdentifier><vb2-operand1><vb3-operand2> <vb1-RowIdentifier><vb2-Operand1><vb3-Operand2>
In this case, the GetRow request is seeking to retrieve two specific A traditional OID for a given object instance in a table can be
column objects from a specific row. broken up into these logical components:
To understand how each rowIdentifier varbind is constructed and what OID = <TableName><1><ObjectSubid><Instance>
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 ObjectSubid is equivalent to one of the column descriptors. A more
three logical components: formal representation for RowIdentifier is now possible:
OID = <tableEntryPart><columnPart><instancePart> RowIdentifier = <vb.name=AggName,
vb.type=OID,
vb.value=1.0.Instance>
If a traditional SetRequest contains two varbinds referring to two The component, AggName (Aggregate Name), takes the same value of
different columns in the same row, it is evident that both OIDs TableName.
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: The vb.type MUST specify a type of OID. This is because the instance
part of an OID is actually comprised of one or more table index
values, each of which resolves to one or more subids.
rowIdentifier = <vb.name=tableEntryPart, Because the Instance always resolves to zero or more subids (because
there are cases when Instance is optional within a RowIdentifier),
and because a valid OID must be composed of at least two subids,
Instance is prefixed with the OID value of 1.0. The reason for this
choice of prefixes is that every valid table object name contains the
value of <1.ObjectSubid> as part of its OID.
The AggName of a RowIdentifier MUST NOT contain partial OIDs. This
means that the AggName MUST always exactly correspond to a legal
table definition (if the desired results are to be achieved). The
motivation behind this is that all RowOps are performed at the row
level on a specific table.
The Instance within a GetNextRow is not required to be fully formed
except that if the value is non-NULL, it MUST at least contain the
1.0 prefix. Also note that GetNextRow RowOps 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 RowOps are limited to
operate within the subtree of the targeted table(s), though the
Singletons within a GetNextRow or GetBulkRow request have no such
constraint.
3.2.4. RowIdentifiers in GetBulkRow Requests
GetBulkRow RowIdentifiers have a slightly different construction than
the RowIdentifiers for the other five request types. The diagram
below shows two new components are included in these RowIdentifiers,
InstanceLen and Instance2.
RowIdentifier = <vb.name=AggName,
vb.type=OID, vb.type=OID,
vb.value=0.1.instancePart> vb.value=1.0.InstanceLen.Instance.Instance2>
The vb.type MUST specify a type of OID. This is because the The two instance components define the search range of the GetBulkRow
instancePart of an OID is actually comprised of one or more table request (i.e. the rows from which data may be returned). Unlike the
index values, depending on which table is affected and how many MIB traditional GetBulk request, which may operate across one or more
objects comprise the INDEX clause of that table. For example, for a tables and/or scalar objects, each RowOp within a GetBulkRow request
table whose INDEX is comprised of a single integer, instancePart will is confined to operate only within the table specified by the AggName
be a single subid; and for a table whose INDEX is comprised of two or component, although each RowOp may operate on different tables.
more objects of any kind, the instancePart will be an OID (index1 + Furthermore, each RowOp operates only within the range of rows as
index2 + ... + indexN) with each index component representing one or specified by the two instance components (inclusive) and upon one or
more subids. more columns within that row range, as specified by the Operands that
are associated with the RowOp.
Because the instancePart always resolves to one or more subids, and The InstanceLen component specifies the number of subids that
because a valid OID must be composed of at least two subids, we comprise Instance. InstanceLen may be 0, which indicates that
prefix the instancePart with the OID value of 0.1. The reason Instance is not provided and that the search range begins at the
instancePart cannot simply be prefixed with a single subid is that first row (head) of the table and ends with the row specified by
OIDs of the form 0.X, where X > 39, are not legal. Thus, if Instance2. Instance or Instance2 need not resolve to existing rows.
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 The number of subids in Instance2 may be 0 or more, and if 0 (i.e.
specifies the exact row affected by the rowOp (but not which column Instance2 is not provided), this indicates that the search range
objects are affected in that row). includes any row that may correspond to the row specified by Instance
and all those that follow (i.e. to the end of the table).
Consider the case of two or more rowOps in, say, a SetRow request If Instance2 is lexicographically identical to Instance, the search
that only affects different rows in the same table. In such cases, range is confined to the one row common to both instances, or if
the varbind names of all the rowIdentifier varbinds will contain identical values do not resolve to an existing row, a NuSuchInstance
identical values. In order to therefore further minimize information error is returned. If Instance2 is lexicographically smaller than
redundancy, the OID of 1.0 (hereafter referred to as the inheritance Instance, a NoSuchInstance error will be returned.
OID, and occupying only a single byte within the resulting PDU) is
permitted to be substituted as the varbind name of any rowIdentifier The max-repetitions field in the GetBulkRow request may contain a
to indicate that the most recent (leftmost) rowIdentifier whose name non-zero value (M) to indicate a head or tail function should be
is dissimilar (not 1.0) contains the OID value intended to be used. performed for each RowOp in the request. Otherwise, max-repetitions
MUST always be zero (for all request types). If InstanceLen contains
the value 0 (i.e. Instance is not provided), at most M rows will be
returned from the head of the table. If InstanceLen contains a non-
zero value (i.e. Instance is provided), then at most M rows at the
tail of the table will be returned. For a head function, all returned
rows MUST be lexicographically smaller than or equal to Instance2, if
provided. For a tail function, all returned rows MUST be
lexicographically greater than or equal to Instance; and Instance2,
if provided, is ignored. The Instance2 component of a given RowOp,
therefore, SHOULD NOT be provided in a GetBulkRow request whose max-
repetitions and InstanceLen values are both non-zero as this
unnecessarily increases PDU size.
Whether the GetBulkRow request indicates a head or tail function (or
neither), it should be noted that the vb.value can be provided as
either 1.0.0 or as 1.0 to indicate that the desired search range
includes the entire table. The latter OID is slightly more efficient,
and both forms have the same semantics unless a head or tail function
is indicated (max-repetitions is non-zero). If max-repetitions is
non-zero and the vb.value = 1.0.0, this indicates a head function
whose search range is the entire table. If max-repetitions is non-
zero and the vb.value = 1.0, this indicates a tail function whose
search range is the entire table.
3.2.5. RowIdentifier Inheritance
Several forms of OID inheritance are possible within RowIdentifiers
in order to further minimize PDU size: name-level, prefix-level, and
instance-level inheritance.
In order to further minimize information redundancy, the OID of 0.0
is permitted to be substituted as the AggName component of any
RowIdentifier to indicate that the most recent (left) RowIdentifier
whose AggName is dissimilar (not 0.0) contains the OID value intended
to be used.
In this example, a simplified notation is used to help illustrate how 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 RowOps (the two middle ones) use the inheritance OID to minimize PDU
to minimize PDU size. This example shows four rowOps, each comprised size. This example shows four RowOps, each comprised of one
of one rowIdentifier and one operand (op): RowIdentifier and one Operand (op):
[<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><op>] [<foo><op>] [<0.0><op>] [<0.0><op>] [<fum><op>]
The following is logically identical to the preceding example (though The following is logically identical, though it forms a larger PDU:
it forms a larger PDU):
[<foo><op>] [<foo><op>] [<foo><op>] [<fum><op>] [<foo><op>] [<foo><op>] [<foo><op>] [<fum><op>]
In order for an inheritance OID to be correctly used, all RowOps that
affect the same table MUST be consecutively placed in the varbind
list, and also the first such RowIdentifier MUST NOT contain the
inheritance OID. The above is known as name-level inheritance.
Of course, this implies that rowOps that affect the same table SHOULD If a RowIdentifier of any request type has a NULL varbind value, this
be consecutively placed in the PDU varbind list, and also that the indicates that the most recent non-NULL varbind value is to be
first rowIdentifier in the PDU MUST NOT contain the inheritance OID. inherited. If the first RowIdentifier in a request contains a NULL
varbind value, the OID of 1.0 will be substituted. This is known as
instance-level inheritance.
Each rowOp is fully independant of any other despite any inheritance The third form of inheritance (prefix-level inheritance) occurs
whenever the varbind name of any AggName of a RowIdentifier begins
with the OID prefix of 0.0 AND four or more subids exist in the OID.
In such cases, the OID value of 1.3.6.1 is to be substituted in place
of the 0.0 prefix.
The example below shows two RowOps, each comprised of one
RowIdentifier and one Operand (op). Name- and prefix-level
inheritance are used:
[<0.0.foo><op>] [<0.0><op>]
The following is logically identical, though it forms a larger PDU:
[<1.3.6.1.foo><op>] [<1.3.6.1.foo><op>]
The following OID is not a candidate for prefix-level inheritance
because it has less than four subids: 0.0.1
Each RowOp is fully independent of any other despite any inheritance
it may use. it may use.
Each rowOp MUST contain a single rowIdentifier varbind, which MUST be 3.2.6. The Operands
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
level.
The instancePart within a GetNextRow is not required to be fully The remaining varbinds for a given RowOp are referred to as its
formed except that if the value is non-NULL, it MUST at least contain Operands and are formed as standard request varbinds except that the
the 0.1 prefix. Also note that GetNextRow requests do not "jump" to name of each varbind is an OID whose length is either two or three
the next table. In other words, in the event a GetNextRow rowOp subids long, as follows:
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 0.ObjectSubid (where ObjectSubid > 0 and ObjectSubid <= 39)
The remaining varbinds for a given rowOp are referred to as its or
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 0.1.ObjectSubid (where ObjectSubid == 0 or ObjectSubid > 39)
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 Each Operand contained in the same RowOp SHOULD be ordered according
request MUST contain at least one operand. to ascending values of the ObjectSubids.
In case of RetrieveRow requests, if zero operands are provided in a By way of example, if a table, foo, had four columns whose
rowOp, this implicitly calls for the retrieval of all instantiated descriptors (ObjectSubids) were 0, 1, 39 and 40, their Operand names
objects in the affected row. Otherwise, only the specified objects would be 0.1.0, 0.1, 0.39 and 0.1.40, respectively. Because the
are retrieved. majority of MIB object descriptors are between 1 and 39, typical
Operand names will take the form of 0.X.
In cases of CreateRow, at least one column definition in each of the 3.2.7. Extended Error Codes
affected tables must have a MAX-ACCESS of read-create and the the
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 In addition to the standard error-status and error-index values in a
object whose value is being changed and whose MAX-ACCESS is either response PDU, and varbind-level exceptions, an implementation MAY
read-create or read-write. The affected rows MUST already exist (in provide application-specific (extended) error indications in any
whole or part), though the specific operands MAY refer to objects response by inserting one new varbind at the end of the varbind list.
that do not yet exist. Only the last varbind MAY contain extended error information.
In cases of DeleteRow, each rowOp MAY contain operands whose MAX- Extended error information may be included in the PDU whether or not
ACCESS are either read-write or read-create. While it is not other errors/exceptions are indicated in the response (e.g. error-
essential that operands be included in a DeleteRow request, they may status).
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 The name of any varbind containing an extended error code is
constructed as follows:
As described earlier, the varbinds in a rowOp function either as a 0.0.<ErrorInfo><ErrorInfo><...>
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 Each ErrorInfo component is constructed as follows:
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 0.ErrorCode[.<VbList>]
(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 The ErrorInfo component may repeat multiple times but MUST have at
least one occurrence. The leading subid of 0 in the ErrorInfo
component serves as a separator between successive ErrorInfo
components.
It is worthwhile to note that SetRow class requests allow new MIBs to ErrorCode is a value in the range 1..4294967295.
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
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 The optional VbList is one or more subids which indicates a list of
varbind positions (one per subid) within the same response PDU that
associate to the preceding ErrorCode. The subids MUST be a value in
the range of 1..max-bindings [RFC1905].
In the event a SetRow class request contains two or more rowOps that The value component of a varbind containing an extended error
affect the same row, the elements of procedure (below) indicate that information is always NULL.
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 A properly formed varbind name will have a prefix of 0.0.0. This
with each varbind. prefix allows EOS-enabled SNMP applications to distinguish these
varbinds from all other varbind types (i.e. Singletons,
RowIdentifiers or Operands).
3.2.6. Response PDUs The ErrorCode of 3 in the following example indicates the 4th and 5th
varbinds raised that error.
This document does not define any new response PDU. Instead, the vb.name = 0.0.0.3.4.5
traditional Response-PDU [RFC1905] is used as the standard response vb.name = NULL
to each of the SetRow and RetrieveRow requests, except that the
varbinds are constructed using the same OID suppression techniques as The same varbinds MAY be associated to one or more extended error
described above. codes. The following example indicates an error code of 2 (for
varbinds 1 and 2), an error code of 5 (no specific varbinds
provided), an error code of 8 (for varbinds 2, 6 and 7) and an error
code of 9 (for varbind 8). An error code that does not have a VbList
(e.g. 5 in the above example) maps to a condition that applies to the
entire PDU as opposed to a set of varbinds.
vb.name = 0.0.0.2.1.2.0.5.0.8.2.6.7.0.9.8
vb.name = NULL
The set of all returned errors and exceptions indicated within a
Request-PDU is comprised of the error indicated in error-status (and
error-index), if any, the extended errors codes, if any, and the
exceptions present in any varbind, if any. Each error and/or
exception is independent of any other.
An implementation SHOULD NOT provide extended error information if
the desired information can instead be adequately conveyed using the
error-status/index fields or varbind-level exceptions. An
implementation MAY use extended error codes to convey a more detailed
error status than is otherwise possible using traditional
error/exception mechanisms. For example, if a wrongValue error is
returned for varbind 5, an implementation may also choose to provide
an extended error value to indicate that the provided value was
"TooLarge".
The presence of extended error codes (or lack thereof) in a response
does not guarantee all possible errors in the original request have
been identified (or that there are no unknown errors). The presense
of extended error information does not determine success/failure of a
protocol operation. Rather, the error-status of noError implies a
successful operation, whereas all other error-status values imply
failure.
The method used to impart meaning to the returned error values is out
of scope to this document. See [TBD] for details.
3.2.8. RowOps and Group Scalar Objects.
It is also possible to use the new requests to access or modify
groups of scalar objects where each RowOp relates to a specific
group. The only exception to this is that GetBulkRow RowOps are
limited to operating on tables only (though the Singletons within a
GetBulkRow may reference scalar objects).
To form a valid RowOp that refers to a group, the following MUST be
done: First, the AggName instead refers to a valid group OID (e.g.
the system group OID is 1.3.6.1.2.1.1), second, the RowIdentifier
Instance prefix value is always provided as 0.0 (instead of 1.0 as
for tables) and third, there is no Instance provided. The following
example shows the relevant OIDs within a RowOp which accesses the
system group scalars:
RowIdentifier = <vb.name=AggName=0.0.2.1.1, -- 1.3.6.1.2.1.1
vb.type=OID,
vb.value=0.0> -- not a table
Operand1 = 0.1 -- sysDescr
Operand2 = 0.2 -- sysObjectID
Operand3 = 0.3 -- sysUptime
Operand4 = 0.4 -- sysContact
Operand5 = 0.5 -- sysName
Operand6 = 0.6 -- sysLocation
Operand7 = 0.7 -- sysServices
A CreateRow request can be used for group scalars if the affected
scalars MAX-ACCESS values are read-create and the objects do not
exist.
A DeleteRow request can be used for group scalars if the affected
scalars MAX-ACCESS values are read-create.
An EditRow request can be used for group scalars if the affected
scalars MAX-ACCESS values are either read-write or read-create.
The GetRow or GetNextRow requests may also be used for group scalars.
The following shows a request with three RowOps using instance-level
inheritance for group scalar access:
[<system:0.0><op>]
[<snmpTargetObjects:NULL><op>]
[<snmpEngine:NULL><op>]
The following is logically identical to the above example, though it
forms a larger PDU:
[<system:0.0><op>]
[<snmpTargetObjects:0.0><op>]
[<snmpEngine:0.0><op>]
3.2.9. Three-Phase Sets
All SetRow requests are processed using a three-phase processing
model instead of the two-phase model defined in [RFC1905]. The new
third phase (retrieve Operand values) occurs only if the first phase
(test) completes successfully. If the test phase results in an
error, all Operand values in the response will be set to NULL or
appropriate errors and exceptions will be returned. Otherwise, all
Operand values in the response will contain the value of the
indicated object as it exists at the start of the third-phase (i.e.
after the completion of the commit phase) or may contain exceptions
if the Operand value is unavailable. In the event any Operand refers
to an object which is known to have existed at the start of the first
phase but not at the start of the third phase (as is possible with
DeleteRow), the value of such Operands will be NULL in the final
response.
3.2.10. Response PDUs
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 and, except for a successful GetBulkRow
response, the number and type of varbinds (though not necessarily
their names and values) returned are identical to the original
request. Any response MAY also contain an additional varbind (the
last) containing extended error information. The structure and
contents of GetBulkRow responses are a bit more unpredictable.
Singletons within a GetBulkRow (or any) request always have
corresponding Singletons in the response (i.e. the first N varbinds
MAY be Singletons). The RowOps in a GetBulkRow request, however, are
not returned in a successful response; instead, new RowOps and/or
Singletons are inserted into the response after varbind N. A RowOp
will be included only if it contains two or more Operands, whereas a
Singleton will be included if a RowOp with only one Operand from a
given row would otherwise be returned. Thus, RowOps and Singletons
may be interspersed together in the response, although in all cases
they are provided in row by row order.
The returned row information MUST be ordered so that RowOp i is
lexicographically smaller than or equal to RowOp i+1. RowOps with
similar AggName values MUST also be sub-ordered in lexicographically
ascending order based on their Instance values. Any two returned
RowOps MUST NOT contain identical AggName and Instance values.
Similarly, for all new Singletons included after varbind N, Singleton
i MUST be lexicographically smaller than Singleton i+1 and they MUST
be interspersed with RowOps so that all RowIdentifier and Singleton
varbinds (after varbind N) are ordered in lexicographically ascending
order. In addition, Singletons MUST NOT be inserted between any
RowIdentifier and one of its Operands.
If an otherwise successful response to a GetBulkRow request ever
fails to include all the data requested (due to PDU size
limitations), then the response MAY include an appropriate extended
error indicating this fact. In this way, the last RowOp (or
Singleton) in the response contains an Instance that can be used to
calculate the beginning search range for a subsequent GetBulkRow
request.
SNMP applications which generate GetBulkRow requests MUST preserve
(i.e. remember) the value of the non-repeaters field for each request
where it was non-zero. This allows the application to easily and
correctly distinguish the first N (N = non-repeaters) Singletons from
subsequent response components.
3.2.11. Determining Varbind Roles
Varbinds function as either Singletons, RowIdentifiers, Operands, or
as carriers of extended error information. It is important for an
implementation to correctly determine the role of every varbind in
any given request or response. The following procedure is used to
correctly identify the role of a given varbind, V, where V is a value
in the range (1..max-bindings) in a request or response, and where N
= non-repeaters in the associated request. The first rule below that
applies determines the correct role of the varbind.
- If V <= N, and N > 0, V is a Singleton.
- If V is the last varbind in a Response-PDU, and V has a name
prefixed by the value, 0.0.0, V contains extended error
information.
- If the name of V is comprised of exactly two subids and this
name is the value 0.X (where X > 0 and X <= 39), V is an
Operand.
- If the name of V is comprised of exactly three subids and this
name is the value 0.1.X (where X = 0, or X > 39), V is an
Operand.
- If V is in any request or response other than a successful
GetBulkRow response, V is a RowIdentifier.
- If V is in a successful GetBulkRow response and the varbind V+1
exists, and varbind V+1 is an Operand, then V is a
RowIdentifier.
- If V is in a successful GetBulkRow response and the varbind V+1
exists, and varbind V+1 is NOT an Operand, then V is a
Singleton.
- Otherwise, V is a Singleton
4. Elements of Procedure 4. Elements of Procedure
4.1. CreateRow Request Processing 4.1. CreateRow Request Processing
TBD TBD
4.2. DeleteRow Request Processing 4.2. DeleteRow Request Processing
TBD TBD
skipping to change at page 15, line 17 skipping to change at page 20, line 5
TBD TBD
4.4. GetRow Request Processing 4.4. GetRow Request Processing
TBD TBD
4.5. GetNextRow Request Processing 4.5. GetNextRow Request Processing
TBD TBD
4.6. Response-PDU Processing 4.6. GetBulkRow Request Processing
TBD
4.7. Response-PDU Processing
TBD TBD
5. Coexistence and Transition 5. Coexistence and Transition
An essential requirement for these operations is that they must An essential requirement for these operations is that they must
operate seamlessly in existing networks and not disrupt legacy SNMP operate seamlessly in existing networks and not disrupt legacy SNMP
devices. This is satisfied by the fact that the new protocol devices. This is satisfied by the fact that the new protocol
operations have new and unique ASN.1 tags, which allow older operations have new and unique ASN.1 tags, which allow older
implementations to efficiently and silently drop these new PDU implementations to efficiently and silently drop these new requests.
requests.
Some entities may only support these extensions for certain tables. Some entities may only support these extensions for certain tables.
For example, different AgentX subagents may or may not support these For example, different AgentX subagents may or may not support these
operations. This requires that the requests fail whenever a table is operations. This requires that the requests fail whenever a table is
targeted that cannot support the new operation. The elements of targeted that cannot support the new operation. The elements of
procedure indictate the proper exceptions in these cases. procedure indicate the proper exceptions in these cases.
It is also possible that some table implementations may support only It is also possible that some table implementations may support only
some subset of the new operations, for example, the RetrieveRow some subset of the new operations, for example, the RetrieveRow
requests, but not the SetRow requests. It is herein RECOMMENDED that requests, but not the SetRow requests.
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.
In an ideal world, the extensions herein would be easily translatable In an ideal world, the extensions herein would be easily translatable
to traditional operations. However, this is not the case. to traditional operations. However, this is not the case for the
CreateRow, DeleteRow and GetBulkRow requests. On the other hand, it
is believed the GetRow, GetNextRow and EditRow requests can be
translated into conventional request formats (or subagent
operations).
Consider, for example, that it is impossible to form an equivalent One possible transition strategy is to enable existing SNMP
SetRequest from a DeleteRow request that contains only a applications to support GetRow, GetNextRow and EditRow requests (with
rowIdentifier but no operands. In fact, any SetRow or RetrieveRow or without the traditional requests). A proxy application, for
request containing no operands cannot be translated into an example, could bridge an EOS network with a non-EOS network by
equivalent Set/Get request because at least one operand is needed to translating those EOS requests into conventional requests (and
convert the rowIdentifier information into a valid object (OID) responses). Similarly, an AgentX master agent could translate this
reference. DeleteRow may optionally include a RowStatus object, which same subset of EOS requests into conventional AgentX requests (and
allows such a translation, but then the question arises as to the responses). The benefits achieved with this strategy would be to
need for DeleteRow definitions in the first place. obtain smaller PDU sizes on the network along with a 100% reuse of
existing instrumentation methods (and subagent protocols). Subsequent
support of the CreateRow, DeleteRow and GetBulkRow requests is always
possible at a future date, or on a subagent by subagent basis
(assuming a compatible subagent protocol has been adopted).
Or consider a proxy application that accepts CreateRow or EditRow The procedures to translate EOS requests into conventional
requests and translates them into an equivalent SetRequest. For operations, where possible, are out of scope of this document.
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 It is RECOMMENDED, however, that new SNMP implementations support
the extensions into traditional subagent PDU forms. Semantics may be (for all MIB objects) all of the RetrieveRow class of requests. It is
lost in the translation, and only some amount of workaround is further RECOMMENDED that new implementations supporting any of the
possible unless the underlying subagent protocol is itself extended SetRow class of requests instead support all of the SetRow requests
to accomodate the new extensions. (for all applicable MIB objects).
While it is possible to develop proxy applications that incorporate Also, it is RECOMMENDED that new SNMP MIBs SHOULD use the RowState
simple PDU translation schemes to generally allow EOS-capable devices textual-convention in lieu of RowStatus, if applicable.
(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 Proxy applications wishing to fulfill these recommendations can only
that non-EOS-capable devices need to be converted into EOS-capable serve as EOS request forwarders for the CreateRow, DeleteRow and
devices by means other than simple PDU translation schemes. In order GetBulkRow requests, and as request translators (or forwarders) for
to enable a transition strategy that uses simple PDU translation the other requests.
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
row fate, and perhaps other goals as well).
6. Protocol Operations Definitions 6. Protocol Operations Definitions
SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
PDU BulkPDU
SNMPv2-PDU; SNMPv2-PDU;
ROWOP-PDUs ::= ROWOP-PDUs ::=
CHOICE { CHOICE {
create-row-request create-row-request
CreateRowRequest-PDU, CreateRowRequest-PDU,
delete-row-request delete-row-request
DeleteRowRequest-PDU, DeleteRowRequest-PDU,
edit-row-request edit-row-request
EditRowRequest-PDU, EditRowRequest-PDU,
get-row-request get-row-request
GetRowRequest-PDU, GetRowRequest-PDU,
get-next-row-request get-next-row-request
GetNextRowRequest-PDU GetNextRowRequest-PDU
get-bulk-row-request
GetBulkRowRequest-PDU
} }
CreateRowRequest-PDU ::= CreateRowRequest-PDU ::=
[9] [9]
IMPLICIT PDU IMPLICIT BulkPDU
DeleteRowRequest-PDU ::= DeleteRowRequest-PDU ::=
[10] [10]
IMPLICIT PDU IMPLICIT BulkPDU
EditRowRequest-PDU ::= EditRowRequest-PDU ::=
[11] [11]
IMPLICIT PDU IMPLICIT BulkPDU
GetRowRequest-PDU ::= GetRowRequest-PDU ::=
[12] [12]
IMPLICIT PDU IMPLICIT BulkPDU
GetNextRowRequest-PDU ::= GetNextRowRequest-PDU ::=
[13] [13]
IMPLICIT PDU IMPLICIT BulkPDU
GetBulkRowRequest-PDU ::=
[14]
IMPLICIT BulkPDU
END END
7. Managed Object Definitions 7. Managed Object Definitions
SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpRowopMIB MODULE-IDENTITY snmpRowopMIB MODULE-IDENTITY
LAST-UPDATED "200104191653Z" LAST-UPDATED "200106151500Z"
ORGANIZATION "EOS Working Group" ORGANIZATION "EOS Working Group"
CONTACT-INFO "WG-EMail: eos@ops.ietf.org CONTACT-INFO "WG-EMail: eos@ops.ietf.org
Subscribe: eos-request@ops.ietf.org Subscribe: eos-request@ops.ietf.org
Co-Chair: Dale Francisco Co-Chair: Dale Francisco
Cisco Systems, Inc. EMail: dfrancisco@acm.org
postal: 80 West Tasman Drive phone: +1 408-324-1389
San Jose, CA 95134
USA
EMail: dfrancis@cisco.com
phone: +1 408-527-9787
Co-Chair: Glenn Waters Co-Chair: Glenn Waters
Nortel Networks Nortel Networks
postal:
USA
EMail: gww@nortelnetworks.com EMail: gww@nortelnetworks.com
phone:
Co-editor: Lauren Heintz Editor: Lauren Heintz
Cisco Systems, Inc. Cisco Systems, Inc.
postal: 130 Baytech Drive postal: 130 Baytech Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: lheintz@cisco.com EMail: lheintz@cisco.com
phone: +1 408-853-6568 phone: +1 408-853-6568
" "
DESCRIPTION "The SNMP Row Operations MIB" DESCRIPTION "The SNMP Row Operations MIB"
REVISION "200103280000Z" REVISION "200106151500Z"
DESCRIPTION "The initial version, published in DESCRIPTION "The initial version, published in
draft-ietf-eos-snmp-rowops-00.txt. draft-ietf-eos-snmp-rowops-01.txt.
" "
::= { snmpModules TBD } ::= { snmpModules TBD }
-- Textual Conventions -- Textual Conventions
RowState ::= TEXTUAL-CONVENTION RowState ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION "TBD" DESCRIPTION "
SYNTAX INTEGER {TBD} This textual-convention provides a means
to represent the state of a conceptual row;
it does not provide a means to manage creation
and/or destruction of conceptual rows.
In any row which includes a definition of RowState
that is also mandatory, that row MUST contain
an instantiation of a RowState object if any other
object in the same row is instantiated.
A status column of this type has three defined
values:
- `active', which indicates that the
conceptual row is in use by the managed
device and is considered fully operational
from a management perspective;
- `notInService', which indicates that the
conceptual row is available for use by
the managed device but is NOT considered
fully operational from a management
perspective; a row in this state contains
all information necessary for a transition to
the active state;
- `notReady', which indicates that the
conceptual row is not available for use
by the managed device, perhaps because the
row is missing information or the row has
been explicitly set to this state;
Any of the three states may be specified in a
management protocol set operation. At any time,
the value of an existing RowState object may be
modified or changed to any other state unless
the current value is notReady and the row (after
completion of a management set operation) would
not be consistent with an active state (i.e.
information is missing or inconsistent and as a
result the row could not assume an active state
until further management set operations were
performed). In this case, the value MUST remain
at notReady and an inconsistentValue error is
returned.
A RowState object whose value is notReady MUST
implicitly promote itself from notReady to
notInService if any management protocol set
operation not referencing the status column
explicitly changes the value of any other object
in the same row AND the row afterward is now
consistent with the active state (i.e all
information needed to make the row active is
available).
When a row does not exist, and a management
protocol set operation causes any object in the row
to be created, the status object will also be
instantiated and its initial value will be determined
by the first of the following rules that are satisfied:
1. if the set operation includes an initial value,
the RowState object will take on the highest
value (i.e. active is highest) consistent with
the state definitions, but no higher than the
provided value. For example, if a set operation
contains a varbind where RowState=notInService
(or active), the initial value will be notReady
if the row is in an inconsistent state after the
operation is complete; otherwise, it will be
notInService (or active).
2. if the set operation does not include an initial
value, but the RowState definition does include
a supported DEFVAL, the initial value will be the
highest value consistent with the state definitions
but no higher than the value specified in the
DEFVAL, unless the DEFVAL specifies a value of
notReady, which in this case, the DEFVAL is ignored
(i.e. case 3 below instead applies).
3. otherwise, the set operation does not include an
initial value, and the RowState definition does
not include a DEFVAL, and the initial value will
be set to the highest value consistent with the
state definitions. Thus, the initial state will
be active if the new row is consistent with that
state, or it will be notReady otherwise.
No constraint is imposed on whether other objects
in the same row can be modified, regardless of the
value of the associated RowState object. If such
constraints are desired, they MUST be explicitly
stated in the DESCRIPTION clause of the status column.
In the absence of such statements, the managed device
MUST allow any object in any row to be modified at
any time, notwithstanding the possibility that other
MIB objects MAY also impose similar constraints.
An inconsistentValue error is returned when an invalid
attempt is made to alter a row whose state precludes
such an operation.
RowState description clauses, in addition to
the DESCRIPTION clauses of associated column
objects, SHOULD together describe the general
conditions under which a row can be made active.
In the absence of such statements, any row SHOULD
generally be capable of being made active at any
time.
The agent must detect conceptual rows that
have been in the notReady state for an abnormally
long period of time and remove them. It is the
responsibility of the DESCRIPTION clause of the
status column to indicate what an abnormally long
period of time would be. This period of time should
be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absense of such information in the DESCRIPTION
clause, it is suggested that this period be approximately
5 minutes in length. This removal action applies not only
to newly-created rows, but also to previously active rows
which are set to, and left in, the notReady state for a
prolonged period exceeding that which is considered normal
for such a conceptual row."
SYNTAX INTEGER {
active(1),
notInService(2),
notReady(3)
}
END END
8. IANA Considerations 8. IANA Considerations
This document requires IANASnmpExtendedProtocol values to be reserved This document requires IANASnmpExtendedProtocol values to be reserved
for allowing command responders to advertise their ability to support for allowing command responders to advertise their ability to support
the extensions outlined in this document. IANASnmpExtendedProtocol the extensions outlined in this document. IANASnmpExtendedProtocol
values are administered by IANA. IANASnmpExtendedProtocol is defined values are administered by IANA. IANASnmpExtendedProtocol is defined
in SNMP-X-PROTOCOL-TC. in SNMP-X-PROTOCOL-TC.
skipping to change at page 19, line 49 skipping to change at page 27, line 9
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
10. Acknowledgements 10. Acknowledgements
This document is the result of the efforts of the Evolution Of SNMP This document is the result of the efforts of the Evolution Of SNMP
(EOS) Working Group. Some special thanks are in order to the (EOS) Working Group. Some special thanks are in order to the
following EOS WG members: following EOS WG members for their ideas, efforts and asundry
contributions:
TBD Dr. Jeff Case
Sharon Chisholm
Dale Francisco
Sandra McLeod
Steve Moulton
David Perkins
Randy Presuhn
Jeurgen Schoenwaelder
Robert Story
Glenn Waters
Matt White
11. Security Considerations 11. Security Considerations
TBD TBD
12. References 12. References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and [RFC1155] Rose, M. and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP- Identification of Management Information for TCP/IP-
based internets", STD 16, RFC 1155, May 1990. based internets", STD 16, RFC 1155, May 1990.
skipping to change at page 20, line 47 skipping to change at page 28, line 16
"Textual Conventions for SMIv2", STD 58, RFC 2579, April "Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999. 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network Waldbusser, "Protocol Operations for the Simple Network
Management Protocol", <draft-ietf-snmpv3-update-proto- Management Protocol", <draft-ietf-snmpv3-update-proto-
05.txt>, April 2001. 05.txt>, June 2001.
[RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for the Simple Network Waldbusser, "Transport Mappings for the Simple Network
Management Protocol", <draft-ietf-snmpv3-update- Management Protocol", <draft-ietf-snmpv3-update-
transmap-05.txt>, April 2001. transmap-05.txt>, June 2001.
[RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base for the Simple Waldbusser, "Management Information Base for the Simple
Network Management Protocol", <draft-ietf-snmpv3- Network Management Protocol", <draft-ietf-snmpv3-
update-mib-05.txt>, April 2001. update-mib-05.txt>, June 2001.
[RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework", of the Internet-standard Network Management Framework",
<draft-ietf-snmpv3-coex-v2-00.txt>, April 2001. <draft-ietf-snmpv3-coex-v2-00.txt>, June 2001.
[RFC1909] McCloghrie, K., Editor, "An Administrative [RFC1909] McCloghrie, K., Editor, "An Administrative
Infrastructure for SNMPv2", RFC 1909, February 1996. Infrastructure for SNMPv2", RFC 1909, February 1996.
[RFC1910] Waters, G., Editor, "User-based Security Model for [RFC1910] Waters, G., Editor, "User-based Security Model for
SNMPv2", RFC 1910, February 1996. SNMPv2", RFC 1910, February 1996.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January, 1998. 10646", RFC 2279, January, 1998.
skipping to change at page 21, line 38 skipping to change at page 29, line 6
[BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October the IETF Standards Process", BCP 11, RFC 2028, October
1996. 1996.
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group
MIB." RFC 2863, June 2000. MIB." RFC 2863, June 2000.
[SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple "Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", <draft-ietf- Network Management Protocol (SNMP)", <draft-ietf-
snmpv3-mpd-v2-00.txt>, April 2001. snmpv3-mpd-v2-00.txt>, June 2001.
[SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model for Version 3 of the Simple Network Management Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", <draft-ietf-snmpv3-usm-v2-00.txt>, Protocol (SNMPv3)", <draft-ietf-snmpv3-usm-v2-00.txt>,
April 2001. June 2001.
[SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management Access Control Model for the Simple Network Management
Protocol (SNMP)", <draft-ietf-snmpv3-vacm-04.txt>, Protocol (SNMP)", <draft-ietf-snmpv3-vacm-04.txt>,
February 1999. <draft-ietf-snmpv3-vacm-v2-00.txt>, February 1999. <draft-ietf-snmpv3-vacm-v2-00.txt>, June
April 2001. 2001.
[RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP
Applications", <draft-ietf-snmpv3-apps-v2-00.txt>, April Applications", <draft-ietf-snmpv3-apps-v2-00.txt>, June
2001. 2001.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard "Introduction to Version 3 of the Internet-standard
Network Management Framework", <draft-ietf-snmpv3- Network Management Framework", <draft-ietf-snmpv3-
intro-04.txt>, January 1999. intro-04.txt>, January 1999.
[RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework", of the Internet-standard Network Management Framework",
<draft-ietf-snmpv3-coex-v2-00.txt>, April 2001. <draft-ietf-snmpv3-coex-v2-00.txt>, June 2001.
13. Editor's Addresses 13. Editor's Addresses
Lauren Heintz Lauren Heintz
Cisco Systems, Inc. Cisco Systems, Inc.
130 Baytech Drive 130 Baytech Drive
San Jose, Ca 95134 San Jose, Ca 95134
Phone: +1 408-853-6568 Phone: +1 408-853-6568
EMail: lheintz@cisco.com EMail: lheintz@cisco.com
skipping to change at page 24, line 20 skipping to change at page 31, line 20
An issue remains whether a new message processing model MUST be An issue remains whether a new message processing model MUST be
specified as part of the SNMPv3 (or later) standard. Otherwise, it is specified as part of the SNMPv3 (or later) standard. Otherwise, it is
not seen that these extensions pose any impact to other SNMPv3 not seen that these extensions pose any impact to other SNMPv3
architectural components (i.e. USM, VACM) because the new protocol architectural components (i.e. USM, VACM) because the new protocol
operations and their contents contain sufficient information (along operations and their contents contain sufficient information (along
with the information provided in whatever version-specific message with the information provided in whatever version-specific message
wrapper they are contined within) to satisfy the abstract service wrapper they are contined within) to satisfy the abstract service
interfaces for those components. interfaces for those components.
However, these extensions are not compatible with the SNMPv3 proxy However, these extensions may not be fully compatible with the SNMPv3
application (or any legacy SNMP application incorporating a message proxy application (or any legacy SNMP application incorporating a
processing module that receives and processes or forwards SNMP message processing module that receives and processes or forwards
messages). SNMP messages).
A.2. AgentX A.2. AgentX
These extensions imply that AgentX will have to evolve in order to These extensions imply that AgentX will have to evolve in order to
support the new protocol operations. For example, AgentX does not support the new protocol operations. For example, AgentX does not
provide a delete PDU (to support DeleteRow), and neither does its provide a delete PDU (to support DeleteRow), and neither does its
TestSet PDU provide for a standard way to indicate whether the TestSet PDU provide for a standard way to indicate whether the
operation being performed maps to a CreateRow or EditRow request. operation being performed maps to a CreateRow or EditRow request.
Furthermore, master agents will need to know how to recognize and Furthermore, master agents will need to know how to recognize and
process the new protocol operations (i.e. distinguish rowIdentifiers process the new protocol operations (i.e. distinguish RowIdentifiers
from operands, logically expand the targeted object OIDs and map them from Operands, logically expand the targeted object OIDs and map them
to subtree registrations). to subtree registrations).
B. Alternative Approaches The feature to allow extended error codes to be returned in response
PDUs may also require AgentX to provide a means to communicate such
information from the subagent(s) to the master agent.
This section will be deleted before going standards track. B. Examples of Row Operations
This document outlines one approach to achieving the design goals B.1. CreateRow
stated earlier. Several other approaches also exist. Here are some
hints:
- Use the same approach described herein except define a new Create two new rows in the snmpNotifyTable [RFC2573]. This table
"RowPDU" to further optimize OID suppression (i.e. get rid of uses RowStatus, so we choose to explicitly set its value for each row
the 0.1.X column subid notation). This may require a new kind (new impls may allow the request to omit a RowStatus varbind if its
of varbind list where each varbind is no longer an OID/value value is createAndGo). The response includes the values of the
pair, but instead it is an Integer/Value pair. Similarly, this specified Operands after row creation.
new PDU could contain one or more rowIdentifier items (one per
rowOp).
- Instead of having five new request types, use only one instead CreateRow
and perhaps have an operator within the request to indicate the (
nature of the operation. Also, the operator might be included request-id = 1
within each rowOp contained within the request so that one non-repeaters = 0 -- 0 Singletons
protocol operation might contain mixed row operations (i.e. a max-repetitions = 0
createRow and deleteRow might co-exist in the same protocol
request).
- Maintain the same PDU structure, but re-define what a varbind -- RowOp 1
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 -- RowIdentifier
traditional protocol operations, perhaps with a way of vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
minimizing overhead. In this case, we would tradeoff feature vb1.value = 1.0.114.111.119.49 -- "row1"
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? vb2.name = 0.2 -- snmpNotifyTag
vb2.value = "tag1"
C. Examples of Row Operations vb3.name = 0.3 -- snmpNotifyType
vb3.value = 1 -- trap
Each of the following examples assumes that the error-index and -- skip snmpNotifyStorageType. Use DEFVAL
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 vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value = createAndGo
This protocol exchange illustrates the use of the CreateRow request -- RowOp 2
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 -- RowIdentifier
the previous rowOp (because 1.0 instructs this). vb5.name = 0.0 -- inherit snmpNotifyTable
vb5.value = 1.0.114.111.119.50 -- "row2"
CreateRow vb6.name = 0.3 -- snmpNotifyType
vb6.value = 1 -- trap
vb7.name = 0.5 -- snmpNotifyRowStatus
vb7.value = createAndWait
)
ResponsePdu
( (
-- rowOp 1 request-id = 1
error-status = noError
-- rowIdentifier (table and instance) -- RowOp 1
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 -- RowIdentifier
vb2.value(SnmpTagValue) = "tag1" vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.114.111.119.49 -- "row1"
vb3.name = 0.1.3 -- snmpNotifyType vb2.name = 0.2 -- snmpNotifyTag
vb3.value(INT) = 1 -- trap vb2.value = "tag1"
-- skip snmpNotifyStorageType. Use DEFVAL vb3.name = 0.3 -- snmpNotifyType
vb3.value = 1 -- trap
vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value(RowStatus) = createAndGo vb4.value = active
-- rowOp 2 -- RowOp 2
-- rowIdentifier (table and instance) -- RowIdentifier
vb5.name = 1.0 -- inherit snmpNotifyEntry vb5.name = 0.0 -- inherit snmpNotifyTable
vb5.value(OID) = 0.1.114.111.119.50 -- "row2" vb5.value = 1.0.114.111.119.50 -- "row2"
vb6.name = 0.1.5 -- snmpNotifyRowStatus vb6.name = 0.3 -- snmpNotifyType
vb6.value(RowStatus) = createAndWait vb6.value = 1 -- trap
)
C.2. CreateRow with RowState vb7.name = 0.5 -- snmpNotifyRowStatus
vb7.value = notInService
)
This protocol exchange illustrates the use of the CreateRow request This protocol exchange illustrates the use of the CreateRow request
to create two new rows in the snmpNotifyTable [RFC2573] except that to create two new rows in the snmpNotifyTable [RFC2573] except that
we pretend here that RowState was used in the design of that table we pretend here that RowState was used in the design of that table
instead of RowStatus. instead of RowStatus.
CreateRow CreateRow
( (
-- rowOp 1 request-id = 2
non-repeaters = 0 -- 0 Singletons
max-repetitions = 0
-- rowIdentifier (table and instance) -- RowOp 1
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 -- RowIdentifier
vb2.value(SnmpTagValue) = "tag1" vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.114.111.119.49 -- "row1"
vb3.name = 0.1.3 -- snmpNotifyType vb2.name = 0.2 -- snmpNotifyTag
vb3.value(INT) = 1 -- trap vb2.value = "tag1"
-- skip snmpNotifyStorageType. Use DEFVAL
vb3.name = 0.3 -- snmpNotifyType
vb3.value = 1 -- trap
-- skip snmpNotifyStorageType. Use DEFVAL
-- By omitting a RowState varbind, it is the -- By omitting a RowState varbind, it is the
-- same as setting RowState=Active. -- same as setting RowState=Active.
-- rowOp 2 -- RowOp 2
-- rowIdentifier (table and instance) -- RowIdentifier
vb4.name = 1.0 -- inherit snmpNotifyEntry vb4.name = 0.0 -- inherit snmpNotifyTable
vb4.value(OID) = 0.1.114.111.119.50 -- "row2" vb4.value = 1.0.114.111.119.50 -- "row2"
vb5.name = 0.3 -- snmpNotifyType
vb5.value = 1 -- trap
-- Explicitly set RowState to an initial -- Explicitly set RowState to an initial
-- value because we don't want to go -- value because we don't want to go
-- active just yet. Even though we hint -- active just yet. Even though we hint
-- for an initial value of NotInService, -- for an initial value of NotInService,
-- it's possible that the result might -- it's possible that the result might
-- show NotReady (if the row as defined -- show NotReady (if the row as defined
-- by CreateRow were not ready to go Active). -- by this RowOp were not ready to go Active).
vb5.name = 0.1.5 -- snmpNotifyRowState -- If a DEFVAL (NotInService) were provided
vb5.value(RowState) = NotInService -- in the MIB, this varbind could be omitted
-- from this RowOp.
vb6.name = 0.5 -- snmpNotifyRowState
vb6.value = NotInService
) )
C.3. DeleteRow ResponsePdu
(
request-id = 2
error-status = noError
This example illustrates how a DeleteRow request containing two row -- RowOp 1
operations is formed to delete the two rows created in either of the
two previous examples. Note that the rowIdentifier in the second -- RowIdentifier
rowOp does not inherit the table OID from the first rowOp. Although vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
this is legal, it also increases the request PDU size unnecessarily. vb1.value = 1.0.114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value = "tag1"
vb3.name = 0.3 -- snmpNotifyType
vb3.value = 1 -- trap
-- RowOp 2
-- RowIdentifier
vb4.name = 0.0 -- inherit snmpNotifyTable
vb4.value = 1.0.114.111.119.50 -- "row2"
vb5.name = 0.3 -- snmpNotifyType
vb5.value = 1 -- trap
vb6.name = 0.5 -- snmpNotifyRowState
vb6.value = NotInService
)
B.2. DeleteRow
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
needlessly increases the request PDU size. Also note that the
command responder instead chose to use name-level inheritance.
DeleteRow DeleteRow
( (
-- rowOp 1 request-id = 3
non-repeaters = 0 -- 0 Singletons
max-repetitions = 0
-- rowIdentifier (table and instance) -- RowOp 1
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
vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.114.111.119.49 -- "row1"
-- rowIdentifier (table and instance) -- RowOp 2
vb2.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb2.value(OID) = 0.1.114.111.119.50 -- "row2" -- RowIdentifier
vb2.name = 1.3.6.1.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.114.111.119.50 -- "row2"
) )
C.4. GetRow and GetNextRow ResponsePdu
(
request-id = 3
error-status = noError
This example illustrates how a GetRow request with three row -- RowOp 1
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 -- RowIdentifier
exist in the table row. vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.114.111.119.49 -- "row1"
The Response PDU is also shown afterward. -- RowOp 2
-- RowIdentifier
vb2.name = 0.0 -- snmpNotifyTable
vb2.value = 1.0.114.111.119.50 -- "row2"
)
GetNextRow performs very similarly to GetRow except that the Response This DeleteRow example illustrates the use of Singletons. The
PDU will contain the object names and values from the next row in the Singletons allow a complete object instance to be provided (whereas
table (if any), or will contain exceptions as placeholders where the the previous example contained no Operands and thus did not have
requested objects do not exist. access to the column descriptors, which are needed to form complete
OIDs). If the user's VACM view only allowed him/her to delete certain
rows in a table, the DeleteRow request would have to contain enough
information to satisfy the isAccessAllowed service interface
[RFC2573], and the above example does not. This can be accomplished
by either providing an Operand within each RowOp or by instead using
Singletons, which are more efficient than using RowOps in such cases.
DeleteRow
(
request-id = 4
non-repeaters = 2 -- 2 Singletons
max-repetitions = 0
-- Singleton 1
-- delete snmpNotifyTag in row1, which
-- in this case also deletes all of row1
vb1.name = 0.0.6.3.13.1.1.1.2.114.111.119.49
vb1.value = NULL
-- Singleton 2
-- delete snmpNotifyTag in row2, which
-- in this case also deletes all of row2
vb1.name = 0.0.6.3.13.1.1.1.2.114.111.119.50
vb1.value = NULL
)
B.3. GetRow
This is an example of a protocol exchange for a GetRow request and
its response.
GetRow GetRow
( (
-- rowOp 1 request-id = 5
non-repeaters = 0 -- 0 Singletons
max-repetitions = 0
-- RowOp 1
-- rowIdentifier (table and instance) -- RowIdentifier
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb1.value = 1.0.114.111.119.49 -- "row1"
vb2.name = 0.1.2 -- snmpNotifyTag vb2.name = 0.2 -- snmpNotifyTag
vb2.value = NULL vb2.value = NULL
-- rowOp 2 vb3.name = 0.3 -- snmpNotifyType
vb3.value = NULL
-- rowIdentifier (table and instance) -- RowOp 2
vb3.name = 1.0 -- inherit snmpNotifyEntry
vb3.value(OID) = 0.1.114.111.119.50 -- "row2"
vb4.name = 0.1.5 -- snmpNotifyRowStatus -- RowIdentifier
vb4.value = NULL vb4.name = 0.0 -- inherit snmpNotifyTable
vb4.value = 1.0.114.111.119.50 -- "row2"
vb5.name = 0.1.999 -- doesn't exist, but try anyway vb5.name = 0.5 -- snmpNotifyRowStatus
vb5.value = NULL vb5.value = NULL
-- rowOp 3 -- must use the 0.1.X OID form because 999 > 39
vb6.name = 0.1.999 -- Should result in NoSuchObject
vb6.value = NULL
)
-- rowIdentifier (table and instance) ResponsePdu
vb6.name = 1.0 -- inherit snmpNotifyEntry (
vb6.value(OID) = 0.1.114.111.119.50 -- "row2" request-id = 5
error-status = noError
-- omitting all operands indicates "get all" row objects. -- RowOp 1
-- RowIdentifier
vb1.name = 0.0.6.3.13.1.1.1 -- snmpNotifyTable
vb1.value = 1.0.114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value = "tag1"
vb3.name = 0.3 -- snmpNotifyType
vb3.value = 1 -- trap
-- RowOp 2
-- RowIdentifier
vb4.name = 0.0 -- inherit snmpNotifyTable
vb4.value = 1.0.114.111.119.50 -- "row2"
vb5.name = 0.5 -- snmpNotifyRowStatus
vb5.value = NotInService
vb6.name = 0.1.999
vb6.value = NoSuchObject
) )
This GetRow request includes one Singleton using prefix-level
inheritance to retrieve the sysUpTime value along with one RowOp.
GetRow
(
request-id = 6
non-repeaters = 1 -- 1 Singleton
max-repetitions = 0
-- Singletons
vb1.name = 0.0.2.1.1.3.0 -- get(sysUpTime.0)
vb1.value = NULL
-- RowOp 1
-- RowIdentifier
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.114.111.119.49 -- "row1"
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = NULL
vb4.name = 0.3 -- snmpNotifyType
vb4.value = NULL
}
ResponsePdu ResponsePdu
( (
-- rowOp 1 request-id = 6
error-status = noError
-- rowIdentifier (table and instance) -- Singletons
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 -- Singleton 1. The original request
vb2.value(snmpTagValue) = "tag1" -- contained non-repeaters = 1. This
-- count is not transmitted back in the
-- response, so the originating command generator
-- must maintain this count and associate it
-- to the returned request-id.
vb1.name = 0.0.2.1.1.3.0 -- sysUpTime.0
vb1.value = 123456
-- rowOp 2 -- RowOp 1
-- rowIdentifier (table and instance) -- RowIdentifier
vb3.name = 1.0 -- inherit snmpNotifyEntry vb2.name = 0.0.6.3.13.1.1.1 -- snmpNotifyTable
vb3.value(OID) = 0.1.114.111.119.50 -- "row2" vb2.value = 1.0.114.111.119.49 -- "row1"
vb4.name = 0.1.5 -- snmpNotifyRowStatus vb3.name = 0.2 -- snmpNotifyTag
vb4.value(RowStatus) = NotInService vb3.value = "tag1"
vb5.name = 0.1.999 -- doesn't exist vb4.name = 0.3 -- snmpNotifyType
vb5.value(int) = NoSuchObject vb4.value = 1 -- trap
)
-- rowOp 3 B.4. GetNextRow
-- rowIdentifier (table and instance) This is an example of a protocol exchange for a GetNextRow request
vb6.name = 1.0 -- inherit snmpNotifyEntry and its response.
vb6.value(OID) = 0.1.114.111.119.50 -- "row2"
vb7.name = 0.1.2 -- snmpNotifyTag GetNextRow
vb7.value(SnmpTagValue) = "" (
request-id = 7
non-repeaters = 1 -- 1 Singleton
max-repetitions = 0
vb8.name = 0.1.3 -- snmpNotifyType -- Singletons
vb8.value(INT) = 1 -- trap
vb9.name = 0.1.4 -- snmpNotifyStorageType vb1.name = 0.0.2.1.1.3 -- getNext(sysUpTime)
vb9.value(StorageType) = nonVolatile vb1.value = NULL
vb10.name = 0.1.5 -- snmpNotifyRowStatus -- RowOp 1
vb10.value(RowStatus) = NotInService
-- RowIdentifier
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.114.111.119 -- "row" (partial instance)
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = NULL
vb4.name = 0.3 -- snmpNotifyType
vb4.value = NULL
-- RowOp 2
-- RowIdentifier
vb5.name = 0.0 -- inherit snmpNotifyTable
vb5.value = 1.0
-- No Operands, this RowOp is logically identical
-- to GetNext(snmpNotifyEntry). A bit inefficient
-- since it produces a response RowOp containing
-- only one Operand (would be better as a Singleton)..
) )
D. Known issues ResponsePdu
(
request-id = 7
error-status = noError
This section will be deleted before becoming an RFC. -- Singletons
These are known issues that need to be resolved before going vb1.name = 0.0.2.1.1.3.0 -- sysUpTime.0
standards track: vb1.value = 123457
- Which SNMP message versions can these rowop PDUs be wrapped in? -- RowOp 1
SNMPv3 only?
- It is possible to further optimize the above PDU. For example, -- RowIdentifier
the instancePart of the rowIdentifiers can omit the 0.1 prefix vb2.name = 0.0.6.3.13.1.1.1 -- snmpNotifyTable
if the instancePart contains two or subids whose first two vb2.value = 1.0.114.111.119.49 -- "row1"
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 vb3.name = 0.2 -- snmpNotifyTag
names to begin with the prefix 0.0 as a substitute for 1.3.6.1. vb3.value = "tag1"
This would save a few bytes per rowOp.
- Change the inheritance OID from 1.0 to 0.0? vb4.name = 0.3 -- snmpNotifyType
vb4.value = 1 -- trap
- GetNextRow: Should we disallow use of wildcarding (where no -- RowOp 2
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 -- RowIdentifier
"translatable" into traditional SNMP requests? If so, vb5.name = 0.0 -- inherit snmpNotifyTable
DeleteRow is not translatable, so should it be deleted? vb5.value = 1.0.114.111.119.49 -- "row1"
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
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 vb6.name = 0.2 -- snmpNotifyTag
the values should be something like: Undefined, Unlocked and vb6.value = "tag1"
Locked, and the TC name should be RowLock! )
- Do we need a GetBulkRow request that makes use of similar OID The RowOps in this GetNextRow request are logically the same as a
suppression techniques as defined herein? It might be argued getNext(snmpNotifyEntry), getNext(snmpNotifyTag) and getNext(system).
this would be the most effective use of OID suppression. The fourth RowOp is illegally constructed and would return a genErr
error, because although the RowIdentifier is correctly formed, in
this case it contains an Instance without at least one Operand, and
without an Operand it is impossible to decide which table object the
getNext should be performed on. Note that it would be more efficient
to instead provide these types of RowOps as individual Singletons.
GetNextRow
(
request-id = 8
non-repeaters = 0 -- 0 Singletons
max-repetitions = 0
-- RowOp 1, same as getNext(snmpNotifyEntry)
-- RowIdentifier
vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0
-- RowOp 2, same as getNext(snmpNotifyTag)
-- RowIdentifier
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = NULL
-- RowOp 3, same as getNext(system)
-- RowIdentifier
vb4.name = 0.0.2.1.1 -- system
vb4.value = 0.0 -- not a table
-- RowOp 4, same as getNext(snmpNotifyEntry)
-- RowIdentifier (missing Operand produces genErr)
vb5.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb5.value = 1.0.114.111.119.49 -- "row1"
}
B.5. GetBulkRow
This GetBulkRow request includes one Singleton using prefix-level
inheritance to retrieve the sysUpTime value along with two RowOps.
Though both of the RowOps in this request are legal, note that RowOp2
returns a subset of RowOp1's desired values. Therefore, RowOp2 could
be omitted without affecting the response.
GetBulkRow
(
request-id = 9
non-repeaters = 1 -- 1 Singleton
max-repetitions = 0 -- head/tail disabled
-- Singletons
vb1.name = 0.0.2.1.1.3 -- getNext(sysUpTime)
vb1.value = NULL
-- RowOp 1
-- RowIdentifier
-- Retreive all snmpNotifyTags and
-- RowStatus objects from
-- row1 to end of table (Instance2 not provided).
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.4.114.111.119.49 -- "row1"
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = NULL
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value = NULL
-- RowOp 2
-- RowIdentifier
-- Retreive all snmpNotifyTags and
-- RowStatus objects from
-- row1 to row3 (inclusive)
vb5.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb5.value = 1.0.4.114.111.119.49.114.111.119.51
vb6.name = 0.2 -- snmpNotifyTag
vb6.value = NULL
vb7.name = 0.5 -- snmpNotifyRowStatus
vb7.value = NULL
}
ResponsePdu
(
request-id = 9
error-status = noError
-- Singletons
vb1.name = 0.0.2.1.1.3.0 -- sysUpTime.0
vb1.value = 123458
-- RowOp 1
-- RowIdentifier
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.4.114.111.119.49 -- "row1"
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = "tag1"
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value = Active
-- RowOp 2
-- RowIdentifier
vb5.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb5.value = 1.0.4.114.111.119.50 -- "row2"
vb6.name = 0.2 -- snmpNotifyTag
vb6.value = "tag2"
vb7.name = 0.5 -- snmpNotifyRowStatus
vb7.value = Active
-- RowOp 3
-- RowIdentifier
vb8.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb8.value = 1.0.4.114.111.119.51 -- "row3"
vb9.name = 0.2 -- snmpNotifyTag
vb9.value = "tag3"
vb10.name = 0.5 -- snmpNotifyRowStatus
vb10.value = Active
-- RowOp 4
-- RowIdentifier
vb11.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb11.value = 1.0.4.114.111.119.52 -- "row4"
vb12.name = 0.2 -- snmpNotifyTag
vb12.value = "tag4"
vb13.name = 0.5 -- snmpNotifyRowStatus
vb13.value = Active
-- RowOp 5
-- RowIdentifier
vb14.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb14.value = 1.0.4.114.111.119.53 -- "row5"
vb15.name = 0.2 -- snmpNotifyTag
vb15.value = "tag5"
vb16.name = 0.5 -- snmpNotifyRowStatus
vb16.value = Active
}
This GetBulkRow request is the same as the previous example except
that RowOp2 specifies a column not included in RowOp1. The response
would be identical to the above response except that RowOps1-3 (row
1-3) would include a Operand/value for snmpNotifyType.
GetBulkRow
(
request-id = 10
non-repeaters = 1 -- 1 Singleton
max-repetitions = 0 -- head/tail disabled
-- Singletons
vb1.name = 0.0.2.1.1.3 -- getNext(sysUpTime)
vb1.value = NULL
-- RowOp 1
-- RowIdentifier
-- Retreive all snmpNotifyTags and
-- RowStatus objects from
-- row1 to end of table (Instance2 not provided).
vb2.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb2.value = 1.0.4.114.111.119.49 -- "row1"
vb3.name = 0.2 -- snmpNotifyTag
vb3.value = NULL
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value = NULL
-- RowOp 2
-- RowIdentifier
-- Retreive all snmpNotifyTypes and
-- RowStatus objects from
-- row1 to row3 (inclusive)
vb5.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb5.value = 1.0.4.114.111.119.49.114.111.119.51
vb6.name = 0.3 -- snmpNotifyType
vb6.value = NULL
vb7.name = 0.5 -- snmpNotifyRowStatus
vb7.value = NULL
}
This GetBulkRow request includes two RowOps to show how to perform a
head and tail function, respectively.
In RowOp1 (head function), the search range is indicated by the OID
1.0.0 (no Instance or Instance2 values provided). That value along
with a non-zero max-reps value indicates a head function with a
possible search range of the entire table.
In RowOp2 (tail function), the search range is indicated by the the
OID 1.0 (no InstanceLen, Instance or Instance2 values provided). That
value along with a non-zero max-reps value indicates a tail function
with a possible search range of the entire table.
The Response indicates the desired objects in the first and last two
rows of the table are returned (five rows in table, so row3 is not
returned).
Note that if max-reps were instead 0, the two RowOps would be
logically identical.
GetBulkRow
(
request-id = 11
non-repeaters = 0 -- 0 Singletons
max-repetitions = 2 -- head/tail enabled
-- RowOp 1
-- RowIdentifier
vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.0 -- head search entire table
vb2.name = 0.2 -- snmpNotifyTag
vb2.value = NULL
vb3.name = 0.5 -- snmpNotifyRowStatus
vb3.value = NULL
-- RowOp 2
-- RowIdentifier
vb4.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb4.value = 1.0 -- tail search entire table
vb5.name = 0.2 -- snmpNotifyTag
vb5.value = NULL
vb6.name = 0.5 -- snmpNotifyRowStatus
vb6.value = NULL
}
ResponsePdu
(
request-id = 11
error-status = noError
-- RowOp 1
-- RowIdentifier
vb1.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb1.value = 1.0.4.114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value = "tag1"
vb3.name = 0.5 -- snmpNotifyRowStatus
vb3.value = Active
-- RowOp 2
-- RowIdentifier
vb4.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb4.value = 1.0.4.114.111.119.50 -- "row2"
vb5.name = 0.2 -- snmpNotifyTag
vb5.value = "tag2"
vb6.name = 0.5 -- snmpNotifyRowStatus
vb6.value = Active
-- RowOp 3
-- RowIdentifier
vb7.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb7.value = 1.0.4.114.111.119.52 -- "row4"
vb8.name = 0.2 -- snmpNotifyTag
vb8.value = "tag4"
vb9.name = 0.5 -- snmpNotifyRowStatus
vb9.value = Active
-- RowOp 4
-- RowIdentifier
vb10.name = 0.0.6.3.13.1.1 -- snmpNotifyTable
vb10.value = 1.0.4.114.111.119.53 -- "row5"
vb11.name = 0.2 -- snmpNotifyTag
vb11.value = "tag5"
vb12.name = 0.5 -- snmpNotifyRowStatus
vb12.value = Active
}
This GetBulkRow requests data from two columns of the same table. The
response shows RowOps and Singletons interspersed with one another
(i.e. rows with only one object to return cause Singletons to be
returned instead of RowOps, which be definitions MUST have two or
more Operands in GetBulkRow responses). Although this example uses a
shorthand notation (i.e. fooTable), the actual OIDs would utilize OID
inheritance wherever possible. Also note that row3 did not produce a
result.
GetBulkRow
(
request-id = 12
non-repeaters = 0 -- 0 Singletons
max-repetitions = 0 -- head/tail disabled
-- RowOp 1
-- RowIdentifier
vb1.name = fooTable
vb1.value = 1.0 -- search entire table
vb2.name = 0.2 -- fooColumnA
vb2.value = NULL
vb3.name = 0.3 -- fooColumnB
vb3.value = NULL
}
ResponsePdu
(
request-id = 12
error-status = noError
-- RowOp 1
-- RowIdentifier
vb1.name = fooTable
vb1.value = 1.0.1 -- row 1
vb2.name = 0.2 -- fooColumnA
vb2.value = 1
vb3.name = 0.3 -- fooColumnB
vb3.value = 1
-- Singleton 1
vb4.name = fooColumnA.2 -- row 2
vb4.value = 2
-- Singleton 2
vb5.name = fooColumnB.3 -- row 4
vb5.value = 4
-- RowOp 2
-- RowIdentifier
vb6.name = fooTable
vb6.value = 1.0.5 -- row 5
vb7.name = 0.2 -- fooColumnA
vb7.value = 5
vb8.name = 0.3 -- fooColumnB
vb8.value = 5
-- Singleton 3
vb9.name = fooColumnA.6 -- row 6
vb9.value = 6
}
B.6. EditRow
This EditRow hypothetically produces the shown response which
indicates several errors: first, varbind 2 caused a wrongValue error,
secondly, varbind 2 also caused an application specific error 11
(perhaps tooManySlicesInserted), and finally, varbinds 3 and 6 both
caused yet another application specific error 14 (perhaps
tempTooHigh). Additionally, the returned Operand values are set to
NULL to indicate the third-phase (get) was not executed (due to
test-phase failure).
EditRow
(
request-id = 13
non-repeaters = 0 -- no Singletons
max-repetitions = 0
-- RowOp 1
-- RowIdentifier
vb1.name = toasterTable
vb1.value = 1.0.1 -- toaster/row "1"
vb2.name = 0.2 -- toasterSlicesInserted
vb2.value = 100
vb3.name = 0.3 -- toasterTemp
vb3.value = 1000
-- RowOp 2
-- RowIdentifier
vb4.name = toasterTable
vb4.value = 1.0.2 -- toaster/row "2"
vb5.name = 0.2 -- toasterSlicesInserted
vb5.value = 2
vb6.name = 0.3 -- toasterTemp
vb6.value = 1000
}
ResponsePdu
(
request-id = 13
error-status = 10 (wrongValue)
error-index = 2
-- RowOp 1
-- RowIdentifier
vb1.name = toasterTable
vb1.value = 1.0.1 -- toaster/row "1"
vb2.name = 0.2 -- toasterSlicesInserted
vb2.value = NULL
vb3.name = 0.3 -- toasterTemp
vb3.value = NULL
-- RowOp 2
-- RowIdentifier
vb4.name = toasterTable
vb4.value = 1.0.2 -- toaster/row "2"
vb5.name = 0.2 -- toasterSlicesInserted
vb5.value = NULL
vb6.name = 0.3 -- toasterTemp
vb6.value = NULL
-- Extended errors:
vb7.name = 0.0.0.11.2.0.14.3.6
vb7.value = NULL
}
C. Known issues
This section will be deleted before becoming an RFC.
These are known issues that need to be resolved before going
standards track:
- Should the coexistence and transition section be moved to a - Should the coexistence and transition section be moved to a
different document? different document?
- Should we remove the comments about the timeout issues with - Need to specify a way for extended error codes to be mapped to
RowStatus from the meat of the document? meaningful error messages. Perhaps IANA would maintain an
IANAExtendedErrorCodes textual-convention (along the lines of
IANAIfType) and all extended error codes would thus be
controlled via IANA. Also, a small range of the codes may need
to be reserved up-front for use by the IETF so that the
standard SNMP error-status codes and varbind-level exceptions
can also be mapped to extended code values. For example, we
may want to return "tooBig" in the case where a successful
GetBulkRow response is returned with only a portion of the
requested data. The tooBig extended error is a "more" signal
to perform at least one more GetBulkRow (using the Instance in
the last RowOp as a beginnning search range).
E. Full Copyright Statement - What other extended error codes should be reserved and defined
up front? For example, perhaps an "unsupportedOperation" needs
to be defined so that the EOS requests could return that error
on a RowOp by RowOp basis (where a given subagent is non-EOS
capable and others are). In such cases, incrementing the
droppedPdu counter may not be possible.
- How can SetRequests and/or EditRows be used to safely create
rows in tables using RowState in multi-mgr environments? It
would be ideal to have such a mechanism (without re-creating
RowStatus all over again) in order to ease the transition to
EOS-capable networks.
- Should this document contain procedures to translate EOS
operations to/from conventional operations?
- Should the MIB defs in this document (and all other EOS
documents) instead be located in one EOS document? This could
reduce the number of modules needed to be IMPORTED in future
MIBs/appls.
D. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 198 change blocks. 
658 lines changed or deleted 1631 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/