RFC 2513
Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
RFC 2513 🎀
Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
Okay bestie, let's start with the who-and-what ✨. This one came out in February 1999 and it's on the Standards Track 🦋. The authors are K. McCloghrie (Cisco Systems, Inc.), J. Heinanen (Telia Finland, Inc.), W. Greene (MCI Telecommunications Corp.), and A. Prasad (Cisco Systems, Inc.) 💅. It doesn't list any RFC that it obsoletes or updates, so nothing older is getting replaced here 🙈.
Status of this Memo 📜
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💖. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved. 🫶
Table of Contents 🗂️
1 Introduction .................................................... 2
2 The SNMP Network Management Framework ........................... 2
3 Overview ........................................................ 3
3.1 Operational Model ............................................. 3
3.2 Selection of Accounting Data .................................. 5
3.3 Format of Collection File ..................................... 6
4 Definitions ..................................................... 9
5 Acknowledgements ................................................25
6 References ......................................................25
7 Security Considerations .........................................27
8 IANA Considerations .............................................27
9 Authors' Addresses ..............................................28
10 Full Copyright Statement .......................................291. Introduction 🌸
This memo defines a chunk of the Management Information Base (MIB) for use with network management protocols in the Internet community 🧚. Specifically, it covers managed objects for controlling how accounting information gets collected and stored for connection-oriented networks, like ATM. The accounting data is gathered into files that you can fetch later with a file transfer protocol 📁. If you want to know what data can be collected for ATM networks, see [19] 👀.
2. The SNMP Network Management Framework 🧠
The SNMP Management Framework currently has five major components 💜:
- An overall architecture, described in RFC 2271 [1].
- 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 is described in STD 16, RFC 1155 [2], STD 16, 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].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
- 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 through a virtual information store called the Management Information Base, or MIB 🗃️. Objects in the MIB are defined using the mechanisms that the SMI defines ✨.
This memo specifies a MIB module that is compliant to SMIv2 💅. A MIB conforming to 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 (for example, use of Counter64) 🙈. Some machine-readable information in SMIv2 gets converted into textual descriptions in SMIv1 during translation. However, losing that machine-readable information is not considered to change the semantics of the MIB 🦋.
3. Overview 🔭
In some connection-oriented network environments, the network administrator needs to be able to collect accounting data on how bandwidth and resources are used by connections (for example, ATM connections) inside the network 📊. Data collection should be available for switched virtual connections (SVCs and SVPs), permanent virtual connections (PVCs and PVPs), and soft-permanent virtual connections (SPVCCs and SPVPCs) 🌈. This need exists for ATM networks, and it may well exist for other connection-oriented networks, such as Frame Relay 🫶.
The potential amount of this accounting information is so large that, in general, it isn't feasible to retrieve it via SNMP 😭. A better approach is to store the collected accounting information in a file, which can then be retrieved later via a file transfer protocol 💾.
It is still appropriate to provide management control over selecting and collecting this accounting data via SNMP 🎛️. This memo describes a MIB module that provides that control in a way that is independent of the type of network 💖. One or more other documents define the particular items of accounting data that can be selected. For example, a particular set of data items that can be collected for ATM networks is specified in [19] 🧚.
3.1. Operational Model 🛠️
The requirement is for switches (for example, ATM switches) to collect data about the connections routed across some subset of their interfaces (for example, ATM UNI and/or NNI interfaces) 🔁. The collected data is stored into one or more "files". Using multiple files means, for example, that the data collected for PVCs can be different from the data collected for SVCs 🎀.
To retrieve the data currently being stored in a file, the administrator tells the switch to stop collecting data into that file and to start collecting data into a new file 🧾.
After this operation, the data in the old file is available for retrieval via file transfer 📥.
A collection file is defined to have a maximum size. When the size of the file currently being collected goes over a threshold percentage of that maximum, an SNMP notification (for example, a trap) can optionally be generated 🚨. An SNMP notification might also be generated if the file reaches its maximum size 😬.
The accounting data collected for each connection consists of a set of objects and their values. That set of objects and values is collected on one or more of the following occasions 🗓️:
- On the release (termination) of a connection, optionally including failed connection attempts ❌.
- For each active connection (having a particular minimum age), on a periodic basis ⏰.
- For each active connection (having a particular minimum age), when a management application commands it to 🫡.
While collecting data to be stored in a particular file, the same set of objects is collected for each connection on each occasion. Keeping the same set of objects on every occasion lets you store only the values of those objects, which is a total glow-up for file size 📉. The names of the objects get stored once and only once at the beginning of the file, instead of storing every value as a (name, value) pair 🧠.
Two modes of agent behaviour are allowed when a file reaches its maximum size 🦋:
- Management application in control: The agent does not automatically swap to a new file. Instead, it discards newly collected data until the management application subsequently instructs it to swap to a new file. Before a swap, the name of the file into which data is currently being collected is an implementation issue of no concern to an NM application. After the swap, the name of the file available for retrieval is as specified by the controlling MIB objects. This behaviour lets the application know exactly how many files need to be retrieved and their names, without having to do any file directory operation. The catch is that data can be discarded if the application doesn't instruct the agent to swap within the required time frame 😳.
- Agent automatically swaps to new file: The agent terminates collection into the current (full) file and begins collecting data into a new version of the same base file name. This behaviour aims to avoid data loss by assuming that additional storage space is actually available to create a new version of the file 💪. To support it, files are named using suffixes. When the current version of the file becomes full, the agent begins collecting data into a file with the same base file name but with an incremented (or otherwise modified) suffix. This requires the application to perform file directory operations before retrieving completed files, so it can know how many suffixes have been used and which ones they are 🗂️.
With either behaviour, any completed file must be an integral number of connection records (see below) 💅. When a file reaches its maximum size, collection into that file is terminated either immediately before or immediately after storing the whole of the current connection record into the file. Terminating before the record makes the file just less than its maximum size, and terminating after it makes the file just greater than its maximum size ✨.
3.2. Selection of Accounting Data
okay so the accounting data you collect is a set of objects 💅 and the admin gets to pick which objects go in by writing one or more (subtree, list) tuples 🎀. The final set is the union of whatever each tuple gives you ✨
- 'subtree' is an OBJECT IDENTIFIER value. Every object in the subset is named by that value with one extra sub-identifier tacked on the end 🦋
- 'list' is an OCTET STRING. If the N-th bit of its value is set, the subset includes the object named by the subtree plus N as one extra sub-identifier 🌸
the reason each subset is a (subtree, list) tuple is that you only need ONE OBJECT IDENTIFIER and ONE OCTET STRING to define the whole thing 😭🫶 that makes the MIB stuff way simpler, because an NM application only has to create one conceptual row in a MIB table per subset. it does NOT have to make a row for every single object in the set. main character energy 👑
how many tuples a switch supports is up to the implementation 🧚. one idea is to support two tuples, so one can point at a standard 'subtree' (like the atmAcctngDataObjects subtree defined in [19]) and the other can point at an enterprise-specific 'subtree'. that way your selected set is the union of standard objects and enterprise-defined objects. iconic, honestly 💜
3.3. Format of Collection File
a collection file made by this process holds the values of MIB objects defined using the SMIv2 📦 the standard, device-independent way to encode those values is ASN.1's Basic Encoding Rules (BER) [18] 🍓 so the standard format of an accounting file is defined here using the same adapted subset of ASN.1 [17] that the SMIv2 uses 🌈
the file is a header followed by zero or more collection records ✨ the header tells you (via sysName [16]) which switch collected the data 🖥️, the date and time the collection into this file started ⏰, and the sequence of one or more (subtree, list) tuples that identify the objects whose values live in each connection record 💖. the header also has a textual description of what's in the file 📝
each connection record has a sequence of values for every tuple, in the same order the tuples are listed in the header 🫶 and for each tuple, those values go in ascending order of the sub-identifier that identifies them within the subtree 🔥
formally, an accounting file is an ASN.1 value with this syntax:
File ::=
[1]
IMPLICIT SEQUENCE {
-- header information
sysName -- name of the switch
DisplayString,
description -- textual description of the collection
DisplayString,
startTime -- start time of the collection
DateAndTime,
SEQUENCE OF { -- sequence of (subtree, list) tuples
SEQUENCE {
subtree
OBJECT IDENTIFIER,
list
OCTET STRING
}
}
-- sequence of connection records
SEQUENCE OF {
-- each record containing a sequence
SEQUENCE OF { -- per identified tuple
SEQUENCE OF { -- each per-tuple sequence containing
value -- a sequence of object values
ObjectSyntax
}
}
}
}where the bits and pieces mean:
- the value of the sysName component is whatever the sysName object in the System group [16] says 🖥️
- each (subtree, list) sets the objects that live in that tuple's sequence inside each and every connection record 💅
- the tuples' sequences inside each connection record show up in the same order as the (subtree, list) tuples in the header information 🎀
- the object values inside each connection record are in the same order as their bits show up in the matching list value 🦋
- ObjectSyntax is defined by the SMIv2 [5] 📚
- okay this one deserves a little extra attention 👀 an object that holds the checksum of an accounting record (like atmAcctngRecordCrc16, defined in [19]) is a special category. it usually has a SYNTAX of a fixed-length OCTET STRING, and its value starts out as a string of all zeros while the accounting record containing it is being composed. the spot where those zeros sit gets saved 🙈 once the record is generated, the checksum is calculated over the whole connection record (including the starting SEQUENCE OF and the trailing end-of-contents octets, if they're used), and then the zeros get overwritten at that saved spot with the calculated checksum value 🔥
the encoding of that syntax with the Basic Encoding Rules is the same as what SNMPv2 [10] defines, with one exception 🌸
- when you encode the length field for a structured type (a SEQUENCE or SEQUENCE OF), the indefinite form encoding is permitted 🧚
for example, here's a file holding this data:
[1] IMPLICIT SEQUENCE a1 80
OCTET STRING 04 09 73 77 69 74 63 68 2d 31 32
OCTET STRING 04 0a 41 63 63 6f 75 6e 74 69 6e 67
OCTET STRING 04 08 07 cc 07 14 10 05 00 00
SEQUENCE OF 30 0e
SEQUENCE 30 0c
OBJECT IDENTIFIER 06 07 2b 06 01 03 7f 01 01
OCTET STRING 04 01 c0
SEQUENCE OF 30 80
SEQUENCE OF 30 08
SEQUENCE OF 30 06
INTEGER 02 01 00
INTEGER 02 01 21
SEQUENCE OF 30 08
SEQUENCE OF 30 06
INTEGER 02 01 00
INTEGER 02 01 22
end-of-contents 00 00
end-of-contents 00 00this file has two connection records, and each one has a single tuple listing two (integer) data items in a (fictitious) subtree: 1.3.6.1.3.127.1.1 🦋 the header says it's for "switch-12" with the description "Accounting", and it was collected at 16:05:00 on 20 July 1996 🎀
btw, on top of the standard format above, the MIB also lets you use other enterprise-specific formats 🌈
4. Definitions ✨
okay here's the actual MIB module 📜 it's the big one, so buckle up 💖
ACCOUNTING-CONTROL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
mib-2, Integer32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TestAndIncr,
DisplayString, TruthValue FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
ifIndex FROM IF-MIB;
accountingControlMIB MODULE-IDENTITY
LAST-UPDATED "9809281000Z"
ORGANIZATION "IETF AToM MIB Working Group"
CONTACT-INFO "Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134-1706.
Phone: +1 408 526 5260
Email: kzm@cisco.com"
DESCRIPTION
"The MIB module for managing the collection and storage of
accounting information for connections in a connection-
oriented network such as ATM."
::= { mib-2 60 }
acctngMIBObjects OBJECT IDENTIFIER ::= { accountingControlMIB 1 }
acctngSelectionControl OBJECT IDENTIFIER ::= { acctngMIBObjects 1 }
acctngFileControl OBJECT IDENTIFIER ::= { acctngMIBObjects 2 }
acctngInterfaceControl OBJECT IDENTIFIER ::= { acctngMIBObjects 3 }
acctngTrapControl OBJECT IDENTIFIER ::= { acctngMIBObjects 4 }
-- Textual Conventions
DataCollectionSubtree ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The subtree component of a (subtree, list) tuple. Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
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."
SYNTAX OBJECT IDENTIFIER
DataCollectionList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The list component of a (subtree, list) tuple. Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
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 (to be) present in
the data collected for a connection; the absence of an item
from the list indicates that the item is not (to be) present
in the data collected for a connection. 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."
SYNTAX OCTET STRING (SIZE(0..8))
FileIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An arbitrary integer value identifying a file into which
accounting data is being collected."
SYNTAX Integer32 (1..65535)
-- The Accounting Information Selection tableokay so the selection table is where the magic happens 🎀 each row is basically a little (subtree, list) pair that says "collect THIS stuff," and the changes you make don't kick in until the next new file starts. iykyk 💅
acctngSelectionTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcctngSelectionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of accounting information selection entries.
Note that additions, modifications and deletions of entries
in this table can occur at any time, but such changes only
take effect on the next occasion when collection begins into
a new file. Thus, between modification and the next 'swap',
the content of this table does not reflect the current
selection."
::= { acctngSelectionControl 1 }
acctngSelectionEntry OBJECT-TYPE
SYNTAX AcctngSelectionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry identifying an (subtree, list) tuple used to
select a set of accounting information which is to be
collected."
INDEX { acctngSelectionIndex }
::= { acctngSelectionTable 1 }
AcctngSelectionEntry ::=
SEQUENCE {
acctngSelectionIndex Integer32,
acctngSelectionSubtree DataCollectionSubtree,
acctngSelectionList DataCollectionList,
acctngSelectionFile FileIndex,
acctngSelectionType BITS,
acctngSelectionRowStatus RowStatus
}So every row in that table has six columns: an index, a subtree, a list, a file, a type, and a row status. Think of it like a playlist entry that knows what to grab, where to put it, and whether it's currently live 🦋
acctngSelectionIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An arbitrary integer value which uniquely identifies a
tuple stored in this table. This value is required to be
the permanent 'handle' for an entry in this table for as
long as that entry exists, including across restarts and
power outages."
::= { acctngSelectionEntry 1 }
acctngSelectionSubtree OBJECT-TYPE
SYNTAX DataCollectionSubtree
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The combination of acctngSelectionSubtree and
acctngSelectionList specifies one (subtree, list) tuple
which is to be collected."
::= { acctngSelectionEntry 2 }
acctngSelectionList OBJECT-TYPE
SYNTAX DataCollectionList
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The combination of acctngSelectionSubtree and
acctngSelectionList specifies one (subtree, list) tuple
which is to be collected."
::= { acctngSelectionEntry 3 }
acctngSelectionFile OBJECT-TYPE
SYNTAX FileIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An indication of the file into which the accounting
information identified by this entry is to be stored. If
there is no conceptual row in the acctngFileTable for which
the value of acctngFileIndex has the same value as this
object, then the information selected by this entry is not
collected."
::= { acctngSelectionEntry 4 }The index is the permanent handle for a row, and it has to stick around even through restarts and power outages 🫶 The subtree and list columns are a team: you only get a full (subtree, list) pair when you read them together. And if the file column doesn't point at a real file row, the selection just quietly doesn't collect anything. Plot twist 🙈
acctngSelectionType OBJECT-TYPE
SYNTAX BITS { svcIncoming(0),
svcOutgoing(1),
svpIncoming(2),
svpOutgoing(3),
pvc(4),
pvp(5),
spvcOriginator(6),
spvcTarget(7),
spvpOriginator(8),
spvpTarget(9) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the types of connections for which the
information selected by this entry are to be collected."
DEFVAL { { svcIncoming, svcOutgoing,
svpIncoming, svpOutgoing } }
::= { acctngSelectionEntry 5 }
acctngSelectionRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row. An agent may refuse to
create new conceptual rows and/or modify existing conceptual
rows, if such creation/modification would cause multiple
rows to have the same values of acctngSelectionSubtree and
acctngSelectionList.
A conceptual row can not have the status of 'active' until
values have been assigned to the acctngSelectionSubtree,
acctngSelectionList and acctngSelectionFile columnar objects
within that row.
An agent must not refuse to change the values of the
acctngSelectionSubtree, acctngSelectionList and
acctngSelectionFile columnar objects within a conceptual row
even while that row's status is 'active'. Similarly, an
agent must not refuse to destroy an existing conceptual row
while the file referenced by that row's instance of
acctngSelectionFile is in active use, i.e., while the
corresponding instance of acctngFileRowStatus has the value
'active'. However, such changes only take effect upon the
next occasion when collection begins into a new (version of
the) file."
::= { acctngSelectionEntry 6 }The type column is a set of bits, one per kind of connection, and it defaults to the svc and svp incoming and outgoing ones 💜 The row status is the drama queen of the table 👑 A row can't go 'active' until its subtree, list and file all have values, and the agent isn't allowed to block changes to those three columns while the row is live. Even so, the changes only show up when the next new file starts. Patience, bestie ✨
Now we move on to the file side of things 🌸
-- The Accounting File table
acctngFileTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcctngFileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of files into which accounting information is to be
stored."
::= { acctngFileControl 1 }
acctngFileEntry OBJECT-TYPE
SYNTAX AcctngFileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry identifying a file into which accounting
information is to be collected."
INDEX { acctngFileIndex }
::= { acctngFileTable 1 }
AcctngFileEntry ::=
SEQUENCE {
acctngFileIndex FileIndex,
acctngFileName DisplayString,
acctngFileNameSuffix DisplayString,
acctngFileDescription DisplayString,
acctngFileCommand INTEGER,
acctngFileMaximumSize Integer32,
acctngFileCurrentSize Integer32,
acctngFileFormat INTEGER,
acctngFileCollectMode BITS,
acctngFileCollectFailedAttempts BITS,
acctngFileInterval Integer32,
acctngFileMinAge Integer32,
acctngFileRowStatus RowStatus
}
acctngFileIndex OBJECT-TYPE
SYNTAX FileIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value identifying a file into which accounting
data is to be stored. This value is required to be the
permanent 'handle' for an entry in this table for as long as
that entry exists, including across restarts and power
outages."
::= { acctngFileEntry 1 }
acctngFileName OBJECT-TYPE
SYNTAX DisplayString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The name of the file into which accounting data is to be
stored. If files are named using suffixes, then the name of
the current file is the concatenation of acctngFileName and
acctngFileNameSuffix.
An agent will respond with an error (e.g., 'wrongValue') to
a management set operation which attempts to modify the
value of this object to the same value as already held by
another instance of acctngFileName. An agent will also
respond with an error (e.g., 'wrongValue') if the new value
is invalid for use as a file name on the local file system
(e.g., many file systems do not support white space embedded
in file names).
The value of this object can not be modified while the
corresponding instance of acctngFileRowStatus is 'active'."
::= { acctngFileEntry 2 }
acctngFileNameSuffix OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The suffix, if any, of the name of a file into which
accounting data is currently being stored. If suffixes are
not used, then the value of this object is the zero-length
string. Note that if a separator, such as a period, is used
in appending the suffix to the file name, then that
separator appears as the first character of this value."
::= { acctngFileEntry 3 }
acctngFileDescription OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The textual description of the accounting data which will
be stored (on the next occasion) when header information is
stored in the file. The value of this object may be
modified at any time."
DEFVAL { "" }
::= { acctngFileEntry 4 }
acctngFileCommand OBJECT-TYPE
SYNTAX INTEGER {
-- the following two values are states:
-- they may be read but not written
idle(1),
cmdInProgress(2),
-- the following two values are actions:
-- they may be written, but are never read
swapToNewFile(3),
collectNow(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control object for the collection of accounting data.
When read the value is either 'idle' or 'cmdInProgress'.
Writing a value is only allowed when the current value is
'idle'. When a value is successfully written, the value
changes to 'cmdInProgress' until completion of the action,
at which time the value reverts to 'idle'. Actions are
invoked by writing the following values:
'swapToNewFile' - the collection of data into the current
file is terminated, and collection continues into
a new (version of the) file.
'collectNow' - the agent creates and stores a connection
record into the current file for each active
connection having a type matching
acctngSelectionType and an age greater than
acctngFileMinAge."
DEFVAL { idle }
::= { acctngFileEntry 5 }
acctngFileMaximumSize OBJECT-TYPE
SYNTAX Integer32 (100..2147483647)
UNITS "bytes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum size of the file (including header
information). When the file of collected data reaches this
size, either the agent automatically swaps to a new version
(i.e., a new value acctngFileNameSuffix) of the file, or new
records are discarded. Since a file must contain an
integral number of connection records, the actual maximum
size of the file may be just less OR Just greater than the
value of this object.
The value of this object can not be modified while the
corresponding instance of acctngFileRowStatus is 'active'.
The largest value of the maximum file size in some agents
will be less than 2147483647 bytes."
DEFVAL { 5000000 }
::= { acctngFileEntry 6 }
acctngFileCurrentSize OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current size of the file into which data is currently
being collected, including header information."
::= { acctngFileEntry 7 }acctngFileFormat
acctngFileFormat OBJECT-TYPE
SYNTAX INTEGER { other(1), ber(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An indication of the format in which the accounting data is
to be stored in the file. If the value is modified, the new
value takes effect after the next 'swap' to a new file. The
value ber(2) indicates the standard format."
DEFVAL { ber }
::= { acctngFileEntry 8 }okay so this one picks the format the accounting data gets saved in 📁✨ it's an integer, other(1) or ber(2), and the default is ber, which is the standard format 💖 if you change it, the new format doesn't kick in right away. it waits until the next 'swap' to a new file, so no mid-file surprises 🙈 literally so considerate
acctngFileCollectMode
acctngFileCollectMode OBJECT-TYPE
SYNTAX BITS { onRelease(0), periodically(1) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An indication of when accounting data is to be written into
this file. Note that in addition to the occasions indicated
by the value of this object, an agent always writes
information on appropriate connections to the file when the
corresponding instance of acctngFileCommand is set to
'collectNow'.
- 'onRelease' - whenever a connection (or possibly,
connection attempt) is terminated, either through
a Release message or through management removal,
information on that connection is written.
- 'periodically' - information on appropriate connections
is written on the expiry of a periodic timer,
This value may be modified at any time."
DEFVAL { { onRelease } }
::= { acctngFileEntry 9 }this is the "when do we write stuff down" setting 📝 there are two flags, onRelease(0) and periodically(1), and the default is just onRelease 💅
onReleasemeans the write happens whenever a connection (or maybe just a connection attempt) gets terminated, either by a Release message or by management removing it.periodicallymeans the write happens when a periodic timer runs out.
no matter what's set here, the agent ALWAYS writes the relevant connections whenever acctngFileCommand gets set to 'collectNow' 🔥 that's the "pls save it NOW" button. and you can change this anytime bestie 🦋
acctngFileCollectFailedAttempts
acctngFileCollectFailedAttempts OBJECT-TYPE
SYNTAX BITS { soft(0), regular(1) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An indication of whether connection data is to be collected
for failed connection attempts when the value of the
corresponding instance of acctngFileCollectMode includes
'onRelease'. The individual values have the following
meaning:
'soft' - indicates that connection data is to be collected
for failed Soft PVCs/PVPs which originate or terminate at
the relevant interface.
'regular' - indicates that connection data is to be
collected for failed SVCs, including Soft PVCs/PVPs not
originating or terminating at the relevant interface.
This value may be modified at any time."
DEFVAL { { soft, regular } }
::= { acctngFileEntry 10 }this one is about failed connection attempts 🙈 it only matters when acctngFileCollectMode includes 'onRelease'. the default is both flags on, soft and regular.
softcovers failed Soft PVCs/PVPs that start or end at the relevant interface.regularcovers failed SVCs, plus Soft PVCs/PVPs that don't start or end at that interface.
the vibe is "track the fails too" 🎀 and it can be changed anytime ✨
acctngFileInterval
acctngFileInterval OBJECT-TYPE
SYNTAX Integer32 (60..86400)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of seconds between the periodic collections of
accounting data when the value of the corresponding instance
of acctngFileCollectMode includes 'periodically'. Some
agents may impose restrictions on the range of this
interval. This value may be modified at any time."
DEFVAL { 3600 }
::= { acctngFileEntry 11 }this is the timer ⏰ it's measured in seconds, between 60 and 86400, and the default is 3600 (that's one hour, bestie). it only applies when acctngFileCollectMode includes 'periodically'. some agents might limit the range, so it's not guaranteed to be whatever you want 💀 and yes, you can change it whenever 🌸
acctngFileMinAge
acctngFileMinAge OBJECT-TYPE
SYNTAX Integer32 (60..86400)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The minimum age of a connection, as used to determine the
set of connections for which data is to be collected at the
periodic intervals and/or when acctngFileCommand is set to
'collectNow'. The age of a connection is the elapsed time
since it was last installed.
When the periodic interval expires for a file or when
acctngFileCommand is set to 'collectNow', accounting data is
collected and stored in the file for each connection having
a type matching acctngSelectionType and whose age at that
time is greater than the value of acctngFileMinAge
associated with the file. This value may be modified at any
time."
DEFVAL { 3600 }
::= { acctngFileEntry 12 }okay so min age is the "old enough to count" check 🧚 it's in seconds, 60 to 86400, and defaults to 3600. a connection's age is how long it's been since it was last installed ⏳
when the periodic timer runs out, or someone sets acctngFileCommand to 'collectNow', the agent grabs data for each connection whose acctngSelectionType matches AND whose age is greater than acctngFileMinAge for that file. so brand-new connections get left out, lowkey iconic 👑 you can tweak it anytime 🫶
acctngFileRowStatus
acctngFileRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row.
This object can not be set to 'active' until a value has
been assigned to the corresponding instance of
acctngFileName. Collection of data into the file does not
begin until this object has the value 'active' and one or
more (active) instances of acctngSelectionFile refer to it.
If this value is modified after a collection has begun,
collection into this file terminates and a new (or new
version of the) file is immediately made ready for future
collection (as if acctngFileCommand had been set to
'swapToNewFile'), but collection into the new (or new
version of the) file does not begin until the value is
subsequently set back to active."
::= { acctngFileEntry 13 }this is the row's on/off switch 🔘 you can't set it to 'active' until acctngFileName has a value, so no nameless files allowed 🙅♀️
collection only starts once this is 'active' AND at least one active acctngSelectionFile points at it. if you change it after collection has already started, collection into this file stops and a fresh (or new version of the) file gets prepped for next time, as if acctngFileCommand had been set to 'swapToNewFile' 🔄 then collection into that new file doesn't start until the value goes back to active. it's a whole plot twist, honestly 😭
Overall Control
-- Overall Control
acctngAdminStatus OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control object to indicate the administratively desired
state of the collection of accounting records across all
interfaces.
Modifying the value of acctngAdminStatus to 'disabled' does
not remove or change the current configuration as
represented by the active rows in the acctngSelectionTable,
acctngFileTable and acctngInterfaceTable tables."
::= { acctngInterfaceControl 1 }
acctngOperStatus OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A status object to indicate the operational state of the
collection of accounting records across all interfaces.
When the value of acctngAdminStatus is modified to be
'enabled', the value of this object will change to 'enabled'
providing it is possible to begin collecting accounting
records.
When the value of acctngAdminStatus is modified to be
'disabled', the value of this object will change to
'disabled' as soon as the collection of accounting records
has terminated."
::= { acctngInterfaceControl 2 }
acctngProtection OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control object to protect against duplication of control
commands. Over some transport/network protocols, it is
possible for SNMP messages to get duplicated. Such
duplication, if it occurred at just the wrong time could
cause serious disruption to the collection and retrieval of
accounting data, e.g., if a SNMP message setting
acctngFileCommand to 'swapToNewFile' were to be duplicated,
a whole file of accounting data could be lost.
To protect against such duplication, a management
application should retrieve the value of this object, and
include in the Set operation needing protection, a variable
binding which sets this object to the retrieved value."
::= { acctngInterfaceControl 3 }
acctngAgentMode OBJECT-TYPE
SYNTAX INTEGER { swapOnCommand(1), swapOnFull(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the behaviour mode of the agent when a
file becomes full:
'swapOnCommand' - the agent does not automatically swap
to a new file; rather, it discards newly collected
data until a management application subsequently
instructs it to swap to a new file.
'swapOnFull' - the agent terminates collection into the
current file as and when that file becomes full."
::= { acctngInterfaceControl 4 }acctngAdminStatus
this is the big master switch for accounting across all interfaces 🎛️ it can be enabled(1) or disabled(2), and it's the admin's wish, basically what you WANT the state to be.
flipping it to 'disabled' doesn't wipe your setup 🙌 your active rows in acctngSelectionTable, acctngFileTable and acctngInterfaceTable all stay exactly as they are. pause, not delete, very self-care 🧖♀️
acctngOperStatus
this is the reality check 👀 it's read-only and tells you what's actually happening across all interfaces, enabled(1) or disabled(2).
- once
acctngAdminStatusgoes to'enabled', this flips to'enabled'too, as long as accounting records can actually start being collected. - once
acctngAdminStatusgoes to'disabled', this flips to'disabled'as soon as collection has fully stopped.
so admin says yes, oper tells you if it's real 💅
acctngProtection
this one is the anti-double-tap guard 🛡️ over some transport and network protocols, SNMP messages can get duplicated, and if that happens at the wrong moment it can mess things up badly. the example in the RFC is a duplicated acctngFileCommand set to 'swapToNewFile', which could make a whole file of accounting data disappear 😱
the fix is: the management app reads this object's value, then includes it in the Set it needs protected, sending back the value it just retrieved. it's a TestAndIncr, so it's basically a little ticket number 🎟️ literally so smart
acctngAgentMode
this tells you what the agent does when a file gets full 📂 it's read-only, and it's swapOnCommand(1) or swapOnFull(2).
'swapOnCommand': the agent does NOT switch files on its own. it just throws away new data until a management app tells it to swap to a new file 🗑️'swapOnFull': the agent stops collecting into the current file as soon as that file is full 🛑
two very different vibes, pick your fighter 🥊
Per-interface control table
-- Per-interface control table
acctngInterfaceTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcctngInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table controlling the collection of accounting data on
specific interfaces of the switch."
::= { acctngInterfaceControl 5 }
acctngInterfaceEntry OBJECT-TYPE
SYNTAX AcctngInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry which controls whether accounting data is to be
collected on an interface. The types of interfaces which
are represented in this table is implementation-specific."
INDEX { ifIndex }
::= { acctngInterfaceTable 1 }
AcctngInterfaceEntry ::=
SEQUENCE {
acctngInterfaceEnable TruthValue
}
acctngInterfaceEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether the collection of accounting data is
enabled on this interface."
::= { acctngInterfaceEntry 1 }okay so this is the per-interface control table 🔌 acctngInterfaceTable is the table that controls accounting on specific switch interfaces. each row is indexed by ifIndex, and each row decides whether accounting is on for that interface 💖
the table's entries are acctngInterfaceEntry, and which types of interfaces show up in here is implementation-specific, so it depends on the box 🤷♀️
the actual on/off toggle is acctngInterfaceEnable, a TruthValue you can read and write. it just says whether accounting data collection is enabled on that interface ✨
Objects for controlling the use of Notifications
-- Objects for controlling the use of Notifications
acctngControlTrapThreshold OBJECT-TYPE
SYNTAX INTEGER (0..99)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A percentage of the maximum file size at which a 'nearly-
full' trap is generated. The value of 0 indicates that no
'nearly-full' trap is to be generated."
::= { acctngTrapControl 1 }
acctngControlTrapEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An indication of whether the acctngFileNearlyFull and
acctngFileFull traps are enabled."
::= { acctngTrapControl 2 }acctngControlTrapThreshold
this sets the "getting kinda full" alarm point 🚨 it's a percentage, 0 to 99, of the maximum file size, and it's the point where a 'nearly-full' trap fires. set it to 0 and you're basically saying "never send the nearly-full trap" 🙅♀️
acctngControlTrapEnable
this is the on/off for the file traps 🔔 it's a TruthValue that says whether acctngFileNearlyFull and acctngFileFull traps are enabled. read-write, so you control it 👑
Notifications
-- notifications
acctngNotifications OBJECT IDENTIFIER ::= { accountingControlMIB 2 }
acctngNotifyPrefix OBJECT IDENTIFIER ::= { acctngNotifications 0 }
acctngFileNearlyFull NOTIFICATION-TYPE
OBJECTS { acctngFileName,
acctngFileMaximumSize,
acctngControlTrapThreshold,
acctngFileNameSuffix }
STATUS current
DESCRIPTION
"An indication that the size of the file into which
accounting information is currently being collected has
exceeded the threshold percentage of its maximum file size.
This notification is generated only at the time of the
transition from not-exceeding to exceeding."
::= { acctngNotifyPrefix 1 }
acctngFileFull NOTIFICATION-TYPE
OBJECTS { acctngFileName,
acctngFileMaximumSize,
acctngFileNameSuffix }
STATUS current
DESCRIPTION
"An indication that the size of the file into which
accounting information is currently being collected has
transistioned to its maximum file size. This notification
is generated (for all values of acctngAgentMode) at the time
of the transition from not-full to full. If acctngAgentMode
has the value 'swapOnCommand', it is also generated
periodically thereafter until such time as collection of
data is no longer inhibited by the file full condition."
::= { acctngNotifyPrefix 2 }okay so the notification tree lives under accountingControlMIB 📡 acctngNotifications is the { accountingControlMIB 2 } branch, and acctngNotifyPrefix hangs off of it at 0 🧚
there are two notifications, and each one lists the objects it carries:
acctngFileNearlyFullgoes off when the file being collected into has gone past the threshold percentage of its max size. it only fires on the transition from not-exceeding to exceeding, so no spam 🙅♀️ it carriesacctngFileName,acctngFileMaximumSize,acctngControlTrapThresholdandacctngFileNameSuffix.acctngFileFullgoes off when the file has hit its max size. it fires for every value ofacctngAgentModeat the moment it goes from not-full to full 💥 and if the mode is'swapOnCommand', it keeps firing periodically after that until collection isn't blocked by the file-full state anymore. it carriesacctngFileName,acctngFileMaximumSizeandacctngFileNameSuffix.
Conformance information
-- conformance information
acctngConformance OBJECT IDENTIFIER ::= { accountingControlMIB 3 }
acctngGroups OBJECT IDENTIFIER ::= { acctngConformance 1 }
acctngCompliances OBJECT IDENTIFIER ::= { acctngConformance 2 }last bit of this chunk, the conformance branch 🎀 acctngConformance sits at { accountingControlMIB 3 }, and it has two sub-branches: acctngGroups at 1 and acctngCompliances at 2. it's basically the org chart for the groups and compliance statements, and that's where we'll pick up next 🫶🌈
acctngCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for switches which implement the
Accounting Control MIB."
MODULE -- this module
MANDATORY-GROUPS { acctngBasicGroup,
acctngNotificationsGroup }
OBJECT acctngSelectionType
SYNTAX BITS { svcIncoming(0), svcOutgoing(1) }
DESCRIPTION "The minimal requirement is collection for SVCs."
OBJECT acctngSelectionRowStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileCommand
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileFormat
SYNTAX INTEGER { ber(2) }
MIN-ACCESS read-only
DESCRIPTION "Only the standard format is required, and write
access is not required."
OBJECT acctngFileMaximumSize
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileCollectMode
SYNTAX BITS { onRelease(0) }
MIN-ACCESS read-only
DESCRIPTION "The minimal requirement is for collection on
connection release."
OBJECT acctngFileInterval
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileCollectFailedAttempts
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acctngFileRowStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { acctngCompliances 1 }
-- units of conformance
acctngBasicGroup OBJECT-GROUP
OBJECTS { acctngSelectionSubtree, acctngSelectionList,
acctngSelectionFile, acctngSelectionType,
acctngSelectionRowStatus, acctngFileName,
acctngFileNameSuffix, acctngFileDescription,
acctngFileCommand, acctngFileMaximumSize,
acctngFileCurrentSize, acctngFileRowStatus,
acctngFileFormat, acctngFileCollectMode,
acctngFileCollectFailedAttempts, acctngFileInterval,
acctngFileMinAge,
acctngAdminStatus, acctngOperStatus,
acctngProtection, acctngAgentMode,
acctngInterfaceEnable,
acctngControlTrapThreshold,
acctngControlTrapEnable
}
STATUS current
DESCRIPTION
"A collection of objects providing control of the basic
collection of accounting data for connection-oriented
networks."
::= { acctngGroups 1 }
acctngNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { acctngFileNearlyFull, acctngFileFull }
STATUS current
DESCRIPTION
"The notifications of events relating to controlling the
collection of accounting data."
::= { acctngGroups 2 }
END5. Acknowledgements 🫶
Huge thank-yous to the IETF's AToM MIB Working Group for their comments, they really helped make this spec slay ✨
6. References 📚
- [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
- [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [5] SNMPv2 Working Group, 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, January 1996.
- [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
- [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
- [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, 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, 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, January 1998.
- [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
- [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, 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, January 1998.
- [16] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
- [17] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8824, December 1987.
- [18] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8825, December 1987.
- [19] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "Accounting Information for ATM Networks", RFC 2512, February 1999.
- [20] Noto, M., Spiegel, E., and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999.
7. Security Considerations 🔐
Okay bestie, this section is seriously important, so read it carefully 💀
The MIB in this memo controls and monitors the collection of accounting data. Lock down access to that control capability so nobody can mess with data collection, possibly with shady fraudulent intent. Examples of that kind of disruption are turning off the collection of data, or making the wrong set of data items get collected. Not cute.
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. 😭
It is recommended that implementers consider the security features provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. 🦋
It is then a customer/user responsibility to make sure that the SNMP entity giving access to an instance of this MIB is properly configured, so access to the objects is only given to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 🔥
8. IANA Considerations 🧚
Before this memo gets published as an RFC, IANA is asked to make a suitable OBJECT IDENTIFIER assignment. 🌸
9. Authors' Addresses 💜
Here's who wrote this, bestie 💖
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134
Phone: +1 408 526 5260
EMail: kzm@cisco.com
Juha Heinanen
Telia Finland, Inc.
Myyrmaentie 2
01600 VANTAA
Finland
Phone +358 303 944 808
EMail: jh@telia.fi
Wedge Greene
MCI Telecommunications Corporation
901 International Parkway
Richardson, Texas 75081
Phone: 214-498-1232 or 972-729-1232
EMail: wedge.greene@mci.com
Anil Prasad
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134
Phone: 408 525-7209
EMail: aprasad@cisco.com10. Full Copyright Statement ⭐
Copyright (C) The Internet Society (1999). 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. 🎀
📦 where this page comes from
- ietf: rfc2513 1999-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms