RFC 1381
SNMP MIB Extension for X.25 LAPB
RFC 1381: SNMP MIB Extension for X.25 LAPB 🎀
Okay bestie, this one's the MIB spec for LAPB, the link layer of X.25 🦋 Here's the title block so you know who's behind it:
Network Working Group Request for Comments: 1381 Authors: D. Throop (Data General Corporation) and F. Baker (Advanced Computer Communications) 💅 Date: November 1992 Category: IAB standards track protocol 📜 Obsoletes and updates: the title block doesn't list anything it obsoletes or updates ✨
Status of This Memo 🌸
This RFC is an IAB standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬 For the standardization state and status, check the current edition of the "IAB Official Protocol Standards" 🔍 Distribution of this memo is unlimited 🫶
Abstract 🦋
This memo defines a chunk of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets 🌈 Specifically, it covers objects for managing the Link Layer of X.25, which is LAPB 🔥 These objects work together with the objects in the "SNMP MIB Extension for the Packet Layer of X.25" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8] 💜 Put all three together and you can manage a whole X.25 protocol stack, which is so iconic 👑
Table of Contents 📚
1. The Network Management Framework ....................... 2
2. Objects ................................................ 2
2.1 Format of Definitions ................................. 3
3. Overview ............................................... 3
3.1 Informal overview ..................................... 3
3.2 Textual Conventions ................................... 4
3.3 Formal overview ....................................... 4
3.4 Tables ................................................ 5
3.5 Traps ................................................. 6
4. Object Definitions ..................................... 6
5. Appendix: Revision History ............................. 27
July 30, 1992 .......................................... 27
June 12, 1992 .......................................... 27
May 18, 1992 ........................................... 28
April 8, 1992 .......................................... 28
February 1992 .......................................... 28
October 1991 ........................................... 29
June 1991 .............................................. 30
April 1991 ............................................. 30
6. Acknowledgements ....................................... 30
7. References ............................................. 31
8. Security Considerations ................................ 33
9. Authors' Addresses ..................................... 331. The Network Management Framework 🧚
The Internet-standard Network Management Framework has three components 💖 They set the rules for defining objects, the definitions of the objects, and the protocol for manipulating them 🫶
The framework organises objects into an abstract information tree 🌳 The branches name the objects, and the leaves hold the values that get manipulated to do the managing. This tree is called the Management Information Base, or MIB ✨ The concepts behind the tree are in STD 16/RFC 1155 "The Structure of Management Information" or SMI [1]. The SMI defines the trunk of the tree and the types of objects you use for the leaves 🌸 STD 16/RFC 1212, "Towards Concise MIB Definitions" [4], gives a shorter way to describe things, and it keeps all the principles of the SMI intact 🎀
The core MIB definitions for the Internet suite of protocols are in RFC 1156 [2] "Management Information Base for Network Management of TCP/IP-based internets" 💅 STD 17/RFC 1213 [5] defines MIB-II, which is basically MIB-I evolved, with changes based on implementation experience and new operational requirements 🔥
STD 15/RFC 1157 [3] defines the SNMP protocol itself 🦋 It says how to manipulate the objects in a remote MIB 👑
The tree structure of the MIB lets you define new objects for experimentation and evaluation 🧪
2. Objects 💜
Defining an object in the MIB needs an object name and a type 💖 Object names and types are written using the subset of Abstract Syntax Notation One (ASN.1) [6] that the SMI [1] defines 🌈 Objects get named with ASN.1 object identifiers, which are administratively assigned names, to specify object types ✨ The object name plus an optional object instance uniquely identifies one specific instance of an object 🎯 For human convenience, we often use a text string called the OBJECT DESCRIPTOR to refer to objects too 🫶
Objects also have a syntax, which defines the abstract data structure that goes with that object type 🧩 The ASN.1 language [6] gives you the primitives for that 💅 The SMI [1] purposely limits which ASN.1 constructs you can use, to keep things simple and easy to implement 🌸 The encoding of an object type just describes how to represent an object with the ASN.1 encoding rules [7], so it can be used with the SNMP protocol 🦋
2.1. Format of Definitions 🎀
Section 4 has the specification for every object type in this MIB module 🔍 The definitions use the conventions from the SMI [1] as amended by the concise MIB definitions [4] 💖
3. Overview 🌈
3.1. Informal overview ✨
This section explains how the objects below relate to other MIBs 🧩 It's only informational, so you can understand how the pieces fit together 🫶
The objects below are meant to be used together with MIB-II and other MIBs, like the X.25 packet level MIB [9] 💜 A system running a complete X.25 stack over a synchronous line has at least two interfaces in the ifTable defined in MIB-II 🔥 One is for LAPB, and another one is for the packet layer of X.25 💅 There are also objects in the RS-232-like MIB for the physical sync line 🌸
Each software interface names the layer below it that it uses to send and receive packets 🦋 The X.25 MIB object, x25InfoDataLinkId, points to an instance of lapbAdmnIndex for the LAPB interface under that X.25 🎯 The LAPB object lapbOperPortId, defined below, identifies an instance of rs232PortIndex for the Sync line that LAPB uses 💖
For X.25 running over LAPB over Ethernet, lapbAdmnPortId would identify the instance of ifIndex for the Ethernet interface 🌐
Every X.25 subnetwork gets its own entries in the ifTable 🧁 So a system with two X.25 lines would have two ifTable entries for the two X.25 packet layers, plus two more for the two LAPB interfaces 💅 Each X.25 Packet Layer MIB identifies the LAPB MIB instance below it, and each LAPB MIB identifies the Sync line below it 🫶 That system would also have two entries in rs232PortTable and two in rs232SyncPortTable, one for each physical line ✨
The ifTable in MIB-II is device independent, so it doesn't have anything specific to any one type of interface 🧩 The objects below hold the LAPB-specific info for an interface of type LAPB 🌸 Different LAPB interfaces can also be told apart by matching the values of ifIndex with lapbAdmnIndex 🦋
3.2. Textual Conventions 📝
This document introduces two new data types as textual conventions 💜 They make the spec easier to read and easier to compare with other specs when that makes sense 🌈 Introducing them doesn't change the syntax or the semantics of any managed object at all 😌 They're just a side effect of how the document explains things 🎀 Objects defined with one of these get encoded using the rules for the primitive type they're built on 💖 So no changes to the SMI or SNMP are needed for them, because they're only there for readers and writers chasing clear, concise, unambiguous MIB docs 🧠
This MIB introduces these data types:
PositiveInteger
ifIndexType3.3. Formal overview 🔥
Instances of the objects below represent attributes of a LAPB interface 💅 LAPB interfaces are identified by an ifType value in the Internet-standard MIB [5] of:
lapb(16).For these interfaces, the ifSpecific variable in MIB-II [5] has this OBJECT IDENTIFIER value:
lapb OBJECT IDENTIFIER ::= { transmission 16 }The relationship between a LAPB interface and an interface in the Internet-standard MIB [5] is one-to-one 💖 So the value of an ifIndex object instance can be used directly to identify the matching instances of the objects below 🎯
The objects below are defined in the context of ISO 7776 [10] and ISO 8885 [11] 📖 Looking at those documents may help (but isn't essential) with understanding some object names and semantics 🌸 Where it's possible, the object descriptions use ISO 7776 terminology 🦋 For example, a commonly used term calls the peer LAPB the DCE/remote DTE 🧩 That terminology doesn't limit the instrumented LAPB to only working as a DTE 💜 This MIB may be applied to a LAPB configured as either a DCE or a DTE 🌈
Attributes from the Internet-standard MIB [5] that apply to LAPB have not been copied here 🫶 In a few cases, there's some clarification on how to apply those objects to LAPB 🎀
Some objects below include a DEFVAL clause 🧁 It gives reasonable (but not mandatory) default values to use when you create these objects ✨ This doesn't mean the MIB defines any mechanism for creating or deleting LAPB interfaces 🙅 Creating and deleting the objects in this MIB depend on how the implementation creates and deletes LAPB interfaces 🔧 The DEFVAL clause gives reasonable defaults, so the MIB can be extended later with ways to create and delete LAPB interfaces without deprecating these objects just because they lack a DEFVAL clause 🦋
3.4. Tables 🌷
This extension adds four tables to the MIB 💖 They are:
lapbAdmnTable,
lapbOperTable,
lapbFlowTable, and
lapbXidTable.The lapbAdmnTable holds objects for common LAPB parameters, like the T1 retransmission timer or the N2 retransmission counter 🎯 Changing objects in this table doesn't need to affect a running interface 🌸 It gives you access to the values used to initialise an interface 🧩 These values are read-write 💅
The lapbOperTable has objects that show the parameters an interface is actually using 👀 These objects are read only 🔒 The values in use may be different from the lapbAdmnTable values if lapbAdmnTable was changed after the interface was initialised, or if XID negotiation picked different values 🌈
The lapbFlowTable has objects that report how the LAPB interface is performing 📊 These are read-only objects for monitoring operation 💜
The lapbXidTable is not required for systems that don't transmit XID frames 🙅♀️ For systems that do transmit XID frames, this table provides the values for the XID frame fields that aren't already in the lapbAdmnTable 🫶 The objects in this table are read-write ✨
That's part 1 wrapped, bestie 🦋 More parts are coming, so stay tuned 💖
3.5. Traps ✨
okay so since every LAPB interface has an entry in the ifTable, any big change in an interface's state should send a linkUp or linkDown trap 🔔 like a little alarm bell. so if an interface receives or sends a Frame Reject frame, it should send a linkDown trap. and if it comes back up later, it should then send a linkUP trap 🦋
4. Object Definitions 💖
here's the whole MIB module, bestie 🎀 every line is copied exactly as it appears in the original, so the vibe is casual but the details are 100% serious 💅
RFC1381-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter
FROM RFC1155-SMI
transmission
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- LAPB MIB
lapb OBJECT IDENTIFIER ::= { transmission 16 }
PositiveInteger ::= INTEGER (0..2147483647)
IfIndexType ::= INTEGER (1..2147483647)
-- IfIndexType specifies an index object for a table
-- with entries that match entries in the MIB-II ifTable.
-- The value of the index for the table will match the
-- ifIndex entry for same interface in the ifTable.
-- The values of this object range from 1 to ifNumber
-- inclusive.
-- ###########################################################
-- LAPB Admn Table
-- ###########################################################
-- Support of the lapbAdmnTable is mandatory for all
-- agents of systems that implement LAPB.
lapbAdmnTable OBJECT-TYPE
SYNTAX SEQUENCE OF LapbAdmnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains objects that can be
changed to manage a LAPB interface.
Changing one of these parameters may take
effect in the operating LAPB immediately or
may wait until the interface is restarted
depending on the details of the
implementation.
Most of the objects in this read-write table
have corresponding read-only objects in the
lapbOperTable that return the current
operating value.
The operating values may be different from
these configured values if changed by XID
negotiation or if a configured parameter was
changed after the interface was started."
::= { lapb 1 }
lapbAdmnEntry OBJECT-TYPE
SYNTAX LapbAdmnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Configured parameter values for a specific
LAPB."
INDEX { lapbAdmnIndex }
::= { lapbAdmnTable 1 }
LapbAdmnEntry ::= SEQUENCE {
lapbAdmnIndex
IfIndexType,
lapbAdmnStationType
INTEGER,
lapbAdmnControlField
INTEGER,
lapbAdmnTransmitN1FrameSize
PositiveInteger,
lapbAdmnReceiveN1FrameSize
PositiveInteger,
lapbAdmnTransmitKWindowSize
INTEGER,
lapbAdmnReceiveKWindowSize
INTEGER,
lapbAdmnN2RxmitCount
INTEGER,
lapbAdmnT1AckTimer
PositiveInteger,
lapbAdmnT2AckDelayTimer
PositiveInteger,
lapbAdmnT3DisconnectTimer
PositiveInteger,
lapbAdmnT4IdleTimer
PositiveInteger,
lapbAdmnActionInitiate
INTEGER,
lapbAdmnActionRecvDM
INTEGER
}
lapbAdmnIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the LAPB interface."
::= { lapbAdmnEntry 1 }
lapbAdmnStationType OBJECT-TYPE
SYNTAX INTEGER {
dte (1),
dce (2),
dxe (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Identifies the desired station type of this
interface."
REFERENCE "ISO 7776 section 3.1"
DEFVAL { dte }
::= { lapbAdmnEntry 2 }
lapbAdmnControlField OBJECT-TYPE
SYNTAX INTEGER {
modulo8 (1),
modulo128 (2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The desired size of the sequence numbers
used to number frames."
REFERENCE "ISO 8885 Table 3, Name: HDLC Option - 10"
DEFVAL { modulo8 }
::= { lapbAdmnEntry 3 }
lapbAdmnTransmitN1FrameSize OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default maximum N1 frame size desired
in number of bits for a frame transmitted by
this DTE. This excludes flags and 0 bits
inserted for transparency."
REFERENCE "ISO 8885 Table 3,
Name: Information Field length"
DEFVAL { 36000 } -- 4500 * 8; 802.5 Frame size
::= { lapbAdmnEntry 4 }
lapbAdmnReceiveN1FrameSize OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default maximum N1 frame size desired
in number of bits for a frame the DCE/remote
DTE transmits to this DTE. This excludes
flags and 0 bits inserted for transparency."
DEFVAL { 36000 } -- 4500 * 8; 802.5 Frame size
::= { lapbAdmnEntry 5 }
lapbAdmnTransmitKWindowSize OBJECT-TYPE
SYNTAX INTEGER (1..127)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default transmit window size for this
Interface. This is the maximum number of
unacknowledged sequenced PDUs that may be
outstanding from this DTE at any one time."
REFERENCE "ISO 8885 Table 3, Name: Window size"
DEFVAL { 7 }
::= { lapbAdmnEntry 6 }
lapbAdmnReceiveKWindowSize OBJECT-TYPE
SYNTAX INTEGER (1..127)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default receive window size for this
Interface. This is the maximum number of
unacknowledged sequenced PDUs that may be
outstanding from the DCE/remote DTE at any
one time."
REFERENCE "ISO 8885 Table 3, Name: Window size"
DEFVAL { 7 }
::= { lapbAdmnEntry 7 }
lapbAdmnN2RxmitCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default N2 retry counter for this
interface. This specifies the number of
times a PDU will be resent after the T1
timer expires without an acknowledgement for
the PDU."
REFERENCE "ISO 8885 Table 3,
Name: Retransmission Attempts"
DEFVAL { 20 }
::= { lapbAdmnEntry 8 }
lapbAdmnT1AckTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default T1 timer for this interface.
This specifies the maximum time in
Milliseconds to wait for acknowledgment of a
PDU."
REFERENCE "ISO 8885 Table 3, Name:
Acknowledgement timer"
DEFVAL { 3000 }
::= { lapbAdmnEntry 9 }
lapbAdmnT2AckDelayTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default T2 timer for this interface.
This specifies the maximum time in
Milliseconds to wait before sending an
acknowledgment for a sequenced PDU. A value
of zero means there will be no delay in
acknowledgement generation."
REFERENCE "ISO 8885 Table 3,
Name: Reply delay timer"
DEFVAL { 0 }
::= { lapbAdmnEntry 10 }
lapbAdmnT3DisconnectTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T3 timer for this interface. This
specifies the time in Milliseconds to wait
before considering the link disconnected. A
value of zero indicates the link will be
considered disconnected upon completion of
the frame exchange to disconnect the link."
REFERENCE "ISO 7776 section 5.7.1.3"
DEFVAL { 60000 }
::= { lapbAdmnEntry 11 }
lapbAdmnT4IdleTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T4 timer for this interface. This
specifies the maximum time in Milliseconds
to allow without frames being exchanged on
the data link. A value of 2147483647
indicates no idle timer is being kept."
REFERENCE "ISO 7776 section 5.7.1.4"
DEFVAL { 2147483647 }
::= { lapbAdmnEntry 12 }okay so the admin knobs for LAPB get a glow-up here 💅 first up, the two action objects that decide what LAPB does when a link set-up goes sideways 🎀
lapbAdmnActionInitiate OBJECT-TYPE
SYNTAX INTEGER {
sendSABM (1),
sendDISC (2),
sendDM (3),
none (4),
other (5)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This identifies the action LAPB will take
to initiate link set-up."
DEFVAL { sendSABM }
::= { lapbAdmnEntry 13 }
lapbAdmnActionRecvDM OBJECT-TYPE
SYNTAX INTEGER {
sendSABM (1),
sendDISC (2),
other (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This identifies the action LAPB will take
when it receives a DM response."
DEFVAL { sendSABM }
::= { lapbAdmnEntry 14 }Now we're in the operating parameters era ✨ the lapbOperTable is the "what's actually set right now" table, so it's giving live status vibes. Support for it is mandatory for every agent or system that implements LAPB, so no skipping this one bestie 🫶
-- ###########################################################
-- LAPB operating parameters.
-- ###########################################################
-- Support of the lapbOperTable is mandatory for all
-- agents of systems that implement LAPB.
lapbOperTable OBJECT-TYPE
SYNTAX SEQUENCE OF LapbOperEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains configuration
information about interface parameters
currently set in the interface. Many of
these objects have corresponding objects in
the lapbAdmnTable."
::= { lapb 2 }
lapbOperEntry OBJECT-TYPE
SYNTAX LapbOperEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Currently set parameter values for a
specific LAPB."
INDEX { lapbOperIndex }
::= { lapbOperTable 1 }
LapbOperEntry ::= SEQUENCE {
lapbOperIndex
IfIndexType,
lapbOperStationType
INTEGER,
lapbOperControlField
INTEGER,
lapbOperTransmitN1FrameSize
PositiveInteger,
lapbOperReceiveN1FrameSize
PositiveInteger,
lapbOperTransmitKWindowSize
INTEGER,
lapbOperReceiveKWindowSize
INTEGER,
lapbOperN2RxmitCount
INTEGER,
lapbOperT1AckTimer
PositiveInteger,
lapbOperT2AckDelayTimer
PositiveInteger,
lapbOperT3DisconnectTimer
PositiveInteger,
lapbOperT4IdleTimer
PositiveInteger,
lapbOperPortId
OBJECT IDENTIFIER,
lapbOperProtocolVersionId
OBJECT IDENTIFIER
}
lapbOperIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the LAPB interface."
::= { lapbOperEntry 1 }
lapbOperStationType OBJECT-TYPE
SYNTAX INTEGER {
dte (1),
dce (2),
dxe (3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Identifies the current operating station
type of this interface. A value of dxe (3)
indicates XID negotiation has not yet taken
place."
REFERENCE "ISO 7776 section 3.1"
::= { lapbOperEntry 2 }
lapbOperControlField OBJECT-TYPE
SYNTAX INTEGER {
modulo8 (1),
modulo128 (2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current operating size of the sequence
numbers used to number frames."
REFERENCE "ISO 7776 section 3.3"
::= { lapbOperEntry 3 }
lapbOperTransmitN1FrameSize OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current operating N1 frame size used
for the maximum number of bits in a frame
this DTE can transmit. This excludes flags
and 0 bits inserted for transparency."
REFERENCE "ISO 7776 section 5.7.3"
::= { lapbOperEntry 4 }
lapbOperReceiveN1FrameSize OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
-- See lapbOperTransmitN1FrameSize above
DESCRIPTION
"The current operating N1 frame size used
for the maximum number of bits in a frame
the DCE/remote DTE can transmit. This
excludes flags and 0 bits inserted for
transparency."
::= { lapbOperEntry 5 }
lapbOperTransmitKWindowSize OBJECT-TYPE
SYNTAX INTEGER (1..127)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current PDU window size this Interface
uses to transmit. This is the maximum
number of unacknowledged sequenced PDUs that
may be outstanding from this DTE at any one
time."
REFERENCE "ISO 7776 section 5.7.4"
::= { lapbOperEntry 6 }
lapbOperReceiveKWindowSize OBJECT-TYPE
SYNTAX INTEGER (1..127)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current receive PDU window size for
this Interface. This is the maximum number
of unacknowledged sequenced PDUs that may be
outstanding from the DCE/remote DTE at any
one time."
REFERENCE "ISO 7776 section 5.7.4"
::= { lapbOperEntry 7 }
lapbOperN2RxmitCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current N2 retry counter used for this
interface. This specifies the number of
times a PDU will be resent after the T1
timer expires without an acknowledgement for
the PDU."
REFERENCE "ISO 7776 section 5.7.2"
::= { lapbOperEntry 8 }
lapbOperT1AckTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current T1 timer for this interface.
This specifies the maximum time in
Milliseconds to wait for acknowledgment of a
PDU."
REFERENCE "ISO 7776 section 5.7.1.1"
::= { lapbOperEntry 9 }
lapbOperT2AckDelayTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current T2 timer for this interface.
This specifies the maximum time in
Milliseconds to wait before sending an
acknowledgment for a sequenced PDU. A value
of zero means there will be no delay in
acknowledgement generation."
REFERENCE "ISO 7776 section 5.7.1.2"
::= { lapbOperEntry 10 }
lapbOperT3DisconnectTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current T3 timer for this interface.
This specifies the time in Milliseconds to
wait before considering the link
disconnected. A value of zero indicates the
link will be considered disconnected upon
completion of the frame exchange to
disconnect the link."
REFERENCE "ISO 7776 section 5.7.1.3"
::= { lapbOperEntry 11 }
lapbOperT4IdleTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The current T4 timer for this interface.
This specifies the maximum time in
Milliseconds to allow without frames being
exchanged on the data link. A value of
2147483647 indicates no idle timer is being
kept."
REFERENCE "ISO 7776 section 5.7.1.4"
::= { lapbOperEntry 12 }
lapbOperPortId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies an instance of the
index object in the first group of objects
in the MIB specific to the physical device
or interface used to send and receive
frames. If an agent does not support any
such objects, it should return nullSpec
OBJECT IDENTIFIER {0 0}."
::= { lapbOperEntry 13 }
lapbOperProtocolVersionId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the version of the
lapb protocol implemented by this
interface."
::= { lapbOperEntry 14 }the T-timers are the clock-watchers of this whole table, so keep an eye on the millisecond values 👀⏱️
And last but not least, the LAPB Flow Table opens up right here 🦋 Same deal as the operating table: support is mandatory for every agent or system that implements LAPB, so it's a must-have 🌸
-- ###########################################################
-- LAPB Flow Table
-- ###########################################################
-- Support of the lapbFlowTable is mandatory for all
-- agents of systems that implement LAPB.Okay bestie, the LAPB flow table is where the box keeps receipts on traffic flow 💅 Here's the table and its entry, exactly as the spec has them 🦋
lapbFlowTable OBJECT-TYPE
SYNTAX SEQUENCE OF LapbFlowEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table defines the objects recorded by
LAPB to provide information about the
traffic flow through the interface."
::= { lapb 3 }
lapbFlowEntry OBJECT-TYPE
SYNTAX LapbFlowEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The information regarding the effects of
flow controls in LAPB."
INDEX { lapbFlowIfIndex }
::= { lapbFlowTable 1 }
LapbFlowEntry ::= SEQUENCE {
lapbFlowIfIndex
IfIndexType,
lapbFlowStateChanges
Counter,
lapbFlowChangeReason
INTEGER,
lapbFlowCurrentMode
INTEGER,
lapbFlowBusyDefers
Counter,
lapbFlowRejOutPkts
Counter,
lapbFlowRejInPkts
Counter,
lapbFlowT1Timeouts
Counter,
lapbFlowFrmrSent
OCTET STRING,
lapbFlowFrmrReceived
OCTET STRING,
lapbFlowXidReceived
OCTET STRING
}The entry is indexed by lapbFlowIfIndex, which points back at the LAPB interface through its ifIndex. Each column below is a read-only object 🌸 ✨
lapbFlowIfIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the LAPB Interface."
::= { lapbFlowEntry 1 }
lapbFlowStateChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of LAPB State Changes, including
resets."
::= { lapbFlowEntry 2 }
lapbFlowChangeReason OBJECT-TYPE
SYNTAX INTEGER {
notStarted (1), -- Initial state
abmEntered (2), -- SABM or UA
abmeEntered (3), -- SABME or UA
abmReset (4), -- SABM in ABM
abmeReset (5), -- SABME in ABME
dmReceived (6), -- DM Response
dmSent (7), -- DM sent
discReceived (8), -- DISC Response
discSent (9), -- DISC Sent
frmrReceived (10), -- FRMR Received
frmrSent (11), -- FRMR Sent
n2Timeout (12), -- N2 Timer Expired
other (13)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The reason for the most recent incrementing
of lapbFlowStateChanges. A DM or DISC frame
generated to initiate link set-up does not
alter this object. When the MIB-II object
ifOperStatus does not have a value of
testing, there exists a correlation between
this object and ifOperStatus. IfOperStatus
will have a value of up when this object
contains: abmEntered, abmeEntered,
abmReset, or abmeReset. IfOperStatus will
have a value of down when this object has a
value of notStarted, or dmReceived through
n2Timeout. There is no correlation when
this object has the value other."
::= { lapbFlowEntry 3 }Okay the lapbFlowChangeReason one is a whole vibe 🔥 It's the reason for the latest bump in lapbFlowStateChanges, and it even tells you how it lines up with ifOperStatus from MIB-II 👑
lapbFlowCurrentMode OBJECT-TYPE
SYNTAX INTEGER {
disconnected (1),
-- initial state or DISC received
linkSetup (2),
-- SABM sent
frameReject (3),
-- Invalid frame received and
-- FRMR sent
disconnectRequest (4),
-- DISC sent
informationTransfer (5),
-- normal information transfer state
-- SABM(E) sent and UA received, or
-- SABM(E) received and UA sent
rejFrameSent (6),
-- invalid NS received and REJ sent
waitingAcknowledgement (7),
-- T1 expired and RR sent
stationBusy (8),
-- RNR sent
remoteStationBusy (9),
-- RNR received
bothStationsBusy (10),
-- RNR received and RNR sent
waitingAckStationBusy (11),
-- T1 expired, RNR sent
waitingAckRemoteBusy (12),
-- T1 expired, RNR received
waitingAckBothBusy (13),
-- T1 expired, RNR sent,
-- and RNR received
rejFrameSentRemoteBusy (14),
-- REJ sent and RNR received
xidFrameSent (15),
-- XID frame sent
error (16),
-- An error state other than
-- a one defined above
other (17)
-- A state not listed above
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current condition of the conversation."
::= { lapbFlowEntry 4 }
lapbFlowBusyDefers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times this device was unable
to transmit a frame due to a perceived
remote busy condition. Busy conditions can
result from the receipt of an RNR from the
remote device, the lack of valid sequence
number space (window saturation), or other
conditions."
::= { lapbFlowEntry 5 }
lapbFlowRejOutPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of REJ or SREJ frames sent by
this station."
::= { lapbFlowEntry 6 }
lapbFlowRejInPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of REJ or SREJ frames received
by this station."
::= { lapbFlowEntry 7 }
lapbFlowT1Timeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times a re-transmission was
effected by the T1 Timer expiring."
::= { lapbFlowEntry 8 }
lapbFlowFrmrSent OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..7))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Information Field of the FRMR most
recently sent. If no FRMR has been sent
(the normal case) or the information isn't
available, this will be an OCTET STRING of
zero length."
REFERENCE "ISO 7776 Section 4.3.9, tables 7 and 8"
::= { lapbFlowEntry 9 }
lapbFlowFrmrReceived OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..7))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Information Field of the FRMR most
recently received. If no FRMR has been
received (the normal case) or the
information isn't available, this will be an
OCTET STRING of zero length."
REFERENCE "ISO 7776 Section 4.3.9, tables 7 and 8"
::= { lapbFlowEntry 10 }
lapbFlowXidReceived OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..8206))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Information Field of the XID frame most
recently received. If no XID frame has been
received, this will be an OCTET STRING of
zero length."
REFERENCE "ISO 8885"
::= { lapbFlowEntry 11 }Now the lapbFlowCurrentMode enum is the full mood board of the conversation 🌈 It runs from disconnected all the way to other, and it's giving detailed state machine energy 🧚
Next up is the XID table 🎀 The comments below are the actual rules for who needs it, so read them closely, periodt 💜
-- ###########################################################
-- LAPB XID Table
-- ###########################################################
-- Support for the lapbXidTable is mandatory for all agents
-- of systems that have a LAPB implementation using XID
-- negotiation. Agents of systems without XID negotiation
-- support should not implement this table.
lapbXidTable OBJECT-TYPE
SYNTAX SEQUENCE OF LapbXidEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table defines values to use for XID
negotiation that are not found in the
lapbAdmnTable. This table is optional for
implementations that don't support XID and
mandatory for implementations that do
initiate XID negotiation."
::= { lapb 4 }
lapbXidEntry OBJECT-TYPE
SYNTAX LapbXidEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"XId negotiation parameter values for a
specific LAPB."
INDEX { lapbXidIndex }
::= { lapbXidTable 1 }Quick vibe check: the XID table is basically the spare parameter drawer for XID negotiation, the stuff that isn't already in lapbAdmnTable 🦋 Whether you need it depends on whether your box does XID negotiation at all 🫶
Still more to come, so keep your eyes peeled 👀✨
4. Object Definitions ✨
okay so this is where the XID table really comes together 💅 each lapbXidEntry row has seven columns, and they're all about the XID exchange parameters. Every one of them is read-write and mandatory, and most default to a zero-length string (''h) so nothing is set until somebody sets it 🫶
LapbXidEntry ::= SEQUENCE {
lapbXidIndex
IfIndexType,
lapbXidAdRIdentifier
OCTET STRING,
lapbXidAdRAddress
OCTET STRING,
lapbXidParameterUniqueIdentifier
OCTET STRING,
lapbXidGroupAddress
OCTET STRING,
lapbXidPortNumber
OCTET STRING,
lapbXidUserDataSubfield
OCTET STRING
}
lapbXidIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the LAPB interface."
::= { lapbXidEntry 1 }
lapbXidAdRIdentifier OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the Address Resolution
Identifier. A zero length string indicates
no Identifier value has been assigned."
REFERENCE "ISO 8885 Table 2, Name: Identifier"
DEFVAL { ''h }
::= { lapbXidEntry 2 }
lapbXidAdRAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the Address Resolution
Address. A zero length string indicates no
Address value has been assigned."
REFERENCE "ISO 8885 Table 2, Name: Address"
DEFVAL { ''h }
::= { lapbXidEntry 3 }
lapbXidParameterUniqueIdentifier OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the parameter unique
Identifier. A zero length string indicates
no Unique identifier value has been
assigned."
REFERENCE "ISO 8885 Table 3, Name: Identifier"
DEFVAL { ''h }
::= { lapbXidEntry 4 }
lapbXidGroupAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the parameter Group address.
A zero length string indicates no Group
address value has been assigned."
REFERENCE "ISO 8885 Table 3, Name: Group address"
DEFVAL { ''h }
::= { lapbXidEntry 5 }
lapbXidPortNumber OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The port number assigned for this link. A
zero length string indicates no local port
number identifier has been assigned."
REFERENCE "ISO 8885 Table 3, Name: Port number"
DEFVAL { ''h }
::= { lapbXidEntry 6 }
lapbXidUserDataSubfield OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..8206))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A user data subfield, if any, to be
transmitted in an XID frame. A zero length
frame indicates no user data subfield has
been assigned. The octet string should
include both the User data identifier and
User data field as shown in Figures 1 and
4."
REFERENCE "ISO 8885 section 4.3"
DEFVAL { ''h }
::= { lapbXidEntry 7 }
-- ###########################################################
-- LAPB protocol versions
-- ###########################################################
lapbProtocolVersion OBJECT IDENTIFIER
::= { lapb 5 }
lapbProtocolIso7776v1986 OBJECT IDENTIFIER
::= { lapbProtocolVersion 1 }
lapbProtocolCcittV1980 OBJECT IDENTIFIER
::= { lapbProtocolVersion 2 }
lapbProtocolCcittV1984 OBJECT IDENTIFIER
::= { lapbProtocolVersion 3 }
-- The following describes some of the MIB-II interface
-- objects and their relationship with the objects in this
-- MIB extension.
-- ifDescr: describes the interface. It should include
-- identification information for the physical line and a
-- description of the network. For connections to PDNs,
-- it should name the PDN.
-- ifMtu: the maximum number of octets an upper layer can
-- pass to this interface as a single frame.
-- ifSpeed:
-- ifAdminStatus:
-- ifOperStatus:
-- ifLastChange: the last time the state of the interface
-- changed. A reset is considered an instantaneous change to
-- the ndm state and back to abm or abme. This will be the
-- last time that lapbFlowChangeReason and lapbFlowChanges
-- changed.
-- ifInOctets: contains the number of octets
-- received from the peer LAPB including FCS.
-- ifInUcastPkts: contains the number of I-frames delivered
-- by this interface to a higher layer interface.
-- ifInDiscards: contains the number of received
-- frames discarded because of internal conditions
-- (such as lack of buffering).
-- ifInErrors: contains the number of Invalid frames received.
-- This does not have any relationship with the number REJ,
-- or RNR frames sent or received.
-- ifInUnknownProtos: contains the number of frames
-- that were correct but were dropped because they
-- were inappropriate for the current state. This
-- includes an invalid Poll bit, an unknown address,
-- or other condition such as an RNR when connection
-- not established. This also includes the number of
-- DISC or other frames that were ignored because the
-- link was not established and this interface was not
-- configured to perform link setup on that type frame.
-- ifOutOctets: number of octets sent to peer including
-- FCS octets.
-- ifOutUcastPkts: number of I-frames received from
-- a higher layer for transmission to peer.
-- ifOutDiscards: number of frames to be sent that were
-- dropped due to internal conditions such as buffering etc.
-- ifOutErrors: number of transmissions that failed
-- due to errors or were considered invalid by the receiver.
-- This does not have any relationship with the number REJ,
-- or RNR frames sent or received.
-- ifOutQLen: number of frames waiting to be transmitted.
-- This MIB does not provide any support for:
-- Multilink procedure (MLP) in ISO 7776 section 6
-- LLC Pbit timer
-- LLC REJ timer
-- LLC Busy State Timer 7.8.1.4
-- ###########################################################
ENDQuick heads-up, bestie: the MIB-II block above is just a list of comments, but it's the bit that tells you how ifTable and this MIB play together 🦋 and the last comment block is the list of things this MIB doesn't cover. Don't skip it 💀
5. Appendix: Revision History 🌸
Okay, the revision history is basically the glow-up diary of this doc 📖✨ Let's go newest to oldest... wait, no, let's go oldest to newest so the story makes sense 💖
April 8, 1992
The April 8, 1992 revision of this document (Editor's Internal Reference 2.4) incorporated the following changes:
- All reference comments in the MIB were moved to the REFERENCE field of the OBJECT-TYPE macro.
- A type of PositiveInteger was introduced and used for common integer values including all timers. This effectively made the maximum value for timers 2147483646 milliseconds. The type of the frame size was changed to positiveInteger.
- The reference to ISO 7776 has been broadened to say the MIB descriptions use the terminology of ISO 7776.
- A comment was added to the overview section discussing creation and deletion of tables.
- The objects in the lapbParmTable and lapbDefTable were redistributed to create a lapbOperTable, a lapbAdmnTable, and a lapbXidTable. The lapbParmTable and lapbDefTable were deleted. Objects were included in the Admn table for t3 and t4.
- An object identifier was added to identify the protocol version.
- A DEFVAL clause was added for all writable objects.
- Some more overview text was included.
May 18, 1992
The May 18, 1992 revision of this document (Editor's Internal Reference 2.8) incorporated the following changes:
- The states of lapbFlowCurrentMode were redefined.
- The default value for lapbAdmnControlField was changed from
module8tomodulo8.
June 12, 1992
The June 12, 1992 revision of this document (Editor's Internal Reference 2.9) incorporated some clarifications and updated the status.
- The range on PositiveInteger was changed to start at 0 rather than 1.
- The syntax of lapbXidIndex was changed to PositiveInteger.
- A value of dxe was added to lapbOperStationType.
- The range of lapbAdmnN2RxmitCount was changed to (0..65535).
- The definition of ifInOctets, ifInUcastPkts, ifInErrors, ifInUnknownProtos, ifOutOctets, and
ifoutUcastPktswas clarified.
July 30, 1992
The July revision of this document (Editor's Internal Reference 2.10) incorporated the comments of the SNMP directorate. Big moment, the SNMP directorate got involved! 🌈
- The ifIndexType textual convention was added and used as the type for all index objects.
- The enumeration xidDetection of the lapbAdmnStationType was changed to dxe to be consistent with other similar enumerations.
- Conformance statements were added before every table as ASN.1 comments.
February 1992 ✨
The February 1992 revision (Editor's Internal Reference 1.17) was a big glow-up. Here's everything that changed, bestie 💅
- The name changed from HDLC to LAPB 🎀. Other flavors of HDLC, like LAPD, SDLC, and raw HDLC framing, are different enough that this MIB wouldn't manage them properly, so the name had to level up.
- The Historical Perspective section at the start got swapped for a more concise Network Management Framework section 🦋.
lapbParmKWindowSizebecamelapbParmTransmitKWindowSize, andlapbParmReceiveKWindowSizewas added 🌸. The reason: section 5.7.4 of ISO 7776 and Table 3 of ISO 8885 allow different transmit and receive window sizes, so the MIB needed to match.lapbParmN1FrameSizebecamelapbParmTransmitN1FrameSize, andlapbParmReceiveN1FrameSizewas added 🍓. Same deal: section 5.7.3 of ISO 7776 and Table 3 of ISO 8886 allow different transmit and receive maximum frame sizes.lapbParmPortIndexgot deleted, and the description oflapbParmPortIdwas rewritten 🧚. NowlapbParmPortIdidentifies an instance of the index object for the MIB of the physical device or interface below LAPB.- The timers are now measured in Milliseconds, to match ISO 8885 (see table 3) ⏱️.
lapbParamT2AckDelayTimerandlapbParamT3DisconnectTimerboth accept 0 to show the timer isn't being used 💜.lapbParamT4IdleTimergot a value that means the timer is not in use 🙈.lapbFlowXidReceivedjoined the flow table ✨.- The
lapbDefTablewas added 👑. - Every INTEGER and OCTET STRING that was missing ranges and sizes got them now 🌈. Finally!!
October 1991 💀
The October 1991 revision mostly switched the name from LAPB to HDLC 🦋, so the objects would suit a wider range of uses. It also made a bunch of smaller tweaks to line things up with established conventions 💅.
- The enumerated values of
hdlcParmStationTypewere renumbered from 0 and 1 to 1 and 2 🔢. hdlcFlowBusyDeferwas renamedhdlcFlowBusyDefers🎀.hdlcFlowRejSentwas renamedhdlcFlowRejOutPkts🌸.hdlcFlowRejReceivedwas renamedhdlcFlowRejInPkts🫶.
June 1991 🌷
The June revision pulled in a lot of the E-mail discussion on the first draft 📬. The big move was replacing the lapbStatTable (and all of its contents) with the lapbFlowTable 🦋.
April 1991 🌱
The April 24 version was the very first release 🍼. At that point, the document was basically a pile of objects pieced together from various vendor MIBs, plus a quick skim of ISO 7776 [10] 📚. On first read, it seemed to instrument too many LAPB normal functions and too few exceptional conditions 😬. The lapbStatTable was also way too long and needed a total redo 💀.
6. Acknowledgements 💖
This document was produced by the x25mib working group 🫶:
Fred Baker, ACC
Art Berggreen, ACC
Frank Bieser
Gary Bjerke, Tandem
Bill Bowman, HP
Christopher Bucci, Datability
Charles Carvalho, ACC
Jeff Case, Snmp Research
Angela Chen, HP
Carson Cheung, BNR
Tom Daniel, Spider Systems
Chuck Davin, MIT
Billy Durham, Honeywell
Richard Fox, Synoptics
Doug Geller, Data General
Herve Goguely, LIR Corp
Andy Goldthorpe, british-telecom
Walter D. Guilarte
David Gurevich
Steve Huston, Process Software Corporation
Jon Infante, ICL
Frank Kastenholz, Clearpoint
Zbigniew Kielczewski, Eicon
Cheryl Krupezak, Georgia Tech
Mats Lindstrom, Diab Data AB
Andrew Malis, BBN
Evan McGinnis, 3Com
Gary (G.P.)Mussar, BNR
Chandy Nilakantan, 3Com
Randy Pafford, Data General
Ragnar Paulson, The Software Group Limited
Dave Perkins, Synoptics
Walter Pinkarschewsky, DEC
Karen Quidley, Data General
Chris Ranch, Novell
Paul S. Rarey, DHL Systems Inc.
Jim Roche, Newbridge Research
Philippe Roger, LIR Corp.
Timon Sloane
Mike Shand, DEC
Brad Steina, Microcom
Bob Stewart, Xyplex
Tom Sullivan, Data General
Rodney Thayer, Sable Technology Corporation
Mark Therieau, Microcom
Jane Thorn, Data General
Dean Throop, Data General
Maurice Turcotte, Racal Datacom
Mike Zendels, Data GeneralBig thank-you to these people too, whose comments were acknowledged 🥹:
Keith McCloghrie7. References 📚
[1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
[2] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990.
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
[4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.
[5] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Performance Systems International, March 1991.
[6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.
[7] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987.
[8] Stewart, B., Editor, "Definitions of Managed Objects for RS-232-like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992.
[9] Throop, D., Editor, "SNMP MIB extension for the Packet Layer of X.25", RFC 1382, Data General Corporation, November 1992.
[10] "Information processing systems - Data communication - High-level data link control procedure - Description of the X.25 LAPB-compatible DTE data link procedures", International Organization for Standardization, International Standard 7776, December 1986.
[11] "Information technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - General purpose XID frame information field contents and format", International Organization for Standardization, International Standard 8885.
8. Security Considerations 😱
Security issues are not discussed in this memo. 😱 Not one word, bestie. That's the whole plot twist, so keep your eyes wide open 👀.
9. Authors' Addresses 📮
Dean D. Throop
Data General Corporation
62 Alexander Dr.
Research Triangle Park, NC 27709
Phone: (919)248-8421
EMail: throop@dg-rtp.dg.com
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, CA 93101
Phone: (805) 685-4455
EMail: fbaker@acc.comWhile the working group has completed discussion of this document, comments are still welcome 🌸. Please send comments to the x25mib working group at: x25mib@dg-rtp.dg.com 💌
That's the whole RFC, bestie!! 🌈✨
📦 where this page comes from
- ietf: rfc1381 1992-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms