idnits 2.17.1 draft-ietf-eos-snmp-bulkdata-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 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. ** The abstract seems to contain references ([RFC2571]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 369 has weird spacing: '...), this defin...' == Line 693 has weird spacing: '...running dat...' == Line 695 has weird spacing: '...emptied an ...' == Line 696 has weird spacing: '...noSpace no ...' == Line 697 has weird spacing: '...badName no ...' == (3 more instances...) -- 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 (13 July 2001) is 8322 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 77, but not defined == Missing Reference: 'RFC1906' is mentioned on line 87, but not defined ** Obsolete undefined reference: RFC 1906 (Obsoleted by RFC 3417) == Missing Reference: 'RFC2572' is mentioned on line 88, but not defined ** Obsolete undefined reference: RFC 2572 (Obsoleted by RFC 3412) == Missing Reference: 'RFC2574' is mentioned on line 88, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC1905' is mentioned on line 120, but not defined ** Obsolete undefined reference: RFC 1905 (Obsoleted by RFC 3416) == Missing Reference: 'RFC2573' is mentioned on line 97, but not defined ** Obsolete undefined reference: RFC 2573 (Obsoleted by RFC 3413) == Missing Reference: 'RFC2575' is mentioned on line 98, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) == Unused Reference: 'RFC-PROTO' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC-TMM' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'RFC-MIB' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC-COEX' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC1910' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC-APPL' is defined on line 894, 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: 19 errors (**), 0 flaws (~~), 28 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David L. Battle 3 Cisco Systems, Inc. 5 Bryan Levin 6 Allegro Networks 8 13 July 2001 10 SNMP Bulk Data Transfer Extensions 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document describes a set of extensions (protocol operations and 40 textual conventions) to the existing SNMP framework architecture 41 [RFC2571]. These extensions provide mechanisms for efficient bulk 42 retrieval of table rows and other information. 44 Table of Contents 46 1. The SNMP Network Management Framework ....................... 3 47 2. Overview .................................................... 4 48 2.1. Terms ..................................................... 4 49 2.2. Motivations for the Extensions ............................ 4 50 2.3. Design Goals .............................................. 4 51 3. The Extensions .............................................. 5 52 4. Elements of Procedure ....................................... 5 53 4.1. Creating a row in the sliceTable .......................... 5 54 4.2. Creating a row in the xferTable ........................... 5 55 4.3. Activating a transfer ..................................... 5 56 5. Coexistence and Transition .................................. 5 57 6. Managed Object Definitions .................................. 5 58 7. Intellectual Property ....................................... 17 59 8. Acknowledgements ............................................ 18 60 9. Security Considerations ..................................... 18 61 10. References ................................................. 18 62 11. Editor's Addresses ......................................... 21 63 A. Impact to SNMP and other Protocols .......................... 22 64 A.1. SNMPv3 .................................................... 22 65 B. Full Copyright Statement .................................... 22 67 1. The SNMP Network Management Framework 69 The SNMP Management Framework presently consists of five major 70 components: 72 - An overall architecture, described in RFC 2571 [RFC2571]. 74 - Mechanisms for describing and naming objects and events for the 75 purpose of management. The first version of this Structure of 76 Management Information (SMI) is called SMIv1 and described in 77 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 78 The second version, called SMIv2, is described in RFC 2578 79 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 81 - Message protocols for transferring management information. The 82 first version of the SNMP message protocol is called SNMPv1 and 83 described in RFC 1157 [RFC1157]. A second version of the SNMP 84 message protocol, which is not an Internet standards track 85 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 86 and RFC 1906 [RFC1906]. The third version of the message 87 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 88 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 90 - Protocol operations for accessing management information. The 91 first set of protocol operations and associated PDU formats is 92 described in RFC 1157 [RFC1157]. A second set of protocol 93 operations and associated PDU formats is described in RFC 1905 94 [RFC1905]. 96 - A set of fundamental applications described in RFC 2573 97 [RFC2573] and the view-based access control mechanism described 98 in RFC 2575 [RFC2575]. 100 A more detailed introduction to the current SNMP Management Framework 101 can be found in RFC 2570 [RFC2570]. 103 Managed objects are accessed via a virtual information store, termed 104 the Management Information Base or MIB. Objects in the MIB are 105 defined using the mechanisms defined in the SMI. 107 This memo specifies a MIB module that is compliant to the SMIv2. A 108 MIB conforming to the SMIv1 can be produced through the appropriate 109 translations. The resulting translated MIB must be semantically 110 equivalent, except where objects or events are omitted because no 111 translation is possible (use of Counter64). Some machine readable 112 information in SMIv2 will be converted into textual descriptions in 113 SMIv1 during the translation process. However, this loss of machine 114 readable information is not considered to change the semantics of the 115 MIB. 117 2. Overview 119 This document describes a set of SNMP extensions to current protocol 120 operations [RFC1905] to provide for efficient management operations 121 (i.e. bulk retrieval of mib data). 123 2.1. Terms 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.2. Motivations for the Extensions 131 Experience has shown that current SNMP protocol operations and 132 management structures are not ideally suited to retrieving large 133 amounts of information. The extensions described in this document 134 are specifically designed to minimize, or provide opportunities to 135 minimize, the following problems which inhibit the effectiveness of 136 SNMP: 138 - The existing bulk transfer mechanism (GetBulk) is difficult to 139 use and difficult to control (can overshoot table boundaries). 141 - No mechanism is currently provided for transfering large tables 142 to the NMS without constant, active NMS participation. 144 - 146 2.3. Design Goals 148 Several goals were identified when considering the kind and nature of 149 extensions that were needed: 151 - Define a mechanism that is easy for normal humans to implement 152 and use. 154 - Define a mechanism that can be used to transfer large tables to 155 the NMS without constant NMS participation. 157 3. The Extensions 159 The extension consists of a mib document together with a description 160 of how it can be incorporated into an existing SNMP Agent in order to 161 achieve the desired bulk data retrieval behavior. 163 4. Elements of Procedure 165 4.1. Creating a row in the sliceTable 167 This can be a partial or complete MIB table or, alternately, a whole 168 MIB subtree. If using the MIB table method, the user can select just 169 the columns and rows that are to be saved and uploaded. 171 4.2. Creating a row in the xferTable 173 This includes information about the remote fileserver, path/filename, 174 login authentication and an index reference to an entry that was 175 previously created in the Data Slice table. 177 4.3. Activating a transfer 179 Perform an SNMP Set to the RowStatus variable 'xferEntryStatus', 180 giving it the value of 'createAndGo' or 'active'. This will initiate 181 the file transfer. Note that this variable could be set via remote 182 SNMP Sets, via the local agent's craft interface, or via a threshold 183 or timer event, such as found in the DISMAN-SCHEDULE-MIB. 185 5. Coexistence and Transition 187 Since this extension doesn't directly impact existing SNMP Protocol 188 operations, coexistence and transition issues are minimized. If an 189 NMS attempts to use this extension and an agent supports it, life is 190 good. Otherwise, fallback to traditional protocol operations is 191 still possible. 193 6. Managed Object Definitions 195 BULK-DATA-MIB DEFINITIONS ::= BEGIN 197 IMPORTS 198 OBJECT-TYPE, MODULE-IDENTITY, 199 experimental, IpAddress, Unsigned32 FROM SNMPv2-SMI 200 RowStatus, TimeStamp, DisplayString FROM SNMPv2-TC 201 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 203 bulkDataMIB MODULE-IDENTITY 204 LAST-UPDATED "200107121954Z" 205 ORGANIZATION "IETF Evolution of SNMP Working Group" 206 CONTACT-INFO "Bryan Levin, Allegro Networks 207 Postal: 6399 San Ignacio 208 San Jose, CA 95119-1206 210 Tel: +1 408 281-5500 211 E-mail: snmp@allegronetworks.com 213 David Battle, Cisco Systems 214 Postal: 204 Golfclub Rd 215 Knoxville, TN 37919-5924 217 Tel: +1 865 588-7763 218 E-mail: dbattle@cisco.com" 219 DESCRIPTION 220 "The MIB module for defining Bulk Data objects along with the 221 Bulk Data file format, Upload Fileserver and Data Slice." 222 ::= { experimental 999 } 224 bulkDataSliceObjects OBJECT IDENTIFIER ::= { bulkDataMIB 1 } 226 bulkDataFileTransferObjects OBJECT IDENTIFIER ::= { bulkDataMIB 2 } 228 -- Data Slicing Control 230 sliceTable OBJECT-TYPE 231 SYNTAX SEQUENCE OF SliceEntry 232 MAX-ACCESS not-accessible 233 STATUS current 234 DESCRIPTION 235 "This table describes a bulk data slice that is a subset of 236 the current running agent's MIB data." 237 ::= { bulkDataSliceObjects 1 } 239 sliceEntry OBJECT-TYPE 240 SYNTAX SliceEntry 241 MAX-ACCESS not-accessible 242 STATUS current 243 DESCRIPTION 244 "The data slice entry." 245 INDEX { sliceIndex } 246 ::= { sliceTable 1 } 248 SliceEntry ::= SEQUENCE { 249 sliceIndex Unsigned32, 250 sliceType INTEGER, 251 sliceOIDSubtree OBJECT IDENTIFIER, 252 sliceColumnMask OCTET STRING, 253 sliceRowRangeType INTEGER, 254 sliceRowRangeTimestamp TimeStamp, 255 sliceRowRangeStart Unsigned32, 256 sliceRowRangeEnd Unsigned32, 257 sliceRowRangeNetmask1 IpAddress, 258 sliceRowRangeNetmask2 IpAddress, 259 sliceEntryStatus RowStatus } 261 sliceIndex OBJECT-TYPE 262 SYNTAX Unsigned32 (1..4294967295) 263 MAX-ACCESS not-accessible 264 STATUS current 265 DESCRIPTION 266 "An arbitrary integer to uniquely identify this entry. To 267 create an entry a management application should pick a random 268 number." 269 ::= { sliceEntry 1 } 271 sliceType OBJECT-TYPE 272 SYNTAX INTEGER { 273 oidSubtree(1), 274 mibTable(2) 275 } 276 MAX-ACCESS read-create 277 STATUS current 278 DESCRIPTION 279 "This describes the type of data bulk data. 281 If set to oidSubtree(1) then all MIB data with the prefix of 282 sliceOIDSubtree will be included in the data slice. 284 If set to mibTable(2), then the values of sliceColumnMask, 285 sliceRowRangeType,sliceRowRangeTimestamp,sliceRowRangeStart, 286 sliceRowRangeEnd are significant." 287 ::= { sliceEntry 2 } 289 sliceOIDSubtree OBJECT-TYPE 290 SYNTAX OBJECT IDENTIFIER 291 MAX-ACCESS read-create 292 STATUS current 293 DESCRIPTION 294 "Valid only if sliceType is set to oidSubtree(1). 296 This describes an OID prefix, whose subtree will be included 297 in the 298 data slice." 299 ::= { sliceEntry 3 } 301 sliceColumnMask OBJECT-TYPE 302 SYNTAX OCTET STRING (SIZE (1..255)) 303 MAX-ACCESS read-create 304 STATUS current 305 DESCRIPTION 306 "A bitstring that represents which columns of the conceptual 307 table are to be included in this data slice. If the bit has 308 a value of '1', the column is to be included in this data 309 slice. 311 The mapping of bit positions to table columns is from most 312 significant bit (first column entry) to least significant 313 bit (last column entry)." 314 ::= { sliceEntry 4 } 316 sliceRowRangeType OBJECT-TYPE 317 SYNTAX INTEGER { 318 simple(1), 319 netMask(2), 320 olderThan(3), 321 newerThan(4) 322 } 323 MAX-ACCESS read-create 324 STATUS current 325 DESCRIPTION 326 "This defines how the rows will be selected. 328 If set to simple(1), the rows will range from the value of 329 sliceRowRangeStart thru sliceRowRangeEnd, inclusive. 331 If set to netMask(2), all rows whose index matches a netmask 332 wildcard will be selected. For tables that have one 333 IpAddress in their index field, sliceRowRangeNetmask1 will be 334 the selector. For tables that have two IpAddress fields, 335 sliceRowRangeNetmask1 will be used to match the first 336 IpAddress index and sliceRowRangeNetmask2 will be used to 337 match the second IpAddress index. 339 If set to olderThan(3) or newerThan(4), table rows that have 340 been changed (ie, have had a value change in their row) 341 before or after the timestamp 'sliceRowRangeTimestamp' will 342 be selected." 343 ::= { sliceEntry 5 } 345 sliceRowRangeTimestamp OBJECT-TYPE 346 SYNTAX TimeStamp 347 MAX-ACCESS read-create 348 STATUS current 349 DESCRIPTION 350 "This defines the rows in a table that are older than 351 or newer than this timestamp. 353 If sliceRowRangeType is set to olderThan(3), all rows whose 354 time of last modification are older than this timestamp are 355 included in this data slice. If sliceRowRangeType is set to 356 newerThan(4), all rows whose time of last modification are 357 newer than this timestamp are included in this data slice. 359 This column is only significant if sliceRowRangeType 360 is set to olderThan(3) or newerThan(4)." 361 ::= { sliceEntry 6 } 363 sliceRowRangeStart OBJECT-TYPE 364 SYNTAX Unsigned32 365 MAX-ACCESS read-create 366 STATUS current 367 DESCRIPTION 368 "For simple tables (ie, where the indexing is a single 369 integer), this defines the beginning index value to be 370 included in the data slice. The rows selected are an 371 inclusive range bounded by the values of sliceRowRangeStart 372 and sliceRowRangeEnd. 374 This column is only significant if sliceRowRangeType 375 is set to simple(1)." 376 ::= { sliceEntry 7 } 378 sliceRowRangeEnd OBJECT-TYPE 379 SYNTAX Unsigned32 380 MAX-ACCESS read-create 381 STATUS current 382 DESCRIPTION 383 "For simple tables (ie, where the indexing is a single 384 integer), this defines the ending index value to be included 385 in the data slice. The rows selected are an inclusive range 386 bounded by the values of sliceRowRangeStart and 387 sliceRowRangeEnd. 389 This column is only significant if sliceRowRangeType 390 is set to simple(1)." 391 ::= { sliceEntry 8 } 393 sliceRowRangeNetmask1 OBJECT-TYPE 394 SYNTAX IpAddress 395 MAX-ACCESS read-create 396 STATUS current 397 DESCRIPTION 398 "For tables that are indexed by an IpAddress component, this 399 defines the netmask for the selection of rows to be included 400 in the data slice. All rows that match this netmask will be 401 included in this data slice. This column is only significant 402 if sliceRowRangeType is set to netMask(2). 404 Note that for multiply indexed tables where there is more 405 than one IpAddress, this mask will be applied to the first 406 one, only. 408 If both sliceRowRangeNetmask1 and sliceRowRangeNetmask2 are 409 defined, the rows selected will be the logical intersection 410 of the sliceRowRangeNetmask1 rows and the 411 sliceRowRangeNetmask2 rows." 412 ::= { sliceEntry 9 } 414 sliceRowRangeNetmask2 OBJECT-TYPE 415 SYNTAX IpAddress 416 MAX-ACCESS read-create 417 STATUS current 418 DESCRIPTION 419 "For tables that are indexed by an IpAddress component, this 420 defines the netmask for the selection of rows to be included 421 in the data slice. All rows that match this netmask will be 422 included in this data slice. This column is only significant 423 if sliceRowRangeType is set to netMask(2). 425 Note that for multiply indexed tables where there is more 426 than one IpAddress, this mask will be applied to the first 427 one, only. 429 If both sliceRowRangeNetmask1 and sliceRowRangeNetmask2 are 430 defined, the rows selected will be the logical intersection 431 of the sliceRowRangeNetmask1 rows and the 432 sliceRowRangeNetmask2 rows." 433 ::= { sliceEntry 10 } 435 sliceEntryStatus OBJECT-TYPE 436 SYNTAX RowStatus 437 MAX-ACCESS read-create 438 STATUS current 439 DESCRIPTION 440 "The control variable that allows creation, modification, and 441 deletion of entries in this table." 442 ::= { sliceEntry 11 } 444 -- File Transfer Control 446 xferTable OBJECT-TYPE 447 SYNTAX SEQUENCE OF XferEntry 448 MAX-ACCESS not-accessible 449 STATUS current 450 DESCRIPTION 451 "This table describes a bulk data transfer protocol, file 452 encoding, remote path/filename, remote authentication 453 and local file transfer status." 454 ::= { bulkDataFileTransferObjects 1 } 456 xferEntry OBJECT-TYPE 457 SYNTAX XferEntry 458 MAX-ACCESS not-accessible 459 STATUS current 460 DESCRIPTION 461 "The transfer table entry." 462 INDEX { xferIndex } 463 ::= { xferTable 1 } 465 XferEntry ::= SEQUENCE { 466 xferIndex Unsigned32, 467 xferSliceIndex Unsigned32, 468 xferProtocol INTEGER, 469 xferFileEncoding INTEGER, 470 xferFileCompression INTEGER, 471 xferFileServerManditory DisplayString, 472 xferFileServerOptional DisplayString, 473 xferFileWriteControl INTEGER, 474 xferFilePath DisplayString, 475 xferFileName DisplayString, 476 xferAuthUsername DisplayString, 477 xferAuthPassword DisplayString, 478 xferState INTEGER, 479 xferStartTime TimeStamp, 480 xferCompletionTime TimeStamp, 481 xferFileSize Unsigned32, 482 xferEntryStatus RowStatus } 484 xferIndex OBJECT-TYPE 485 SYNTAX Unsigned32 (1..4294967295) 486 MAX-ACCESS not-accessible 487 STATUS current 488 DESCRIPTION 489 "An integer to uniquely identify the data slice that is to be 490 transferred to the fileserver. This refers to an entry in 491 the SliceTable." 492 ::= { xferEntry 1 } 494 xferSliceIndex OBJECT-TYPE 495 SYNTAX Unsigned32 496 MAX-ACCESS read-create 497 STATUS current 498 DESCRIPTION 499 "An integer to uniquely identify the data slice to be 500 transferred to the fileserver." 501 ::= { xferEntry 2 } 503 xferProtocol OBJECT-TYPE 504 SYNTAX INTEGER { 505 ftp(1), 506 tftp(2), 507 sftp(3), 508 scp(4), 509 http(5), 510 smtp(6) 511 } 512 MAX-ACCESS read-create 513 STATUS current 514 DESCRIPTION 515 "This defines the standard protocol that is used to upload 516 the data slice to the fileserver. The agent is the client in 517 this transaction; ie, it initiates the upload to the 518 fileserver." 519 ::= { xferEntry 3 } 521 xferFileEncoding OBJECT-TYPE 522 SYNTAX INTEGER { 523 standardBER(1), 524 ascii(2), 525 xml(3) 526 } 527 MAX-ACCESS read-create 528 STATUS current 529 DESCRIPTION 530 "If set to standardBER(1), the ASN.1/BER format is identical 531 to SNMP variable bindings, that is, each object has a full 532 OID and a fully tagged value. The file content is similar to 533 what would be obtained with a Get request. 535 If set to ascii(2), the format is human-readable ascii with a 536 lines in the form: 538 # table-name@timestamp column-1 column-2 ... column-n 539 instance-1 value-1 value-2 ... 540 instance-2 value-3 value-4 ... 541 ... 543 where: 545 table-name is the ascii representation of the MIB module 546 table name in usual dotted notation. 548 timestamp is the value of sysUptime on the agent when the 549 snapshot of the data slice was taken. 551 column-1 thru column-n are the human-readable MIB module 552 column names that are included in this data slice. 554 instance-1 (etc) are human-readable MIB module instance 555 names in usual dotted notation. 557 value-1 (etc) are human-readable ascii representations 558 of the actual values of the data cells. This is in 559 DisplayString format regardless of the native data type of 560 the column. 562 For example, an ifTable data slice file fragment might be: 564 # interfaces.ifTable@28711187 ifDescr ifType ifInOctets 565 ifOutOctets 566 1 lo0 softwareLoopback 54550782 54552115 567 2 eth0 ethernet-csmacd 372380346 2746062289 568 3 eth0.0 ethernet-csmacd 4002949 126167 570 If set to xml(3), the data will be saved in XML tagged 571 format." 572 ::= { xferEntry 4 } 574 xferFileCompression OBJECT-TYPE 575 SYNTAX INTEGER { 576 none(1), 577 bzip(2), 578 gzip(3) 579 } 580 MAX-ACCESS read-create 581 STATUS current 582 DESCRIPTION 583 "If set to none(1), no file compression will be applied 584 before the data slice is uploaded to the fileserver. 586 If set to bzip(2), the standard bzip compression algorithm 587 will be applied to the data slice before the file is uploaded 588 to the fileserver. 590 If set to gzip(3), the standard GNU gzip compression 591 algorithm will be applied to the data slice before the file 592 is uploaded to the fileserver. 594 If a compression setting is used, it is acceptable to 595 compress the data slice either on-the-fly or in advance of 596 uploading to the fileserver." 597 ::= { xferEntry 5 } 599 xferFileServerManditory OBJECT-TYPE 600 SYNTAX DisplayString 601 MAX-ACCESS read-create 602 STATUS current 603 DESCRIPTION 604 "The primary target upload hostname or address to send the 605 bulk file. Successful upload to this host is required before 606 the local agent copy can be deleted." 607 ::= { xferEntry 6 } 609 xferFileServerOptional OBJECT-TYPE 610 SYNTAX DisplayString 611 MAX-ACCESS read-create 612 STATUS current 613 DESCRIPTION 614 "The secondary upload hostname or address to send the bulk 615 file. Successful upload to this host is optional; an attempt 616 is made to transfer the file to this host but successful 617 upload is not required for the agent to be able to delete the 618 local copy." 619 ::= { xferEntry 7 } 621 xferFileWriteControl OBJECT-TYPE 622 SYNTAX INTEGER { 623 failIfExists(1), 624 overwrite(2), 625 createNewVersion(3) 626 } 627 MAX-ACCESS read-create 628 STATUS current 629 DESCRIPTION 630 "This defines the action to take when uploading bulk data to 631 a fileserver. If set to failIfExists(1) and a filename 632 described by xferFilePath and xferFileName already exists, 633 the upload will fail and the existing file on the server will 634 not be overwritten. If set to overwrite(2), a file will be 635 uploaded and saved under the specified xferFilePath and 636 xferFileName, even if one by that composite name already 637 exists; if none exists by that composite name, a new 638 file will be created. If set to createNewVersion(3), the 639 version number of the filename on the fileserver will be 640 incremented if version numbering is supported on the 641 fileserver." 642 ::= { xferEntry 8 } 644 xferFilePath OBJECT-TYPE 645 SYNTAX DisplayString 646 MAX-ACCESS read-create 647 STATUS current 648 DESCRIPTION 649 "The remote directory path where the file is to be saved on 650 the fileserver." 651 ::= { xferEntry 9 } 653 xferFileName OBJECT-TYPE 654 SYNTAX DisplayString 655 MAX-ACCESS read-create 656 STATUS current 657 DESCRIPTION 658 "The remote file name of the file that is to be saved on the 659 fileserver. For fileservers that support versioning, the 660 appropriate version prefix or suffix is to be added to this 661 base filename." 662 ::= { xferEntry 10 } 664 xferAuthUsername OBJECT-TYPE 665 SYNTAX DisplayString 666 MAX-ACCESS read-create 667 STATUS current 668 DESCRIPTION 669 "The user name to use at the FTP server." 670 ::= { xferEntry 11 } 672 xferAuthPassword OBJECT-TYPE 673 SYNTAX DisplayString 674 MAX-ACCESS read-create 675 STATUS current 676 DESCRIPTION 677 "The password to use at the FTP server." 678 ::= { xferEntry 12 } 680 xferState OBJECT-TYPE 681 SYNTAX INTEGER { 682 running(1), ready(2), 683 emptied(3), noSpace(4), 684 badName(5), writeErr(6), 685 noMem(7), buffErr(8), 686 aborted(9) 687 } 688 MAX-ACCESS read-only 689 STATUS current 690 DESCRIPTION 691 "The file state: 693 running data is being written to the file 694 ready the file is ready to be read 695 emptied an ephemeral file was successfully consumed 696 noSpace no data due to insufficient file space 697 badName no data due to a name or path problem 698 writeErr no data due to fatal file write error 699 noMem no data due to insufficient dynamic memory 700 buffErr implementation buffer too small 701 aborted short terminated by operator command 703 Only the 'ready' state implies that the file is available 704 for transfer. 706 The disposition of files after an error is implementation 707 and file-syste specific." 708 ::= { xferEntry 13 } 710 xferStartTime OBJECT-TYPE 711 SYNTAX TimeStamp 712 MAX-ACCESS read-only 713 STATUS current 714 DESCRIPTION 715 "The value of sysUptime on the agent when the file transfer 716 was initiated. This variable is only valid upon the 717 successful 718 completion of a file transfer." 719 ::= { xferEntry 14 } 721 xferCompletionTime OBJECT-TYPE 722 SYNTAX TimeStamp 723 MAX-ACCESS read-only 724 STATUS current 725 DESCRIPTION 726 "The value of sysUptime on the agent when the file transfer 727 was completed. This variable is only valid upon the 728 successful completion of a file transfer." 729 ::= { xferEntry 15 } 731 xferFileSize OBJECT-TYPE 732 SYNTAX Unsigned32 733 MAX-ACCESS read-only 734 STATUS current 735 DESCRIPTION 736 "The actual size of the file (after optional file compression 737 was applied) that was uploaded to the fileserver. The size 738 is measured in bytes. This variable is only valid upon the 739 successful completion of a file transfer." 740 ::= { xferEntry 16 } 742 xferEntryStatus OBJECT-TYPE 743 SYNTAX RowStatus 744 MAX-ACCESS read-create 745 STATUS current 746 DESCRIPTION 747 "The control that allows creation, modification, and deletion 748 of entries. 750 Setting this variable to createAndGo or active will initiate 751 a file transfer to the fileserver. 753 Setting this variable to delete will delete this row entry 754 and abort any file transfer in progress that corresponds 755 to this row entry. 757 Note that in practice, this variable could be set by an 758 operator via the agent's craft interface, remotely via an NMS 759 using SNMP, or locally within the agent via automatic means, 760 such as described in the DISMAN-SCHEDULE-MIB." 761 ::= { xferEntry 17 } 763 END 765 7. Intellectual Property 767 The IETF takes no position regarding the validity or scope of any 768 intellectual property or other rights that might be claimed to 769 pertain to the implementation or use of the technology described in 770 this document or the extent to which any license under such rights 771 might or might not be available; neither does it represent that it 772 has made any effort to identify any such rights. Information on the 773 IETF's procedures with respect to rights in standards-track and 774 standards-related documentation can be found in BCP-11. Copies of 775 claims of rights made available for publication and any assurances of 776 licenses to be made available, or the result of an attempt made to 777 obtain a general license or permission for the use of such 778 proprietary rights by implementors or users of this specification can 779 be obtained from the IETF Secretariat. 781 The IETF invites any interested party to bring to its attention any 782 copyrights, patents or patent applications, or other proprietary 783 rights which may cover technology that may be required to practice 784 this standard. Please address the information to the IETF Executive 785 Director. 787 8. Acknowledgements 789 This document is the result of the efforts of the Evolution Of SNMP 790 (EOS) Working Group. Some special thanks are in order to the 791 following EOS WG members for their ideas, efforts and asundry 792 contributions: 794 Dr. Jeff Case 795 Dale Francisco 796 David Perkins 797 Randy Presuhn 798 Jeurgen Schoenwaelder 799 Bob Stewart 800 L. Heintz 802 9. Security Considerations 804 TBD 806 10. References 808 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 809 Identification of Management Information for TCP/IP- 810 based internets", STD 16, RFC 1155, May 1990. 812 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 813 Simple Network Management Protocol", STD 15, RFC 1157, 814 May 1990. 816 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 817 STD 16, RFC 1212, March 1991. 819 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 820 Rose, M. and S. Waldbusser, "Introduction to 821 Community-based SNMPv2", RFC 1901, January 1996. 823 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 824 Architecture for Describing SNMP Management Frameworks", 825 RFC 2571, April 1999. 827 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 828 "Structure of Management Information Version 2 (SMIv2)", 829 STD 58, RFC 2578, April 1999. 831 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 832 "Textual Conventions for SMIv2", STD 58, RFC 2579, April 833 1999. 835 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 836 "Conformance Statements for SMIv2", STD 58, RFC 2580, 837 April 1999. 839 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 840 Waldbusser, "Protocol Operations for the Simple Network 841 Management Protocol", , July 2001. 844 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 845 Waldbusser, "Transport Mappings for the Simple Network 846 Management Protocol", , July 2001. 849 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 850 Waldbusser, "Management Information Base for the Simple 851 Network Management Protocol", , July 2001. 854 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 855 "Coexistence between Version 1, Version 2, and Version 3 856 of the Internet-standard Network Management Framework", 857 , July 2001. 859 [RFC1909] McCloghrie, K., Editor, "An Administrative 860 Infrastructure for SNMPv2", RFC 1909, February 1996. 862 [RFC1910] Waters, G., Editor, "User-based Security Model for 863 SNMPv2", RFC 1910, February 1996. 865 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 866 10646", RFC 2279, January, 1998. 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in 872 the IETF Standards Process", BCP 11, RFC 2028, October 873 1996. 875 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group 876 MIB." RFC 2863, June 2000. 878 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 879 "Message Processing and Dispatching for the Simple 880 Network Management Protocol (SNMP)", , July 2001. 883 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 884 Model for Version 3 of the Simple Network Management 885 Protocol (SNMPv3)", , 886 July 2001. 888 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 889 Access Control Model for the Simple Network Management 890 Protocol (SNMP)", , 891 February 1999. , July 892 2001. 894 [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP 895 Applications", , July 896 2001. 898 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 899 "Introduction to Version 3 of the Internet-standard 900 Network Management Framework", , January 1999. 903 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 904 "Coexistence between Version 1, Version 2, and Version 3 905 of the Internet-standard Network Management Framework", 906 , July 2001. 908 11. Editor's Addresses 910 David L. Battle 911 Cisco Systems 912 204 Golfclub Rd 913 Knoxville, TN 37919-5924 915 Phone: +1 865-588-7763 916 EMail: dbattle@cisco.com 918 Bryan Levin 919 Allegro Netowrks 920 6399 San Ignacio 921 San Jose, Ca 95199-1206 923 Phone: +1 408-281-5500 924 EMail: snmp@allegronetworks.com 926 APPENDIXES 928 A. Impact to SNMP and other Protocols 930 A.1. SNMPv3 932 An issue remains whether a new message processing model MUST be 933 specified as part of the SNMPv3 (or later) standard. Otherwise, it is 934 not seen that these extensions pose any impact to other SNMPv3 935 architectural components (i.e. USM, VACM) because the new protocol 936 operations and their contents contain sufficient information (along 937 with the information provided in whatever version-specific message 938 wrapper they are contined within) to satisfy the abstract service 939 interfaces for those components. 941 B. Full Copyright Statement 943 Copyright (C) The Internet Society (2001). All Rights Reserved. 945 This document and translations of it may be copied and furnished to 946 others, and derivative works that comment on or otherwise explain it 947 or assist in its implementation may be prepared, copied, published 948 and distributed, in whole or in part, without restriction of any 949 kind, provided that the above copyright notice and this paragraph are 950 included on all such copies and derivative works. However, this 951 document itself may not be modified in any way, such as by removing 952 the copyright notice or references to the Internet Society or other 953 Internet organizations, except as needed for the purpose of 954 developing Internet standards in which case the procedures for 955 copyrights defined in the Internet Standards process must be 956 followed, or as required to translate it into languages other than 957 English. 959 The limited permissions granted above are perpetual and will not be 960 revoked by the Internet Society or its successors or assigns. 962 This document and the information contained herein is provided on an 963 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 964 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 965 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 966 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 967 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 969 Acknowledgement 970 Funding for the RFC Editor function is currently provided by the 971 Internet Society.