Internet Draft Bulk File MIB 16 November 1998 Bulk File MIB 16 November 1998 draft-stewart-bulk-file-mib-00.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the author or one of the IETF Area Directors for Operations and Management: Harald Alvestrand and Bert Wijnen . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires 16 November 1998+6 months [Page 1] Internet Draft Bulk File MIB 16 November 1998 1. Abstract This memo defines an enterprise portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the creation of files containing MIB objects. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined Expires 16 November 1998+6 months [Page 2] Internet Draft Bulk File MIB 16 November 1998 using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Expires 16 November 1998+6 months [Page 3] Internet Draft Bulk File MIB 16 November 1998 3. Overview The Bulk File MIB is an alternative answer to the problem of efficiently moving large amounts of SNMP MIB data. It represents an application that can take local MIB objects, subject to normal access control, and put them into a file. The file can be stored locally or, using other means such as the FTP Client MIB [16] transferred remotely either during or after creation. Indeed on a system that integrates remote file access to look like an ordinary sequential file outpt, remote transfer becomes a straightforward byproduct of file creation. Even systems with no file system can use the concept of an ephemeral file as the output of the Bulk File and the input to the FTP Client MIB. An ephemeral file exists only one buffer at a time, handed back and forth from the writer to the reader, synchronized by a small, easy-to- implement package that provides what looks like an ordinary file interface. The file format is either normal SNMP ASN.1 BER or, preferrably, a simple, sequential format in either binary or ASCII form with minimal redundancy of OID information. See comments in the body of the MIB for the file format. Furthermore, the order of table rows in the file can be whatever the application can generate most efficiently rather than being bound to lexical order. 4. Patent Notice Cisco Systems, Inc. has applied for patents relating to functions of the Bulk File MIB and ephemeral files. If the IETF wishes to standardize those functions as part of SNMP bulk data transfer Cisco is willing to abide by the usual IETF conventions for patent licensing, perhaps with the exception of any company actively involved in patent-based litigation against Cisco. 5. MIB Sections The MIB has two sections: file definition and creation status. In the file definiition section are scalars for managing resources, a Expires 16 November 1998+6 months [Page 4] Internet Draft Bulk File MIB 16 November 1998 table for defining and controlling creation and a table for the objects in each file. The status section contains the status of file creation attempts. 6. Operation Operation is relatively simple. An application creates a definition for a file and the objects to go in it, then sets an object to initiate creation. Status of that creation appears in a new entry in the status table. How the application obtains MIB information is implementation dependent. 7. Security Security of MIB entries depends on SNMPv3 access control for the entire MIB. Security while obtaining MIB data for a file depends on the application conceptually using the isAccessAllowed function from the SNMP View-based Access Control Model (VACM) [15] with the security identification and parameters used to trigger the file creation. Security of files is dependent on the file system in which they reside. Expires 16 November 1998+6 months [Page 5] Internet Draft Bulk File MIB 16 November 1998 8. Definitions CISCO-BULK-FILE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32 FROM SNMPv2-SMI Unsigned32 FROM CISCO-TC RowStatus, DisplayString, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ciscoMgmt FROM CISCO-SMI; ciscoBulkFileMIB MODULE-IDENTITY LAST-UPDATED "9810291700Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: cs-snmp@cisco.com" DESCRIPTION "The MIB module for creating and deleting bulk files of SNMP data for file transfer." ::= { ciscoMgmt 81 } ciscoBulkFileMIBObjects OBJECT IDENTIFIER ::= { ciscoBulkFileMIB 1 } cbfDefine OBJECT IDENTIFIER ::= { ciscoBulkFileMIBObjects 1 } cbfStatus OBJECT IDENTIFIER ::= { ciscoBulkFileMIBObjects 2 } -- -- Bulk File Formats -- -- There are three bulk transfer file formats: -- . ASN.1/BER variable bindings - standard BER, just like you'd Expires 16 November 1998+6 months [Page 6] Internet Draft Bulk File MIB 16 November 1998 -- find it in the varbinds section of a Response PDU. -- . Bulk binary - a binary form designed for fast, sequential -- processing and minimum redundancy. -- . Bulk ASCII - the binary form, mechanically translated to -- human-readable ASCII. -- The ASN.1/BER format is identical to SNMP variable bindings, that is, -- each object has a full OID and a fully tagged value. The file content -- is similar to what would be obtained with a GetBulk request except that -- it does not overshoot for uninstantiated values. In other words, the -- file contains no data at all for scalars or columns that could not be -- read. -- The remainder of this description applies to the bulk binary and bulk -- ASCII formats, not to the ASN.1/BER format. -- The file contains two types of fields: tags and data. Tags identify -- portions of the file and are discussed in detail below. All other -- information is in data fields. -- Note: For efficiency and compactness data fields are not tagged with a -- type. The interpreter of the data must thus know or have access to -- appropriate MIB syntax descriptions to understand the file. -- All data fields are positional relative to a tag and every data field -- has a length prefix. All initial length prefixes are one byte. For -- any data type the distinguished length value 255 indicates that the -- data content is null, that is, no data content value was available and -- there are no additional bytes in the data field. -- INTEGER data fields include all data that maps to ASN.1 INTEGER, -- regardless of length and whether signed or unsigned. They have a -- length prefix value of zero to eight, followed by that many bytes of -- data, high-order byte first. High order bytes that are all zero are -- omitted, thus a length of zero indicates a value of zero. For signed -- numbers, leading bytes of all ones (hex FF) are omitted if the next -- remaining byte has the high bit on. This implies that the file parser -- must know the difference between signed and unsigned integers. -- OCTET STRING values have a length prefix value of zero to two for a -- subsequent unsigned byte count for the number of bytes in the OCTET -- STRING itself, which immediately follows the byte count. The byte -- count can thus range from zero to 65,535. Expires 16 November 1998+6 months [Page 7] Internet Draft Bulk File MIB 16 November 1998 -- OBJECT IDENTIFIER values have a length of zero to 128, for the number -- of sub-identifiers. Each subsequent sub-identifier is encoded as an -- unsigned INTEGER of 0-4 bytes. -- The bulk binary file layout directly reflects the contents of the -- cbfDefineFileObjectTable. It has tagged sections corresponding to -- cbfDefineObjectClass with a few additional tags for utility purposes. -- A tag is one byte with one of the following values: -- -2 row -- -1 prefix -- 0 reserved -- 1 object -- 2 table -- The prefix tag changes the default OID prefix that is assumed to -- precede all OIDs that are not MIB object data values. The prefix tag -- may appear anywhere another tag could appear. A prefix tag is followed -- by one OID data field. The default prefix is 1.3.6.1. A file need not -- set the prefix to the default value. Note that when changing the -- prefix, the default portion must be included at the beginning of the -- new prefix. Typically the prefix will change for each table or group -- of scalar objects. -- An object tag is followed by one OID data field and one data field -- appropriate to the syntax of the object. This OID is the full OID for -- the object minus the current prefix. -- A table tag is followed by one INTEGER data field whose value is the -- number of columns in the table, as implemented by the agent. This is -- followed by one OID data field for each column. This is the OID for -- the column minus the prefix and the instance (typically one -- subidentifier). -- The OIDs are then followed by one row for each row in the table. A row -- starts with a row tag and one OID data field containing only the -- instance portion of the OIDs for the objects in that row. Following -- this is one data field of appropriate type for each column. -- The bulk ASCII form mechanically translates bulk binary into -- human-readable text. -- The indicator for a null value is "~". -- An INTEGER becomes the integer value with a preceding "-" for negative Expires 16 November 1998+6 months [Page 8] Internet Draft Bulk File MIB 16 November 1998 -- values and no leading zeros. -- An OCTET STRING becomes the byte values in hexadecimal, lower case, two -- characters per byte (that is, with leading zeros), no delimiters -- between bytes. -- An OBJECT IDENTIFIER becomes the usual dotted decimal form. -- A tag becomes the tag's name, spelled out fully in lower case, followed -- by one blank and the data field(s) for the tag, separated by spaces and -- ending with a carriage return/line feed. All tags are at the beginning -- of a "line" that is terminated with a carriage return/line feed that -- immediately precedes the next tag or the end of file. -- -- -- File Definition and Creation Control -- -- Definition Resource Management cbfDefineMaxFiles OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of file definitions this system can hold in cbfDefineFileTable. A value of 0 indicates no configured limit. This object may be read-only on some systems. Changing this number does not disturb existing entries." ::= { cbfDefine 1 } cbfDefineFiles OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of file definitions in cbfDefineFileTable." ::= { cbfDefine 2 } cbfDefineHighFiles OBJECT-TYPE Expires 16 November 1998+6 months [Page 9] Internet Draft Bulk File MIB 16 November 1998 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of cbfDefineFiles since system initialization." ::= { cbfDefine 3 } cbfDefineFilesRefused OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of attempts to create a file definition that failed due to exceeding cbfDefineMaxFiles." ::= { cbfDefine 4 } cbfDefineMaxObjects OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum total number of object selections to go with file definitions this system, that is, the total number of objects this system can hold in cbfDefineObjectTable. A value of 0 indicates no configured limit. This object may be read-only on some systems. Changing this number does not disturb existing entries." ::= { cbfDefine 5 } cbfDefineObjects OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of object selections in cbfDefineObjectTable." ::= { cbfDefine 6 } cbfDefineHighObjects OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of cbfDefineObjects since system initialization." Expires 16 November 1998+6 months [Page 10] Internet Draft Bulk File MIB 16 November 1998 ::= { cbfDefine 7 } cbfDefineObjectsRefused OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of attempts to create an object selection that failed due to exceeding cbfDefineMaxObjects." ::= { cbfDefine 8 } -- File Definition Table cbfDefineFileTable OBJECT-TYPE SYNTAX SEQUENCE OF CbfDefineFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of bulk file definition and creation controls." ::= { cbfDefine 9 } cbfDefineFileEntry OBJECT-TYPE SYNTAX CbfDefineFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information for creation of a bulk file. To creat a bulk file an application creates an entry in this table and corresponding entries in cbfDefineObjectTable. When the entry in this table and the corresponding entries in cbfDefineObjectTable are 'active' the appliction uses cbfDefineFileNow to create the file and a corresponding entry in cbfStatusFileTable. Deleting an entry in cbfDefineFileTable deletes all corresponding entries in cbfDefineObjectTable and cbfStatusFileTable. An entry may not be modified or deleted while its cbfDefineFileNow has the value 'running'." INDEX { cbfDefineFileIndex } ::= { cbfDefineFileTable 1 } Expires 16 November 1998+6 months [Page 11] Internet Draft Bulk File MIB 16 November 1998 CbfDefineFileEntry ::= SEQUENCE { cbfDefineFileIndex Unsigned32, cbfDefineFileName DisplayString, cbfDefineFileStorage INTEGER, cbfDefineFileFormat INTEGER, cbfDefineFileNow INTEGER, cbfDefineFileEntryStatus RowStatus } cbfDefineFileIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to uniquely identify this entry. To create an entry a management application should pick a random number." ::= { cbfDefineFileEntry 1 } cbfDefineFileName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The file name which is to be created. Explicit device or path choices in the value of this object override cbfDefineFileStorage." ::= { cbfDefineFileEntry 2 } cbfDefineFileStorage OBJECT-TYPE SYNTAX INTEGER { ephemeral(1), volatile(2), permanent(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of file storage to use: ephemeral data exists in small amounts until read volatile data exists in volatile memory permanent data survives reboot An ephemeral file is suitable to be read only one time. Note that this value is taken as advisory and may be overridden by explicit device or path choices in cbfDefineFile. Expires 16 November 1998+6 months [Page 12] Internet Draft Bulk File MIB 16 November 1998 A given system may support any or all of these." DEFVAL { ephemeral } ::= { cbfDefineFileEntry 3 } cbfDefineFileFormat OBJECT-TYPE SYNTAX INTEGER { standardBER(1), bulkBinary(2), bulkASCII(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The format of the data in the file: standardBER standard SNMP ASN.1 BER bulkBinary a binary format specified with this MIB bulkASCII a human-readable form of bulkBinary A given system may support any or all of these." DEFVAL { bulkBinary } ::= { cbfDefineFileEntry 4 } cbfDefineFileNow OBJECT-TYPE SYNTAX INTEGER { notActive(1), ready(2), create(3), running(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The control to cause file creation. The only value that can be set is 'create' and that can be set only when the value is 'ready'. Setting it to 'create' begins a file creation and creates a corresponding entry in cbfStatusFileTable. The value is 'notActve' as long as cbfDefineFileEntryStatus or any corresponding cbfDefineObjectEntryStatus is not active. When cbfDefineFileEntryStatus becomes active and all corresponding cbfDefineObjectEntryStatuses are active this object automatically goes to 'ready'." DEFVAL { notActive } ::= { cbfDefineFileEntry 5 } cbfDefineFileEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation, modification, and deletion of entries. For detailed rules see the DESCRIPTION for Expires 16 November 1998+6 months [Page 13] Internet Draft Bulk File MIB 16 November 1998 cbfDefineFileEntry." ::= { cbfDefineFileEntry 6 } -- File Object Table cbfDefineObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF CbfDefineObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects to go in bulk files." ::= { cbfDefine 10 } cbfDefineObjectEntry OBJECT-TYPE SYNTAX CbfDefineObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one object for a particular file. An application uses cbfDefineObjectEntryStatus to create entries in this table in correspondence with entries in cbfDefineFileTable, which must be created first. Entries in this table may not be changed, created or deleted while the corresponding value of cbfDefineFileNow is 'running'." INDEX { cbfDefineFileIndex, cbfDefineObjectIndex } ::= { cbfDefineObjectTable 1 } CbfDefineObjectEntry ::= SEQUENCE { cbfDefineObjectIndex Unsigned32, cbfDefineObjectClass INTEGER, cbfDefineObjectID OBJECT IDENTIFIER, cbfDefineObjectEntryStatus RowStatus } cbfDefineObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to uniquely identify this entry. The numeric order of the entries controls the order of Expires 16 November 1998+6 months [Page 14] Internet Draft Bulk File MIB 16 November 1998 the objects in the file." ::= { cbfDefineObjectEntry 1 } cbfDefineObjectClass OBJECT-TYPE SYNTAX INTEGER { object(1), lexicalTable(2), leastCpuTable(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The object class: object a single MIB object lexicalTable an entire table in lexical order leastCpuTable an entire table in cheapest order For 'leastCpuTable' cheapest is defined by the implementation and could be lexical at the same cost." DEFVAL { leastCpuTable } ::= { cbfDefineObjectEntry 2 } cbfDefineObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of a MIB object to be included in the file. If cbfDefineObjectClass is 'object' this must be a full OID, including all instance information. If cbfDefineObjectClass is 'lexicalTable' or 'leastCpuTable' this must be the OID of the table-defining SEQUENCE OF registration point." ::= { cbfDefineObjectEntry 3 } cbfDefineObjectEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation, modification, and deletion Expires 16 November 1998+6 months [Page 15] Internet Draft Bulk File MIB 16 November 1998 of entries. For detailed rules see the DESCRIPTION for cbfDefineObjectEntry." ::= { cbfDefineObjectEntry 4 } -- -- File Status -- -- Resource Control cbfStatusMaxFiles OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of file statuses this system can hold in cbfStatusFileTable. A value of 0 indicates no configured limit. This object may be read-only on some systems. Changing this number deletes the oldest finished entries until the new limit is satisfied." ::= { cbfStatus 1 } cbfStatusFiles OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of file statuses in cbfStatusFileTable." ::= { cbfStatus 2 } cbfStatusHighFiles OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of cbfStatusFiles since system initialization." ::= { cbfStatus 3 } cbfStatusFilesBumped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires 16 November 1998+6 months [Page 16] Internet Draft Bulk File MIB 16 November 1998 STATUS current DESCRIPTION "The number times the oldest entry was deleted due to exceeding cbfStatusMaxFiles." ::= { cbfStatus 4 } -- File Table cbfStatusFileTable OBJECT-TYPE SYNTAX SEQUENCE OF CbfStatusFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of bulk file status." ::= { cbfStatus 5 } cbfStatusFileEntry OBJECT-TYPE SYNTAX CbfStatusFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status for a particular file. An entry exists in this table for each time cbfDefineFileNow has been set to 'create' and the corresponding entry here has not been explicitly deleted by the application or bumped to make room for a new entry. Deleting an entry with cbfStatusFileState 'running' aborts the file creation attempt. It is implementation and file-system specific whether deleting the entry also deletes the file." INDEX { cbfDefineFileIndex, cbfStatusFileIndex } ::= { cbfStatusFileTable 1 } CbfStatusFileEntry ::= SEQUENCE { cbfStatusFileIndex Unsigned32, cbfStatusFileState INTEGER, cbfStatusFileCompletionTime TimeStamp, cbfStatusFileEntryStatus RowStatus } cbfStatusFileIndex OBJECT-TYPE Expires 16 November 1998+6 months [Page 17] Internet Draft Bulk File MIB 16 November 1998 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to uniquely identify this file. The numeric order of the entries implies the creation order of the files." ::= { cbfStatusFileEntry 1 } cbfStatusFileState OBJECT-TYPE SYNTAX INTEGER { running(1), ready(2), emptied(3), noSpace(4), badName(5), writeErr(6), noMem(7), buffErr(8), aborted(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The file state: running data is being written to the file ready the file is ready to be read emptied an ephemeral file was successfully consumed noSpace no data due to insufficient file space badName no data due to a name or path problem writeErr no data due to fatal file write error noMem no data due to insufficient dynamic memory buffErr implementation buffer too small aborted short terminated by operator command Only the 'ready' state implies that the file is available for transfer. The disposition of files after an error is implementation and file-syste specific." ::= { cbfStatusFileEntry 2 } cbfStatusFileCompletionTime OBJECT-TYPE Expires 16 November 1998+6 months [Page 18] Internet Draft Bulk File MIB 16 November 1998 SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the creation attempt completed. A value of 0 indicates not complete. For ephemeral files this is the time when cbfStatusFileState goes to 'emptied'. For others this is the time when the state leaves 'running'." ::= { cbfStatusFileEntry 3 } cbfStatusFileEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The control that allows deletion of entries. For detailed rules see the DESCRIPTION for cbfDefineStatusEntry. This object may not be set to any value other than 'destroy'." ::= { cbfStatusFileEntry 4 } -- -- Conformance -- ciscoBulkFileMIBConformance OBJECT IDENTIFIER ::= { ciscoBulkFileMIB 3 } ciscoBulkFileMIBCompliances OBJECT IDENTIFIER ::= { ciscoBulkFileMIBConformance 1 } ciscoBulkFileMIBGroups OBJECT IDENTIFIER ::= { ciscoBulkFileMIBConformance 2 } -- Compliance ciscoBulkFileMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Cisco Bulk File MIB. Implementation of this MIB is based on individual product needs." MODULE -- this module MANDATORY-GROUPS { ciscoBulkFileDefineGroup, ciscoBulkFileStatusGroup Expires 16 November 1998+6 months [Page 19] Internet Draft Bulk File MIB 16 November 1998 } ::= { ciscoBulkFileMIBCompliances 1 } -- Units of Conformance ciscoBulkFileDefineGroup OBJECT-GROUP OBJECTS { cbfDefineMaxFiles, cbfDefineFiles, cbfDefineHighFiles, cbfDefineFilesRefused, cbfDefineMaxObjects, cbfDefineObjects, cbfDefineHighObjects, cbfDefineObjectsRefused, cbfDefineFileName, cbfDefineFileStorage, cbfDefineFileFormat, cbfDefineFileNow, cbfDefineFileEntryStatus, cbfDefineObjectClass, cbfDefineObjectID, cbfDefineObjectEntryStatus } STATUS current DESCRIPTION "Bulk file definition management." ::= { ciscoBulkFileMIBGroups 1 } ciscoBulkFileStatusGroup OBJECT-GROUP OBJECTS { cbfStatusMaxFiles, cbfStatusFiles, cbfStatusHighFiles, cbfStatusFilesBumped, cbfStatusFileState, cbfStatusFileCompletionTime, cbfStatusFileEntryStatus } STATUS current DESCRIPTION "Bulk file status management." ::= { ciscoBulkFileMIBGroups 2 } Expires 16 November 1998+6 months [Page 20] Internet Draft Bulk File MIB 16 November 1998 END Expires 16 November 1998+6 months [Page 21] Internet Draft Bulk File MIB 16 November 1998 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Expires 16 November 1998+6 months [Page 22] Internet Draft Bulk File MIB 16 November 1998 10. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 16 November 1998+6 months [Page 23] Internet Draft Bulk File MIB 16 November 1998 11. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires 16 November 1998+6 months [Page 24] Internet Draft Bulk File MIB 16 November 1998 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998. [16] Stewart, B., "FTP Client MIB", RFC ????, Cisco Systems, Inc., ?Month? 1998. Expires 16 November 1998+6 months [Page 25] Internet Draft Bulk File MIB 16 November 1998 12. Security Considerations Security issues are discussed in the Overview section and in the DESCRIPTION clauses of relevant objects. 13. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 526 4527 Email: bstewart@cisco.com Expires 16 November 1998+6 months [Page 26] Internet Draft Bulk File MIB 16 November 1998 14. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 16 November 1998+6 months [Page 27] Internet Draft Bulk File MIB 16 November 1998 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 4 Patent Notice ................................................... 4 5 MIB Sections .................................................... 4 6 Operation ....................................................... 5 7 Security ........................................................ 5 8 Definitions ..................................................... 6 9 Intellectual Property ........................................... 22 10 Acknowledgements ............................................... 23 11 References ..................................................... 24 12 Security Considerations ........................................ 26 13 Author's Address ............................................... 26 14 Full Copyright Statement ....................................... 27 Expires 16 November 1998+6 months [Page 28]