INTERNET-DRAFT                                                 L. Heintz
                                                     Cisco Systems, Inc.
                                                           19 April 2001

                     SNMP Row Operations Extensions


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


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes a set of extensions (protocol operations and
   textual conventions) to the existing SNMP framework architecture as
   defined in RFC2571.  These extensions provide mechanisms for
   efficient creation, modification, deletion and retrieval of table
   rows.

Table of Contents

   1. The SNMP Network Management Framework .......................    3
   2. Overview ....................................................    4
   2.1. Terms .....................................................    4
   2.2. Motivations for the Extensions ............................    4
   2.3. Design Goals ..............................................    5



EOS Working Group         Expires October 2001                  [Page 1]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   3. The Extensions ..............................................    6
   3.1. RowState ..................................................    6
   3.2. Row Operations ............................................    8
   3.2.1. The rowIdentifier .......................................    9
   3.2.2. The operands ............................................   12
   3.2.3. Distinguishing rowIdentifiers from operands .............   13
   3.2.4. RowState and RowStatus Considerations ...................   13
   3.2.5. Granularity of Success/Fail .............................   14
   3.2.6. Response PDUs ...........................................   14
   4. Elements of Procedure .......................................   14
   4.1. CreateRow Request Processing ..............................   14
   4.2. DeleteRow Request Processing ..............................   14
   4.3. EditRow Request Processing ................................   15
   4.4. GetRow Request Processing .................................   15
   4.5. GetNextRow Request Processing .............................   15
   4.6. Response-PDU Processing ...................................   15
   5. Coexistence and Transition ..................................   15
   6. Protocol Operations Definitions .............................   17
   7. Managed Object Definitions ..................................   18
   8. IANA Considerations .........................................   19
   9. Intellectual Property .......................................   19
   10. Acknowledgements ...........................................   19
   11. Security Considerations ....................................   20
   12. References .................................................   20
   13. Editor's Addresses .........................................   23
   A. Impact to SNMP and other Protocols ..........................   24
   A.1. SNMPv3 ....................................................   24
   A.2. AgentX ....................................................   24
   B. Alternative Approaches ......................................   24
   C. Examples of Row Operations ..................................   25
   C.1. CreateRow with RowStatus ..................................   25
   C.2. CreateRow with RowState ...................................   26
   C.3. DeleteRow .................................................   27
   C.4. GetRow and GetNextRow .....................................   28
   D. Known issues ................................................   29
   E. Full Copyright Statement ....................................   31















EOS Working Group         Expires October 2001                  [Page 2]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


1.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

      -  An overall architecture, described in RFC 2571 [RFC2571].

      -  Mechanisms for describing and naming objects and events for the
         purpose of management. The first version of this Structure of
         Management Information (SMI) is called SMIv1 and described in
         RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].
         The second version, called SMIv2, is described in RFC 2578
         [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].

      -  Message protocols for transferring management information. The
         first version of the SNMP message protocol is called SNMPv1 and
         described in RFC 1157 [RFC1157]. A second version of the SNMP
         message protocol, which is not an Internet standards track
         protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
         and RFC 1906 [RFC1906].  The third version of the message
         protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
         RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

      -  Protocol operations for accessing management information. The
         first set of protocol operations and associated PDU formats is
         described in RFC 1157 [RFC1157]. A second set of protocol
         operations and associated PDU formats is described in RFC 1905
         [RFC1905].

      -  A set of fundamental applications described in RFC 2573
         [RFC2573] and the view-based access control mechanism described
         in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB. Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the



EOS Working Group         Expires October 2001                  [Page 3]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   MIB.


2.  Overview

   This document describes a set of SNMP extensions to current protocol
   operations [RFC1905] to provide for efficient row operations (i.e.
   creating, modifying, deleting and retrieving table rows). In
   addition, a new textual convention, RowState, is defined to replace
   RowStatus in future MIBs. RowState maintains the ability to report
   the state of a row, but does not attempt to provide a mechanism to
   create or delete a row.

   APPENDIX A discusses some of the known impacts that these extensions
   may cause to current frameworks or protocols (e.g. AgentX).

   It is recognized that any one of several other approaches exist that
   could have been used to meet the design goals of this document.  As
   such, a few of these approaches are briefly discussed in APPENDIX B.


2.1.  Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Terminology such as "leftmost" or "left" indicates a PDU component
   that is transmitted on the wire prior to other components.  Thus,
   terms such as "rightmost" imply components that have similar, but
   opposite semantics.

   Protocol operation refers to a high-level request, such as a
   SetRequest or GetRequest (or one of the five new requests defined
   within this document). Row operation refers to one logical operation
   that affects one specific table row. A protocol operation may contain
   one or more row operations. The term rowOp refers to the component
   parts of a protocol operation that comprise a single row operation.


2.2.  Motivations for the Extensions

   Experience has shown that current SNMP protocol operations and
   management structures are not ideally suited to effect configuration
   changes within managed devices and when retrieving information.  The
   extensions described in this document are specifically designed to
   minimize, or provide opportunities to minimize the following problems
   which inhibit th effectiveness of SNMP:



