INTERNET-DRAFT                                                 L. Heintz
                                                     Cisco Systems, Inc.

                     SNMP Row Operations Extensions

                  <draft-ietf-eos-snmp-rowops-00.txt>

                  <draft-ietf-eos-snmp-rowops-01.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.
   [RFC2571].  These extensions provide mechanisms for efficient
   creation, modification, deletion and retrieval of table
   rows. rows and
   other information.

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
   3. The Extensions ..............................................    6
   3.1. RowState ..................................................    6    7
   3.2. Row Protocol Operations ............................................    8
   3.2.1. The rowIdentifier .......................................    9    7
   3.2.1. Singletons ..............................................    8
   3.2.2. The operands ............................................   12 RowOp ...............................................    9
   3.2.3. Distinguishing rowIdentifiers from operands .............   13 The RowIdentifier .......................................   10
   3.2.4. RowState and RowStatus Considerations RowIdentifiers in GetBulkRow Requests ...................   13   11
   3.2.5. Granularity of Success/Fail .............................   14 RowIdentifier Inheritance ...............................   12
   3.2.6. The Operands ............................................   13
   3.2.7. Extended Error Codes ....................................   14
   3.2.8. RowOps and Group Scalar Objects.  .......................   16
   3.2.9. Three-Phase Sets ........................................   17
   3.2.10. Response PDUs ...........................................   14 ..........................................   17
   3.2.11. Determining Varbind Roles ..............................   18
   4. Elements of Procedure .......................................   14   19
   4.1. CreateRow Request Processing ..............................   14   19
   4.2. DeleteRow Request Processing ..............................   14   19
   4.3. EditRow Request Processing ................................   15   19
   4.4. GetRow Request Processing .................................   15   19
   4.5. GetNextRow Request Processing .............................   15   19
   4.6. GetBulkRow Request Processing .............................   20
   4.7. Response-PDU Processing ...................................   15   20
   5. Coexistence and Transition ..................................   15   20
   6. Protocol Operations Definitions .............................   17   21
   7. Managed Object Definitions ..................................   18   22
   8. IANA Considerations .........................................   19   26
   9. Intellectual Property .......................................   19   26
   10. Acknowledgements ...........................................   19   27
   11. Security Considerations ....................................   20   27
   12. References .................................................   20   27
   13. Editor's Addresses .........................................   23   30
   A. Impact to SNMP and other Protocols ..........................   24   31
   A.1. SNMPv3 ....................................................   24   31
   A.2. AgentX ....................................................   24   31
   B. Alternative Approaches ......................................   24
   C. Examples of Row Operations ..................................   25
   C.1. CreateRow with RowStatus ..................................   25
   C.2.   31
   B.1. CreateRow with RowState ...................................   26
   C.3. .................................................   31
   B.2. DeleteRow .................................................   27
   C.4.   35
   B.3. GetRow and ....................................................   36
   B.4. GetNextRow .....................................   28
   D. ................................................   39
   B.5. GetBulkRow ................................................   41
   B.6. EditRow ...................................................   48
   C. Known issues ................................................   29
   E.   50
   D. Full Copyright Statement ....................................   31   51

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
   MIB.

2.  Overview

   This document describes a set of SNMP extensions to current protocol
   operations [RFC1905] to provide for efficient row management operations
   (i.e. creating, modifying, deleting and retrieving table rows). rows and
   other MIB data).  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 six 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 RowOp refers to the component aggregate
   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 large amounts of
   information.  The extensions described in this document are
   specifically designed to minimize, or provide opportunities to minimize
   minimize, the following problems which inhibit th the effectiveness of
   SNMP:

      -  Requests that contains contain 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 independent decisions as to which
         varbind
         value will effectively be used as the final result. used.

      -  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 set request 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 kind and nature of
   extensions that were needed:

      -  allow separate row operations (hereafter referred to as rowOps) RowOps)
         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
         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.

      -  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

   Six 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 GetNextRow), and
   GetBulkRowRequest-PDU (aka GetBulkRow). These requests are based on
   the same PDU 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
   and EditRow are more generically referred to as SetRow class
   requests, while GetRow and GetRow, GetNextRow and GetBulkRow are referred to as
   RetrieveRow class requests.

   In addition, a RowState textual convention is defined and is intended
   to replace

   The CreateRow request can only succeed if it is used to create an
   aggregate (e.g. row) that doesn't already exist. EditRow has no such
   constraints and can be used much in the same way traditional
   SetRequests are used. One noteworthy feature of the GetBulkRow
   request is that it can perform head and/or tail functions on a table.
   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. Although RowState is not a protocol
   operation, it does serve
   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

   As mentioned earlier,

   The RowState textual convention defined in this document defines a proposed textual
   convention, RowState, whose purpose is intended
   to replace RowStatus in future
   MIBs.  This convention new MIBs and 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
         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, CreateAndWait,
   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 usually
   unnecessary to directly set or reference a RowState instance in order
   to create and activate a new row.

3.2.  Protocol Operations

   The initial state of RowState is
   determined at the moment of initial row creation according new protocol operations are designed to "fit" in the
   semantics specified by existing
   BulkPDU structure [RFC1905]. Formal definitions of the MIB designer (as new protocol
   operations are provided within in section 6.

   This document specifies an evolutionary approach in the
   Description clause of way the RowState object, new
   protocol operations are encoded or contained within the BulkPDU. The
   new requests capitalize on OID suppression techniques to minimize
   information redundancy and much therefore minimize PDU size. Note that the
   traditional SNMP protocol operations [RFC1905] are not being changed,
   either in their semantics, the same way
   that RowStatus descriptions customize data is encoded within them, or
   the semantics of those
   objects). At way they are processed.

   The following general discussion centers on how the time varbinds of row creation, the row creator may explicitly
   set the RowState object to a desired initial value, but
   new protocol operations and their responses are constructed and
   generally used. The elements of procedure formally describes how the
   processing entity refers to this as a kind
   new requests are processed and how the responses are constructed. The
   APPENDIX provides high-level examples of "hint" since protocol exchanges using the final
   decision
   extensions.

   Each varbind in a request serves one of three purposes: as to a
   Singleton, as a RowIdentifier or as an Operand.

3.2.1.  Singletons

   A varbind that serves as a Singleton functions more or less like
   varbinds in a traditional SNMP request (e.g. SetRequest, GetRequest).
   They are encoded in the initial value can only same manner, and except for prefix-level
   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 determined after the
   complete row contents within first N varbinds in the creation operation have been
   evaluated.

   One request, where N is
   provided in the non-repeaters field of the other differences between RowState and RowStatus is that
   RowState objects can never request. N may be automatically deleted from zero to
   indicate that Singletons have not been included in the entity
   as a result of timeouts when their states request.  If N
   Singletons are either NotInService or
   Active. This provides included in a request, then the ability to use RowState objects same N Singletons will
   also exist in the response, although in a successful response to
   indefinitely take a row out
   GetBulkRow request, additional Singletons may also be present.

   The set of service without Singletons contained in a request SHOULD be ordered so
   that the fear name of it being
   automatically deleted. When and whether rows containing RowState
   objects are added to, Singleton i is lexicographically smaller than
   Singleton i+1, though SNMP applications MUST be prepared to accept
   unordered Singletons.

   Singletons may be included within a CreateRow or removed from, non-volatile storage are not
   addressed by RowState. a DeleteRow request.
   Such behavior must be specified by other
   means Singletons indicate a specific object instance within an
   aggregate (e.g. StorageType), a row or a group scalar) upon which a creation or
   deletion operation is out of scope for this document.

   In addition, unlike RowStatus, it is permissible 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 explicitly set
   RowState whether only the directly referenced objects to in the NotReady state as a crude means
   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 allowing
   traditional SetRequests to delete the row. In this case, deletion
   occurs as protocol exchange examples in the
   APPENDIX illustrates such a side effect of case).

   Within any EditRow class request, Singletons function much like
   individual varbinds within a row timeout. As will be shown, conventional SetRequest, and the
   preferred method name of deleting
   any row is via use of the new DeleteRow
   request, which does not contain Singleton MUST NOT refer to any direct reference other Singleton or to any specific
   row
   existing (or not) object (such as RowState).

   The CreateRow request introduces within any RowOp of the ability to set either RowStatus
   or RowState objects without same EditRow
   request.

   Within the need to explicitly include GetRow request, Singletons function much like individual
   varbinds within a varbind
   in conventional GetRequest.

   Within the request. A CreateRow request by convention contains an
   implicit operand (i.e. varbind) to set GetNextRow request, Singletons function much like
   individual varbinds within a corresponding RowState
   object (if any) to conventional GetNextRequest.

   Within the Active value. This implicit varbind can be
   overridden by GetBulkRow request, Singletons function much like the inclusion of an actual RowState varbind. For
   example,
   non-repeaters varbinds in the following two CreateRow requests are logically
   identical, conventional GetBulk request; thus,
   they function 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 GetNextRequest varbinds.

   The new protocol operations are designed to "fit" remaining varbinds in the existing PDU
   structure any request form one or more independent
   RowOps with each varbind serving as originally defined in [RFC1905]. One of the alternative
   approaches discussed in the Appendix is the possibility either a RowIdentifier or as an
   Operand component of defining a RowOp.

