[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

Attached is a sneak peek at the rowOps doc (work-in-progress).
Please take a look and provide comments (even simple yeah's and
nay's of support) to the list.

In sum, the described approach provides: new RowState TC
to replace RowStatus, and 5 new Request types (CreateRow,
DeleteRow, EditRow, GetRow, GetNextRow).  The appendix
hints at some alternatives to instead consider.

The TBDs (and grammar/spell errors, and murky text, etc) will
get fixed after some measure of agreement on the overall approach
is apparent.

Thanks, Lauren






INTERNET-DRAFT                                                 L. Heintz
                                                     Cisco Systems, Inc.
                                                           16 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 September 2001                 [Page 1]

Internet Draft      SNMP Row Operations Extensions         16 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
   4. Elements of Procedure .......................................   14
   4.1. CreateRow Request Processing ..............................   14
   4.2. DeleteRow Request Processing ..............................   14
   4.3. EditRow Request Processing ................................   14
   4.4. GetRow Request Processing .................................   14
   4.5. GetNextRow Request Processing .............................   14
   4.6. Entities not supporting SetRow or RetrieveRow.  ...........   14
   5. Protocol Operations Definitions .............................   15
   6. Managed Object Definitions ..................................   15
   7. IANA Considerations .........................................   16
   8. Intellectual Property .......................................   16
   9. Acknowledgements ............................................   17
   10. Security Considerations ....................................   17
   11. References .................................................   17
   12. Editor's Addresses .........................................   20
   A. Impact to Other Protocols ...................................   21
   B. Alternative Approaches ......................................   21
   C. Examples of Row Operations ..................................   21
   C.1. CreateRow with RowStatus ..................................   22
   C.2. CreateRow with RowState ...................................   22
   C.3. DeleteRow .................................................   23
   C.4. GetRow and GetNextRow .....................................   24
   D. Known issues ................................................   26
   E. Full Copyright Statement ....................................   26



















EOS Working Group        Expires September 2001                 [Page 2]

Internet Draft      SNMP Row Operations Extensions         16 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 September 2001                 [Page 3]

Internet Draft      SNMP Row Operations Extensions         16 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.

   It is important to understand the difference between the concepts of
   protocol operation and row operation and the term rowOp.  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 with SNMP has shown that there are certain problems and
   inefficiencies when using current protocol operations and management
   structures to effect configuration changes within managed devices and
   when retrieving information.  The extensions described in this



EOS Working Group        Expires September 2001                 [Page 4]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   document are specifically designed to minimize, or provide
   opportunities to minimize the following problems:

      -  Requests that contains multiple varbinds that affect only 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 and which will be ignored.

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



EOS Working Group        Expires September 2001                 [Page 5]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


         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 AgentX, and 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, which is
   intended to replace RowStatus in all future MIB designs. 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



EOS Working Group        Expires September 2001                 [Page 6]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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



EOS Working Group        Expires September 2001                 [Page 7]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   occurs as a side effect of a row timeout.

   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 an even 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 September 2001                 [Page 8]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   requests capitalize on OID suppression techniques to minimize
   information redundancy and minimize PDU size. Note that the
   traditional SNMP protocol operations as defined in [RFC1905] are not
   being changed, either in their semantics, the way they are encoded
   within a PDU, 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. one, two, or more than two). 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. The next two sections describe these
   basic rowOp components.


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



EOS Working Group        Expires September 2001                 [Page 9]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   and 5th varbinds are therefore rowIdentifiers while the 2nd, 4th and
   6th varbinds are operands.

   The following diagram shows a GetRow request containing a single
   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, vb.value=instancePart>

   The vb.type MUST specify either OID or Unsigned32.  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.

   In the case where instancePart is a single subid then vb.type MUST be
   specified as Unsigned32 and instancePart will be the integer value of
   that single subid.  Otherwise, vb.type MUST specify an OID as the



EOS Working Group        Expires September 2001                [Page 10]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   type and the instancePart will be provided as an OID value.

   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 affect different rows in the same table. In such cases,
   tableEntryPart of all the related rowIdentifier varbinds will contain
   identical values. Thus, in order to further minimize information
   redundancy, the OID of 1.0 is permitted to be substituted into the
   tableEntryPart of any rowIdentifier to indicate the correct
   tableEntryPart value for that rowIdentifier is located in the most
   recent (leftmost) rowIdentifier whose name was NOT 1.0.

   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 value of 1.0.

   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
   (1.0) 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>]

   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 rowIdentifier MUST be fully
   formed and cannot contain partial OIDs, as are possible in
   traditional getNextRequests.  This means that the tableEntryPart MUST
   always exactly correspond to a legal table entry definition (if the
   desired results are to be achieved). The motivation behind this is
   that all rowOps are performed at the row level; therefore, each rowOp
   within a given GetNextRow request, for example, MUST refer to a row
   (existing or not) after which the next row (if any) is retrieved.
   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



