idnits 2.17.1 draft-schoenw-storage-type-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: ---------------------------------------------------------------------------- == 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 an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 75 instances of lines with control characters in the document. 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 (June 21, 2001) is 8335 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) -- Looks like a reference, but probably isn't: 'RFC2574' on line 483 -- Looks like a reference, but probably isn't: 'RFC2575' on line 484 == Unused Reference: '1' is defined on line 521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft TU Braunschweig 4 Expires: December 20, 2001 June 21, 2001 6 Storage Type MIB 7 draft-schoenw-storage-type-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 20, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The second version of the Structure of Management Information (SMIv2) 39 introduced the StorageType textual convention in RFC 2579. It is 40 used to describe the memory realization of rows in conceptual tables. 41 Several standards-track MIB modules make use of this convention. 42 Implementation experience shows that different approaches are used to 43 actually write conceptual rows into non-volatile memory. This memo 44 addresses this question and provides a MIB module which can be used 45 to explicitly commit non-volatile rows into non-volatile memory. 47 Table of Contents 49 1. The SNMP Management Framework . . . . . . . . . . . . . . . . 3 50 2. StorageType Interpretations . . . . . . . . . . . . . . . . . 4 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 53 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 54 6. Intellectual Property Notice . . . . . . . . . . . . . . . . . 12 55 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 57 A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 58 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 60 1. The SNMP Management Framework 62 The SNMP Management Framework presently consists of five major 63 components: 65 o An overall architecture, described in RFC 2571 [2]. 67 o Mechanisms for describing and naming objects and events for the 68 purpose of management. The first version of this Structure of 69 Management Information (SMI) is called SMIv1 and described in STD 70 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 71 second version, called SMIv2, is described in STD 58, RFC 2578 72 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 74 o Message protocols for transferring management information. The 75 first version of the SNMP message protocol is called SNMPv1 and 76 described in STD 15, RFC 1157 [9]. A second version of the SNMP 77 message protocol, which is not an Internet standards track 78 protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 79 1906 [11]. The third version of the message protocol is called 80 SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 81 [13]. 83 o Protocol operations for accessing management information. The 84 first set of protocol operations and associated PDU formats is 85 described in STD 15, RFC 1157 [9]. A second set of protocol 86 operations and associated PDU formats is described in RFC 1905 87 [14]. 89 o A set of fundamental applications described in RFC 2573 [15] and 90 the view-based access control mechanism described in RFC 2575 91 [16]. 93 A more detailed introduction to the current SNMP Management Framework 94 can be found in RFC 2570 [17]. 96 Managed objects are accessed via a virtual information store, termed 97 the Management Information Base or MIB. Objects in the MIB are 98 defined using the mechanisms defined in the SMI. 100 This memo specifies a MIB module that is compliant to the SMIv2. A 101 MIB conforming to the SMIv1 can be produced through the appropriate 102 translations. The resulting translated MIB must be semantically 103 equivalent, except where objects or events are omitted because no 104 translation is possible (use of Counter64). Some machine readable 105 information in SMIv2 will be converted into textual descriptions in 106 SMIv1 during the translation process. However, this loss of machine 107 readable information is not considered to change the semantics of the 108 MIB. 110 2. StorageType Interpretations 112 The SMIv2 introduced the StorageType textual convention which is used 113 to describe the memory realization of a conceptual rows. In 114 particular, the StorageType textual convention can be used to mark 115 dynamically created rows as volatile or non-volatile. Several MIBs 116 on the standards-track use this StorageType textual convention for 117 all conceptual tables that support row creation. The StorageType 118 textual convention is defined in RFC 2579 [7] as follows: 120 StorageType ::= TEXTUAL-CONVENTION 121 STATUS current 122 DESCRIPTION 123 "Describes the memory realization of a conceptual row. A 124 row which is volatile(2) is lost upon reboot. A row which 125 is either nonVolatile(3), permanent(4) or readOnly(5), is 126 backed up by stable storage. A row which is permanent(4) 127 can be changed but not deleted. A row which is readOnly(5) 128 cannot be changed nor deleted. 130 If the value of an object with this syntax is either 131 permanent(4) or readOnly(5), it cannot be written. 132 Conversely, if the value is either other(1), volatile(2) or 133 nonVolatile(3), it cannot be modified to be permanent(4) or 134 readOnly(5). (All illegal modifications result in a 135 'wrongValue' error.) 137 Every usage of this textual convention is required to 138 specify the columnar objects which a permanent(4) row must 139 at a minimum allow to be writable." 140 SYNTAX INTEGER { 141 other(1), -- eh? 142 volatile(2), -- e.g., in RAM 143 nonVolatile(3), -- e.g., in NVRAM 144 permanent(4), -- e.g., partially in ROM 145 readOnly(5) -- e.g., completely in ROM 146 } 148 Note that the text in the DESCRIPTION clause does not make any 149 explicit statements when a conceptual row is actually written to non- 150 volatile storage. One possible interpretation is that rows must be 151 committed to non-volatile storage on each set operation which 152 modifies a row. However, many implementations prefer to not write to 153 non-volatile storage on each set operation. There are two main 154 reasons for this: 156 1. Writing non-volatile storage is on some systems time and/or 157 resource consuming. Committing rows to non-volatile memory 158 during the set operation is thus considered too expensive. 160 2. Some management applications create and configure rows by sending 161 a sequence of set requests. Committing the row to non-volatile 162 storage on every single set operation is too costly, especially 163 on systems that can only commit complex system configurations to 164 non-volatile memory. 166 Implementations therefore use different strategies: 168 1. Some systems update the non-volatile storage on each set 169 operation. 171 2. Some systems first return a positive response to the set 172 operation and they write the modified variables to non-volatile 173 storage at some later point in time when there are no more 174 changes. 176 3. Some systems first return a positive response to the set 177 operation and they delay the actual write to non-volatile storage 178 to some external event (e.g. shutdown of the agent, pushing of a 179 global write button). 181 4. Some systems first return a positive response to the set 182 operation and they write the modified variables when a logical 183 row operation has completed. (For example, an incomplete 184 conceptual row is not saved in non-volatile storage until it is 185 complete and activated.) 187 It seems that delayed writes to non-volatile storage are common 188 practice. However, since this behavior is right now completely 189 implementation dependent, there is no simple mechanism a management 190 application can use to learn how a given device implements the 191 StorageType textual convention and therefore it is unclear when a row 192 is actually written to stable storage. 194 Commonly used command line interfaces of network devices follow a 195 paradigm where explicit commands trigger the storage of the device 196 configuration (or logical parts of the device configuration) in non- 197 volatile storage. Operational experience with these interfaces 198 suggests that it is (i) valuable to have explicit control when 199 configuration data is written to non-volatile storage and (ii) 200 efficient to implement on networking devices. 202 This document therefore proposes to introduce new MIB objects which 203 can be used by management applications to control when non-volatile 204 conceptual rows are written to stable storage. The MIB supports 205 multiple "write buttons" to support implementations which use 206 different mechanisms in different parts of the MIBs to save rows in 207 non-volatile storage. All "write buttons" are registered in a common 208 table so that management applications can easily find them. The 209 table is organized so that sub-agents can register rows in the table 210 easily. In addition, there is a global "write button" which 211 basically causes all write buttons in the table to be triggered. 213 The objects defined in the MIB support slow write transactions where 214 the time required to commit data to non-volatile storage is much 215 larger than the time for processing set operations. Status objects 216 report the progress of writing data to non-volatile storage. A 217 management application can poll these status objects in order to 218 detect when the write has completed and whether there were any 219 errors. 221 An alternative approach would have been to introduce "write button" 222 scalars in various MIB modules that use the StorageType textual 223 convention. However, this leads to serious problems for management 224 applications to find the right scalars for the right set of MIB 225 objects. Furthermore, it would be hard to realize a global "write 226 button" in a master/subagent environment without specific protocol 227 support. 229 3. Definitions 231 SNMP-STORAGE-MIB DEFINITIONS ::= BEGIN 233 IMPORTS 234 MODULE-IDENTITY, OBJECT-TYPE, snmpModules, Unsigned32 235 FROM SNMPv2-SMI 237 DateAndTime, AutonomousType 238 FROM SNMPv2-TC 240 MODULE-COMPLIANCE, OBJECT-GROUP 241 FROM SNMPv2-CONF 243 SnmpAdminString 244 FROM SNMP-FRAMEWORK-MIB; 246 snmpStorageMIB MODULE-IDENTITY 247 LAST-UPDATED "200106210000Z" 248 ORGANIZATION "IETF" 249 CONTACT-INFO 250 "Juergen Schoenwaelder (Editor) 251 TU Braunschweig 252 Bueltenweg 74/75 253 38106 Braunschweig, Germany 255 Phone: +49 531 391-3289 256 EMail: schoenw@ibr.cs.tu-bs.de 258 Send comments to ." 259 DESCRIPTION 260 "This MIB modules provides objects that allow management 261 applications to commit non-volatile conceptual rows to 262 stable storage." 263 REVISION "200106210000Z" 264 DESCRIPTION "The initial revision, published as RFC XXXX." 265 ::= { snmpModules xxx } 267 snmpStorageObjects OBJECT IDENTIFIER ::= { snmpStorageMIB 1 } 268 snmpStorageConformance OBJECT IDENTIFIER ::= { snmpStorageMIB 2 } 270 snmpStorageGlobControl OBJECT-TYPE 271 SYNTAX INTEGER { nop(1), write(2) } 272 MAX-ACCESS read-write 273 STATUS current 274 DESCRIPTION 275 "Setting this object to write(2) causes the agent to sync 276 not yet committed non-volatile MIB data to stable storage. 278 Setting this object to write(2) while the value of the 279 snmpStorageGlobStatus object is writing(3) leads to an 280 inconsitent value error. 282 Setting this object to nop(1) always succeeds and has no 283 effect. 285 Management applications are advised to make use of the 286 snmpSetSerialNo object defined in the SNMPv2-MIB to 287 coordinate their use of this object." 288 ::= { snmpStorageObjects 1 } 290 snmpStorageGlobStatus OBJECT-TYPE 291 SYNTAX INTEGER { 292 other(1), 293 dirty(2), -- can probably not be implemented ? 294 writing(3), -- perhaps we only need 'idle' and 295 finished(4), -- 'inProgress'? 296 error(5) 297 } 298 MAX-ACCESS read-only 299 STATUS current 300 DESCRIPTION 301 "This object reports the current status of the write operation." 302 ::= { snmpStorageObjects 2 } 304 snmpStorageGlobError OBJECT-TYPE 305 SYNTAX SnmpAdminString 306 MAX-ACCESS read-only 307 STATUS current 308 DESCRIPTION 309 "This object contains a descriptive error message if the 310 last attempt to write global stable storage has failed." 311 ::= { snmpStorageObjects 3 } 313 snmpStorageGlobErrorTime OBJECT-TYPE 314 SYNTAX DateAndTime 315 MAX-ACCESS read-only 316 STATUS current 317 DESCRIPTION 318 "The data and time when the snmpStorageGlobError was last 319 updated. The value '0000000000000000'H is returned if 320 snmpStorageGlobError has not yet been updated after the 321 initialization." 322 ::= { snmpStorageObjects 4 } 324 snmpStorageTable OBJECT-TYPE 325 SYNTAX SEQUENCE OF SnmpStorageEntry 326 MAX-ACCESS not-accessible 327 STATUS current 328 DESCRIPTION 329 "" 330 ::= { snmpStorageObjects 5 } 332 snmpStorageEntry OBJECT-TYPE 333 SYNTAX SnmpStorageEntry 334 MAX-ACCESS not-accessible 335 STATUS current 336 DESCRIPTION 337 "" 338 INDEX { snmpStorageIndex } 339 ::= { snmpStorageTable 1 } 341 SnmpStorageEntry ::= SEQUENCE { 342 snmpStorageIndex Unsigned32, 343 snmpStorageDescr SnmpAdminString, 344 snmpStorageID AutonomousType, 345 snmpStorageControl INTEGER, 346 snmpStorageStatus INTEGER, 347 snmpStorageError SnmpAdminString, 348 snmpStorageErrorTime DateAndTime 349 } 351 snmpStorageIndex OBJECT-TYPE 352 SYNTAX Unsigned32 (1..4294967295) 353 MAX-ACCESS not-accessible 354 STATUS current 355 DESCRIPTION 356 "The index which uniquely identifies a row in the 357 snmpStorageTable." 358 ::= { snmpStorageEntry 1 } 360 snmpStorageDescr OBJECT-TYPE 361 SYNTAX SnmpAdminString 362 MAX-ACCESS read-only 363 STATUS current 364 DESCRIPTION 365 "A textual description which explains the scope of 366 MIB data which is controlled by this row." 367 ::= { snmpStorageEntry 2 } 369 snmpStorageID OBJECT-TYPE 370 SYNTAX AutonomousType 371 MAX-ACCESS read-only 372 STATUS current 373 DESCRIPTION 374 "" 375 ::= { snmpStorageEntry 3 } 377 snmpStorageControl OBJECT-TYPE 378 SYNTAX INTEGER { nop(1), write(2) } 379 MAX-ACCESS read-write 380 STATUS current 381 DESCRIPTION 382 "Setting this object to write(2) causes the agent to sync 383 not yet committed non-volatile MIB data to stable storage. 385 Setting this object to write(2) while the value of the 386 snmpStorageStatus object is writing(3) leads to an 387 inconsitent value error. 389 Setting this object to nop(1) always succeeds and has no 390 effect. 392 Management applications are advised to make use of the 393 snmpSetSerialNo object defined in the SNMPv2-MIB to 394 coordinate their use of this object." 395 ::= { snmpStorageEntry 4 } 397 snmpStorageStatus OBJECT-TYPE 398 SYNTAX INTEGER { 399 other(1), 400 dirty(2), 401 writing(3), 402 finished(4), 403 error(5) 404 } 405 MAX-ACCESS read-only 406 STATUS current 407 DESCRIPTION 408 "This object reports the current status of the write operation." 409 ::= { snmpStorageEntry 5 } 411 snmpStorageError OBJECT-TYPE 412 SYNTAX SnmpAdminString 413 MAX-ACCESS read-only 414 STATUS current 415 DESCRIPTION 416 "This object contains a descriptive error message if the 417 last attempt to write into stable storage has failed." 418 ::= { snmpStorageEntry 6 } 420 snmpStorageErrorTime OBJECT-TYPE 421 SYNTAX DateAndTime 422 MAX-ACCESS read-only 423 STATUS current 424 DESCRIPTION 425 "The data and time when the snmpStorageError was last 426 updated. The value '0000000000000000'H is returned if 427 snmpStorageError has not yet been updated after the 428 initialization." 429 ::= { snmpStorageEntry 7 } 431 snmpStorageCompliances OBJECT IDENTIFIER ::= { snmpStorageConformance 1 } 432 snmpStorageGroups OBJECT IDENTIFIER ::= { snmpStorageConformance 2 } 434 snmpStorageCompliance MODULE-COMPLIANCE 435 STATUS current 436 DESCRIPTION 437 "" 438 MODULE -- this module 439 MANDATORY-GROUPS { snmpStorageGlobalGroup } 440 GROUP snmpStorageGroup 441 DESCRIPTION 442 "Implementation of this group is only mandatory for 443 systems that support multiple write buttons for 444 different sets of MIB objects." 446 ::= { snmpStorageCompliances 1 } 448 snmpStorageGlobalGroup OBJECT-GROUP 449 OBJECTS { snmpStorageGlobControl, snmpStorageGlobStatus, 450 snmpStorageGlobError, snmpStorageGlobErrorTime } 451 STATUS current 452 DESCRIPTION 453 "" 454 ::= { snmpStorageGroups 1 } 456 snmpStorageGroup OBJECT-GROUP 457 OBJECTS { snmpStorageDescr, snmpStorageID, 458 snmpStorageControl, snmpStorageStatus, 459 snmpStorageError, snmpStorageErrorTime } 460 STATUS current 461 DESCRIPTION 462 "" 463 ::= { snmpStorageGroups 2 } 465 END 467 4. Security Considerations 469 There are a number of management objects defined in this MIB that 470 have a MAX-ACCESS clause of read-write and/or read-create. Such 471 objects may be considered sensitive or vulnerable in some network 472 environments. The support for SET operations in a non-secure 473 environment without proper protection can have a negative effect on 474 network operations. 476 SNMPv1 by itself is not a secure environment. Even if the network 477 itself is secure (for example by using IPSec), even then, there is no 478 control as to who on the secure network is allowed to access and 479 GET/SET (read/change/create/delete) the objects in this MIB. 481 It is recommended that the implementers consider the security 482 features as provided by the SNMPv3 framework. Specifically, the use 483 of the User-based Security Model RFC 2574 [RFC2574] and the View- 484 based Access Control Model RFC 2575 [RFC2575] is recommended. 486 It is then a customer/user responsibility to ensure that the SNMP 487 entity giving access to an instance of this MIB, is properly 488 configured to give access to the objects only to those principals 489 (users) that have legitimate rights to indeed GET or SET 490 (change/create/delete) them. 492 5. Acknowledgments 494 The author would like to thank David Harrington, Jon Saperia, Steve 495 Waldbusser for their comments and suggestions. 497 6. Intellectual Property Notice 499 The IETF takes no position regarding the validity or scope of any 500 intellectual property or other rights that might be claimed to 501 pertain to the implementation or use of the technology described in 502 this document or the extent to which any license under such rights 503 might or might not be available; neither does it represent that it 504 has made any effort to identify any such rights. Information on the 505 IETF's procedures with respect to rights in standards-track and 506 standards-related documentation can be found in BCP-11. Copies of 507 claims of rights made available for publication and any assurances of 508 licenses to be made available, or the result of an attempt made to 509 obtain a general license or permission for the use of such 510 proprietary rights by implementors or users of this specification can 511 be obtained from the IETF Secretariat. 513 The IETF invites any interested party to bring to its attention any 514 copyrights, patents or patent applications, or other proprietary 515 rights which may cover technology that may be required to practice 516 this standard. Please address the information to the IETF Executive 517 Director. 519 References 521 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 522 Levels", BCP 14, RFC 2119, March 1997. 524 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 525 Describing SNMP Management Frameworks", RFC 2571, April 1999. 527 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 528 Management Information for TCP/IP-based Internets", STD 16, RFC 529 1155, May 1990. 531 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 532 RFC 1212, March 1991. 534 [5] Rose, M., "A Convention for Defining Traps for use with the 535 SNMP", RFC 1215, March 1991. 537 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 538 M. and S. Waldbusser, "Structure of Management Information 539 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 541 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 542 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 543 RFC 2579, April 1999. 545 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 546 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 547 58, RFC 2580, April 1999. 549 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 550 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 551 1990. 553 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 554 "Introduction to Community-based SNMPv2", RFC 1901, January 555 1996. 557 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 558 "Transport Mappings for Version 2 of the Simple Network 559 Management Protocol (SNMPv2)", RFC 1906, January 1996. 561 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 562 Processing and Dispatching for the Simple Network Management 563 Protocol (SNMP)", RFC 2572, April 1999. 565 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 566 for version 3 of the Simple Network Management Protocol 567 (SNMPv3)", RFC 2574, April 1999. 569 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 570 Operations for Version 2 of the Simple Network Management 571 Protocol (SNMPv2)", RFC 1905, January 1996. 573 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 574 2573, April 1999. 576 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 577 Control Model (VACM) for the Simple Network Management Protocol 578 (SNMP)", RFC 2575, April 1999. 580 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 581 to Version 3 of the Internet-standard Network Management 582 Framework", RFC 2570, April 1999. 584 Author's Address 586 Juergen Schoenwaelder 587 TU Braunschweig 588 Bueltenweg 74/75 589 38106 Braunschweig 590 Germany 592 Phone: +49 531 391-3266 593 EMail: schoenw@ibr.cs.tu-bs.de 595 Appendix A. Open Issues 597 o How do we best describe the scope of a write button? 599 o Should we just provide a TC an simply point to MIB specific 600 scalars that use this TC? 602 o Is the error handling mechanism over-designed? 604 o Do we ever clear the error message like we do it in the DISMAN- 605 SCRIPT-MIB? 607 Full Copyright Statement 609 Copyright (C) The Internet Society (2001). All Rights Reserved. 611 This document and translations of it may be copied and furnished to 612 others, and derivative works that comment on or otherwise explain it 613 or assist in its implementation may be prepared, copied, published 614 and distributed, in whole or in part, without restriction of any 615 kind, provided that the above copyright notice and this paragraph are 616 included on all such copies and derivative works. However, this 617 document itself may not be modified in any way, such as by removing 618 the copyright notice or references to the Internet Society or other 619 Internet organizations, except as needed for the purpose of 620 developing Internet standards in which case the procedures for 621 copyrights defined in the Internet Standards process must be 622 followed, or as required to translate it into languages other than 623 English. 625 The limited permissions granted above are perpetual and will not be 626 revoked by the Internet Society or its successors or assigns. 628 This document and the information contained herein is provided on an 629 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 630 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 631 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 632 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 633 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Acknowledgement 637 Funding for the RFC Editor function is currently provided by the 638 Internet Society.