[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]