EOS Working Group        Expires September 2001                [Page 11]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   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 two subids
   long and whose first subid is always the value 0. The second subid is
   always taken from the affected column descriptor value whose object
   instance is affected. This means that each affected column object
   within a rowOp is explicitly named. At the expense of wasting a few
   octets of PDU size in the storage of subids that are always 0, this
   helps avoid processing errors that are possible if an implicit means
   of identifying column objects was instead used.

   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, MUST be to the left of the operand with the name of, 0.2, if
   they are operands of the same rowOp.

   In cases of RetrieveRow class requests, each rowOp MAY contain zero
   or more operands. If zero operands are provided, this implicitly
   calls for the retrieval of all instantiated objects in the specified
   row. Otherwise, only the specified row objects are retrieved (or
   exceptions returned).

   In cases of CreateRow, each rowOp MUST contain at least one operand
   whose MAX-ACCESS value is read-create. Also, the rows MUST NOT
   already exist (in whole or part).

   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 MUST NOT contain any operands.







EOS Working Group        Expires September 2001                [Page 12]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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). The first varbind in any SetRow or RetrieveRow request is a
   rowIdentifier, because by definition the first varbind in each rowOp
   MUST be a rowIdentifier. The varbind names of all rowIdentifiers are
   guaranteed to be OIDs with a minimum of three 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 special OID value of, 1.0, which serves to indicate that
   the varbind name in the previous rowIdentifier (whose name is not
   equal to 1.0) is to be logically inherited or substituted in place of
   the 1.0 value.

   The varbind names of all operands, on the other hand, are OID values
   with exactly two subids and whose first subid MUST be 0. Note that
   0.0 is a legal varbind name for an operand (if the affected column
   descriptor is equal to 0).

   In summary, if a varbind name contains two subids, the first of which
   equals 0, 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
   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.






EOS Working Group        Expires September 2001                [Page 13]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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.


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.  Entities not supporting SetRow or RetrieveRow.

   An essential requirement for these operations is that it 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.




EOS Working Group        Expires September 2001                [Page 14]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   Some entities may only support these operations 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.


5.  Protocol Operations Definitions

   TBD


6.  Managed Object Definitions

   SNMP-ROWOPS-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;

   snmpRowopsMIB MODULE-IDENTITY
       LAST-UPDATED "200104162050Z"
       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:
                                 USA
                     EMail:      dfrancis@cisco.com
                     phone:



EOS Working Group        Expires September 2001                [Page 15]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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

                     Co-editor:  Lauren Heintz
                                 Cisco Systems, Inc.
                     postal:
                                 USA
                     EMail:      lheintz@cisco.com
                     phone:
                    "
       DESCRIPTION  "The SNMP Row Operations Extensions 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


7.  IANA Considerations

   This document defines one number space administered by IANA for
   providing a capability expression to allow command responders to
   advertise their ability to support the extensions outlined in this
   document.  TBD

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



EOS Working Group        Expires September 2001                [Page 16]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


   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.

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

       Wiley Coyote (Acme)

10.  Security Considerations

   This is where security considerations will be.

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



EOS Working Group        Expires September 2001                [Page 17]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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



EOS Working Group        Expires September 2001                [Page 18]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


                "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
                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 September 2001                [Page 19]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


12.  Editor's Addresses

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

   Phone:      +1 408-615-7605
   EMail:      lheintz@cisco.com










































EOS Working Group        Expires September 2001                [Page 20]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


APPENDIXES


A.  Impact to Other Protocols

   TBD


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.X column subid notation).  This may require a new kind of
         varbind list where each varbind is no longer an OID/value, 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 with the request to indicate the
         kind of 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.

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



EOS Working Group        Expires September 2001                [Page 21]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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
      (
       -- rowOp 1

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

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

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

          -- skip snmpNotifyStorageType.  Use DEFVAL

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

       -- rowOp 2

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

          vb8.name = 0.5 -- snmpNotifyRowStatus
          vb8.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.




EOS Working Group        Expires September 2001                [Page 22]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


      CreateRow
      (
       -- rowOp 1

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

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

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

          -- skip snmpNotifyStorageType.  Use DEFVAL

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

       -- rowOp 2

          -- rowIdentifier (table and instance)
          vb5.name = 1.0 -- inherit snmpNotifyEntry
          vb5.value(OID) = 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).
          vb8.name = 0.5 -- snmpNotifyRowState
          vb8.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



EOS Working Group        Expires September 2001                [Page 23]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


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

       -- rowOp 2

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


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) = 114.111.119.49 -- "row1"

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

      -- rowOp 2

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

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



EOS Working Group        Expires September 2001                [Page 24]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


          vb5.name = 0.999 -- doesn't exist
          vb5.value = NULL

      -- rowOp 3

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

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

      ResponsePdu
      (
       -- rowOp 1

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

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

      -- rowOp 2

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

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

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

      -- rowOp 3

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

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

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

          vb9.name = 0.4 -- snmpNotifyStorageType



EOS Working Group        Expires September 2001                [Page 25]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


          vb9.value(StorageType) = nonVolatile

          vb10.name = 0.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
   standards track:

      -  The instancePart of the rowIdentifier is contained within the
         value part of a varbind.  Usually, only SetRequests contain
         non-NULL value varbind components, so what impact do these new
         requests (with these non-NULL value components) cause?


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 September 2001                [Page 26]

Internet Draft      SNMP Row Operations Extensions         16 April 2001


Acknowledgement

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















































EOS Working Group        Expires September 2001                [Page 27]