3.2.2.  The RowOp

   The new PDU structure that requests defined in this document may generally contain zero
   or more RowOps. This allows a more efficient OID suppression
   strategy than the single CreateRow request, for example,
   to create one described herein. However, the initial approach
   offered or more new rows in intended to "look and feel" as close a single protocol operation. Each
   RowOp corresponds to the current
   framework as possible. As will be shown, the current PDU structure is
   quite sufficient one attempt to obtain significant (but not optimal) OID
   suppression benefits.

   Formal definitions of the new protocol operations are provided create a row, 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 case, or contained within the PDU. As such, the new
   requests capitalize on OID suppression techniques
   corresponds to minimize
   information redundancy one attempt to delete a row in the case of DeleteRow,
   and therefore minimize PDU size. so forth.

   Note that the
   traditional SNMP protocol operations as defined three layers 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 the diagram below do not describe
   different sections of the PDU, request, rather, they each represent the
   same information and structure (at different levels of abstraction).

      <CreateRow.............>
      <rowOp1><rowOp2><rowOp3>
      <RowOp1><RowOp2><RowOp3>
      <vb><vb><vb><vb><vb><vb>

   Although the above diagram shows a CreateRow request logically
   containing three rowOps RowOps (i.e. create three rows) with two consecutive
   varbinds per rowOp, RowOp, in reality, these requests may contain one, two,
   or more than two rowOps, zero to
   many 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 varbinds.

   The first varbind in each rowOp provides basic request parameters,
   and RowOp is hereafter referred to as the rowIdentifier parameter
   RowIdentifier of a
   rowOp. RowOp. The remaining varbinds in a given rowOp RowOp
   provide the individual operands (i.e. the affected row objects),
   which are hereafter referred to as operands. Operands. In the diagram above,
   the 1st, 3rd and 5th varbinds are therefore rowIdentifiers while RowIdentifiers and the
   2nd, 4th and 6th varbinds are operands. Operands.

3.2.3.  The RowIdentifier

   The following diagram shows a GetRow request containing a single
   rowOp
   RowOp that itself is composed of the required rowIdentifier RowIdentifier and two
   operands.

      <GetRow.......................................>
      <rowOp........................................>
      <vb1-rowIdentifier><vb2-operand1><vb3-operand2>
   Operands.  In this case, the GetRow request is seeking to retrieve
   two specific column objects from a specific row.

   To understand how each rowIdentifier varbind is constructed and what
   information is contained therein, it is useful to consider how OIDs
   for table objects are formed.

   An

      <GetRow.......................................>
      <RowOp........................................>
      <vb1-RowIdentifier><vb2-Operand1><vb3-Operand2>

   A traditional OID for a given object instance in a table can be
   broken up into
   three these logical components:

      OID = <tableEntryPart><columnPart><instancePart>

   If a traditional SetRequest contains two varbinds referring to two
   different columns in the same row, it <TableName><1><ObjectSubid><Instance>

   ObjectSubid is evident that both OIDs
   differ only in the integer value equivalent to one 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. column descriptors.  A more meaningful
   formal representation for rowIdentifier RowIdentifier is now possible:

      rowIdentifier

      RowIdentifier = <vb.name=tableEntryPart, <vb.name=AggName,
                       vb.type=OID,
                       vb.value=0.1.instancePart>
                       vb.value=1.0.Instance>

   The component, AggName (Aggregate Name), takes the same value of
   TableName.

   The vb.type MUST specify a type of OID.  This is because the
   instancePart instance
   part 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 of which resolves to one or more subids.

   Because the instancePart Instance always resolves to one zero or more subids, 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, we
   prefix the instancePart
   Instance is prefixed with the OID value of 0.1. 1.0. The reason
   instancePart cannot simply be prefixed with a single subid for this
   choice of prefixes is that
   OIDs 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 form 0.X, where X > 39, are not legal. Thus, if
   instancePart resolved AggName MUST always exactly correspond to a single subid of 40 (or greater), the value
   of 0.40 would be illegal. Thus legal
   table definition (if the need desired results are to prefix instancePart with
   two subids be achieved). The
   motivation behind this is that guarantee all RowOps are performed at the row
   level on a valid OID will specific table.

   The Instance within a GetNextRow is not required to be fully formed regardless of
   how instancePart
   except that if the value is resolved.  Note non-NULL, it MUST at least contain the
   1.0 prefix. Also note that due GetNextRow RowOps do not "jump" to ASN.1/BER encoding
   rules, the first two subids comprise only a single byte within the
   PDU.

   The rowIdentifier of each rowOp
   next table.  In other words, in the event a SetRow or RetrieveRow request
   specifies GetNextRow RowOp refers
   to the exact last row affected by in a given table, the rowOp (but not which column
   objects are affected in appropriate exception is
   returned for that RowOp even if other tables follow that row).

   Consider contain
   retrievable rows. In this sense, GetNextRow RowOps are limited to
   operate within the case 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.value=1.0.InstanceLen.Instance.Instance2>

   The two instance components define the search range of the GetBulkRow
   request (i.e. the rows from which data may be returned). Unlike the
   traditional GetBulk request, which may operate across one or more rowOps in, say,
   tables and/or scalar objects, each RowOp within a SetRow GetBulkRow request
   that
   is confined to operate only affects within the table specified by the AggName
   component, although each RowOp may operate on different tables.
   Furthermore, each RowOp operates only within the range of rows in as
   specified by the same table. In such cases, two instance components (inclusive) and upon one or
   more columns within that row range, as specified by the varbind names Operands that
   are associated with the RowOp.

   The InstanceLen component specifies the number of all subids that
   comprise Instance. InstanceLen may be 0, which indicates that
   Instance is not provided and that the rowIdentifier varbinds will contain
   identical values. In order to therefore further minimize information
   redundancy, search range begins at the OID
   first row (head) of 1.0 (hereafter referred to as the inheritance
   OID, table and occupying only a single byte within ends with the resulting PDU) is
   permitted row specified by
   Instance2.  Instance or Instance2 need not resolve to existing rows.

   The number of subids in Instance2 may be substituted as 0 or more, and if 0 (i.e.
   Instance2 is not provided), this indicates that the varbind name of search range
   includes any rowIdentifier
   to indicate row that may correspond to the most recent (leftmost) rowIdentifier whose name
   is dissimilar (not 1.0) contains the OID value intended row specified by Instance
   and all those that follow (i.e. to be used.

   In this example, a simplified notation the end of the table).

   If Instance2 is used lexicographically identical to help illustrate how
   a rowOp (the two middle ones in this case) uses Instance, the inheritance OID search
   range is confined to minimize PDU size.  This example shows four rowOps, each comprised
   of one rowIdentifier and the one operand (op):

      [<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><op>]

   The following is logically row common to both instances, or if
   identical values do not resolve to the preceding example (though
   it forms an existing row, a larger PDU):

      [<foo><op>] [<foo><op>] [<foo><op>] [<fum><op>]

   Of course, this implies that rowOps that affect the same table SHOULD NuSuchInstance
   error is returned. If Instance2 is lexicographically smaller than
   Instance, a NoSuchInstance error will be consecutively placed in the PDU varbind list, and also that the
   first rowIdentifier returned.

   The max-repetitions field in the PDU MUST NOT contain the inheritance OID.

   Each rowOp is fully independant of any other despite any inheritance
   it GetBulkRow request may use.

   Each rowOp MUST contain a single rowIdentifier varbind, which MUST
   non-zero value (M) to indicate a head or tail function should be
   the first varbind in
   performed for each rowOp.  The tableEntryPart of a
   rowIdentifier MUST NOT contain partial OIDs.  This means that RowOp in the
   tableEntryPart request. Otherwise, max-repetitions
   MUST always exactly correspond to a legal table entry
   definition (if the desired results are to be achieved). The
   motivation behind this is that zero (for all rowOps are performed at request types). If InstanceLen contains
   the row
   level.

   The instancePart within a GetNextRow value 0 (i.e. Instance is not required to provided), at most M rows will be fully
   formed except that if
   returned from the head of the table. If InstanceLen contains a non-
   zero value (i.e. Instance is non-NULL, it MUST provided), then at most M rows at least contain
   the 0.1 prefix. Also note that GetNextRow requests do not "jump" to the next table.  In other words, in
   tail of the event table will be returned. For a GetNextRow rowOp
   refers head function, all returned
   rows MUST be lexicographically smaller than or equal to the last row in Instance2, if
   provided. For a given table, the appropriate exception is tail function, all returned for that rowOp even rows MUST be
   lexicographically greater than or equal to Instance; and Instance2,
   if other tables follow that contain
   retrievable rows. In this sense, GetNextRow provided, is limited to operate
   within the subtree of the targeted table(s).

