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