The list component of a (subtree, list) tuple. The purpose of
a tuple is to identify the base objects of a 'table' type
data group.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier. The list
specifies a set of data items, where the presence of an item
in the list indicates that the item is selected as a column
of the 'table' type data group; the absence of an item
from the list indicates that the item is not selected as a
column of the 'table' type data group.
Each data item is represented by an integer which when
appended (as as additional sub-identifier) to the OBJECT
IDENTIFIER value of the subtree identified by the tuple, is
the name of an object defining that data item (its description
and its syntax).
The list is specified as an OCTET STRING in which each data
item is represented by a single bit, where data items 1
through 8 are represented by the bits in the first octet,
data items 9 through 16 by the bits in the second octet,
etc. In each octet, the lowest numbered data item is
represented by the most significant bit, and the highest
numbered data item by the least significant bit. A data
item is present in the list when its bit is set, and absent
when its bit is reset. If the length of an OCTET STRING
value is too short to represent one or more data items
defined in a subtree, then those data items are absent from
the set identified by the tuple of that subtree and that
OCTET STRING value.
CdcCollectionSubtree
string
The subtree component of a (subtree, list) tuple.
The purpose of a tuple is to identify the columns
(base objects) in a 'table' type data group.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier derived from
the list component of the tuple.
A typical example would be the OBJECT IDENTIFER of the
fooEntry construct in a MIB table.
e.g. ifEntry.
CdcFileFormat
enumeration
The file formats supported are:
cdcBulkASCII ASCII format similar to
the 'bulkASCII' format of the
CISCO-BULK-FILE-MIB.
cdcBulkBinary Binary format similar to
the 'bulkBinary' format of the
CISCO-BULK-FILE-MIB.
cdcSchemaASCII Again an ASCII format, but contains
parser friendly hints for parsing data
values.
Format descriptions :
---------------------
The below description applies to cdcBulkASCII & cdcBulkBinary
and is extracted from CISCO-BULK-FILE-MIB. Some differences are
highlighted below:
1) Data for a single data group can be collected more than
once into the same VFile (due to periodic polling). Each
such instance of a data group, can be treated much like
different 'table' types in the CISCO-BULK-FILE-MIB.
2) Every object & table tag contains an additional sysUpTime
field. Similarly each row tag contains the value of the
sysUpTime when the data for that row was collected.
The rest of the description is taken from the
CISCO-BULK-FILE-MIB.
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.
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
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.
A table tag is followed by one INTEGER data field whose value
is the number of columns in the table (including the
sysUpTime column), as implemented by the agent. This is
followed by an OID field containing the sysUpTime OID. 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, one OID data field
containing only the instance portion of the OIDs for the
objects in that row and one data field indicating the
sysUpTime when the row was sampled.
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 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.
CdcFileXferStatus
enumeration
The status of a file transfer. The different values are given
below:
notStarted File transfer has not started.
success File transfer has successfully
completed.
aborted File transfer has been aborted.
fileOpenFailRemote Remote file could not be opened.
badDomainName Bad domain name given in the URL.
unreachableIpAddress IP address given in the URL could not
be reached.
networkFailure Transfer failed due to a network
failure.
fileWriteFailed A write on the remote file has
failed.
authFailed Authentication failed. For instance
incorrect password in CdcUrl incase
of FTP(File Transfer Protocol).
CdcRowInstanceId
string
A fragment of a OBJECT IDENTIFIER (OID). It is used to
specify the instances of the base objects whose values
need to be fetched. To comply with the definition of an
OBJECT IDENTIFIER, the first two sub-ids of a
CdcRowInstanceId value is {0,0}.
CdcUrl
binary
Represents a string that contains a Uniformed Resource
Locator as defined in RFC 1738.