3.2.2.  The operands ignored. The remaining varbinds for Instance2 component of a given rowOp are referred to as its
   operands, RowOp,
   therefore, SHOULD NOT be provided in a GetBulkRow request whose max-
   repetitions and InstanceLen values are formed both non-zero as standard SetRequest varbinds except this
   unnecessarily increases PDU size.

   Whether the GetBulkRow request indicates a head or tail function (or
   neither), it should be noted that the name of each varbind is an 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 whose length is exactly three
   subids long. The first two subids MUST be 0.1 slightly more efficient,
   and both forms have the third subid same semantics unless a head or tail function
   is
   taken from indicated (max-repetitions is non-zero). If max-repetitions is
   non-zero and the affected column descriptor value vb.value = 1.0.0, this indicates a head function
   whose object instance search range is affected. The reason three subids are specified (0.1.columnSubid)
   instead of two (0.columnSubid) the entire table. If max-repetitions is that columnSubid must accept all
   values in non-
   zero and the vb.value = 1.0, this indicates a tail function whose
   search range from 0 is the entire table.

3.2.5.  RowIdentifier Inheritance

   Several forms of OID inheritance are possible within RowIdentifiers
   in order to 4294967295. However, further minimize PDU size: name-level, prefix-level, and
   instance-level inheritance.

   In order to further minimize information redundancy, 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 0.0
   is small) will permitted to be comprised substituted as the AggName component of only two bytes despite the fact any
   RowIdentifier to indicate 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 most recent (left) RowIdentifier
   whose AggName is dissimilar (not 0.0) contains the name
   of varbind N+1. OID value intended
   to be used.

   In other words, there is this example, a left simplified notation is used to right ordering
   relationship imposed on help illustrate how
   RowOps (the two middle ones) use the rowOp operands inheritance OID to further provide
   implementation optimization opportunities minimize PDU
   size.  This example shows four RowOps, each comprised of one
   RowIdentifier and one Operand (op):

      [<foo><op>] [<0.0><op>] [<0.0><op>] [<fum><op>]

   The following is logically identical, though it forms a larger PDU:

      [<foo><op>] [<foo><op>] [<foo><op>] [<fum><op>]
   In order for an inheritance OID to further guarantee be correctly used, all RowOps that multiple and possibly conflicting operands for
   affect the same column
   object cannot table MUST be provided (further minimizes information redundancy
   and processing ambiguity).  For example, consecutively placed in the operand with varbind
   list, and also the name
   of, 0.1.0, first such RowIdentifier MUST be to NOT contain the left
   inheritance OID. The above is known as name-level inheritance.

   If a RowIdentifier of any request type has a NULL varbind value, this
   indicates that the operand with most recent non-NULL varbind value is to be
   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.

   The third form of inheritance (prefix-level inheritance) occurs
   whenever the varbind name of,
   0.1.1, if they are operands of any AggName of a RowIdentifier begins
   with the same rowOp.

   Any rowOp may contain zero OID prefix of 0.0 AND four or more operands, except that subids exist in the EditRow
   request MUST contain at least one operand. OID.
   In case such cases, the OID value of RetrieveRow requests, if zero operands are provided 1.3.6.1 is to be substituted in a
   rowOp, this implicitly calls for place
   of 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 0.0 prefix.

   The example below shows two RowOps, each comprised of the
   affected tables must have a MAX-ACCESS of read-create one
   RowIdentifier 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
   object whose value is being changed one Operand (op). Name- and whose MAX-ACCESS is either
   read-create or read-write. prefix-level
   inheritance are used:

      [<0.0.foo><op>] [<0.0><op>]

   The affected rows MUST already exist (in
   whole or part), following is logically identical, 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 forms a larger PDU:

      [<1.3.6.1.foo><op>] [<1.3.6.1.foo><op>]

   The following OID is not
   essential that operands be included in a DeleteRow request, they 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
   in special cases be useful, use.

3.2.6.  The Operands

   The remaining varbinds for example, when a proxy application
   translates a DeleteRow request given RowOp are referred to a conventional SetRequest as its
   Operands and are formed as standard request varbinds except that
   requires a RowStatus reference.

3.2.3.  Distinguishing rowIdentifiers from operands

   As described earlier, the varbinds in a rowOp function
   name of each varbind is an OID whose length is either as a
   rowIdentifier (one per rowOp) two or three
   subids long, as an operand (zero follows:

     0.ObjectSubid (where ObjectSubid > 0 and ObjectSubid <= 39)

   or more per
   rowOp). By definition, the first varbind in any SetRow

     0.1.ObjectSubid (where ObjectSubid == 0 or RetrieveRow
   request MUST ObjectSubid > 39)

   Each Operand contained in the same RowOp SHOULD be a rowIdentifier.  The varbind names of all
   rowIdentifiers are guaranteed ordered according
   to be OIDs with a minimum ascending values of the ObjectSubids.

   By way of example, if a table, foo, had four
   subids (because current SMIv2 rules columns whose
   descriptors (ObjectSubids) were 0, 1, 39 and current IANA object
   registrations preclude the possibility that table entry definitions
   can have shorter OIDs). One exception to this, is that varbind 40, their Operand names
   for rowIdentifiers may contain
   would be 0.1.0, 0.1, 0.39 and 0.1.40, respectively. Because the inheritance OID value of, 1.0 (see
   earlier discussion for how
   majority of MIB object descriptors are between 1 and why this is used).

   The varbind 39, typical
   Operand names of all operands, on will take the other hand, are OID values
   with exactly three subids whose first two subids form an OID of
   0.1.X. 0.X.

