idnits 2.17.1 draft-stewart-ftp-client-mib-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 554 has weird spacing: '...for the purpo...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (16 November 1998) is 9293 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) ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 23 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft FTP Client MIB 16 November 1998 4 FTP Client MIB 6 16 November 1998 8 draft-stewart-ftp-client-mib-00.txt 10 Bob Stewart 11 Cisco Systems, Inc. 12 bstewart@cisco.com 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference material 24 or to cite them other than as ``work in progress.'' 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 29 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 30 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Distribution of this document is unlimited. Please send comments to the 33 author or one of the IETF Area Directors for Operations and Management: 34 Harald Alvestrand and Bert Wijnen 35 . 37 Copyright Notice 39 Copyright (C) The Internet Society (1998). All Rights Reserved. 41 1. Abstract 43 This memo defines an enterprise portion of the Management Information 44 Base (MIB) for use with network management protocols in the Internet 45 community. In particular, it describes managed objects used for 46 managing the transfer of files as an FTP client. 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119. 52 2. The SNMP Management Framework 54 The SNMP Management Framework presently consists of five major 55 components: 57 o An overall architecture, described in RFC 2271 [1]. 59 o Mechanisms for describing and naming objects and events for the 60 purpose of management. The first version of this Structure of 61 Management Information (SMI) is called SMIv1 and described in 62 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 63 called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 64 1904 [7]. 66 o Message protocols for transferring management information. The 67 first version of the SNMP message protocol is called SNMPv1 and 68 described in RFC 1157 [8]. A second version of the SNMP message 69 protocol, which is not an Internet standards track protocol, is 70 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 71 The third version of the message protocol is called SNMPv3 and 72 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 74 o Protocol operations for accessing management information. The 75 first set of protocol operations and associated PDU formats is 76 described in RFC 1157 [8]. A second set of protocol operations 77 and associated PDU formats is described in RFC 1905 [13]. 79 o A set of fundamental applications described in RFC 2273 [14] and 80 the view-based access control mechanism described in RFC 2275 81 [15]. 83 Managed objects are accessed via a virtual information store, termed the 84 Management Information Base or MIB. Objects in the MIB are defined 85 using the mechanisms defined in the SMI. 87 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 88 conforming to the SMIv1 can be produced through the appropriate 89 translations. The resulting translated MIB must be semantically 90 equivalent, except where objects or events are omitted because no 91 translation is possible (use of Counter64). Some machine readable 92 information in SMIv2 will be converted into textual descriptions in 93 SMIv1 during the translation process. However, this loss of machine 94 readable information is not considered to change the semantics of the 95 MIB. 97 3. Overview 99 The FTP Client MIB represents a simple application for initiating a file 100 transfer as an FTP client. The advantage of acting as an FTP client 101 instead of server is that clients need not represent a structured file 102 system with users and passwords. The MIB exploits that advantage as 103 well as offering the ability to initiate a transfer on demand to any 104 available FTP server. 106 Although the FTP Client MIB is of general utility, its original purpose 107 is as a companion to the Bulk File MIB [16] to act as the remote 108 transfer mechanism for an ephemeral file. 110 4. Operation 112 Operation is relatively simple. An application creates a definition for 113 a for a file transfer and the transfer attempt occurs when the 114 application activates or reactivates the entry. 116 5. Security 118 Security of MIB entries depends on SNMPv3 access control for the entire 119 MIB. 121 Security of files and file transfers is dependent on the file system in 122 which they reside and the security of FTP itself. 124 6. Definitions 126 CISCO-FTP-CLIENT-MIB DEFINITIONS ::= BEGIN 128 IMPORTS 129 MODULE-IDENTITY, OBJECT-TYPE, 130 Gauge32, Counter32 FROM SNMPv2-SMI 131 Unsigned32 FROM CISCO-TC 132 TimeStamp, RowStatus, 133 DisplayString FROM SNMPv2-TC 134 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 135 ciscoMgmt FROM CISCO-SMI; 137 ciscoFtpClientMIB MODULE-IDENTITY 138 LAST-UPDATED "9810291700Z" 139 ORGANIZATION "Cisco Systems, Inc." 140 CONTACT-INFO "Cisco Systems 141 Customer Service 143 Postal: 170 W Tasman Drive 144 San Jose, CA 95134 145 USA 147 Tel: +1 800 553-NETS 149 E-mail: cs-snmp@cisco.com" 150 DESCRIPTION 151 "The MIB module for invoking Internet File Transfer Protocol 152 (FTP) operations for network management purposes." 153 ::= { ciscoMgmt 80 } 155 ciscoFtpClientMIBObjects OBJECT IDENTIFIER ::= { ciscoFtpClientMIB 1 } 157 cfcRequest OBJECT IDENTIFIER ::= { ciscoFtpClientMIBObjects 1 } 159 -- 160 -- Client Request Control 161 -- 163 cfcRequestMaximum OBJECT-TYPE 164 SYNTAX Unsigned32 (0..4294967295) 165 MAX-ACCESS read-write 166 STATUS current 167 DESCRIPTION 168 "The maximum number of requests this system can hold in 169 cfcRequestTable. A value of 0 indicates no configured limit. 171 This object may be read-only on some systems. 173 When an attempt is made to create a new entry but the table 174 is full, the oldest completed entry is bumped out and 175 cfcRequestsBumped is incremented. 177 Changing this number does not disturb existing requests that 178 are not completed and bumps completed requests as necessary." 179 ::= { cfcRequest 1 } 181 cfcRequests OBJECT-TYPE 182 SYNTAX Gauge32 183 MAX-ACCESS read-only 184 STATUS current 185 DESCRIPTION 186 "The current number of requests in cfcRequestTable." 187 ::= { cfcRequest 2 } 189 cfcRequestsHigh OBJECT-TYPE 190 SYNTAX Gauge32 191 MAX-ACCESS read-only 192 STATUS current 193 DESCRIPTION 194 "The highest number of requests in cfcRequestTable since this 195 system was last initialized." 196 ::= { cfcRequest 3 } 198 cfcRequestsBumped OBJECT-TYPE 199 SYNTAX Counter32 200 MAX-ACCESS read-only 201 STATUS current 202 DESCRIPTION 203 "The number of requests in cfcRequestTable that were bumped 204 out to make room for a new request." 205 ::= { cfcRequest 4 } 207 -- 208 -- Client Request Control Table 209 -- 211 cfcRequestTable OBJECT-TYPE 212 SYNTAX SEQUENCE OF CfcRequestEntry 213 MAX-ACCESS not-accessible 214 STATUS current 215 DESCRIPTION 216 "A table of FTP client requests." 217 ::= { cfcRequest 5 } 219 cfcRequestEntry OBJECT-TYPE 220 SYNTAX CfcRequestEntry 221 MAX-ACCESS not-accessible 222 STATUS current 223 DESCRIPTION 224 "Information about an FTP client request. Management applications 225 use cfcRequestEntryStatus to control entry modification, creation, 226 and deletion. 228 Setting cfcRequestEntryStatus to 'active' from any state including 229 'active' causes the operation to be started. 231 An entry may be modified only when its cfcRequestOperationState is 232 'stopped'. 234 The value of cfcRequestEntryStatus may be set to 'destroy' at any 235 time. Doing so will abort a running request." 236 INDEX { cfcRequestIndex } 237 ::= { cfcRequestTable 1 } 239 CfcRequestEntry ::= SEQUENCE { 240 cfcRequestIndex Unsigned32, 241 cfcRequestOperation INTEGER, 242 cfcRequestLocalFile DisplayString, 243 cfcRequestRemoteFile DisplayString, 244 cfcRequestServer DisplayString, 245 cfcRequestUser DisplayString, 246 cfcRequestPassword DisplayString, 247 cfcRequestResult INTEGER, 248 cfcRequestCompletionTime TimeStamp, 249 cfcRequestStop INTEGER, 250 cfcRequestOperationState INTEGER, 251 cfcRequestEntryStatus RowStatus 252 } 254 cfcRequestIndex OBJECT-TYPE 255 SYNTAX Unsigned32 (1..4294967295) 256 MAX-ACCESS not-accessible 257 STATUS current 258 DESCRIPTION 259 "An arbitrary integer to uniquely identify this entry. To 260 create an entry a management application should pick a 261 random number." 262 ::= { cfcRequestEntry 1 } 264 cfcRequestOperation OBJECT-TYPE 265 SYNTAX INTEGER { putBinary(1), putASCII(2) } 266 MAX-ACCESS read-create 267 STATUS current 268 DESCRIPTION 269 "The FTP operation to be performed." 270 DEFVAL { putBinary } 271 ::= { cfcRequestEntry 2 } 273 cfcRequestLocalFile OBJECT-TYPE 274 SYNTAX DisplayString (SIZE (1..255)) 275 MAX-ACCESS read-create 276 STATUS current 277 DESCRIPTION 278 "The local file on which the operation is to be performed." 279 ::= { cfcRequestEntry 3 } 281 cfcRequestRemoteFile OBJECT-TYPE 282 SYNTAX DisplayString (SIZE (1..255)) 283 MAX-ACCESS read-create 284 STATUS current 285 DESCRIPTION 286 "The remote file on which the operation is to be performed." 287 ::= { cfcRequestEntry 4 } 289 cfcRequestServer OBJECT-TYPE 290 SYNTAX DisplayString (SIZE (1..64)) 291 MAX-ACCESS read-create 292 STATUS current 293 DESCRIPTION 294 "The domain name or IP address of the FTP server to use." 295 ::= { cfcRequestEntry 5 } 297 cfcRequestUser OBJECT-TYPE 298 SYNTAX DisplayString (SIZE (1..32)) 299 MAX-ACCESS read-create 300 STATUS current 301 DESCRIPTION 302 "The user name to use at the FTP server." 303 ::= { cfcRequestEntry 6 } 305 cfcRequestPassword OBJECT-TYPE 306 SYNTAX DisplayString (SIZE (0..16)) 307 MAX-ACCESS read-create 308 STATUS current 309 DESCRIPTION 310 "The password to use at the FTP server. 312 When read this object always returns a zero-length string." 313 DEFVAL { ''H } 314 ::= { cfcRequestEntry 7 } 316 cfcRequestResult OBJECT-TYPE 317 SYNTAX INTEGER { 318 pending(1), 319 success(2), 320 aborted(3), 321 fileOpenFailLocal(4), 322 fileOpenFailRemote(5), 323 badDomainName(6), 324 unreachableIpAddress(7), 325 linkFailed(8), 326 fileReadFailed(9), 327 fileWriteFailed(10) 328 } 329 MAX-ACCESS read-only 330 STATUS current 331 DESCRIPTION 332 "The result of the FTP operation." 333 ::= { cfcRequestEntry 8 } 335 cfcRequestCompletionTime OBJECT-TYPE 336 SYNTAX TimeStamp 337 MAX-ACCESS read-only 338 STATUS current 339 DESCRIPTION 340 "The value of sysUpTime when the operation completed. For 341 an incomplete operation this value is zero." 342 ::= { cfcRequestEntry 9 } 344 cfcRequestStop OBJECT-TYPE 345 SYNTAX INTEGER { ready(1), stop(2) } 346 MAX-ACCESS read-create 347 STATUS current 348 DESCRIPTION 349 "The action control to stop a running request. Setting this to 350 'stop' will begin the process of stopping the request. Setting 351 it to 'ready' or setting it to 'stop' more than once have no 352 effect. When read this object always returns ready." 353 ::= { cfcRequestEntry 10 } 355 cfcRequestOperationState OBJECT-TYPE 356 SYNTAX INTEGER { running(1), stopping(2), stopped(3) } 357 MAX-ACCESS read-only 358 STATUS current 359 DESCRIPTION 360 "The operational state of the file transfer. To short-terminate 361 the transfer set cfcRequestStop to 'stop'." 362 ::= { cfcRequestEntry 11 } 364 cfcRequestEntryStatus OBJECT-TYPE 365 SYNTAX RowStatus 366 MAX-ACCESS read-create 367 STATUS current 368 DESCRIPTION 369 "The control that allows modification, creation, and deletion 370 of entries. For detailed rules see the DESCRIPTION for 371 cfcRequestEntry." 372 ::= { cfcRequestEntry 12 } 374 -- 375 -- Conformance 376 -- 378 ciscoFtpClientMIBConformance OBJECT IDENTIFIER ::= { ciscoFtpClientMIB 3 } 380 ciscoFtpClientMIBCompliances OBJECT IDENTIFIER ::= 381 { ciscoFtpClientMIBConformance 1 } 382 ciscoFtpClientMIBGroups OBJECT IDENTIFIER ::= 383 { ciscoFtpClientMIBConformance 2 } 385 -- Compliance 387 ciscoFtpClientMIBCompliance MODULE-COMPLIANCE 388 STATUS current 389 DESCRIPTION 390 "The compliance statement for entities which implement 391 the Cisco FTP Client MIB. Implementation of this MIB 392 is based on individual product needs." 393 MODULE -- this module 394 MANDATORY-GROUPS { 395 ciscoFtpClientRequestGroup 396 } 398 ::= { ciscoFtpClientMIBCompliances 1 } 400 -- Units of Conformance 402 ciscoFtpClientRequestGroup OBJECT-GROUP 403 OBJECTS { 404 cfcRequestMaximum, 405 cfcRequests, 406 cfcRequestsHigh, 407 cfcRequestsBumped, 408 cfcRequestOperation, 409 cfcRequestLocalFile, 410 cfcRequestRemoteFile, 411 cfcRequestServer, 412 cfcRequestUser, 413 cfcRequestPassword, 414 cfcRequestResult, 415 cfcRequestCompletionTime, 416 cfcRequestStop, 417 cfcRequestOperationState, 418 cfcRequestEntryStatus 419 } 420 STATUS current 421 DESCRIPTION 422 "FTP client request management." 423 ::= { ciscoFtpClientMIBGroups 1 } 425 END 426 7. Intellectual Property 428 The IETF takes no position regarding the validity or scope of any 429 intellectual property or other rights that might be claimed to pertain 430 to the implementation or use of the technology described in this 431 document or the extent to which any license under such rights might or 432 might not be available; neither does it represent that it has made any 433 effort to identify any such rights. Information on the IETF's 434 procedures with respect to rights in standards-track and standards- 435 related documentation can be found in BCP-11. Copies of claims of 436 rights made available for publication and any assurances of licenses to 437 be made available, or the result of an attempt made to obtain a general 438 license or permission for the use of such proprietary rights by 439 implementors or users of this specification can be obtained from the 440 IETF Secretariat. 442 8. Acknowledgements 444 This MIB contains considerable contributions from the RMON MIB, the 445 Distributed Management Design Team (Andy Bierman, Maria Greene, Bob 446 Stewart, and Steve Waldbusser), and colleagues at Cisco. 448 9. References 450 [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 451 Describing SNMP Management Frameworks", RFC 2271, Cabletron 452 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 453 January 1998. 455 [2] Rose, M. and K. McCloghrie, "Structure and Identification of 456 Management Information for TCP/IP-based Internets", RFC 1155, 457 Performance Systems International, Hughes LAN Systems, May 1990. 459 [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 460 Performance Systems International, Hughes LAN Systems, March 1991. 462 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 463 RFC 1215, Performance Systems International, March 1991. 465 [5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 466 Management Information for Version 2 of the Simple Network 467 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 468 Systems, Inc., Dover Beach Consulting, Inc., International Network 469 Services, January 1996. 471 [6] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 472 Conventions for Version 2 of the Simple Network Management Protocol 473 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 474 Dover Beach Consulting, Inc., International Network Services, 475 January 1996. 477 [7] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance 478 Statements for Version 2 of the Simple Network Management Protocol 479 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 480 Dover Beach Consulting, Inc., International Network Services, 481 January 1996. 483 [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network 484 Management Protocol", RFC 1157, SNMP Research, Performance Systems 485 International, Performance Systems International, MIT Laboratory 486 for Computer Science, May 1990. 488 [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction 489 to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco 490 Systems, Inc., Dover Beach Consulting, Inc., International Network 491 Services, January 1996. 493 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 494 Mappings for Version 2 of the Simple Network Management Protocol 495 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 496 Dover Beach Consulting, Inc., International Network Services, 497 January 1996. 499 [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message 500 Processing and Dispatching for the Simple Network Management 501 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 502 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 504 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for 505 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 506 2274, IBM T. J. Watson Research, January 1998. 508 [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 509 Operations for Version 2 of the Simple Network Management Protocol 510 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 511 Dover Beach Consulting, Inc., International Network Services, 512 January 1996. 514 [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 515 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 516 Systems, January 1998. 518 [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 519 Control Model (VACM) for the Simple Network Management Protocol 520 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 521 Cisco Systems, Inc., January 1998. 523 [16] Stewart, B., "Bulk File MIB", RFC ????, Cisco Systems, Inc., 524 ?Month? 1998. 526 10. Security Considerations 528 Security issues are discussed in the Overview section and in the 529 DESCRIPTION clauses of relevant objects. 531 11. Author's Address 533 Bob Stewart 534 Cisco Systems, Inc. 535 170 West Tasman Drive 536 San Jose, CA 95134-1706 537 U.S.A. 539 Phone: +1 408 526 4527 540 Email: bstewart@cisco.com 542 12. Full Copyright Statement 544 Copyright (C) The Internet Society (1998). All Rights Reserved. 546 This document and translations of it may be copied and furnished to 547 others, and derivative works that comment on or otherwise explain it or 548 assist in its implementation may be prepared, copied, published and 549 distributed, in whole or in part, without restriction of any kind, 550 provided that the above copyright notice and this paragraph are included 551 on all such copies and derivative works. However, this document itself 552 may not be modified in any way, such as by removing the copyright notice 553 or references to the Internet Society or other Internet organizations, 554 except as needed for the purpose of developing Internet standards in 555 which case the procedures for copyrights defined in the Internet 556 Standards process must be followed, or as required to translate it into 557 languages other than English. 559 The limited permissions granted above are perpetual and will not be 560 revoked by the Internet Society or its successors or assigns. 562 This document and the information contained herein is provided on an "AS 563 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 564 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 565 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 566 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 567 FITNESS FOR A PARTICULAR PURPOSE. 569 Table of Contents 571 1 Abstract ........................................................ 2 572 2 The SNMP Management Framework ................................... 2 573 3 Overview ........................................................ 4 574 4 Operation ....................................................... 4 575 5 Security ........................................................ 4 576 6 Definitions ..................................................... 5 577 7 Intellectual Property ........................................... 12 578 8 Acknowledgements ................................................ 13 579 9 References ...................................................... 14 580 10 Security Considerations ........................................ 16 581 11 Author's Address ............................................... 16 582 12 Full Copyright Statement ....................................... 17