idnits 2.17.1 draft-ietf-eos-snmp-rowops-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (19 April 2001) is 8408 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1215' is mentioned on line 95, but not defined == Missing Reference: 'RFC1906' is mentioned on line 105, but not defined ** Obsolete undefined reference: RFC 1906 (Obsoleted by RFC 3417) == Missing Reference: 'RFC2572' is mentioned on line 106, but not defined ** Obsolete undefined reference: RFC 2572 (Obsoleted by RFC 3412) == Missing Reference: 'RFC2574' is mentioned on line 106, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC1905' is mentioned on line 630, but not defined ** Obsolete undefined reference: RFC 1905 (Obsoleted by RFC 3416) == Missing Reference: 'RFC2573' is mentioned on line 1118, but not defined ** Obsolete undefined reference: RFC 2573 (Obsoleted by RFC 3413) == Missing Reference: 'RFC2575' is mentioned on line 116, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) == Missing Reference: 'RFC1903' is mentioned on line 203, but not defined ** Obsolete undefined reference: RFC 1903 (Obsoleted by RFC 2579) -- Looks like a reference, but probably isn't: '9' on line 766 -- Looks like a reference, but probably isn't: '10' on line 770 -- Looks like a reference, but probably isn't: '11' on line 774 -- Looks like a reference, but probably isn't: '12' on line 778 -- Looks like a reference, but probably isn't: '13' on line 782 == Unused Reference: 'RFC-PROTO' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC-TMM' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC-MIB' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'RFC-COEX' is defined on line 983, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC1910' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC-APPL' is defined on line 974, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2028 (ref. 'BCP-11') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APPL' ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 18 errors (**), 0 flaws (~~), 24 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L. Heintz 3 Cisco Systems, Inc. 4 19 April 2001 6 SNMP Row Operations Extensions 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (C) The Internet Society (2001). All Rights Reserved. 33 Abstract 35 This document describes a set of extensions (protocol operations and 36 textual conventions) to the existing SNMP framework architecture as 37 defined in RFC2571. These extensions provide mechanisms for 38 efficient creation, modification, deletion and retrieval of table 39 rows. 41 Table of Contents 43 1. The SNMP Network Management Framework ....................... 3 44 2. Overview .................................................... 4 45 2.1. Terms ..................................................... 4 46 2.2. Motivations for the Extensions ............................ 4 47 2.3. Design Goals .............................................. 5 48 3. The Extensions .............................................. 6 49 3.1. RowState .................................................. 6 50 3.2. Row Operations ............................................ 8 51 3.2.1. The rowIdentifier ....................................... 9 52 3.2.2. The operands ............................................ 12 53 3.2.3. Distinguishing rowIdentifiers from operands ............. 13 54 3.2.4. RowState and RowStatus Considerations ................... 13 55 3.2.5. Granularity of Success/Fail ............................. 14 56 3.2.6. Response PDUs ........................................... 14 57 4. Elements of Procedure ....................................... 14 58 4.1. CreateRow Request Processing .............................. 14 59 4.2. DeleteRow Request Processing .............................. 14 60 4.3. EditRow Request Processing ................................ 15 61 4.4. GetRow Request Processing ................................. 15 62 4.5. GetNextRow Request Processing ............................. 15 63 4.6. Response-PDU Processing ................................... 15 64 5. Coexistence and Transition .................................. 15 65 6. Protocol Operations Definitions ............................. 17 66 7. Managed Object Definitions .................................. 18 67 8. IANA Considerations ......................................... 19 68 9. Intellectual Property ....................................... 19 69 10. Acknowledgements ........................................... 19 70 11. Security Considerations .................................... 20 71 12. References ................................................. 20 72 13. Editor's Addresses ......................................... 23 73 A. Impact to SNMP and other Protocols .......................... 24 74 A.1. SNMPv3 .................................................... 24 75 A.2. AgentX .................................................... 24 76 B. Alternative Approaches ...................................... 24 77 C. Examples of Row Operations .................................. 25 78 C.1. CreateRow with RowStatus .................................. 25 79 C.2. CreateRow with RowState ................................... 26 80 C.3. DeleteRow ................................................. 27 81 C.4. GetRow and GetNextRow ..................................... 28 82 D. Known issues ................................................ 29 83 E. Full Copyright Statement .................................... 31 85 1. The SNMP Network Management Framework 87 The SNMP Management Framework presently consists of five major 88 components: 90 - An overall architecture, described in RFC 2571 [RFC2571]. 92 - Mechanisms for describing and naming objects and events for the 93 purpose of management. The first version of this Structure of 94 Management Information (SMI) is called SMIv1 and described in 95 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 96 The second version, called SMIv2, is described in RFC 2578 97 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 99 - Message protocols for transferring management information. The 100 first version of the SNMP message protocol is called SNMPv1 and 101 described in RFC 1157 [RFC1157]. A second version of the SNMP 102 message protocol, which is not an Internet standards track 103 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 104 and RFC 1906 [RFC1906]. The third version of the message 105 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 106 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 108 - Protocol operations for accessing management information. The 109 first set of protocol operations and associated PDU formats is 110 described in RFC 1157 [RFC1157]. A second set of protocol 111 operations and associated PDU formats is described in RFC 1905 112 [RFC1905]. 114 - A set of fundamental applications described in RFC 2573 115 [RFC2573] and the view-based access control mechanism described 116 in RFC 2575 [RFC2575]. 118 A more detailed introduction to the current SNMP Management Framework 119 can be found in RFC 2570 [RFC2570]. 121 Managed objects are accessed via a virtual information store, termed 122 the Management Information Base or MIB. Objects in the MIB are 123 defined using the mechanisms defined in the SMI. 125 This memo specifies a MIB module that is compliant to the SMIv2. A 126 MIB conforming to the SMIv1 can be produced through the appropriate 127 translations. The resulting translated MIB must be semantically 128 equivalent, except where objects or events are omitted because no 129 translation is possible (use of Counter64). Some machine readable 130 information in SMIv2 will be converted into textual descriptions in 131 SMIv1 during the translation process. However, this loss of machine 132 readable information is not considered to change the semantics of the 133 MIB. 135 2. Overview 137 This document describes a set of SNMP extensions to current protocol 138 operations [RFC1905] to provide for efficient row operations (i.e. 139 creating, modifying, deleting and retrieving table rows). In 140 addition, a new textual convention, RowState, is defined to replace 141 RowStatus in future MIBs. RowState maintains the ability to report 142 the state of a row, but does not attempt to provide a mechanism to 143 create or delete a row. 145 APPENDIX A discusses some of the known impacts that these extensions 146 may cause to current frameworks or protocols (e.g. AgentX). 148 It is recognized that any one of several other approaches exist that 149 could have been used to meet the design goals of this document. As 150 such, a few of these approaches are briefly discussed in APPENDIX B. 152 2.1. Terms 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 Terminology such as "leftmost" or "left" indicates a PDU component 159 that is transmitted on the wire prior to other components. Thus, 160 terms such as "rightmost" imply components that have similar, but 161 opposite semantics. 163 Protocol operation refers to a high-level request, such as a 164 SetRequest or GetRequest (or one of the five new requests defined 165 within this document). Row operation refers to one logical operation 166 that affects one specific table row. A protocol operation may contain 167 one or more row operations. The term rowOp refers to the component 168 parts of a protocol operation that comprise a single row operation. 170 2.2. Motivations for the Extensions 172 Experience has shown that current SNMP protocol operations and 173 management structures are not ideally suited to effect configuration 174 changes within managed devices and when retrieving information. The 175 extensions described in this document are specifically designed to 176 minimize, or provide opportunities to minimize the following problems 177 which inhibit th effectiveness of SNMP: 179 - Requests that contains multiple varbinds that affect one row of 180 a table may contain significant redundancy of information. This 181 is because each varbind contains an object name (i.e. Object 182 Identifier or OID), and these OIDs may differ only in the 183 single subid that designates a specific column. In cases where 184 strings are used as instance identifiers, for example, UDP 185 maximum-message-size constraints may force multiple SetRequests 186 to be used to construct a new, or modify an existing row in a 187 table. Requests containing redundant data are also more costly 188 to encrypt and decrypt. 190 - SetRequests may contain multiple varbinds that actually refer 191 to the same MIB object. For example, varbind one may be 192 attempting to set the object, foo, to the value 1, while 193 varbind two may be attempting to set the same object, foo, to 194 the value 2. In such cases, the SNMP protocol indicates that 195 implementations may make independant decisions as to which 196 varbind will effectively be used as the final result. 198 - SetRequests do not impose any ordering requirements on the 199 varbinds within a single request, even if they affect different 200 objects in the same row of a table. This can cause added 201 complexity in SetRequest processing. 203 - The RowStatus textual convention [RFC1903] provides a mechanism 204 for row management. RowStatus most often requires the 205 implementation of a rather complicated state machine, many of 206 whose transitions are optional and whose target states are at 207 times non-deterministic. RowStatus also confuses the notion of 208 row status with the notion of row fate, which also tends to 209 complicate both the MIB design and the implementation. 211 2.3. Design Goals 213 Several goals were identified when considering the kinds of 214 extensions that were needed: 216 - allow separate row operations (hereafter referred to as rowOps) 217 to be performed in a single protocol operation. 219 - minimize redundant information in a protocol operation. The 220 extensions should at least make use of OID suppression 221 techniques to meet this goal. Note that OID suppression 222 (largely an issue of how data is stored within a PDU) is not 223 equivalent to OID compression (data compression algorithms). 224 Issues of OID compression are considered out of scope for this 225 document. 227 - eliminate the need for special MIB objects (e.g. RowStatus) 228 that control the creation and deletion of rows. 230 - minimize the impact on existing network management and subagent 231 protocols such as SNMPv3, AgentX, and related applications. 233 - interoperate with legacy MIBs as well as future MIBs. 235 - operate in existing SNMP networks and not disrupt legacy SNMP- 236 capable devices. 238 3. The Extensions 240 Five new conceptual protocol operations are described in this 241 document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU 242 (aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU 243 (aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of 244 these request types are based on the same PDU structure as originally 245 defined in [RFC1905]. 247 For purposes of discussion, the three requests, CreateRow, DeleteRow 248 and EditRow are more generically referred to as SetRow class 249 requests, while GetRow and GetNextRow are referred to as RetrieveRow 250 class requests. 252 In addition, a RowState textual convention is defined and is intended 253 to replace RowStatus in all future MIB designs. It is not the 254 intention to deprecate RowStatus. Although RowState is not a protocol 255 operation, it does serve to reestablish a distinction between SNMP 256 data types and SNMP operations -- a line which is blurred in the 257 current RowStatus definition. 259 3.1. RowState 261 As mentioned earlier, this document defines a proposed textual 262 convention, RowState, whose purpose is to replace RowStatus in future 263 MIBs. This convention provides several important improvements over 264 RowStatus: 266 - RowState relaxes some of the row timeout rules that RowStatus 267 suffers from. Such rules inhibit the usefulness of RowStatus as 268 a means of temporarily placing system resources (i.e. table 269 rows) out of service. For example, if an SNMP manager changes 270 a given instance of snmpNotifyRowStatus from Active to 271 NotInService as a means of temporarily disabling one or more 272 notifications, an unintended side-effect of this action on some 273 implementations may be that the row is automatically deleted 274 after some short amount of time has elapsed (typically, a few 275 minutes). 277 - More importantly, RowState separates the notion of reporting 278 row status and the notion of managing row fate (i.e. creation & 279 deletion). Specifically, the purpose of RowState is to enable 280 reporting of row state, while matters of creating and deleting 281 rows are better served by protocol operations. 283 RowState provides three states: NotReady, NotInService and Active, 284 which are very similar to the corresponding RowStatus definitions. 285 Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo 286 or Destroy. 288 Any entity providing a RowState column in a table must instantiate an 289 instance of RowState when one or more other column objects in the 290 same row have been created or instantiated (by whatever means). Using 291 the new protocol operations defined in this document, it is 292 unnecessary to directly set or reference a RowState instance in order 293 to create and activate a new row. The initial state of RowState is 294 determined at the moment of initial row creation according to the 295 semantics specified by the MIB designer (as provided within the 296 Description clause of the RowState object, and much in the same way 297 that RowStatus descriptions customize the semantics of those 298 objects). At the time of row creation, the row creator may explicitly 299 set the RowState object to a desired initial value, but the 300 processing entity refers to this as a kind of "hint" since the final 301 decision as to the initial value can only be determined after the 302 complete row contents within the creation operation have been 303 evaluated. 305 One of the other differences between RowState and RowStatus is that 306 RowState objects can never be automatically deleted from the entity 307 as a result of timeouts when their states are either NotInService or 308 Active. This provides the ability to use RowState objects to 309 indefinitely take a row out of service without the fear of it being 310 automatically deleted. When and whether rows containing RowState 311 objects are added to, or removed from, non-volatile storage are not 312 addressed by RowState. Such behavior must be specified by other 313 means (e.g. StorageType), which is out of scope for this document. 315 In addition, unlike RowStatus, it is permissible to explicitly set 316 RowState objects to the NotReady state as a crude means of allowing 317 traditional SetRequests to delete the row. In this case, deletion 318 occurs as a side effect of a row timeout. As will be shown, the 319 preferred method of deleting any row is via use of the new DeleteRow 320 request, which does not contain any direct reference to any specific 321 row object (such as RowState). 323 The CreateRow request introduces the ability to set either RowStatus 324 or RowState objects without the need to explicitly include a varbind 325 in the request. A CreateRow request by convention contains an 326 implicit operand (i.e. varbind) to set a corresponding RowState 327 object (if any) to the Active value. This implicit varbind can be 328 overridden by the inclusion of an actual RowState varbind. For 329 example, the following two CreateRow requests are logically 330 identical, as both will attempt to create a newly active fooEntry, 331 whose index is 1, and whose fooInt object equals 2: 333 CreateRow (fooEntry.1, fooInt=2); 334 CreateRow (fooEntry.1, fooInt=2, fooRowState=Active); 336 These two requests are NOT logically identical: 338 CreateRow (fooEntry.1, fooInt=2); 339 CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService); 341 Implementations are not required, however, to support such implicit 342 operands within CreateRow requests for RowStatus objects. This is 343 intended to maximize the set of possible transition solutions for 344 vendors of SNMP technology. 346 The RowState textual convention provides full details of its use and 347 operation and is provided in section 6. 349 3.2. Row Operations 351 The new protocol operations are designed to "fit" in the existing PDU 352 structure as originally defined in [RFC1905]. One of the alternative 353 approaches discussed in the Appendix is the possibility of defining a 354 new PDU structure that allows a more efficient OID suppression 355 strategy than the one described herein. However, the initial approach 356 offered in intended to "look and feel" as close to the current 357 framework as possible. As will be shown, the current PDU structure is 358 quite sufficient to obtain significant (but not optimal) OID 359 suppression benefits. 361 Formal definitions of the new protocol operations are provided in 362 section 5. [RFC1905] provides the PDU definition which these new 363 operations are based on. 365 Although the old PDU structure is maintained for now, this document 366 specifies an evolutionary approach in the way that the new protocol 367 operations are encoded or contained within the PDU. As such, the new 368 requests capitalize on OID suppression techniques to minimize 369 information redundancy and therefore minimize PDU size. Note that the 370 traditional SNMP protocol operations as defined in [RFC1905] are not 371 being changed, either in their semantics, the way data is encoded 372 within them, or the way they are processed. 374 The following general discussion centers on how the varbinds of the 375 new protocol operations are formed or constructed. Other components 376 of the PDU (e.g. error-index) are treated similarly to the current 377 framework. The elements of procedure, section 4, formally describes 378 how the new requests are processed. APPENDIX C provides some high- 379 level examples of the use of these operations. 381 The varbinds in a PDU form one or more independant row operations 382 (rowOps). This allows a single CreateRow request, for example, to 383 create one or more new rows in a single protocol operation. Each 384 rowOp corresponds to one attempt to create a row, in this case, or 385 corresponds to one attempt to delete a row in the case of DeleteRow, 386 and so forth. 388 Note that the three layers in the diagram below do not describe 389 different sections of the PDU, rather, they each represent the same 390 information and structure (at different levels of abstraction). 392 393 394 396 Although the above diagram shows a CreateRow request logically 397 containing three rowOps (i.e. create three rows) with two consecutive 398 varbinds per rowOp, in reality, these requests may contain one, two, 399 or more than two rowOps, each of which may may be comprised of a 400 differing number of varbinds (i.e. zero, one, or more than one). In 401 addition, the above example (and the ones that follow) could have 402 substituted a RetrieveRow class request instead of CreateRow, 404 The varbinds allocatted to a single rowOp serve to function as either 405 a rowIdentifier or as operands. 407 3.2.1. The rowIdentifier 409 The first varbind in each rowOp provides basic request parameters, 410 and is hereafter referred to as the rowIdentifier parameter of a 411 rowOp. The remaining varbinds in a given rowOp provide the 412 individual operands (i.e. the affected row objects), which are 413 hereafter referred to as operands. In the diagram above, the 1st, 3rd 414 and 5th varbinds are therefore rowIdentifiers while the 2nd, 4th and 415 6th varbinds are operands. 417 The following diagram shows a GetRow request containing a single 418 rowOp that itself is composed of the required rowIdentifier and two 419 operands. 421 422 423 425 In this case, the GetRow request is seeking to retrieve two specific 426 column objects from a specific row. 428 To understand how each rowIdentifier varbind is constructed and what 429 information is contained therein, it is useful to consider how OIDs 430 for table objects are formed. 432 An OID for a given object instance in a table can be broken up into 433 three logical components: 435 OID = 437 If a traditional SetRequest contains two varbinds referring to two 438 different columns in the same row, it is evident that both OIDs 439 differ only in the integer value of the columnPart (a single subid). 440 The other two parts, tableEntryPart and instancePart, therefore, are 441 identical for each varbind present in a request affecting only a 442 single table. 444 A more meaningful representation for rowIdentifier is now possible: 446 rowIdentifier = 450 The vb.type MUST specify a type of OID. This is because the 451 instancePart of an OID is actually comprised of one or more table 452 index values, depending on which table is affected and how many MIB 453 objects comprise the INDEX clause of that table. For example, for a 454 table whose INDEX is comprised of a single integer, instancePart will 455 be a single subid; and for a table whose INDEX is comprised of two or 456 more objects of any kind, the instancePart will be an OID (index1 + 457 index2 + ... + indexN) with each index component representing one or 458 more subids. 460 Because the instancePart always resolves to one or more subids, and 461 because a valid OID must be composed of at least two subids, we 462 prefix the instancePart with the OID value of 0.1. The reason 463 instancePart cannot simply be prefixed with a single subid is that 464 OIDs of the form 0.X, where X > 39, are not legal. Thus, if 465 instancePart resolved to a single subid of 40 (or greater), the value 466 of 0.40 would be illegal. Thus the need to prefix instancePart with 467 two subids that guarantee a valid OID will be formed regardless of 468 how instancePart is resolved. Note that due to ASN.1/BER encoding 469 rules, the first two subids comprise only a single byte within the 470 PDU. 472 The rowIdentifier of each rowOp in a SetRow or RetrieveRow request 473 specifies the exact row affected by the rowOp (but not which column 474 objects are affected in that row). 476 Consider the case of two or more rowOps in, say, a SetRow request 477 that only affects different rows in the same table. In such cases, 478 the varbind names of all the rowIdentifier varbinds will contain 479 identical values. In order to therefore further minimize information 480 redundancy, the OID of 1.0 (hereafter referred to as the inheritance 481 OID, and occupying only a single byte within the resulting PDU) is 482 permitted to be substituted as the varbind name of any rowIdentifier 483 to indicate that the most recent (leftmost) rowIdentifier whose name 484 is dissimilar (not 1.0) contains the OID value intended to be used. 486 In this example, a simplified notation is used to help illustrate how 487 a rowOp (the two middle ones in this case) uses the inheritance OID 488 to minimize PDU size. This example shows four rowOps, each comprised 489 of one rowIdentifier and one operand (op): 491 [] [<1.0>] [<1.0>] [] 493 The following is logically identical to the preceding example (though 494 it forms a larger PDU): 496 [] [] [] [] 498 Of course, this implies that rowOps that affect the same table SHOULD 499 be consecutively placed in the PDU varbind list, and also that the 500 first rowIdentifier in the PDU MUST NOT contain the inheritance OID. 502 Each rowOp is fully independant of any other despite any inheritance 503 it may use. 505 Each rowOp MUST contain a single rowIdentifier varbind, which MUST be 506 the first varbind in each rowOp. The tableEntryPart of a 507 rowIdentifier MUST NOT contain partial OIDs. This means that the 508 tableEntryPart MUST always exactly correspond to a legal table entry 509 definition (if the desired results are to be achieved). The 510 motivation behind this is that all rowOps are performed at the row 511 level. 513 The instancePart within a GetNextRow is not required to be fully 514 formed except that if the value is non-NULL, it MUST at least contain 515 the 0.1 prefix. Also note that GetNextRow requests do not "jump" to 516 the next table. In other words, in the event a GetNextRow rowOp 517 refers to the last row in a given table, the appropriate exception is 518 returned for that rowOp even if other tables follow that contain 519 retrievable rows. In this sense, GetNextRow is limited to operate 520 within the subtree of the targeted table(s). 522 3.2.2. The operands 524 The remaining varbinds for a given rowOp are referred to as its 525 operands, and are formed as standard SetRequest varbinds except that 526 the name of each varbind is an OID whose length is exactly three 527 subids long. The first two subids MUST be 0.1 and the third subid is 528 taken from the affected column descriptor value whose object instance 529 is affected. The reason three subids are specified (0.1.columnSubid) 530 instead of two (0.columnSubid) is that columnSubid must accept all 531 values in the range from 0 to 4294967295. However, the ASN.1/BER 532 encoding rules do not allow OID values of 0.X where X > 39. Note 533 that typical OIDs formed this way (where columnSubid is small) will 534 be comprised of only two bytes despite the fact that three subids are 535 specified. 537 Each operand contained in the same rowOp will have a varbind name 538 such that varbind N MUST be lexicographically smaller than the name 539 of varbind N+1. In other words, there is a left to right ordering 540 relationship imposed on the rowOp operands to further provide 541 implementation optimization opportunities and to further guarantee 542 that multiple and possibly conflicting operands for the same column 543 object cannot be provided (further minimizes information redundancy 544 and processing ambiguity). For example, the operand with the name 545 of, 0.1.0, MUST be to the left of the operand with the name of, 546 0.1.1, if they are operands of the same rowOp. 548 Any rowOp may contain zero or more operands, except that the EditRow 549 request MUST contain at least one operand. 551 In case of RetrieveRow requests, if zero operands are provided in a 552 rowOp, this implicitly calls for the retrieval of all instantiated 553 objects in the affected row. Otherwise, only the specified objects 554 are retrieved. 556 In cases of CreateRow, at least one column definition in each of the 557 affected tables must have a MAX-ACCESS of read-create and the the 558 affected rows MUST NOT already exist (in whole or part). If zero 559 operands are provided in a rowOp, then the row must be able to be 560 created in whole or part using only default values. 562 In cases of EditRow, each rowOp contains an operand for each row 563 object whose value is being changed and whose MAX-ACCESS is either 564 read-create or read-write. The affected rows MUST already exist (in 565 whole or part), though the specific operands MAY refer to objects 566 that do not yet exist. 568 In cases of DeleteRow, each rowOp MAY contain operands whose MAX- 569 ACCESS are either read-write or read-create. While it is not 570 essential that operands be included in a DeleteRow request, they may 571 in special cases be useful, for example, when a proxy application 572 translates a DeleteRow request to a conventional SetRequest that 573 requires a RowStatus reference. 575 3.2.3. Distinguishing rowIdentifiers from operands 577 As described earlier, the varbinds in a rowOp function either as a 578 rowIdentifier (one per rowOp) or as an operand (zero or more per 579 rowOp). By definition, the first varbind in any SetRow or RetrieveRow 580 request MUST be a rowIdentifier. The varbind names of all 581 rowIdentifiers are guaranteed to be OIDs with a minimum of four 582 subids (because current SMIv2 rules and current IANA object 583 registrations preclude the possibility that table entry definitions 584 can have shorter OIDs). One exception to this, is that varbind names 585 for rowIdentifiers may contain the inheritance OID value of, 1.0 (see 586 earlier discussion for how and why this is used). 588 The varbind names of all operands, on the other hand, are OID values 589 with exactly three subids whose first two subids form an OID of 590 0.1.X. 592 In summary, if a varbind name contains an OID of the form 0.1.X 593 (exactly three subids) then the varbind in question functions as an 594 operand. Otherwise, the varbind functions as a rowIdentifier. 596 3.2.4. RowState and RowStatus Considerations 598 It is worthwhile to note that SetRow class requests allow new MIBs to 599 be created without requiring use of the RowStatus or RowState textual 600 conventions to allow for either incremental or "big-bang" style (i.e. 601 CreateAndWait or CreateAndGo, resp.) row creation or deletion. 602 RowState is useful only to report the current state of a row -- 603 notwithstanding the slight anomaly that it also allows SetRequests 604 and EditRow requests to explicitly change the state of such objects 605 to NotReady, and thereby cause a row deletion timer to be 606 instantiated. Similarly, traditional SetRequests and SetRow requests 607 can both be used to manage MIBs that incoporate RowStatus columns. 608 For new MIB tables that do not require row state reporting objects, 609 but which do require creation and/or deletion semantics, it is 610 sufficient to omit RowState and RowStatus entirely and instead use a 611 MAX-ACCESS of read-create for all writable objects. Such tables can 612 elegantly support row creation through use of the CreateRow or 613 traditional SetRequest operations, and also support row deletion 614 through use of the DeleteRow operation. 616 3.2.5. Granularity of Success/Fail 618 In the event a SetRow class request contains two or more rowOps that 619 affect the same row, the elements of procedure (below) indicate that 620 all rowOps in the SetRow request are to be rejected (i.e. all rowOps 621 fail and the entity remains in the state it was in prior to receiving 622 the SetRow request). 624 RetrieveRow class requests can succeed or fail individually or even 625 with each varbind. 627 3.2.6. Response PDUs 629 This document does not define any new response PDU. Instead, the 630 traditional Response-PDU [RFC1905] is used as the standard response 631 to each of the SetRow and RetrieveRow requests, except that the 632 varbinds are constructed using the same OID suppression techniques as 633 described above. 635 4. Elements of Procedure 637 4.1. CreateRow Request Processing 639 TBD 641 4.2. DeleteRow Request Processing 643 TBD 645 4.3. EditRow Request Processing 647 TBD 649 4.4. GetRow Request Processing 651 TBD 653 4.5. GetNextRow Request Processing 655 TBD 657 4.6. Response-PDU Processing 659 TBD 661 5. Coexistence and Transition 663 An essential requirement for these operations is that they must 664 operate seamlessly in existing networks and not disrupt legacy SNMP 665 devices. This is satisfied by the fact that the new protocol 666 operations have new and unique ASN.1 tags, which allow older 667 implementations to efficiently and silently drop these new PDU 668 requests. 670 Some entities may only support these extensions for certain tables. 671 For example, different AgentX subagents may or may not support these 672 operations. This requires that the requests fail whenever a table is 673 targeted that cannot support the new operation. The elements of 674 procedure indictate the proper exceptions in these cases. 676 It is also possible that some table implementations may support only 677 some subset of the new operations, for example, the RetrieveRow 678 requests, but not the SetRow requests. It is herein RECOMMENDED that 679 SNMP entities that support at least one operation within a class 680 (i.e. SetRow or RequestRow) for a given table SHOULD support all 681 requests within the same class for that table. Also, it is further 682 RECOMMENDED that if the SetRow class of operations are supported for 683 a given table, then the entity SHOULD also support all the 684 RetrieveRow operations for that table. For any operation not 685 supported by a targeted table (which nevertheless supports other 686 operations), the elements of procedure indicate the proper exceptions 687 that apply. 689 In an ideal world, the extensions herein would be easily translatable 690 to traditional operations. However, this is not the case. 692 Consider, for example, that it is impossible to form an equivalent 693 SetRequest from a DeleteRow request that contains only a 694 rowIdentifier but no operands. In fact, any SetRow or RetrieveRow 695 request containing no operands cannot be translated into an 696 equivalent Set/Get request because at least one operand is needed to 697 convert the rowIdentifier information into a valid object (OID) 698 reference. DeleteRow may optionally include a RowStatus object, which 699 allows such a translation, but then the question arises as to the 700 need for DeleteRow definitions in the first place. 702 Or consider a proxy application that accepts CreateRow or EditRow 703 requests and translates them into an equivalent SetRequest. For 704 example, CreateRow(fooEntry.row1, fooInt=1) is translated into 705 Set(fooEntry.fooInt.row1=1). Note that an EditRow request containing 706 the same varbind info would be translated into the exact same Set 707 request. This implies that proxy applications cannot faithfully 708 translate these two extensions into a SetRequest with the same 709 semantics as the original request. A CreateRow request, after 710 translation, might incorrectly cause an existing row to be modified, 711 whereas an EditRow request might cause a new row to be instantiated. 712 A partial workaround is to explicitly include a RowStatus reference 713 in all CreateRow requests, and to ensure that rows do not exist 714 before issuing EditRow requests, though in multi-manager 715 environments, this latter procedure suffers. 717 The same issues are evident when a master agent needs to translate 718 the extensions into traditional subagent PDU forms. Semantics may be 719 lost in the translation, and only some amount of workaround is 720 possible unless the underlying subagent protocol is itself extended 721 to accomodate the new extensions. 723 While it is possible to develop proxy applications that incorporate 724 simple PDU translation schemes to generally allow EOS-capable devices 725 (as described herein) to interoperate with non-EOS-capable devices, 726 the workarounds that would be needed might in some (but not all) 727 environments mitigate some or all of the benefits in using the new 728 extensions in the first place. 730 In short, with the approach outlined in this document, it is believed 731 that non-EOS-capable devices need to be converted into EOS-capable 732 devices by means other than simple PDU translation schemes. In order 733 to enable a transition strategy that uses simple PDU translation 734 mechanisms, at least some of the earlier stated goals of this 735 document would have to be abandoned (e.g. the goal to replace MIB 736 objects such as RowStatus which confuse the notions of row state with 737 row fate, and perhaps other goals as well). 739 6. Protocol Operations Definitions 741 SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN 743 IMPORTS 744 PDU 745 SNMPv2-PDU; 747 ROWOP-PDUs ::= 748 CHOICE { 749 create-row-request 750 CreateRowRequest-PDU, 752 delete-row-request 753 DeleteRowRequest-PDU, 755 edit-row-request 756 EditRowRequest-PDU, 758 get-row-request 759 GetRowRequest-PDU, 761 get-next-row-request 762 GetNextRowRequest-PDU 763 } 765 CreateRowRequest-PDU ::= 766 [9] 767 IMPLICIT PDU 769 DeleteRowRequest-PDU ::= 770 [10] 771 IMPLICIT PDU 773 EditRowRequest-PDU ::= 774 [11] 775 IMPLICIT PDU 777 GetRowRequest-PDU ::= 778 [12] 779 IMPLICIT PDU 781 GetNextRowRequest-PDU ::= 782 [13] 783 IMPLICIT PDU 785 END 787 7. Managed Object Definitions 789 SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN 791 IMPORTS 792 MODULE-IDENTITY, OBJECT-TYPE, 793 OBJECT-IDENTITY, 794 snmpModules FROM SNMPv2-SMI 795 TEXTUAL-CONVENTION FROM SNMPv2-TC 796 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 798 snmpRowopMIB MODULE-IDENTITY 799 LAST-UPDATED "200104191653Z" 800 ORGANIZATION "EOS Working Group" 801 CONTACT-INFO "WG-EMail: eos@ops.ietf.org 802 Subscribe: eos-request@ops.ietf.org 804 Co-Chair: Dale Francisco 805 Cisco Systems, Inc. 806 postal: 80 West Tasman Drive 807 San Jose, CA 95134 808 USA 809 EMail: dfrancis@cisco.com 810 phone: +1 408-527-9787 812 Co-Chair: Glenn Waters 813 Nortel Networks 814 postal: 815 USA 816 EMail: gww@nortelnetworks.com 817 phone: 819 Co-editor: Lauren Heintz 820 Cisco Systems, Inc. 821 postal: 130 Baytech Drive 822 San Jose, CA 95134 823 USA 824 EMail: lheintz@cisco.com 825 phone: +1 408-853-6568 826 " 827 DESCRIPTION "The SNMP Row Operations MIB" 828 REVISION "200103280000Z" 829 DESCRIPTION "The initial version, published in 830 draft-ietf-eos-snmp-rowops-00.txt. 831 " 833 ::= { snmpModules TBD } 835 -- Textual Conventions 837 RowState ::= TEXTUAL-CONVENTION 838 STATUS current 839 DESCRIPTION "TBD" 840 SYNTAX INTEGER {TBD} 842 END 844 8. IANA Considerations 846 This document requires IANASnmpExtendedProtocol values to be reserved 847 for allowing command responders to advertise their ability to support 848 the extensions outlined in this document. IANASnmpExtendedProtocol 849 values are administered by IANA. IANASnmpExtendedProtocol is defined 850 in SNMP-X-PROTOCOL-TC. 852 9. Intellectual Property 854 The IETF takes no position regarding the validity or scope of any 855 intellectual property or other rights that might be claimed to 856 pertain to the implementation or use of the technology described in 857 this document or the extent to which any license under such rights 858 might or might not be available; neither does it represent that it 859 has made any effort to identify any such rights. Information on the 860 IETF's procedures with respect to rights in standards-track and 861 standards-related documentation can be found in BCP-11. Copies of 862 claims of rights made available for publication and any assurances of 863 licenses to be made available, or the result of an attempt made to 864 obtain a general license or permission for the use of such 865 proprietary rights by implementors or users of this specification can 866 be obtained from the IETF Secretariat. 868 The IETF invites any interested party to bring to its attention any 869 copyrights, patents or patent applications, or other proprietary 870 rights which may cover technology that may be required to practice 871 this standard. Please address the information to the IETF Executive 872 Director. 874 10. Acknowledgements 876 This document is the result of the efforts of the Evolution Of SNMP 877 (EOS) Working Group. Some special thanks are in order to the 878 following EOS WG members: 880 TBD 882 11. Security Considerations 884 TBD 886 12. References 888 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 889 Identification of Management Information for TCP/IP- 890 based internets", STD 16, RFC 1155, May 1990. 892 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 893 Simple Network Management Protocol", STD 15, RFC 1157, 894 May 1990. 896 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 897 STD 16, RFC 1212, March 1991. 899 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 900 Rose, M. and S. Waldbusser, "Introduction to 901 Community-based SNMPv2", RFC 1901, January 1996. 903 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 904 Architecture for Describing SNMP Management Frameworks", 905 RFC 2571, April 1999. 907 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 908 "Structure of Management Information Version 2 (SMIv2)", 909 STD 58, RFC 2578, April 1999. 911 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 912 "Textual Conventions for SMIv2", STD 58, RFC 2579, April 913 1999. 915 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 916 "Conformance Statements for SMIv2", STD 58, RFC 2580, 917 April 1999. 919 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 920 Waldbusser, "Protocol Operations for the Simple Network 921 Management Protocol", , April 2001. 924 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 925 Waldbusser, "Transport Mappings for the Simple Network 926 Management Protocol", , April 2001. 929 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 930 Waldbusser, "Management Information Base for the Simple 931 Network Management Protocol", , April 2001. 934 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 935 "Coexistence between Version 1, Version 2, and Version 3 936 of the Internet-standard Network Management Framework", 937 , April 2001. 939 [RFC1909] McCloghrie, K., Editor, "An Administrative 940 Infrastructure for SNMPv2", RFC 1909, February 1996. 942 [RFC1910] Waters, G., Editor, "User-based Security Model for 943 SNMPv2", RFC 1910, February 1996. 945 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 946 10646", RFC 2279, January, 1998. 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in 952 the IETF Standards Process", BCP 11, RFC 2028, October 953 1996. 955 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group 956 MIB." RFC 2863, June 2000. 958 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 959 "Message Processing and Dispatching for the Simple 960 Network Management Protocol (SNMP)", , April 2001. 963 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 964 Model for Version 3 of the Simple Network Management 965 Protocol (SNMPv3)", , 966 April 2001. 968 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 969 Access Control Model for the Simple Network Management 970 Protocol (SNMP)", , 971 February 1999. , 972 April 2001. 974 [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP 975 Applications", , April 976 2001. 978 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 979 "Introduction to Version 3 of the Internet-standard 980 Network Management Framework", , January 1999. 983 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 984 "Coexistence between Version 1, Version 2, and Version 3 985 of the Internet-standard Network Management Framework", 986 , April 2001. 988 13. Editor's Addresses 990 Lauren Heintz 991 Cisco Systems, Inc. 992 130 Baytech Drive 993 San Jose, Ca 95134 995 Phone: +1 408-853-6568 996 EMail: lheintz@cisco.com 998 APPENDIXES 1000 A. Impact to SNMP and other Protocols 1002 A.1. SNMPv3 1004 An issue remains whether a new message processing model MUST be 1005 specified as part of the SNMPv3 (or later) standard. Otherwise, it is 1006 not seen that these extensions pose any impact to other SNMPv3 1007 architectural components (i.e. USM, VACM) because the new protocol 1008 operations and their contents contain sufficient information (along 1009 with the information provided in whatever version-specific message 1010 wrapper they are contined within) to satisfy the abstract service 1011 interfaces for those components. 1013 However, these extensions are not compatible with the SNMPv3 proxy 1014 application (or any legacy SNMP application incorporating a message 1015 processing module that receives and processes or forwards SNMP 1016 messages). 1018 A.2. AgentX 1020 These extensions imply that AgentX will have to evolve in order to 1021 support the new protocol operations. For example, AgentX does not 1022 provide a delete PDU (to support DeleteRow), and neither does its 1023 TestSet PDU provide for a standard way to indicate whether the 1024 operation being performed maps to a CreateRow or EditRow request. 1025 Furthermore, master agents will need to know how to recognize and 1026 process the new protocol operations (i.e. distinguish rowIdentifiers 1027 from operands, logically expand the targeted object OIDs and map them 1028 to subtree registrations). 1030 B. Alternative Approaches 1032 This section will be deleted before going standards track. 1034 This document outlines one approach to achieving the design goals 1035 stated earlier. Several other approaches also exist. Here are some 1036 hints: 1038 - Use the same approach described herein except define a new 1039 "RowPDU" to further optimize OID suppression (i.e. get rid of 1040 the 0.1.X column subid notation). This may require a new kind 1041 of varbind list where each varbind is no longer an OID/value 1042 pair, but instead it is an Integer/Value pair. Similarly, this 1043 new PDU could contain one or more rowIdentifier items (one per 1044 rowOp). 1046 - Instead of having five new request types, use only one instead 1047 and perhaps have an operator within the request to indicate the 1048 nature of the operation. Also, the operator might be included 1049 within each rowOp contained within the request so that one 1050 protocol operation might contain mixed row operations (i.e. a 1051 createRow and deleteRow might co-exist in the same protocol 1052 request). 1054 - Maintain the same PDU structure, but re-define what a varbind 1055 is (i.e. one varbind might actually be able to contain a 1056 sequence of objects, all of which pertain to one row 1057 operation). You'd still have to define where/how you designate 1058 which row(s) and column(s) are affected. 1060 - Nix the RowState idea, keep RowStatus, and simply provide 1061 traditional protocol operations, perhaps with a way of 1062 minimizing overhead. In this case, we would tradeoff feature 1063 set richness with the potential of being able to provide easier 1064 transition solutions for legacy systems (i.e. the requests 1065 might be more easily translatable into conventional requests). 1067 - Some combination of the above, or other? 1069 C. Examples of Row Operations 1071 Each of the following examples assumes that the error-index and 1072 error-status fields of the manager initiated request are set to 0 and 1073 the request-id contains an appropriate value. 1075 C.1. CreateRow with RowStatus 1077 This protocol exchange illustrates the use of the CreateRow request 1078 to create two new rows in the snmpNotifyTable [RFC2573]. This table 1079 uses RowStatus, so we choose to explicitly set its value for each 1080 row, as desired (some impls may allow us to instead omit setting 1081 RowStatus and rely on implicit support for it). 1083 Note that the second rowOp inherits its table OID information from 1084 the previous rowOp (because 1.0 instructs this). 1086 CreateRow 1087 ( 1088 -- rowOp 1 1090 -- rowIdentifier (table and instance) 1091 vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1092 vb1.value(OID) = 0.1.114.111.119.49 -- "row1" 1094 vb2.name = 0.1.2 -- snmpNotifyTag 1095 vb2.value(SnmpTagValue) = "tag1" 1097 vb3.name = 0.1.3 -- snmpNotifyType 1098 vb3.value(INT) = 1 -- trap 1100 -- skip snmpNotifyStorageType. Use DEFVAL 1102 vb4.name = 0.1.5 -- snmpNotifyRowStatus 1103 vb4.value(RowStatus) = createAndGo 1105 -- rowOp 2 1107 -- rowIdentifier (table and instance) 1108 vb5.name = 1.0 -- inherit snmpNotifyEntry 1109 vb5.value(OID) = 0.1.114.111.119.50 -- "row2" 1111 vb6.name = 0.1.5 -- snmpNotifyRowStatus 1112 vb6.value(RowStatus) = createAndWait 1113 ) 1115 C.2. CreateRow with RowState 1117 This protocol exchange illustrates the use of the CreateRow request 1118 to create two new rows in the snmpNotifyTable [RFC2573] except that 1119 we pretend here that RowState was used in the design of that table 1120 instead of RowStatus. 1122 CreateRow 1123 ( 1124 -- rowOp 1 1126 -- rowIdentifier (table and instance) 1127 vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1128 vb1.value(OID) = 0.1.114.111.119.49 -- "row1" 1130 vb2.name = 0.1.2 -- snmpNotifyTag 1131 vb2.value(SnmpTagValue) = "tag1" 1133 vb3.name = 0.1.3 -- snmpNotifyType 1134 vb3.value(INT) = 1 -- trap 1135 -- skip snmpNotifyStorageType. Use DEFVAL 1137 -- By omitting a RowState varbind, it is the 1138 -- same as setting RowState=Active. 1140 -- rowOp 2 1142 -- rowIdentifier (table and instance) 1143 vb4.name = 1.0 -- inherit snmpNotifyEntry 1144 vb4.value(OID) = 0.1.114.111.119.50 -- "row2" 1146 -- Explicitly set RowState to an initial 1147 -- value because we don't want to go 1148 -- active just yet. Even though we hint 1149 -- for an initial value of NotInService, 1150 -- it's possible that the result might 1151 -- show NotReady (if the row as defined 1152 -- by CreateRow were not ready to go Active). 1153 vb5.name = 0.1.5 -- snmpNotifyRowState 1154 vb5.value(RowState) = NotInService 1155 ) 1157 C.3. DeleteRow 1159 This example illustrates how a DeleteRow request containing two row 1160 operations is formed to delete the two rows created in either of the 1161 two previous examples. Note that the rowIdentifier in the second 1162 rowOp does not inherit the table OID from the first rowOp. Although 1163 this is legal, it also increases the request PDU size unnecessarily. 1165 DeleteRow 1166 ( 1167 -- rowOp 1 1169 -- rowIdentifier (table and instance) 1170 vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1171 vb1.value(OID) = 0.1.114.111.119.49 -- "row1" 1173 -- rowOp 2 1175 -- rowIdentifier (table and instance) 1176 vb2.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1177 vb2.value(OID) = 0.1.114.111.119.50 -- "row2" 1178 ) 1180 C.4. GetRow and GetNextRow 1182 This example illustrates how a GetRow request with three row 1183 operations is used to retrieve row information. Note that rowOp1 1184 retrieves only the snmpNotifyTag from row1, rowOp2 retrieves only the 1185 RowStatus value from row2, and rowOp3 retrieves all values from row2. 1187 rowOp2 additionally attempts to retrieve an object that does not 1188 exist in the table row. 1190 The Response PDU is also shown afterward. 1192 GetNextRow performs very similarly to GetRow except that the Response 1193 PDU will contain the object names and values from the next row in the 1194 table (if any), or will contain exceptions as placeholders where the 1195 requested objects do not exist. 1197 GetRow 1198 ( 1199 -- rowOp 1 1201 -- rowIdentifier (table and instance) 1202 vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1203 vb1.value(OID) = 0.1.114.111.119.49 -- "row1" 1205 vb2.name = 0.1.2 -- snmpNotifyTag 1206 vb2.value = NULL 1208 -- rowOp 2 1210 -- rowIdentifier (table and instance) 1211 vb3.name = 1.0 -- inherit snmpNotifyEntry 1212 vb3.value(OID) = 0.1.114.111.119.50 -- "row2" 1214 vb4.name = 0.1.5 -- snmpNotifyRowStatus 1215 vb4.value = NULL 1217 vb5.name = 0.1.999 -- doesn't exist, but try anyway 1218 vb5.value = NULL 1220 -- rowOp 3 1222 -- rowIdentifier (table and instance) 1223 vb6.name = 1.0 -- inherit snmpNotifyEntry 1224 vb6.value(OID) = 0.1.114.111.119.50 -- "row2" 1226 -- omitting all operands indicates "get all" row objects. 1227 ) 1228 ResponsePdu 1229 ( 1230 -- rowOp 1 1232 -- rowIdentifier (table and instance) 1233 vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry 1234 vb1.value(OID) = 0.1.114.111.119.49 -- "row1" 1236 vb2.name = 0.1.2 -- snmpNotifyTag 1237 vb2.value(snmpTagValue) = "tag1" 1239 -- rowOp 2 1241 -- rowIdentifier (table and instance) 1242 vb3.name = 1.0 -- inherit snmpNotifyEntry 1243 vb3.value(OID) = 0.1.114.111.119.50 -- "row2" 1245 vb4.name = 0.1.5 -- snmpNotifyRowStatus 1246 vb4.value(RowStatus) = NotInService 1248 vb5.name = 0.1.999 -- doesn't exist 1249 vb5.value(int) = NoSuchObject 1251 -- rowOp 3 1253 -- rowIdentifier (table and instance) 1254 vb6.name = 1.0 -- inherit snmpNotifyEntry 1255 vb6.value(OID) = 0.1.114.111.119.50 -- "row2" 1257 vb7.name = 0.1.2 -- snmpNotifyTag 1258 vb7.value(SnmpTagValue) = "" 1260 vb8.name = 0.1.3 -- snmpNotifyType 1261 vb8.value(INT) = 1 -- trap 1263 vb9.name = 0.1.4 -- snmpNotifyStorageType 1264 vb9.value(StorageType) = nonVolatile 1266 vb10.name = 0.1.5 -- snmpNotifyRowStatus 1267 vb10.value(RowStatus) = NotInService 1268 ) 1270 D. Known issues 1272 This section will be deleted before becoming an RFC. 1274 These are known issues that need to be resolved before going 1275 standards track: 1277 - Which SNMP message versions can these rowop PDUs be wrapped in? 1278 SNMPv3 only? 1280 - It is possible to further optimize the above PDU. For example, 1281 the instancePart of the rowIdentifiers can omit the 0.1 prefix 1282 if the instancePart contains two or subids whose first two 1283 subids are not 0.1. Furthermore, where instancePart resolves 1284 to a single subid, we can use vb.type=Unsigned32 instead, and 1285 vb.value will contain the instancePart. The cost is added 1286 complexity (special case handling). 1288 - Another possible optimization is to allow rowIdentifier varbind 1289 names to begin with the prefix 0.0 as a substitute for 1.3.6.1. 1290 This would save a few bytes per rowOp. 1292 - Change the inheritance OID from 1.0 to 0.0? 1294 - GetNextRow: Should we disallow use of wildcarding (where no 1295 operand means get all operands)? Also, requiring a complete 1296 table entry OID (instead of a partial OID) is too strict? The 1297 argument for maintaining this strictness is that this document 1298 is trying to define efficient, predictable protocol operations. 1299 Also, the OID provided cannot appear to be an operand of the 1300 previous rowOp (if any). Traditional SetRequests provide 1301 plenty of opportunity for expressiveness, if one desires such 1302 flexibility and inefficiency. This strictness, for example, 1303 may allow master agents to minimize the number of subagent 1304 protocol operations needed to fulfill a GetNextRowRequest. 1306 - Should it be a requirement that all the new proto-ops are 1307 "translatable" into traditional SNMP requests? If so, 1308 DeleteRow is not translatable, so should it be deleted? 1309 Alternatively, we can allow DeleteRow to contain one optional 1310 operand so that a RowState (or RowStatus) operand can be 1311 included. In this way, DeleteRow requests can also be 1312 translated by, for example, proxies and master agents. Also, a 1313 CreateRow request cannot be translated into a SetRequest 1314 because there is no way to convey the "create-only-if-not- 1315 exists" semantic unless a RowStatus-like object is explicitly 1316 included in the request. If this is a requirement, we may need 1317 to instead adopt the kind of approach where we nix the RowState 1318 idea and simply provide traditional protocol operations that 1319 instead make use of OID suppression or compression techniques. 1320 Cognizant SNMP entities would need to be able to distinguish 1321 such requests from traditional request formats while non- 1322 cognizant entities would predictably reject the request in some 1323 way. Cognizant entities such as proxies and master agents could 1324 then translate the requests as is appropriate (though again, 1325 many of the original motivations and goals stated earlier may 1326 not be achieved with such a solution). 1328 - Are the names for RowState and its values appropriate? Perhaps 1329 the values should be something like: Undefined, Unlocked and 1330 Locked, and the TC name should be RowLock! 1332 - Do we need a GetBulkRow request that makes use of similar OID 1333 suppression techniques as defined herein? It might be argued 1334 this would be the most effective use of OID suppression. 1336 - Should the coexistence and transition section be moved to a 1337 different document? 1339 - Should we remove the comments about the timeout issues with 1340 RowStatus from the meat of the document? 1342 E. Full Copyright Statement 1344 Copyright (C) The Internet Society (2001). All Rights Reserved. 1346 This document and translations of it may be copied and furnished to 1347 others, and derivative works that comment on or otherwise explain it 1348 or assist in its implementation may be prepared, copied, published 1349 and distributed, in whole or in part, without restriction of any 1350 kind, provided that the above copyright notice and this paragraph are 1351 included on all such copies and derivative works. However, this 1352 document itself may not be modified in any way, such as by removing 1353 the copyright notice or references to the Internet Society or other 1354 Internet organizations, except as needed for the purpose of 1355 developing Internet standards in which case the procedures for 1356 copyrights defined in the Internet Standards process must be 1357 followed, or as required to translate it into languages other than 1358 English. 1360 The limited permissions granted above are perpetual and will not be 1361 revoked by the Internet Society or its successors or assigns. 1363 This document and the information contained herein is provided on an 1364 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1365 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1366 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1367 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1368 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1370 Acknowledgement 1372 Funding for the RFC Editor function is currently provided by the 1373 Internet Society.