3.2.7.  Extended Error Codes

   In summary, if addition to the standard error-status and error-index values in a varbind name contains
   response PDU, and varbind-level exceptions, an OID implementation MAY
   provide application-specific (extended) error indications in any
   response by inserting one new varbind at the end of the form 0.1.X
   (exactly three subids) then varbind list.
   Only the last varbind MAY contain extended error information.

   Extended error information may be included in the PDU whether or not
   other errors/exceptions are indicated in question functions as an
   operand. Otherwise, the response (e.g. error-
   status).

   The name of any varbind functions containing an extended error code is
   constructed as a rowIdentifier.

3.2.4.  RowState and RowStatus Considerations

   It follows:

      0.0.<ErrorInfo><ErrorInfo><...>

   Each ErrorInfo component is worthwhile to note that SetRow class requests allow new MIBs to
   be created without requiring use constructed as follows:

      0.ErrorCode[.<VbList>]

   The ErrorInfo component may repeat multiple times but MUST have at
   least one occurrence.  The leading subid of 0 in 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 ErrorInfo
   component serves as a separator between successive ErrorInfo
   components.

   ErrorCode is useful only to report a value in the current state of range 1..4294967295.

   The optional VbList is one or more subids which indicates a row --
   notwithstanding list of
   varbind positions (one per subid) within the slight anomaly same response PDU that it also allows SetRequests
   and EditRow requests
   associate to explicitly change the state preceding ErrorCode. The subids MUST be a value in
   the range of 1..max-bindings [RFC1905].

   The value component 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 varbind containing an extended error
   information is
   sufficient to omit RowState and RowStatus entirely and instead use always NULL.

   A properly formed varbind name will have a
   MAX-ACCESS prefix of read-create for 0.0.0. This
   prefix allows EOS-enabled SNMP applications to distinguish these
   varbinds from all writable objects.  Such tables can
   elegantly support row creation through use of the CreateRow other varbind types (i.e. Singletons,
   RowIdentifiers or
   traditional SetRequest operations, and also support row deletion
   through use Operands).

   The ErrorCode of 3 in the DeleteRow operation.

