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 <Harald.Alvestrand@maxware.no> and Bert Wijnen
<wijnen@vnet.ibm.com>.
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]