EOS Working Group         Expires October 2001                  [Page 4]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


      -  Requests that contains multiple varbinds that affect one row of
         a table may contain significant redundancy of information. This
         is because each varbind contains an object name (i.e. Object
         Identifier or OID), and these OIDs may differ only in the
         single subid that designates a specific column.  In cases where
         strings are used as instance identifiers, for example, UDP
         maximum-message-size constraints may force multiple SetRequests
         to be used to construct a new, or modify an existing row in a
         table. Requests containing redundant data are also more costly
         to encrypt and decrypt.

      -  SetRequests may contain multiple varbinds that actually refer
         to the same MIB object. For example, varbind one may be
         attempting to set the object, foo, to the value 1, while
         varbind two may be attempting to set the same object, foo, to
         the value 2. In such cases, the SNMP protocol indicates that
         implementations may make independant decisions as to which
         varbind will effectively be used as the final result.

      -  SetRequests do not impose any ordering requirements on the
         varbinds within a single request, even if they affect different
         objects in the same row of a table.  This can cause added
         complexity in SetRequest processing.

      -  The RowStatus textual convention [RFC1903] provides a mechanism
         for row management.  RowStatus most often requires the
         implementation of a rather complicated state machine, many of
         whose transitions are optional and whose target states are at
         times non-deterministic. RowStatus also confuses the notion of
         row status with the notion of row fate, which also tends to
         complicate both the MIB design and the implementation.


2.3.  Design Goals

   Several goals were identified when considering the kinds of
   extensions that were needed:

      -  allow separate row operations (hereafter referred to as rowOps)
         to be performed in a single protocol operation.

      -  minimize redundant information in a protocol operation. The
         extensions should at least make use of OID suppression
         techniques to meet this goal.  Note that OID suppression
         (largely an issue of how data is stored within a PDU) is not
         equivalent to OID compression (data compression algorithms).
         Issues of OID compression are considered out of scope for this
         document.



EOS Working Group         Expires October 2001                  [Page 5]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


      -  eliminate the need for special MIB objects (e.g. RowStatus)
         that control the creation and deletion of rows.

      -  minimize the impact on existing network management and subagent
         protocols such as SNMPv3, AgentX, and related applications.

      -  interoperate with legacy MIBs as well as future MIBs.

      -  operate in existing SNMP networks and not disrupt legacy SNMP-
         capable devices.