3.2.5.  Granularity of Success/Fail

   In following example indicates the event a SetRow class request contains two or more rowOps 4th and 5th
   varbinds raised that
   affect the error.

      vb.name = 0.0.0.3.4.5
      vb.name = NULL

   The same row, the elements varbinds MAY be associated to one or more extended error
   codes. The following example indicates an error code of procedure (below) indicate 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
   all rowOps does not have a VbList
   (e.g. 5 in the SetRow request are above example) maps to be rejected (i.e. 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 rowOps
   fail returned errors and exceptions indicated within a
   Request-PDU is comprised of the entity remains error indicated in error-status (and
   error-index), if any, the state it was in prior to receiving extended errors codes, if any, and 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
   exceptions present in any new response PDU.  Instead, the
   traditional Response-PDU [RFC1905] varbind, if any. Each error and/or
   exception is used as the standard response
   to each independent of any other.

   An implementation SHOULD NOT provide extended error information if
   the SetRow and RetrieveRow requests, except that the
   varbinds are constructed desired information can instead be adequately conveyed 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

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
   error-status/index fields or varbind-level exceptions. 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
   implementation MAY use extended error codes to efficiently and silently drop these new PDU
   requests.

   Some entities may only support these extensions for certain tables. convey a more detailed
   error status than is otherwise possible using traditional
   error/exception mechanisms. For example, different AgentX subagents may or may not support these
   operations. This requires that the requests fail whenever if a table wrongValue error is
   targeted
   returned for varbind 5, an implementation may also choose to provide
   an extended error value to indicate that cannot support the new operation. provided value was
   "TooLarge".

   The elements presence of
   procedure indictate the proper exceptions extended error codes (or lack thereof) in these cases.

   It is also a response
   does not guarantee all possible that some table implementations may support only
   some subset of the new operations, for example, errors in the RetrieveRow
   requests, but not the SetRow requests. It is herein RECOMMENDED that
   SNMP entities original request have
   been identified (or that support at least one operation within a class
   (i.e. SetRow or RequestRow) for there are no unknown errors). The presense
   of extended error information does not determine success/failure of a given table SHOULD support all
   requests within the same class for that table. Also, it is further
   RECOMMENDED that if
   protocol operation.  Rather, the SetRow class error-status of operations are supported for noError implies a given table, then the entity SHOULD also support
   successful operation, whereas all the
   RetrieveRow operations for that table. For any operation not
   supported by a targeted table (which nevertheless supports other
   operations), error-status values imply
   failure.

   The method used to impart meaning to the elements returned error values is out
   of procedure indicate the proper exceptions
   that apply.

   In an ideal world, the extensions herein would be easily translatable scope to traditional operations.  However, this is not the case.

   Consider, document. See [TBD] for example, that it details.

3.2.8.  RowOps and Group Scalar Objects.

   It is impossible also possible to use the new requests to access or modify
   groups of scalar objects where each RowOp relates to form an equivalent
   SetRequest from a DeleteRow request that contains specific
   group.  The 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 exception to this is needed that GetBulkRow RowOps are
   limited to
   convert operating on tables only (though the rowIdentifier information into Singletons within a valid object (OID)
   reference. DeleteRow
   GetBulkRow may optionally include reference scalar objects).

   To form a RowStatus object, which
   allows such valid RowOp that refers to a translation, but then group, the question arises as following MUST be
   done: First, the AggName instead refers to a valid group OID (e.g.
   the
   need for DeleteRow definitions in system group OID is 1.3.6.1.2.1.1), second, 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) RowIdentifier
   Instance prefix value is translated into
   Set(fooEntry.fooInt.row1=1). Note that an EditRow request containing always provided as 0.0 (instead of 1.0 as
   for tables) and third, there is no Instance provided. The following
   example shows the same varbind info would be translated into relevant OIDs within a RowOp which accesses the exact same Set
   request.  This implies that proxy applications cannot faithfully
   translate these two extensions into
   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 SetRequest with 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 same
   semantics as affected
   scalars MAX-ACCESS values are read-create and the original request. objects do not
   exist.

   A CreateRow request, after
   translation, might incorrectly cause an existing row to DeleteRow request can be modified,
   whereas an used for group scalars if the affected
   scalars MAX-ACCESS values are read-create.

   An EditRow request might cause a new row to can be instantiated.
   A partial workaround is to explicitly include 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 RowStatus reference
   in all CreateRow requests, and 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 ensure that rows do not exist
   before issuing EditRow requests, the above example, though in multi-manager
   environments, this latter procedure suffers.

   The same issues 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 evident when processed using a master agent needs to translate three-phase processing
   model instead of the extensions into traditional subagent PDU forms. Semantics may be
   lost two-phase model defined in the translation, and [RFC1905]. The new
   third phase (retrieve Operand values) occurs only some amount of workaround is
   possible unless if the underlying subagent protocol is itself extended
   to accomodate first phase
   (test) completes successfully.  If 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, test phase results in an
   error, all Operand values in the workarounds that would response will be needed might in some (but not all)
   environments mitigate some set to NULL or
   appropriate errors and exceptions will be returned. Otherwise, all of the benefits
   Operand values in using the new
   extensions in response will contain the first place.

   In short, with value of the approach outlined in this document,
   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 believed
   that non-EOS-capable devices need to be converted into EOS-capable
   devices by means other than simple PDU translation schemes. unavailable. In order the event any Operand refers
   to enable a transition strategy that uses simple PDU translation
   mechanisms, an object which is known to have existed at least some the start of the earlier stated goals first
   phase but not at the start of this
   document would have to be abandoned (e.g. the goal to replace MIB
   objects 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 RowStatus which confuse the notions standard
   response to each of row state with
   row fate, the SetRow and perhaps other goals RetrieveRow requests, except that
   the varbinds are constructed using the same OID suppression
   techniques 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
   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.
                    "
       ::= { 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 described above and, except for allowing command responders to advertise a successful GetBulkRow
   response, the number and type of varbinds (though not necessarily
   their ability names and values) returned are identical 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 original
   request. Any response MAY also contain an additional varbind (the
   last) containing extended error information. The IETF takes no position regarding the validity or scope structure and
   contents of any
   intellectual property or other rights that might be claimed to
   pertain to GetBulkRow responses are a bit more unpredictable.

   Singletons within a GetBulkRow (or any) request always have
   corresponding Singletons in the implementation or use of response (i.e. the technology described first N varbinds
   MAY be Singletons).  The RowOps in
   this document or the extent to which any license under such rights
   might or might 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 available; neither does included only if it represent 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 it
   has made any effort RowOp i is
   lexicographically smaller than or equal to identify any such rights.  Information on the
   IETF's procedures RowOp i+1.  RowOps with respect to rights in standards-track and
   standards-related documentation can
   similar AggName values MUST also be found sub-ordered in BCP-11.  Copies of
   claims of rights made available lexicographically
   ascending order based on their Instance values. Any two returned
   RowOps MUST NOT contain identical AggName and Instance values.

   Similarly, for publication all new Singletons included after varbind N, Singleton
   i MUST be lexicographically smaller than Singleton i+1 and any assurances of
   licenses to they MUST
   be made available, or the result 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 attempt made otherwise successful response to
   obtain a general license or permission for GetBulkRow request ever
   fails to include all the use of such
   proprietary rights by implementors or users of data requested (due to PDU size
   limitations), then the response MAY include an appropriate extended
   error indicating this specification can
   be obtained from fact. In this way, 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 last RowOp (or
   Singleton) in the response contains an Instance that may can be required used to practice
   this standard.  Please address
   calculate the information to beginning search range for a subsequent GetBulkRow
   request.

   SNMP applications which generate GetBulkRow requests MUST preserve
   (i.e. remember) the IETF Executive
   Director.

10.  Acknowledgements value of the non-repeaters field for each request
   where it was non-zero. This document is allows the result of application to easily and
   correctly distinguish the efforts 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 Evolution Of SNMP
   (EOS) Working Group.  Some special thanks are role of every varbind in order
   any given request or response. The following procedure is used to
   correctly identify the
   following EOS WG members:

       TBD

11.  Security Considerations

   TBD

12.  References

   [RFC1155]    Rose, M. and K. McCloghrie, "Structure and
                Identification role 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. a given varbind, V, where V is a value
   in the range (1..max-bindings) in a request or response, and K. McCloghrie, "Concise MIB Definitions",
                STD 16, RFC 1212, March 1991.

   [RFC1901] where N
   = non-repeaters in the associated request.  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., first rule below that
   applies determines the correct role of the varbind.

      -  If V <= N, and B. Wijnen, "An
                Architecture for Describing SNMP Management Frameworks",
                RFC 2571, April 1999.

   [RFC2578]    McCloghrie, K., Perkins, D. N > 0, V is a Singleton.

      -  If V is the last varbind in a Response-PDU, and J. Schoenwaelder,
                "Structure V has a name
         prefixed by the value, 0.0.0, V contains extended error
         information.

      -  If the name of Management Information Version 2 (SMIv2)",
                STD 58, RFC 2578, April 1999.

   [RFC2579]    McCloghrie, K., Perkins, D., V is comprised of exactly two subids 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., this
         name is the value 0.X (where X > 0 and S.
                Waldbusser, "Protocol Operations for X <= 39), V is an
         Operand.

      -  If the Simple Network
                Management Protocol", <draft-ietf-snmpv3-update-proto-
                05.txt>, April 2001.

   [RFC-TMM]    Presuhn, R., Case, J., McCloghrie, K., Rose, M., name of V is comprised of exactly three subids and S.
                Waldbusser, "Transport Mappings for this
         name is the Simple Network
                Management Protocol", <draft-ietf-snmpv3-update-
                transmap-05.txt>, April 2001.

   [RFC-MIB]    Presuhn, R., Case, J., McCloghrie, K., Rose, M. 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 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., varbind V+1
         exists, and B. Wijnen,
                "Coexistence between Version 1, Version 2, varbind V+1 is an Operand, then V is a
         RowIdentifier.

      -  If V is in a successful GetBulkRow response 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, varbind V+1
         exists, and varbind V+1 is NOT an Operand, then V is a transformation format
         Singleton.

      -  Otherwise, V is a Singleton

4.  Elements 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. Procedure

4.1.  CreateRow Request Processing

   TBD

4.2.  DeleteRow Request Processing

   TBD

4.3.  EditRow Request Processing

   TBD

4.4.  GetRow Request Processing

   TBD

4.5.  GetNextRow Request Processing

   TBD

4.6.  GetBulkRow Request Processing

   TBD

4.7.  Response-PDU Processing

   TBD

5.  Coexistence and S. Bradner, "The Organizations Involved Transition

   An essential requirement for these operations is that they must
   operate seamlessly in
                the IETF Standards Process", BCP 11, RFC 2028, October
                1996.

   [RFC2863]    McCloghrie, K. existing networks and F. Kastenholz.  "The Interfaces Group
                MIB."  RFC 2863, June 2000.

   [SNMP-MPD]   Case, J., Harrington, D., Presuhn, R. not disrupt legacy SNMP
   devices.  This is satisfied by the fact that the new protocol
   operations have new and B. Wijnen,
                "Message Processing unique ASN.1 tags, which allow older
   implementations to efficiently and Dispatching silently drop these new 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 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 requests fail whenever a table is
   targeted that cannot support the new operation.  The elements of
   procedure indicate 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 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 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
                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 RetrieveRow
   requests, but not 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 SetRow requests.

   In an ideal world, the Internet-standard Network Management Framework",
                <draft-ietf-snmpv3-coex-v2-00.txt>, 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

APPENDIXES

A.  Impact to SNMP and other Protocols

A.1.  SNMPv3

   An issue remains whether a new message processing model MUST extensions herein would be
   specified as part of the SNMPv3 (or later) standard. Otherwise, it easily translatable
   to traditional operations.  However, this 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 case for the information provided in whatever version-specific message
   wrapper they are contined within) to satisfy
   CreateRow, DeleteRow and GetBulkRow requests. On the abstract service
   interfaces for those components.

   However, these extensions are not compatible with other hand, it
   is believed the SNMPv3 proxy
   application (or any legacy SNMP application incorporating a message
   processing module that receives GetRow, GetNextRow and processes or forwards SNMP
   messages).

A.2.  AgentX

   These extensions imply that AgentX will have EditRow requests can be
   translated into conventional request formats (or subagent
   operations).

   One possible transition strategy is to evolve in order enable existing SNMP
   applications to support GetRow, GetNextRow and EditRow requests (with
   or without the new protocol operations.  For traditional requests). A proxy application, for
   example, AgentX does not
   provide could bridge an EOS network with a delete PDU (to support DeleteRow), and neither does its
   TestSet non-EOS network by
   translating those EOS requests into conventional requests (and
   responses). Similarly, an AgentX master agent could translate this
   same subset of EOS requests into conventional AgentX requests (and
   responses).  The benefits achieved with this strategy would be to
   obtain smaller PDU provide for sizes on the network along with a standard way to indicate whether 100% reuse of
   existing instrumentation methods (and subagent protocols). Subsequent
   support of the
   operation being performed maps to CreateRow, DeleteRow and GetBulkRow requests is always
   possible at a CreateRow future date, or EditRow request.
   Furthermore, master agents will need to know how to recognize and
   process the new on a subagent by subagent basis
   (assuming a compatible subagent 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 has been adopted).

   The procedures to achieving the design goals
   stated earlier.  Several other approaches also exist. Here translate EOS requests into conventional
   operations, where possible, are some
   hints:

      -  Use the same approach described herein except define a out of scope of this document.

   It is RECOMMENDED, however, that new
         "RowPDU" to further optimize OID suppression (i.e. get rid SNMP implementations support
   (for all MIB objects) all of the 0.1.X column subid notation). This may require a new kind RetrieveRow class of varbind list where each varbind requests. It is no longer an OID/value
         pair, but
   further RECOMMENDED that new implementations supporting any of the
   SetRow class of requests instead support all of the SetRow requests
   (for all applicable MIB objects).

   Also, it is an Integer/Value pair. Similarly, this RECOMMENDED that new PDU could contain one or more rowIdentifier items (one per
         rowOp).

      -  Instead of having five new request types, SNMP MIBs SHOULD use the RowState
   textual-convention in lieu of RowStatus, if applicable.

   Proxy applications wishing to fulfill these recommendations can only one instead
   serve as EOS request forwarders for the CreateRow, DeleteRow and perhaps have
   GetBulkRow requests, and as request translators (or forwarders) for
   the other requests.

6.  Protocol Operations Definitions

   SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       BulkPDU
           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

           get-bulk-row-request
               GetBulkRowRequest-PDU
           }

       CreateRowRequest-PDU ::=
           [9]
               IMPLICIT BulkPDU

       DeleteRowRequest-PDU ::=
          [10]
               IMPLICIT BulkPDU

       EditRowRequest-PDU ::=
          [11]
               IMPLICIT BulkPDU

       GetRowRequest-PDU ::=
          [12]
                IMPLICIT BulkPDU

       GetNextRowRequest-PDU ::=
          [13]
               IMPLICIT BulkPDU

       GetBulkRowRequest-PDU ::=
          [14]
               IMPLICIT BulkPDU

   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 "200106151500Z"
       ORGANIZATION "EOS Working Group"
       CONTACT-INFO "WG-EMail:   eos@ops.ietf.org
                     Subscribe:  eos-request@ops.ietf.org

                     Co-Chair:   Dale Francisco
                     EMail:      dfrancisco@acm.org
                     phone:      +1 408-324-1389

                     Co-Chair:   Glenn Waters
                                 Nortel Networks
                     EMail:      gww@nortelnetworks.com

                     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     "200106151500Z"
       DESCRIPTION  "The initial version, published in
                     draft-ietf-eos-snmp-rowops-01.txt.
                    "
       ::= { snmpModules TBD }

   -- Textual Conventions

   RowState ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "
              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 operator within 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

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 for their ideas, efforts and asundry
   contributions:

       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

   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>, June 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-
                transmap-05.txt>, June 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>, June 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>, June 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>, June 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>,
                June 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>, June
                2001.

   [RFC-APPL]   Levi, D., Meyer, P.  and B. Stewart, "SNMP
                Applications", <draft-ietf-snmpv3-apps-v2-00.txt>, June
                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>, June 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

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 may not be fully 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).

   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.