3.  The Extensions

   Five new conceptual protocol operations are described in this
   document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU
   (aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU
   (aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of
   these request types are based on the same PDU structure as originally
   defined in [RFC1905].

   For purposes of discussion, the three requests, CreateRow, DeleteRow
   and EditRow are more generically referred to as SetRow class
   requests, while GetRow and GetNextRow are referred to as RetrieveRow
   class requests.

   In addition, a RowState textual convention is defined and is intended
   to replace RowStatus in all future MIB designs. It is not the
   intention to deprecate RowStatus. Although RowState is not a protocol
   operation, it does serve to reestablish a distinction between SNMP
   data types and SNMP operations -- a line which is blurred in the
   current RowStatus definition.


3.1.  RowState

   As mentioned earlier, this document defines a proposed textual
   convention, RowState, whose purpose is to replace RowStatus in future
   MIBs.  This convention provides several important improvements over
   RowStatus:

      -  RowState relaxes some of the row timeout rules that RowStatus
         suffers from. Such rules inhibit the usefulness of RowStatus as
         a means of temporarily placing system resources (i.e. table
         rows) out of service.  For example, if an SNMP manager changes
         a given instance of snmpNotifyRowStatus from Active to
         NotInService as a means of temporarily disabling one or more
         notifications, an unintended side-effect of this action on some



EOS Working Group         Expires October 2001                  [Page 6]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


         implementations may be that the row is automatically deleted
         after some short amount of time has elapsed (typically, a few
         minutes).

      -  More importantly, RowState separates the notion of reporting
         row status and the notion of managing row fate (i.e. creation &
         deletion). Specifically, the purpose of RowState is to enable
         reporting of row state, while matters of creating and deleting
         rows are better served by protocol operations.

   RowState provides three states: NotReady, NotInService and Active,
   which are very similar to the corresponding RowStatus definitions.
   Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo
   or Destroy.

   Any entity providing a RowState column in a table must instantiate an
   instance of RowState when one or more other column objects in the
   same row have been created or instantiated (by whatever means). Using
   the new protocol operations defined in this document, it is
   unnecessary to directly set or reference a RowState instance in order
   to create and activate a new row. The initial state of RowState is
   determined at the moment of initial row creation according to the
   semantics specified by the MIB designer (as provided within the
   Description clause of the RowState object, and much in the same way
   that RowStatus descriptions customize the semantics of those
   objects). At the time of row creation, the row creator may explicitly
   set the RowState object to a desired initial value, but the
   processing entity refers to this as a kind of "hint" since the final
   decision as to the initial value can only be determined after the
   complete row contents within the creation operation have been
   evaluated.

   One of the other differences between RowState and RowStatus is that
   RowState objects can never be automatically deleted from the entity
   as a result of timeouts when their states are either NotInService or
   Active. This provides the ability to use RowState objects to
   indefinitely take a row out of service without the fear of it being
   automatically deleted. When and whether rows containing RowState
   objects are added to, or removed from, non-volatile storage are not
   addressed by RowState.  Such behavior must be specified by other
   means (e.g. StorageType), which is out of scope for this document.

   In addition, unlike RowStatus, it is permissible to explicitly set
   RowState objects to the NotReady state as a crude means of allowing
   traditional SetRequests to delete the row. In this case, deletion
   occurs as a side effect of a row timeout. As will be shown, the
   preferred method of deleting any row is via use of the new DeleteRow
   request, which does not contain any direct reference to any specific



EOS Working Group         Expires October 2001                  [Page 7]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   row object (such as RowState).

   The CreateRow request introduces the ability to set either RowStatus
   or RowState objects without the need to explicitly include a varbind
   in the request. A CreateRow request by convention contains an
   implicit operand (i.e. varbind) to set a corresponding RowState
   object (if any) to the Active value. This implicit varbind can be
   overridden by the inclusion of an actual RowState varbind. For
   example, the following two CreateRow requests are logically
   identical, as both will attempt to create a newly active fooEntry,
   whose index is 1, and whose fooInt object equals 2:

      CreateRow (fooEntry.1, fooInt=2);
      CreateRow (fooEntry.1, fooInt=2, fooRowState=Active);

   These two requests are NOT logically identical:

      CreateRow (fooEntry.1, fooInt=2);
      CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService);

   Implementations are not required, however, to support such implicit
   operands within CreateRow requests for RowStatus objects.  This is
   intended to maximize the set of possible transition solutions for
   vendors of SNMP technology.

   The RowState textual convention provides full details of its use and
   operation and is provided in section 6.


3.2.  Row Operations

   The new protocol operations are designed to "fit" in the existing PDU
   structure as originally defined in [RFC1905]. One of the alternative
   approaches discussed in the Appendix is the possibility of defining a
   new PDU structure that allows a more efficient OID suppression
   strategy than the one described herein. However, the initial approach
   offered in intended to "look and feel" as close to the current
   framework as possible. As will be shown, the current PDU structure is
   quite sufficient to obtain significant (but not optimal) OID
   suppression benefits.

   Formal definitions of the new protocol operations are provided in
   section 5. [RFC1905] provides the PDU definition which these new
   operations are based on.

   Although the old PDU structure is maintained for now, this document
   specifies an evolutionary approach in the way that the new protocol
   operations are encoded or contained within the PDU. As such, the new



EOS Working Group         Expires October 2001                  [Page 8]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   requests capitalize on OID suppression techniques to minimize
   information redundancy and therefore minimize PDU size. Note that the
   traditional SNMP protocol operations as defined in [RFC1905] are not
   being changed, either in their semantics, the way data is encoded
   within them, or the way they are processed.

   The following general discussion centers on how the varbinds of the
   new protocol operations are formed or constructed. Other components
   of the PDU (e.g. error-index) are treated similarly to the current
   framework.  The elements of procedure, section 4, formally describes
   how the new requests are processed. APPENDIX C provides some high-
   level examples of the use of these operations.

   The varbinds in a PDU form one or more independant row operations
   (rowOps). This allows a single CreateRow request, for example, to
   create one or more new rows in a single protocol operation. Each
   rowOp corresponds to one attempt to create a row, in this case, or
   corresponds to one attempt to delete a row in the case of DeleteRow,
   and so forth.

   Note that the three layers in the diagram below do not describe
   different sections of the PDU, rather, they each represent the same
   information and structure (at different levels of abstraction).

      <CreateRow.............>
      <rowOp1><rowOp2><rowOp3>
      <vb><vb><vb><vb><vb><vb>

   Although the above diagram shows a CreateRow request logically
   containing three rowOps (i.e. create three rows) with two consecutive
   varbinds per rowOp, in reality, these requests may contain one, two,
   or more than two rowOps, each of which may may be comprised of a
   differing number of varbinds (i.e. zero, one, or more than one). In
   addition, the above example (and the ones that follow) could have
   substituted a RetrieveRow class request instead of CreateRow,

   The varbinds allocatted to a single rowOp serve to function as either
   a rowIdentifier or as operands.


3.2.1.  The rowIdentifier

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



EOS Working Group         Expires October 2001                  [Page 9]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   6th varbinds are operands.

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

      <GetRow.......................................>
      <rowOp........................................>
      <vb1-rowIdentifier><vb2-operand1><vb3-operand2>

   In this case, the GetRow request is seeking to retrieve two specific
   column objects from a specific row.

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

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

      OID = <tableEntryPart><columnPart><instancePart>

   If a traditional SetRequest contains two varbinds referring to two
   different columns in the same row, it is evident that both OIDs
   differ only in the integer value of the columnPart (a single subid).
   The other two parts, tableEntryPart and instancePart, therefore, are
   identical for each varbind present in a request affecting only a
   single table.

   A more meaningful representation for rowIdentifier is now possible:

      rowIdentifier = <vb.name=tableEntryPart,
                       vb.type=OID,
                       vb.value=0.1.instancePart>

   The vb.type MUST specify a type of OID.  This is because the
   instancePart of an OID is actually comprised of one or more table
   index values, depending on which table is affected and how many MIB
   objects comprise the INDEX clause of that table. For example, for a
   table whose INDEX is comprised of a single integer, instancePart will
   be a single subid; and for a table whose INDEX is comprised of two or
   more objects of any kind, the instancePart will be an OID (index1 +
   index2 + ... + indexN) with each index component representing one or
   more subids.

   Because the instancePart always resolves to one or more subids, and
   because a valid OID must be composed of at least two subids, we
   prefix the instancePart with the OID value of 0.1. The reason



EOS Working Group         Expires October 2001                 [Page 10]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   instancePart cannot simply be prefixed with a single subid is that
   OIDs of the form 0.X, where X > 39, are not legal. Thus, if
   instancePart resolved to a single subid of 40 (or greater), the value
   of 0.40 would be illegal. Thus the need to prefix instancePart with
   two subids that guarantee a valid OID will be formed regardless of
   how instancePart is resolved.  Note that due to ASN.1/BER encoding
   rules, the first two subids comprise only a single byte within the
   PDU.

   The rowIdentifier of each rowOp in a SetRow or RetrieveRow request
   specifies the exact row affected by the rowOp (but not which column
   objects are affected in that row).

   Consider the case of two or more rowOps in, say, a SetRow request
   that only affects different rows in the same table. In such cases,
   the varbind names of all the rowIdentifier varbinds will contain
   identical values. In order to therefore further minimize information
   redundancy, the OID of 1.0 (hereafter referred to as the inheritance
   OID, and occupying only a single byte within the resulting PDU) is
   permitted to be substituted as the varbind name of any rowIdentifier
   to indicate that the most recent (leftmost) rowIdentifier whose name
   is dissimilar (not 1.0) contains the OID value intended to be used.

   In this example, a simplified notation is used to help illustrate how
   a rowOp (the two middle ones in this case) uses the inheritance OID
   to minimize PDU size.  This example shows four rowOps, each comprised
   of one rowIdentifier and one operand (op):

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

   The following is logically identical to the preceding example (though
   it forms a larger PDU):

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

   Of course, this implies that rowOps that affect the same table SHOULD
   be consecutively placed in the PDU varbind list, and also that the
   first rowIdentifier in the PDU MUST NOT contain the inheritance OID.

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

   Each rowOp MUST contain a single rowIdentifier varbind, which MUST be
   the first varbind in each rowOp.  The tableEntryPart of a
   rowIdentifier MUST NOT contain partial OIDs.  This means that the
   tableEntryPart MUST always exactly correspond to a legal table entry
   definition (if the desired results are to be achieved). The
   motivation behind this is that all rowOps are performed at the row



EOS Working Group         Expires October 2001                 [Page 11]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   level.

   The instancePart within a GetNextRow is not required to be fully
   formed except that if the value is non-NULL, it MUST at least contain
   the 0.1 prefix. Also note that GetNextRow requests do not "jump" to
   the next table.  In other words, in the event a GetNextRow rowOp
   refers to the last row in a given table, the appropriate exception is
   returned for that rowOp even if other tables follow that contain
   retrievable rows. In this sense, GetNextRow is limited to operate
   within the subtree of the targeted table(s).


3.2.2.  The operands

   The remaining varbinds for a given rowOp are referred to as its
   operands, and are formed as standard SetRequest varbinds except that
   the name of each varbind is an OID whose length is exactly three
   subids long. The first two subids MUST be 0.1 and the third subid is
   taken from the affected column descriptor value whose object instance
   is affected. The reason three subids are specified (0.1.columnSubid)
   instead of two (0.columnSubid) is that columnSubid must accept all
   values in the range from 0 to 4294967295. However, the ASN.1/BER
   encoding rules do not allow OID values of 0.X where X > 39.  Note
   that typical OIDs formed this way (where columnSubid is small) will
   be comprised of only two bytes despite the fact that three subids are
   specified.

   Each operand contained in the same rowOp will have a varbind name
   such that varbind N MUST be lexicographically smaller than the name
   of varbind N+1. In other words, there is a left to right ordering
   relationship imposed on the rowOp operands to further provide
   implementation optimization opportunities and to further guarantee
   that multiple and possibly conflicting operands for the same column
   object cannot be provided (further minimizes information redundancy
   and processing ambiguity).  For example, the operand with the name
   of, 0.1.0, MUST be to the left of the operand with the name of,
   0.1.1, if they are operands of the same rowOp.

   Any rowOp may contain zero or more operands, except that the EditRow
   request MUST contain at least one operand.

   In case of RetrieveRow requests, if zero operands are provided in a
   rowOp, this implicitly calls for the retrieval of all instantiated
   objects in the affected row. Otherwise, only the specified objects
   are retrieved.

   In cases of CreateRow, at least one column definition in each of the
   affected tables must have a MAX-ACCESS of read-create and the the



EOS Working Group         Expires October 2001                 [Page 12]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   affected rows MUST NOT already exist (in whole or part). If zero
   operands are provided in a rowOp, then the row must be able to be
   created in whole or part using only default values.

   In cases of EditRow, each rowOp contains an operand for each row
   object whose value is being changed and whose MAX-ACCESS is either
   read-create or read-write. The affected rows MUST already exist (in
   whole or part), though the specific operands MAY refer to objects
   that do not yet exist.

   In cases of DeleteRow, each rowOp MAY contain operands whose MAX-
   ACCESS are either read-write or read-create.  While it is not
   essential that operands be included in a DeleteRow request, they may
   in special cases be useful, for example, when a proxy application
   translates a DeleteRow request to a conventional SetRequest that
   requires a RowStatus reference.


3.2.3.  Distinguishing rowIdentifiers from operands

   As described earlier, the varbinds in a rowOp function either as a
   rowIdentifier (one per rowOp) or as an operand (zero or more per
   rowOp). By definition, the first varbind in any SetRow or RetrieveRow
   request MUST be a rowIdentifier.  The varbind names of all
   rowIdentifiers are guaranteed to be OIDs with a minimum of four
   subids (because current SMIv2 rules and current IANA object
   registrations preclude the possibility that table entry definitions
   can have shorter OIDs). One exception to this, is that varbind names
   for rowIdentifiers may contain the inheritance OID value of, 1.0 (see
   earlier discussion for how and why this is used).

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

   In summary, if a varbind name contains an OID of the form 0.1.X
   (exactly three subids) then the varbind in question functions as an
   operand. Otherwise, the varbind functions as a rowIdentifier.


3.2.4.  RowState and RowStatus Considerations

   It is worthwhile to note that SetRow class requests allow new MIBs to
   be created without requiring use of the RowStatus or RowState textual
   conventions to allow for either incremental or "big-bang" style (i.e.
   CreateAndWait or CreateAndGo, resp.) row creation or deletion.
   RowState is useful only to report the current state of a row --
   notwithstanding the slight anomaly that it also allows SetRequests



EOS Working Group         Expires October 2001                 [Page 13]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   and EditRow requests to explicitly change the state of such objects
   to NotReady, and thereby cause a row deletion timer to be
   instantiated. Similarly, traditional SetRequests and SetRow requests
   can both be used to manage MIBs that incoporate RowStatus columns.
   For new MIB tables that do not require row state reporting objects,
   but which do require creation and/or deletion semantics, it is
   sufficient to omit RowState and RowStatus entirely and instead use a
   MAX-ACCESS of read-create for all writable objects.  Such tables can
   elegantly support row creation through use of the CreateRow or
   traditional SetRequest operations, and also support row deletion
   through use of the DeleteRow operation.


3.2.5.  Granularity of Success/Fail

   In the event a SetRow class request contains two or more rowOps that
   affect the same row, the elements of procedure (below) indicate that
   all rowOps in the SetRow request are to be rejected (i.e. all rowOps
   fail and the entity remains in the state it was in prior to receiving
   the SetRow request).

   RetrieveRow class requests can succeed or fail individually or even
   with each varbind.


3.2.6.  Response PDUs

   This document does not define any new response PDU.  Instead, the
   traditional Response-PDU [RFC1905] is used as the standard response
   to each of the SetRow and RetrieveRow requests, except that the
   varbinds are constructed using the same OID suppression techniques as
   described above.


4.  Elements of Procedure


4.1.  CreateRow Request Processing

   TBD


4.2.  DeleteRow Request Processing

   TBD






EOS Working Group         Expires October 2001                 [Page 14]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


4.3.  EditRow Request Processing

   TBD


4.4.  GetRow Request Processing

   TBD


4.5.  GetNextRow Request Processing

   TBD


4.6.  Response-PDU Processing

   TBD


5.  Coexistence and Transition

   An essential requirement for these operations is that they must
   operate seamlessly in existing networks and not disrupt legacy SNMP
   devices.  This is satisfied by the fact that the new protocol
   operations have new and unique ASN.1 tags, which allow older
   implementations to efficiently and silently drop these new PDU
   requests.

   Some entities may only support these extensions for certain tables.
   For example, different AgentX subagents may or may not support these
   operations. This requires that the requests fail whenever a table is
   targeted that cannot support the new operation.  The elements of
   procedure indictate the proper exceptions in these cases.

   It is also possible that some table implementations may support only
   some subset of the new operations, for example, the RetrieveRow
   requests, but not the SetRow requests. It is herein RECOMMENDED that
   SNMP entities that support at least one operation within a class
   (i.e. SetRow or RequestRow) for a given table SHOULD support all
   requests within the same class for that table. Also, it is further
   RECOMMENDED that if the SetRow class of operations are supported for
   a given table, then the entity SHOULD also support all the
   RetrieveRow operations for that table. For any operation not
   supported by a targeted table (which nevertheless supports other
   operations), the elements of procedure indicate the proper exceptions
   that apply.




EOS Working Group         Expires October 2001                 [Page 15]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


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

   Consider, for example, that it is impossible to form an equivalent
   SetRequest from a DeleteRow request that contains only a
   rowIdentifier but no operands. In fact, any SetRow or RetrieveRow
   request containing no operands cannot be translated into an
   equivalent Set/Get request because at least one operand is needed to
   convert the rowIdentifier information into a valid object (OID)
   reference. DeleteRow may optionally include a RowStatus object, which
   allows such a translation, but then the question arises as to the
   need for DeleteRow definitions in the first place.

   Or consider a proxy application that accepts CreateRow or EditRow
   requests and translates them into an equivalent SetRequest.  For
   example, CreateRow(fooEntry.row1, fooInt=1) is translated into
   Set(fooEntry.fooInt.row1=1). Note that an EditRow request containing
   the same varbind info would be translated into the exact same Set
   request.  This implies that proxy applications cannot faithfully
   translate these two extensions into a SetRequest with the same
   semantics as the original request. A CreateRow request, after
   translation, might incorrectly cause an existing row to be modified,
   whereas an EditRow request might cause a new row to be instantiated.
   A partial workaround is to explicitly include a RowStatus reference
   in all CreateRow requests, and to ensure that rows do not exist
   before issuing EditRow requests, though in multi-manager
   environments, this latter procedure suffers.

   The same issues are evident when a master agent needs to translate
   the extensions into traditional subagent PDU forms. Semantics may be
   lost in the translation, and only some amount of workaround is
   possible unless the underlying subagent protocol is itself extended
   to accomodate the new extensions.

   While it is possible to develop proxy applications that incorporate
   simple PDU translation schemes to generally allow EOS-capable devices
   (as described herein) to interoperate with non-EOS-capable devices,
   the workarounds that would be needed might in some (but not all)
   environments mitigate some or all of the benefits in using the new
   extensions in the first place.

   In short, with the approach outlined in this document, it is believed
   that non-EOS-capable devices need to be converted into EOS-capable
   devices by means other than simple PDU translation schemes.  In order
   to enable a transition strategy that uses simple PDU translation
   mechanisms, at least some of the earlier stated goals of this
   document would have to be abandoned (e.g. the goal to replace MIB
   objects such as RowStatus which confuse the notions of row state with



EOS Working Group         Expires October 2001                 [Page 16]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   row fate, and perhaps other goals as well).


6.  Protocol Operations Definitions

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

   IMPORTS
       PDU
           SNMPv2-PDU;

       ROWOP-PDUs ::=
           CHOICE {
           create-row-request
               CreateRowRequest-PDU,

           delete-row-request
               DeleteRowRequest-PDU,

           edit-row-request
               EditRowRequest-PDU,

           get-row-request
               GetRowRequest-PDU,

           get-next-row-request
               GetNextRowRequest-PDU
           }

       CreateRowRequest-PDU ::=
           [9]
               IMPLICIT PDU

       DeleteRowRequest-PDU ::=
          [10]
               IMPLICIT PDU

       EditRowRequest-PDU ::=
          [11]
               IMPLICIT PDU

       GetRowRequest-PDU ::=
          [12]
                IMPLICIT PDU

       GetNextRowRequest-PDU ::=
          [13]
               IMPLICIT PDU



EOS Working Group         Expires October 2001                 [Page 17]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   END


7.  Managed Object Definitions

   SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
       OBJECT-IDENTITY,
       snmpModules                           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION                    FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF;

   snmpRowopMIB MODULE-IDENTITY
       LAST-UPDATED "200104191653Z"
       ORGANIZATION "EOS Working Group"
       CONTACT-INFO "WG-EMail:   eos@ops.ietf.org
                     Subscribe:  eos-request@ops.ietf.org

                     Co-Chair:   Dale Francisco
                                 Cisco Systems, Inc.
                     postal:     80 West Tasman Drive
                                 San Jose, CA 95134
                                 USA
                     EMail:      dfrancis@cisco.com
                     phone:      +1 408-527-9787

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

                     Co-editor:  Lauren Heintz
                                 Cisco Systems, Inc.
                     postal:     130 Baytech Drive
                                 San Jose, CA 95134
                                 USA
                     EMail:      lheintz@cisco.com
                     phone:      +1 408-853-6568
                    "
       DESCRIPTION  "The SNMP Row Operations MIB"
       REVISION     "200103280000Z"
       DESCRIPTION  "The initial version, published in
                     draft-ietf-eos-snmp-rowops-00.txt.
                    "



EOS Working Group         Expires October 2001                 [Page 18]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


       ::= { snmpModules TBD }

   -- Textual Conventions

   RowState ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "TBD"
       SYNTAX       INTEGER {TBD}

   END


8.  IANA Considerations

   This document requires IANASnmpExtendedProtocol values to be reserved
   for allowing command responders to advertise their ability to support
   the extensions outlined in this document.  IANASnmpExtendedProtocol
   values are administered by IANA.  IANASnmpExtendedProtocol is defined
   in SNMP-X-PROTOCOL-TC.


9.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

10.  Acknowledgements

   This document is the result of the efforts of the Evolution Of SNMP
   (EOS) Working Group.  Some special thanks are in order to the
   following EOS WG members:



EOS Working Group         Expires October 2001                 [Page 19]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


       TBD

11.  Security Considerations

   TBD


12.  References

   [RFC1155]    Rose, M. and K. McCloghrie, "Structure and
                Identification of Management Information for TCP/IP-
                based internets", STD 16, RFC 1155, May 1990.

   [RFC1157]    Case, J., M. Fedor, M. Schoffstall and J. Davin, "The
                Simple Network Management Protocol", STD 15, RFC 1157,
                May 1990.

   [RFC1212]    Rose, M. and K. McCloghrie, "Concise MIB Definitions",
                STD 16, RFC 1212, March 1991.

   [RFC1901]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
                Rose, M.  and S. Waldbusser, "Introduction to
                Community-based SNMPv2", RFC 1901, January 1996.

   [RFC2571]    Harrington, D., Presuhn, R., and B. Wijnen, "An
                Architecture for Describing SNMP Management Frameworks",
                RFC 2571, April 1999.

   [RFC2578]    McCloghrie, K., Perkins, D. and J. Schoenwaelder,
                "Structure of Management Information Version 2 (SMIv2)",
                STD 58, RFC 2578, April 1999.

   [RFC2579]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                "Textual Conventions for SMIv2", STD 58, RFC 2579, April
                1999.

   [RFC2580]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                "Conformance Statements for SMIv2", STD 58, RFC 2580,
                April 1999.

   [RFC-PROTO]  Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
                Waldbusser, "Protocol Operations for the Simple Network
                Management Protocol", <draft-ietf-snmpv3-update-proto-
                05.txt>, April 2001.

   [RFC-TMM]    Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
                Waldbusser, "Transport Mappings for the Simple Network
                Management Protocol", <draft-ietf-snmpv3-update-



EOS Working Group         Expires October 2001                 [Page 20]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


                transmap-05.txt>, April 2001.

   [RFC-MIB]    Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
                Waldbusser, "Management Information Base for the Simple
                Network Management Protocol", <draft-ietf-snmpv3-
                update-mib-05.txt>, April 2001.

   [RFC-COEX]   Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                "Coexistence between Version 1, Version 2, and Version 3
                of the Internet-standard Network Management Framework",
                <draft-ietf-snmpv3-coex-v2-00.txt>, April 2001.

   [RFC1909]    McCloghrie, K., Editor, "An Administrative
                Infrastructure for SNMPv2", RFC 1909, February 1996.

   [RFC1910]    Waters, G., Editor, "User-based Security Model for
                SNMPv2", RFC 1910, February 1996.

   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 2279, January, 1998.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [BCP-11]     Hovey, R. and S. Bradner, "The Organizations Involved in
                the IETF Standards Process", BCP 11, RFC 2028, October
                1996.

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

   [SNMP-MPD]   Case, J., Harrington, D., Presuhn, R.  and B. Wijnen,
                "Message Processing and Dispatching for the Simple
                Network Management Protocol (SNMP)", <draft-ietf-
                snmpv3-mpd-v2-00.txt>, April 2001.

   [SNMP-USM]   Blumenthal, U.  and B. Wijnen, "The User-Based Security
                Model for Version 3 of the Simple Network Management
                Protocol (SNMPv3)", <draft-ietf-snmpv3-usm-v2-00.txt>,
                April 2001.

   [SNMP-ACM]   Wijnen, B., Presuhn, R.  and K. McCloghrie, "View-based
                Access Control Model for the Simple Network Management
                Protocol (SNMP)", <draft-ietf-snmpv3-vacm-04.txt>,
                February 1999.  <draft-ietf-snmpv3-vacm-v2-00.txt>,
                April 2001.

   [RFC-APPL]   Levi, D., Meyer, P.  and B. Stewart, "SNMP



EOS Working Group         Expires October 2001                 [Page 21]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


                Applications", <draft-ietf-snmpv3-apps-v2-00.txt>, April
                2001.

   [RFC2570]    Case, J., Mundy, R., Partain, D. and B. Stewart,
                "Introduction to Version 3 of the Internet-standard
                Network Management Framework", <draft-ietf-snmpv3-
                intro-04.txt>, January 1999.

   [RFC-COEX]   Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                "Coexistence between Version 1, Version 2, and Version 3
                 of the Internet-standard Network Management Framework",
                <draft-ietf-snmpv3-coex-v2-00.txt>, April 2001.







































EOS Working Group         Expires October 2001                 [Page 22]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


13.  Editor's Addresses

   Lauren Heintz
   Cisco Systems, Inc.
   130 Baytech Drive
   San Jose, Ca 95134

   Phone:      +1 408-853-6568
   EMail:      lheintz@cisco.com










































EOS Working Group         Expires October 2001                 [Page 23]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


APPENDIXES


A.  Impact to SNMP and other Protocols


A.1.  SNMPv3

   An issue remains whether a new message processing model MUST be
   specified as part of the SNMPv3 (or later) standard. Otherwise, it is
   not seen that these extensions pose any impact to other SNMPv3
   architectural components (i.e. USM, VACM) because the new protocol
   operations and their contents contain sufficient information (along
   with the information provided in whatever version-specific message
   wrapper they are contined within) to satisfy the abstract service
   interfaces for those components.

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


A.2.  AgentX

   These extensions imply that AgentX will have to evolve in order to
   support the new protocol operations.  For example, AgentX does not
   provide a delete PDU (to support DeleteRow), and neither does its
   TestSet PDU provide for a standard way to indicate whether the
   operation being performed maps to a CreateRow or EditRow request.
   Furthermore, master agents will need to know how to recognize and
   process the new protocol operations (i.e. distinguish rowIdentifiers
   from operands, logically expand the targeted object OIDs and map them
   to subtree registrations).


B.  Alternative Approaches

   This section will be deleted before going standards track.

   This document outlines one approach to achieving the design goals
   stated earlier.  Several other approaches also exist. Here are some
   hints:

      -  Use the same approach described herein except define a new
         "RowPDU" to further optimize OID suppression (i.e. get rid of
         the 0.1.X column subid notation). This may require a new kind
         of varbind list where each varbind is no longer an OID/value



EOS Working Group         Expires October 2001                 [Page 24]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


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

      -  Instead of having five new request types, use only one instead
         and perhaps have an operator within the request to indicate the
         nature of the operation. Also, the operator might be included
         within each rowOp contained within the request so that one
         protocol operation might contain mixed row operations (i.e. a
         createRow and deleteRow might co-exist in the same protocol
         request).

      -  Maintain the same PDU structure, but re-define what a varbind
         is (i.e. one varbind might actually be able to contain a
         sequence of objects, all of which pertain to one row
         operation). You'd still have to define where/how you designate
         which row(s) and column(s) are affected.

      -  Nix the RowState idea, keep RowStatus, and simply provide
         traditional protocol operations, perhaps with a way of
         minimizing overhead. In this case, we would tradeoff feature
         set richness with the potential of being able to provide easier
         transition solutions for legacy systems (i.e.  the requests
         might be more easily translatable into conventional requests).

      -  Some combination of the above, or other?


C.  Examples of Row Operations

   Each of the following examples assumes that the error-index and
   error-status fields of the manager initiated request are set to 0 and
   the request-id contains an appropriate value.


C.1.  CreateRow with RowStatus

   This protocol exchange illustrates the use of the CreateRow request
   to create two new rows in the snmpNotifyTable [RFC2573].  This table
   uses RowStatus, so we choose to explicitly set its value for each
   row, as desired (some impls may allow us to instead omit setting
   RowStatus and rely on implicit support for it).

   Note that the second rowOp inherits its table OID information from
   the previous rowOp (because 1.0 instructs this).

      CreateRow
      (



EOS Working Group         Expires October 2001                 [Page 25]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


       -- rowOp 1

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

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

          vb3.name = 0.1.3 -- snmpNotifyType
          vb3.value(INT) = 1 -- trap

          -- skip snmpNotifyStorageType.  Use DEFVAL

          vb4.name = 0.1.5 -- snmpNotifyRowStatus
          vb4.value(RowStatus) = createAndGo

       -- rowOp 2

          -- rowIdentifier (table and instance)
          vb5.name = 1.0 -- inherit snmpNotifyEntry
          vb5.value(OID) = 0.1.114.111.119.50 -- "row2"

          vb6.name = 0.1.5 -- snmpNotifyRowStatus
          vb6.value(RowStatus) = createAndWait
      )


C.2.  CreateRow with RowState

   This protocol exchange illustrates the use of the CreateRow request
   to create two new rows in the snmpNotifyTable [RFC2573] except that
   we pretend here that RowState was used in the design of that table
   instead of RowStatus.

      CreateRow
      (
       -- rowOp 1

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

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

          vb3.name = 0.1.3 -- snmpNotifyType
          vb3.value(INT) = 1 -- trap



EOS Working Group         Expires October 2001                 [Page 26]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


          -- skip snmpNotifyStorageType.  Use DEFVAL

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

       -- rowOp 2

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

          -- Explicitly set RowState to an initial
          -- value because we don't want to go
          -- active just yet. Even though we hint
          -- for an initial value of NotInService,
          -- it's possible that the result might
          -- show NotReady (if the row as defined
          -- by CreateRow were not ready to go Active).
          vb5.name = 0.1.5 -- snmpNotifyRowState
          vb5.value(RowState) = NotInService
      )


C.3.  DeleteRow

   This example illustrates how a DeleteRow request containing two row
   operations is formed to delete the two rows created in either of the
   two previous examples. Note that the rowIdentifier in the second
   rowOp does not inherit the table OID from the first rowOp. Although
   this is legal, it also increases the request PDU size unnecessarily.

      DeleteRow
      (
       -- rowOp 1

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

       -- rowOp 2

          -- rowIdentifier (table and instance)
          vb2.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
          vb2.value(OID) = 0.1.114.111.119.50 -- "row2"
      )






EOS Working Group         Expires October 2001                 [Page 27]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


C.4.  GetRow and GetNextRow

   This example illustrates how a GetRow request with three row
   operations is used to retrieve row information.  Note that rowOp1
   retrieves only the snmpNotifyTag from row1, rowOp2 retrieves only the
   RowStatus value from row2, and rowOp3 retrieves all values from row2.

   rowOp2 additionally attempts to retrieve an object that does not
   exist in the table row.

   The Response PDU is also shown afterward.

   GetNextRow performs very similarly to GetRow except that the Response
   PDU will contain the object names and values from the next row in the
   table (if any), or will contain exceptions as placeholders where the
   requested objects do not exist.

      GetRow
      (
       -- rowOp 1

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

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

      -- rowOp 2

          -- rowIdentifier (table and instance)
          vb3.name = 1.0 -- inherit snmpNotifyEntry
          vb3.value(OID) = 0.1.114.111.119.50 -- "row2"

          vb4.name = 0.1.5 -- snmpNotifyRowStatus
          vb4.value = NULL

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

      -- rowOp 3

          -- rowIdentifier (table and instance)
          vb6.name = 1.0 -- inherit snmpNotifyEntry
          vb6.value(OID) = 0.1.114.111.119.50 -- "row2"

          -- omitting all operands indicates "get all" row objects.
      )



EOS Working Group         Expires October 2001                 [Page 28]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


      ResponsePdu
      (
       -- rowOp 1

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

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

      -- rowOp 2

          -- rowIdentifier (table and instance)
          vb3.name = 1.0 -- inherit snmpNotifyEntry
          vb3.value(OID) = 0.1.114.111.119.50 -- "row2"

          vb4.name = 0.1.5 -- snmpNotifyRowStatus
          vb4.value(RowStatus) = NotInService

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

      -- rowOp 3

          -- rowIdentifier (table and instance)
          vb6.name = 1.0 -- inherit snmpNotifyEntry
          vb6.value(OID) = 0.1.114.111.119.50 -- "row2"

          vb7.name = 0.1.2 -- snmpNotifyTag
          vb7.value(SnmpTagValue) = ""

          vb8.name = 0.1.3 -- snmpNotifyType
          vb8.value(INT) = 1 -- trap

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

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


D.  Known issues

   This section will be deleted before becoming an RFC.

   These are known issues that need to be resolved before going



EOS Working Group         Expires October 2001                 [Page 29]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


   standards track:

      -  Which SNMP message versions can these rowop PDUs be wrapped in?
         SNMPv3 only?

      -  It is possible to further optimize the above PDU. For example,
         the instancePart of the rowIdentifiers can omit the 0.1 prefix
         if the instancePart contains two or subids whose first two
         subids are not 0.1.  Furthermore, where instancePart resolves
         to a single subid, we can use vb.type=Unsigned32 instead, and
         vb.value will contain the instancePart.  The cost is added
         complexity (special case handling).

      -  Another possible optimization is to allow rowIdentifier varbind
         names to begin with the prefix 0.0 as a substitute for 1.3.6.1.
         This would save a few bytes per rowOp.

      -  Change the inheritance OID from 1.0 to 0.0?

      -  GetNextRow: Should we disallow use of wildcarding (where no
         operand means get all operands)? Also, requiring a complete
         table entry OID (instead of a partial OID) is too strict? The
         argument for maintaining this strictness is that this document
         is trying to define efficient, predictable protocol operations.
         Also, the OID provided cannot appear to be an operand of the
         previous rowOp (if any).  Traditional SetRequests provide
         plenty of opportunity for expressiveness, if one desires such
         flexibility and inefficiency.  This strictness, for example,
         may allow master agents to minimize the number of subagent
         protocol operations needed to fulfill a GetNextRowRequest.

      -  Should it be a requirement that all the new proto-ops are
         "translatable" into traditional SNMP requests?  If so,
         DeleteRow is not translatable, so should it be deleted?
         Alternatively, we can allow DeleteRow to contain one optional
         operand so that a RowState (or RowStatus) operand can be
         included. In this way, DeleteRow requests can also be
         translated by, for example, proxies and master agents. Also, a
         CreateRow request cannot be translated into a SetRequest
         because there is no way to convey the "create-only-if-not-
         exists" semantic unless a RowStatus-like object is explicitly
         included in the request. If this is a requirement, we may need
         to instead adopt the kind of approach where we nix the RowState
         idea and simply provide traditional protocol operations that
         instead make use of OID suppression or compression techniques.
         Cognizant SNMP entities would need to be able to distinguish
         such requests from traditional request formats while non-
         cognizant entities would predictably reject the request in some



EOS Working Group         Expires October 2001                 [Page 30]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


         way. Cognizant entities such as proxies and master agents could
         then translate the requests as is appropriate (though again,
         many of the original motivations and goals stated earlier may
         not be achieved with such a solution).

      -  Are the names for RowState and its values appropriate?  Perhaps
         the values should be something like: Undefined, Unlocked and
         Locked, and the TC name should be RowLock!

      -  Do we need a GetBulkRow request that makes use of similar OID
         suppression techniques as defined herein?  It might be argued
         this would be the most effective use of OID suppression.

      -  Should the coexistence and transition section be moved to a
         different document?

      -  Should we remove the comments about the timeout issues with
         RowStatus from the meat of the document?


E.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




EOS Working Group         Expires October 2001                 [Page 31]


Internet Draft      SNMP Row Operations Extensions         19 April 2001


Acknowledgement

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















































EOS Working Group         Expires October 2001                 [Page 32]