B.  Examples of Row Operations

B.1.  CreateRow

   Create two new rows in the snmpNotifyTable [RFC2573].  This table
   uses RowStatus, so we choose to explicitly set its value for each row
   (new impls may allow the request to omit a RowStatus varbind if its
   value is createAndGo). The response includes the values of the
   specified Operands after row creation.

      CreateRow
      (
          request-id      = 1
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 0

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.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

          -- skip snmpNotifyStorageType. Use DEFVAL

          vb4.name  = 0.5 -- snmpNotifyRowStatus
          vb4.value = createAndGo

       -- RowOp 2

          -- RowIdentifier
          vb5.name  = 0.0 -- inherit snmpNotifyTable
          vb5.value = 1.0.114.111.119.50 -- "row2"

          vb6.name  = 0.3 -- snmpNotifyType
          vb6.value = 1 -- trap

          vb7.name  = 0.5 -- snmpNotifyRowStatus
          vb7.value = createAndWait
      )

      ResponsePdu
      (
          request-id   = 1
          error-status = noError

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.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

          vb4.name  = 0.5 -- snmpNotifyRowStatus
          vb4.value = active

       -- RowOp 2

          -- RowIdentifier
          vb5.name  = 0.0 -- inherit snmpNotifyTable
          vb5.value = 1.0.114.111.119.50 -- "row2"

          vb6.name  = 0.3 -- snmpNotifyType
          vb6.value = 1 -- trap

          vb7.name  = 0.5 -- snmpNotifyRowStatus
          vb7.value = notInService
      )

   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
      (
          request-id      = 2
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 0

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.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

          -- skip snmpNotifyStorageType. Use DEFVAL
          -- By omitting a RowState varbind, it is the
          -- same as setting RowState=Active.

       -- 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

          -- 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 this RowOp were not ready to go Active).
          -- If a DEFVAL (NotInService) were provided
          -- in the MIB, this varbind could be omitted
          -- from this RowOp.
          vb6.name  = 0.5 -- snmpNotifyRowState
          vb6.value = NotInService
      )

      ResponsePdu
      (
          request-id   = 2
          error-status = noError

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.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.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
      (
          request-id      = 3
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 0

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.1.1 -- snmpNotifyTable
          vb1.value = 1.0.114.111.119.49 -- "row1"

       -- RowOp 2

          -- RowIdentifier
          vb2.name  = 1.3.6.1.6.3.13.1.1 -- snmpNotifyTable
          vb2.value = 1.0.114.111.119.50 -- "row2"
      )

      ResponsePdu
      (
          request-id   = 3
          error-status = noError

       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.1.1 -- snmpNotifyTable
          vb1.value = 1.0.114.111.119.49 -- "row1"

       -- RowOp 2
          -- RowIdentifier
          vb2.name  = 0.0 -- snmpNotifyTable
          vb2.value = 1.0.114.111.119.50 -- "row2"
      )

   This DeleteRow example illustrates the use of Singletons. The
   Singletons allow a complete object instance to be provided (whereas
   the previous example contained no Operands and thus did not have
   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
      (
          request-id      = 5
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 0
       -- RowOp 1

          -- RowIdentifier
          vb1.name  = 0.0.6.3.13.1.1 -- snmpNotifyTable
          vb1.value = 1.0.114.111.119.49 -- "row1"

          vb2.name  = 0.2 -- snmpNotifyTag
          vb2.value = NULL

          vb3.name  = 0.3 -- snmpNotifyType
          vb3.value = NULL

      -- 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 = NULL

          -- must use the 0.1.X OID form because 999 > 39
          vb6.name  = 0.1.999 -- Should result in NoSuchObject
          vb6.value = NULL
      )

      ResponsePdu
      (
          request-id   = 5
          error-status = noError

       -- 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
      (
          request-id   = 6
          error-status = noError

       -- Singletons

          -- Singleton 1. The original request
          -- 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 1

          -- RowIdentifier
          vb2.name  = 0.0.6.3.13.1.1.1 -- snmpNotifyTable
          vb2.value = 1.0.114.111.119.49 -- "row1"

          vb3.name  = 0.2 -- snmpNotifyTag
          vb3.value =  "tag1"

          vb4.name  = 0.3 -- snmpNotifyType
          vb4.value = 1 -- trap
      )

B.4.  GetNextRow

   This is an example of a protocol exchange for a GetNextRow request
   and its response.

      GetNextRow
      (
          request-id      = 7
          non-repeaters   = 1 -- 1 Singleton
          max-repetitions = 0

       -- Singletons

          vb1.name  = 0.0.2.1.1.3 -- getNext(sysUpTime)
          vb1.value = NULL

       -- RowOp 1

          -- 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)..
      )

      ResponsePdu
      (
          request-id   = 7
          error-status = noError

       -- Singletons

          vb1.name  = 0.0.2.1.1.3.0 -- sysUpTime.0
          vb1.value = 123457

       -- RowOp 1

          -- RowIdentifier
          vb2.name  = 0.0.6.3.13.1.1.1 -- snmpNotifyTable
          vb2.value = 1.0.114.111.119.49 -- "row1"

          vb3.name  = 0.2 -- snmpNotifyTag
          vb3.value =  "tag1"

          vb4.name  = 0.3 -- snmpNotifyType
          vb4.value = 1 -- trap

      -- RowOp 2

          -- RowIdentifier
          vb5.name  = 0.0 -- inherit snmpNotifyTable
          vb5.value = 1.0.114.111.119.49 -- "row1"

          vb6.name  = 0.2 -- snmpNotifyTag
          vb6.value = "tag1"
      )

   The RowOps in this GetNextRow request are logically the same as a
   getNext(snmpNotifyEntry), getNext(snmpNotifyTag) and getNext(system).
   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 to indicate the
         nature of the operation. Also, is the operator might be included
         within each rowOp contained within same as the request so previous example except
   that one
         protocol operation might contain mixed row operations (i.e. RowOp2 specifies a
         createRow and deleteRow might co-exist column not included in the same protocol
         request).

      -  Maintain the same PDU structure, but re-define what a varbind
         is (i.e. one varbind might actually RowOp1. The response
   would be able identical to contain the above response except that RowOps1-3 (row
   1-3) would include a
         sequence of objects, 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 which pertain 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 one row
         operation). You'd still have 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 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 show how to perform a way of
         minimizing overhead.
   head and tail function, respectively.

   In this case, we would tradeoff feature
         set richness with RowOp1 (head function), 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 search range is indicated by the above, OID
   1.0.0 (no Instance or other?

C.  Examples of Row Operations

   Each Instance2 values provided).  That value along
   with a non-zero max-reps value indicates a head function with a
   possible search range of the following examples assumes that entire table.

   In RowOp2 (tail function), the error-index and
   error-status fields of search range is indicated by the manager initiated request are set to 0 and the request-id contains an appropriate value.

C.1.  CreateRow
   OID 1.0 (no InstanceLen, Instance or Instance2 values provided). That
   value along with RowStatus

   This protocol exchange illustrates the use a non-zero max-reps value indicates a tail function
   with a possible search range of the CreateRow request
   to create entire table.

   The Response indicates the desired objects in the first and last two new
   rows in of the snmpNotifyTable [RFC2573].  This table
   uses RowStatus, are returned (five rows in table, 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). row3 is not
   returned).

   Note that if max-reps were instead 0, the second rowOp inherits its table OID information from
   the previous rowOp (because 1.0 instructs this).

      CreateRow two RowOps would be
   logically identical.

      GetBulkRow
      (
          request-id      = 11
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 2 -- head/tail enabled

       -- rowOp RowOp 1

          -- rowIdentifier (table and instance) RowIdentifier
          vb1.name  = 1.3.6.1.6.3.13.1.1.1 0.0.6.3.13.1.1 -- snmpNotifyEntry
          vb1.value(OID) snmpNotifyTable
          vb1.value = 0.1.114.111.119.49 1.0.0    -- "row1" head search entire table

          vb2.name  = 0.1.2 0.2 -- snmpNotifyTag
          vb2.value(SnmpTagValue)
          vb2.value = "tag1" NULL

          vb3.name  = 0.1.3 0.5 -- snmpNotifyType
          vb3.value(INT) snmpNotifyRowStatus
          vb3.value = 1 NULL
       -- trap RowOp 2

          -- skip snmpNotifyStorageType.  Use DEFVAL RowIdentifier
          vb4.name  = 0.1.5 0.0.6.3.13.1.1 -- snmpNotifyRowStatus
          vb4.value(RowStatus) snmpNotifyTable
          vb4.value = createAndGo

       -- rowOp 2 1.0      -- rowIdentifier (table and instance) tail search entire table

          vb5.name  = 1.0 0.2 -- inherit snmpNotifyEntry
          vb5.value(OID) snmpNotifyTag
          vb5.value = 0.1.114.111.119.50 -- "row2" NULL

          vb6.name  = 0.1.5 0.5 -- snmpNotifyRowStatus
          vb6.value(RowStatus)
          vb6.value = 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 NULL
      }

      ResponsePdu
      (
          request-id   = 11
          error-status = noError

       -- rowOp RowOp 1

          -- rowIdentifier (table and instance) RowIdentifier
          vb1.name  = 1.3.6.1.6.3.13.1.1.1 0.0.6.3.13.1.1 -- snmpNotifyEntry
          vb1.value(OID) snmpNotifyTable
          vb1.value = 0.1.114.111.119.49 1.0.4.114.111.119.49 -- "row1"

          vb2.name  = 0.1.2 0.2 -- snmpNotifyTag
          vb2.value(SnmpTagValue)
          vb2.value = "tag1"

          vb3.name  = 0.1.3 -- snmpNotifyType
          vb3.value(INT) = 1 -- trap
          -- skip snmpNotifyStorageType.  Use DEFVAL

          -- By omitting a RowState varbind, it is the 0.5 -- same as setting RowState=Active. snmpNotifyRowStatus
          vb3.value = Active

       -- rowOp RowOp 2

          -- rowIdentifier (table and instance) RowIdentifier
          vb4.name  = 1.0 0.0.6.3.13.1.1 -- inherit snmpNotifyEntry
          vb4.value(OID) snmpNotifyTable
          vb4.value = 0.1.114.111.119.50 1.0.4.114.111.119.50 -- "row2"

          vb5.name  = 0.2 -- Explicitly set RowState to an initial snmpNotifyTag
          vb5.value = "tag2"

          vb6.name  = 0.5 -- value because we don't want to go snmpNotifyRowStatus
          vb6.value = Active

       -- active just yet. Even though we hint RowOp 3

          -- for an initial value of NotInService, RowIdentifier
          vb7.name  = 0.0.6.3.13.1.1 -- it's possible that the result might snmpNotifyTable
          vb7.value = 1.0.4.114.111.119.52 -- show NotReady (if the row as defined "row4"
          vb8.name  = 0.2 -- by CreateRow were not ready to go Active).
          vb5.name snmpNotifyTag
          vb8.value = "tag4"

          vb9.name  = 0.1.5 0.5 -- snmpNotifyRowState
          vb5.value(RowState) snmpNotifyRowStatus
          vb9.value = 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
      ( Active

       -- rowOp 1 RowOp 4

          -- rowIdentifier (table and instance)
          vb1.name RowIdentifier
          vb10.name  = 1.3.6.1.6.3.13.1.1.1 0.0.6.3.13.1.1 -- snmpNotifyEntry
          vb1.value(OID) snmpNotifyTable
          vb10.value = 0.1.114.111.119.49 -- "row1"

       -- rowOp 2 1.0.4.114.111.119.53 -- rowIdentifier (table and instance)
          vb2.name "row5"

          vb11.name  = 1.3.6.1.6.3.13.1.1.1 0.2 -- snmpNotifyEntry
          vb2.value(OID) snmpNotifyTag
          vb11.value = "tag5"

          vb12.name  = 0.1.114.111.119.50 0.5 -- "row2"
      )

C.4.  GetRow and GetNextRow snmpNotifyRowStatus
          vb12.value = Active
      }

   This example illustrates how a GetRow request with three row
   operations is used to retrieve row information.  Note that rowOp1
   retrieves only the snmpNotifyTag GetBulkRow requests data from row1, rowOp2 retrieves only two columns of the
   RowStatus value from row2, same table. The
   response shows RowOps and rowOp3 retrieves all values from row2.

   rowOp2 additionally attempts to retrieve an Singletons interspersed with one another
   (i.e. rows with only one 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), return cause Singletons to be
   returned instead of RowOps, which be definitions MUST have two or will contain exceptions as placeholders where
   more Operands in GetBulkRow responses).  Although this example uses a
   shorthand notation (i.e. fooTable), the
   requested objects do actual OIDs would utilize OID
   inheritance wherever possible. Also note that row3 did not exist.

      GetRow produce a
   result.

      GetBulkRow
      (
          request-id      = 12
          non-repeaters   = 0 -- 0 Singletons
          max-repetitions = 0 -- rowOp head/tail disabled

       -- RowOp 1

          -- rowIdentifier (table and instance) RowIdentifier
          vb1.name  = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
          vb1.value(OID) fooTable
          vb1.value = 0.1.114.111.119.49 1.0 -- "row1" search entire table

          vb2.name  = 0.1.2 0.2 -- snmpNotifyTag fooColumnA
          vb2.value = NULL

          vb3.name  = 0.3 -- rowOp 2 fooColumnB
          vb3.value = NULL
      }

      ResponsePdu
      (
          request-id   = 12
          error-status = noError

       -- rowIdentifier (table and instance) RowOp 1

          -- RowIdentifier
          vb1.name  = fooTable
          vb1.value = 1.0.1 -- row 1

          vb2.name  = 0.2 -- fooColumnA
          vb2.value = 1

          vb3.name  = 1.0 0.3 -- inherit snmpNotifyEntry
          vb3.value(OID) fooColumnB
          vb3.value = 0.1.114.111.119.50 1

       -- "row2" Singleton 1

          vb4.name  = 0.1.5 fooColumnA.2 -- snmpNotifyRowStatus row 2
          vb4.value = NULL 2

       -- Singleton 2

          vb5.name  = 0.1.999 fooColumnB.3 -- doesn't exist, but try anyway row 4
          vb5.value = NULL 4

       -- rowOp 3 RowOp 2

          -- rowIdentifier (table and instance) RowIdentifier
          vb6.name  = 1.0 fooTable
          vb6.value = 1.0.5 -- inherit snmpNotifyEntry
          vb6.value(OID) row 5

          vb7.name  = 0.1.114.111.119.50 0.2 -- "row2" fooColumnA
          vb7.value = 5

          vb8.name  = 0.3 -- fooColumnB
          vb8.value = 5

       -- Singleton 3

          vb9.name  = fooColumnA.6 -- omitting all operands indicates "get all" row objects.
      )
      ResponsePdu 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 RowOp 1

          -- rowIdentifier (table and instance) RowIdentifier
          vb1.name  = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
          vb1.value(OID) toasterTable
          vb1.value = 0.1.114.111.119.49 1.0.1   -- "row1" toaster/row "1"

          vb2.name  = 0.1.2 0.2 -- snmpNotifyTag
          vb2.value(snmpTagValue) toasterSlicesInserted
          vb2.value =  "tag1"

      -- rowOp 2

          -- rowIdentifier (table and instance) 100

          vb3.name  = 1.0 0.3 -- inherit snmpNotifyEntry
          vb3.value(OID) toasterTemp
          vb3.value = 0.1.114.111.119.50 1000

       -- "row2" RowOp 2

          -- RowIdentifier
          vb4.name  = 0.1.5 -- snmpNotifyRowStatus
          vb4.value(RowStatus) toasterTable
          vb4.value = NotInService 1.0.2   -- toaster/row "2"

          vb5.name  = 0.1.999 0.2 -- doesn't exist
          vb5.value(int) toasterSlicesInserted
          vb5.value = NoSuchObject

      -- rowOp 3

          -- rowIdentifier (table and instance) 2

          vb6.name  = 1.0 0.3 -- inherit snmpNotifyEntry
          vb6.value(OID) toasterTemp
          vb6.value = 1000
      }

      ResponsePdu
      (
          request-id   = 13
          error-status = 10 (wrongValue)
          error-index  = 0.1.114.111.119.50 2

       -- "row2"

          vb7.name RowOp 1

          -- RowIdentifier
          vb1.name  = 0.1.2 toasterTable
          vb1.value = 1.0.1   -- snmpNotifyTag
          vb7.value(SnmpTagValue) toaster/row "1"

          vb2.name  = ""

          vb8.name 0.2 -- toasterSlicesInserted
          vb2.value = 0.1.3 NULL

          vb3.name  = 0.3 -- snmpNotifyType
          vb8.value(INT) toasterTemp
          vb3.value = NULL

       -- RowOp 2

          -- RowIdentifier
          vb4.name  = toasterTable
          vb4.value = 1 1.0.2   -- trap

          vb9.name toaster/row "2"

          vb5.name  = 0.1.4 0.2 -- snmpNotifyStorageType
          vb9.value(StorageType) toasterSlicesInserted
          vb5.value = nonVolatile

          vb10.name NULL

          vb6.name  = 0.1.5 0.3 -- snmpNotifyRowStatus
          vb10.value(RowStatus) toasterTemp
          vb6.value = NotInService
      )

D. 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:

      -  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  Should the instancePart contains two or subids whose first two
         subids are not 0.1.  Furthermore, where instancePart resolves coexistence and transition section be moved 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).
         different document?

      -  Another possible optimization is to allow rowIdentifier varbind
         names  Need to begin with the prefix 0.0 as specify a substitute way for 1.3.6.1.
         This extended error codes to be mapped to
         meaningful error messages.  Perhaps IANA would save a few bytes per rowOp.

      -  Change maintain an
         IANAExtendedErrorCodes textual-convention (along the inheritance OID from 1.0 to 0.0?

      -  GetNextRow: Should we disallow use lines of wildcarding (where no
         operand means get
         IANAIfType) and all operands)? extended error codes would thus be
         controlled via IANA. Also, requiring a complete
         table entry OID (instead small range 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 codes may need
         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, reserved up-front for example,
         may allow master agents to minimize use by the number of subagent
         protocol operations needed to fulfill a GetNextRowRequest.

      -  Should it be a requirement IETF so that all the new proto-ops are
         "translatable" into traditional
         standard 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 error-status codes and varbind-level exceptions
         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 be mapped to convey extended code values.  For example, we
         may want to return "tooBig" in the "create-only-if-not-
         exists" semantic unless case where a RowStatus-like object successful
         GetBulkRow response is explicitly
         included in returned with only a portion of the request. If this
         requested data.  The tooBig extended error is a requirement, we may need "more" signal
         to instead adopt perform at least one more GetBulkRow (using the kind of approach where we nix Instance in
         the RowState
         idea last RowOp as a beginnning search range).

      -  What other extended error codes should be reserved and simply provide traditional protocol operations that
         instead make use of OID suppression or compression techniques.
         Cognizant SNMP entities would need defined
         up front?  For example, perhaps an "unsupportedOperation" needs
         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 defined so that the EOS requests as could return that error
         on a RowOp by RowOp basis (where a given subagent is appropriate (though again,
         many of the original motivations non-EOS
         capable and goals stated earlier others are). In such cases, incrementing the
         droppedPdu counter may not be achieved with such a solution). possible.

      -  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  How can SetRequests and/or EditRows be RowLock!

      -  Do we need a GetBulkRow request that makes use of similar OID
         suppression techniques as defined herein? used to safely create
         rows in tables using RowState in multi-mgr environments?  It might be argued
         this
         would be ideal to have such a mechanism (without re-creating
         RowStatus all over again) in order to ease the most effective use of OID suppression. transition to
         EOS-capable networks.

      -  Should the coexistence and transition section be moved this document contain procedures to a
         different document? translate EOS
         operations to/from conventional operations?

      -  Should we remove the comments about the timeout issues with
         RowStatus from MIB defs in this document (and all other EOS
         documents) instead be located in one EOS document?  This could
         reduce the meat number of the document?

E. modules needed to be IMPORTED in future
         MIBs/appls.

D.  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.