RFC 3395
Remote Network Monitoring MIB Protocol Identifier Reference Extensions
RFC 3395: Remote Network Monitoring MIB Protocol Identifier Reference Extensions 🦋
📋 The title block (the tea ☕): - RFC number: 3395 - Stream: Network Working Group - Authors: A. Bierman and C. Bucci (both at Cisco Systems, Inc.), R. Dietz (Hifn, Inc.), and A. Warth (no affiliation is listed in this header) - Category: Standards Track - Date: September 2002 - Updates: RFC 2895 (the RMON Protocol Identifier Reference). It doesn't obsolete anything, and it explicitly says it won't obsolete any part of RFC 2895 💖
Status of This Memo ✨
okay so this doc is a standards track protocol spec for the internet community, and it's literally asking for discussion and suggestions to make it better 🫶 If you want to know where this stands in terms of standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). And yes, you're allowed to distribute it as much as you want. Distribution is unlimited 🌸
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 💅
Abstract 🎀
this memo adds extensions to the Protocol Identifier Reference doc so you can identify application verb info. It updates that doc but does not obsolete any of it. The main point is describing the algorithms you need to identify protocol operations (verbs) inside the protocol encapsulations that get managed through MIBs like the Remote Network Monitoring MIB Version 2, RFC 2021. Bestie, this is the core of the whole thing 🔥
Table of Contents
Here's the TOC exactly as the original has it, so you can find your way around 🗺️
1. The SNMP Network Management Framework ..........................2
2. Overview .......................................................3
2.1 Protocol Identifier Framework .................................3
2.2 Protocol Identifier Extensions for Application Verbs ..........4
2.3 Terms .........................................................4
2.4 Relationship to the RMON-2 MIB ................................5
2.5 Relationship to the RMON MIB Protocol Identifier Reference.....5
3. Definitions ....................................................5
3.1 Verb Identifier Macro Format ..................................5
3.1.1 Lexical Conventions .........................................6
3.1.2 Extended Grammar for the PI Language ........................6
3.1.3 Mapping of the Parent Protocol Name .........................7
3.1.4 Mapping of the DESCRIPTION Clause ...........................7
3.1.5 Mapping of the REFERENCE Clause .............................7
3.1.6 Mapping of the Verb List Clause .............................7
3.1.6.1 Mapping of the Verb Name Field ............................8
3.1.6.2 Mapping of the Verb Enum Field ............................8
3.2 Protocol Directory Requirements ...............................8
3.2.1 Mapping of the Verb Layer Numbering Space ...................8
3.2.2 Mapping of the ProtocolDirID object .........................9
3.2.3 Mapping of the ProtocolDirParameters object .................9
3.2.4 Mapping of the ProtocolDirLocalIndex object ................10
3.2.5 Mapping of the protocolDirDescr object .....................10
3.2.6 Mapping of the protocolDirType object ......................10
3.2.7 Mapping of the protocolDirAddressMapConfig object ..........10
3.2.8 Mapping of the protocolDirHostConfig object ................10
3.2.9 Mapping of the protocolDirMatrixConfig object ..............10
3.2.10 Mapping of the protocolDirOwner object ....................11
3.2.11 Mapping of the protocolDirStatus object ...................11
4. Implementation Considerations .................................11
4.1 Stateful Protocol Decoding ...................................11
4.2 Packet Capture ...............................................11
4.3 RMON-2 MIB Collections .......................................12
5. Intellectual Property .........................................12
6. Acknowledgements ..............................................13
7. Normative References ..........................................13
8. Informative References ........................................14
9. IANA Considerations ...........................................15
10. Security Considerations ......................................15
Appendix A: Usage Examples .......................................16
A.1 FTP Example ..................................................16
A.2 POP3 Example .................................................17
A.3 SNMP Example .................................................18
A.4 HTTP Example .................................................18
A.5 SMTP Example .................................................19
Authors' Addresses ...............................................20
Full Copyright Statement..........................................211. The SNMP Network Management Framework ✨
so the SNMP Management Framework is currently made up of five major components 🧚
- An overall architecture, described in RFC 2571 [RFC2571].
- Mechanisms for describing and naming objects and events for management purposes. The first version of this Structure of Management Information (SMI) is called SMIv1. It's described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
- Message protocols for moving management information around. The first version of the SNMP message protocol is called SNMPv1, described in STD 15, RFC 1157 [RFC1157]. A second version, SNMPv2c, is not an Internet standards track protocol. It's described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3, and it's described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
- Protocol operations for accessing management information. The first set of operations and their PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of operations and PDU formats is described in RFC 1905 [RFC1905].
- A set of fundamental applications is described in RFC 2573 [RFC2573]. The view-based access control mechanism is described in RFC 2575 [RFC2575].
if you want a more detailed intro to the current SNMP Management Framework, RFC 2570 [RFC2570] has you covered 💜
Managed objects get accessed through a virtual information store called the Management Information Base, or MIB. Objects in the MIB are defined using the mechanisms in the SMI. It's giving organized 💅
🙅♀️ This memo does not specify a MIB module. Don't go looking for one here.
2. Overview 🌈
okay so there's a real need for a standardized way to identify the protocol operations defined for particular application protocols 🫶 Different protocol operations can have really different performance characteristics, and it's super useful to collect certain metrics at that level of granularity. This memo defines extensions to the existing protocol identifier structure [RFC2895]. It's meant to update the existing protocol identifier encoding rules, not obsolete them 🦋
2.1. Protocol Identifier Framework 🍓
the RMON Protocol Identifier (PI) structure [RFC2895] lets you have a variable number of layer identifiers. Each layer contributes 4 octets to the protocolDirID OCTET STRING, and one octet to the protocolDirParameters OCTET STRING. Those two MIB objects together make up the index in the protocolDirTable [RFC2021]. Together they represent a globally unique identifier for a particular protocol encapsulation. (Or a set of encapsulations, if the wild-card base layer is used.) Iconic, honestly 👑
2.2. Protocol Identifier Extensions for Application Verbs 🔥
the existing RMON protocol identifier architecture requires that an application verb be represented by one extra protocol layer, tacked onto the protocol identifier for the parent application. Some application verbs are defined as strings that can be longer than 4 octets, so each string needs an integer mapping. This memo specifies how the verb layer is structured, and it also defines a verb identifier macro syntax for specifying the verb name-to-integer mappings. Main character energy 💅
2.3. Terms 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Read those carefully, they're the whole vibe of the spec 🎀
This document uses some terms that are defined in the RMON Protocol Identifier Reference document [RFC2895], plus some new terms that need introducing here. Here's the lineup 🧚
Application Verb Also called simply "verb." It refers to one of potentially many protocol operations defined by a particular application protocol.
Note that an application verb is not the same thing as an application protocol sub-command or opcode inside a packet that carries a PDU for the application. An application verb is a transaction type, and it can involve several PDU types within the application protocol (for example, SNMP Get-PDU and Response-PDU). In some applications, a verb can cover protocol operations for more than one protocol entry in the protocol directory (for example, ftp and ftp-data). Not a sub-command, bestie, it's a whole transaction 🙈
Connect Verb The special application verb tied to connection or session setup and teardown traffic, which isn't attributed to any other verb for the application. This verb gets the enumeration value of zero, and the verb connect(0) is implicitly defined for all application protocols. Every protocol gets this one for free 🌸
Parent Application One of potentially many protocol encapsulations that identify a particular application protocol. This term refers generically to any or all of those encapsulations for a given set of application verbs. 🍓
Verb Layer The part of the protocol identifier octet string that identifies the application verb. ✨
Verb Set The group of verbs enumerated for a particular application protocol. The list of verb strings inside a particular verb-identifier macro invocation is also called the verb set for that verb identifier. 💖
2.4. Relationship to the RMON-2 MIB 🦋
The RMON-2 MIB [RFC2021] contains the protocolDirTable MIB objects. Those are used to identify all the protocol encapsulations that a particular RMON agent can monitor. 👀
This memo describes how an implementation maps these MIB objects for entries that identify application verbs. It does not define any new MIB objects for identifying application verbs. The stuff in this doc isn't limited to the RMON-2 MIB, either. Other specs that use the RMON-2 protocolDirTable and/or the protocol identifier macros it represents can also use the application verb macro definitions in this document. Sharing is caring 🫶
2.5. Relationship to the RMON MIB Protocol Identifier Reference 🔥
The RMON MIB Protocol Identifier Reference [RFC2895] defines the RMON Protocol Identifier Macro Specification Language, and also the encoding rules for the ProtocolDirID and protocolDirParameters OCTET STRINGs. This memo extends the Protocol Identifier Reference to cover identifying application verb information. It does not obsolete any part of the Protocol Identifier Reference document 💅
3.1. Verb Identifier Macro Format ✨
okay so this next bit is an example that introduces the verb-identifier macro 💅 it's macro-ish, not a real macro, and it's how you represent the protocol verbs for a specific parent application 🎀
3.1.1. Lexical Conventions 🌸
the PI language gets exactly one new keyword 🫶:
VERB-IDENTIFIER3.1.2. Extended Grammar for the PI Language 🧚
here's the extended BNF for the grammar, with starting symbol <piFile> 💖 ngl the only thing that changes is <piFile> itself, and that's modified from [RFC2895]. the <piDefinition> syntax isn't copied here because this memo is meant to extend that definition, not replace it 💜
-- a file containing one or more
-- Protocol Identifier (PI) definitions
<piFile> = [ <piDefinition> | <piVerbDefinition> ]...
-- a PI definition
<piVerbDefinition> =
[<wspace>] <parentProtoName> <wspace> "VERB-IDENTIFIER"
<wspace> "DESCRIPTION" <wspace> string
[ <wspace> "REFERENCE" <wspace> string ]
[<wspace>] "::=" [<wspace>]
"{" [<wspace>] <verbList> [<wspace>] "}" [<wspace>]
-- a list of verb identifier string
<verbList> = <verbId> [ [<wspace>] "," [<wspace>] <verbId> ]...
-- a verb identifier string
<verbId> = <verbName> [<wspace>] "(" [<wspace>]
<verbEnum> [<wspace>] ")" [<wspace>]
-- a protocol name
<parentProtoName> = <protoName>
-- a verb name
<verbName> = <lcname>
-- a verb enumeration
<verbEnum> = <posNum>
-- a positive integer
<posNum> = any integer value greater than zero and
less than 16,777,216
-- <piDefinition> syntax is defined in [RFC2895]
-- <protoName> syntax is defined in [RFC2895]
-- <wspace> syntax is defined in [RFC2895]
-- <lcname> syntax is defined in [RFC2895]3.1.3. Mapping of the Parent Protocol Name 👑
so the "parentProtoName" value (aka the "parent protocol name") SHOULD be an ASCII string, 1 to 64 characters 🎀 these names show up in IETF docs, so UTF-8 is not appropriate 🙅 the encoding rules are exactly as specified in section 6.2.4 of [RFC2895] for the mapping of the protocol name field. the value for <parentProtoName> MUST be the value of a protocol identifier defined as specified for <protoName> in section 3.2.4 of [RFC2895]. and the value of <parentProtoName> MUST specify a <protoName> defined in the <piFile> ✨
a protocol identifier macro SHOULD exist in the <piFile> for at least one encapsulation of the parent application protocol if any verb identifier macros referencing that parent application are present in the <piFile> 💅
3.1.4. Mapping of the DESCRIPTION Clause 💖
the DESCRIPTION clause is the text description of the protocol verb set this macro identifies. it SHOULD NOT contain details about items covered by the REFERENCE clause 🙈 and the DESCRIPTION clause MUST be present in all verb-identifier macro declarations 🫶
3.1.5. Mapping of the REFERENCE Clause 🦋
if a publicly available reference document exists for this set of application protocol verbs, it SHOULD be listed here 🌈 typically that'll be a URL, otherwise it's the name and address of the controlling body.
the REFERENCE clause is optional but SHOULD be present if an authoritative reference exists which specifies the application protocol verbs defined in the <verbList> section of this macro 📚
3.1.6. Mapping of the Verb List Clause 🍓
the verb list clause MUST be present 🔥 it's used to identify a list of application verb names and attach a numeric constant to each one. at least one verb MUST be specified, and a maximum of 16,777,215 (2^^24 - 1) verbs MAY be specified. this enumerated list SHOULD be densely numbered (i.e., valued from '1' to 'N', where 'N' is the total number of verbs defined in the macro) 👑
3.1.6.1. Mapping of the Verb Name Field 💅
the <verbName> field is case-sensitive and SHOULD be set to the most appropriate string name for each application verb. if an authoritative document defines a descriptive string, then that string SHOULD be used. if no such string exists, then an appropriate but arbitrary string should be selected for this value 🎀
verb names MUST be unique for a particular parent application 🙌 also, the special 'connect(0)' verb is implicitly defined for each application protocol. it's possible for an explicit definition of this verb (e.g., 'connect(8)' for http) to exist for a protocol, as well as the implicit 'connect(0)' verb 🦋
3.1.6.2. Mapping of the Verb Enum Field 🧚
the <verbEnum> field MUST be unique for all verbs associated with a particular parent application 💜 this field SHOULD contain a value between '1' and '16,777,215' inclusive ✨
3.2. Protocol Directory Requirements 👑
this section defines how the protocolDirTable should be populated for any application verb identified with a verb-identifier macro 🌸
an agent MUST implement all applicable protocolDirTable MIB objects on behalf of each supported application verb 🫶
3.2.1. Mapping of the Verb Layer Numbering Space 🌈
the verb layer is the 4 octets inside the protocolDirID INDEX field that identify a particular application verb 💖 check out the layout:
Figure 1
Verb Layer Format
-----------------
protocolDirID string fragment
---+--------+--------+--------+--------+
| resrvd | |
.. | set to | verb enumeration value |
| zero | (a) (b) (c) |
---+--------+--------+--------+--------+ octet
| 1 | 3 | countthe first octet is reserved for future use and MUST be set to zero 🙈
the next three octets identify the <verbEnum> field used to enumerate the particular application verb represented by the <verbName> field. this is a 24-bit unsigned integer, encoded in network byte order ⭐
the value zero is reserved to identify the special 'connect(0)' verb. this verb enumeration value (i.e., '0' part of 'connect(0)') MUST NOT be redefined in a verb identifier macro verb list 🚫 note that the verb name 'connect' is not reserved and MAY be redefined in a verb list 🎀
3.2.2. Mapping of the ProtocolDirID object 💜
the protocolDirID OCTET STRING value for a particular application verb is represented by the protocolDirID value for the parent application, appended with the verb's layer identifier value 🦋
Figure 2
ProtocolDirID Format for Verbs
------------------------------
protocolDirID string
+--------+--------+--------+--------+
| parent | verb |
| protocolDirID | layer |
| string | value |
+--------+--------+--------+--------+ octet
| length of parent ID | 4 | countthe protocolDirID object is encoded as the protocolDirID value of the parent application, followed by four additional octets representing the verb layer 🌸 the verb layer value is encoded as [0.a.b.c], where 'a' is the high order byte, 'b' is the middle order byte, and 'c' is the low order byte of the <verbEnum> field for the specific application verb value. a valid PI verb enumeration will be encoded in the range "0.0.0.0" to "0.255.255.255", where the special value "0.0.0.0" is reserved for the implicitly defined 'connect(0)' verb 🧚
3.2.3. Mapping of the ProtocolDirParameters object 🫶
the protocolDirParameters OCTET STRING value for a particular application verb is represented by the protocolDirParameters value for the parent application, appended with one octet containing the value zero 💖 although it's not actually used, this field is included to conform to the encoding rules defined in the Protocol Identifiers Reference [RFC2895] 📚
3.2.4. Mapping of the ProtocolDirLocalIndex object ⭐
the agent MUST assign an appropriate protocolDirLocalIndex value for each application verb, according to the encoding rules defined for this object in [RFC2021] and [RFC2895] 👑
3.2.5. Mapping of the protocolDirDescr object 🔥
the agent MUST convey the <verbName> value for a particular application verb in the protocolDirDescr object 💅 this object SHOULD be encoded as the protocolDirDescr value for the parent application, appended with a 'dot' character, followed by the exact text contained in the <verbName> field ✨
3.2.6. Mapping of the protocolDirType object 🦋
the agent MUST set the protocolDirType object for each application verb to the value representing the empty bit set ( {} ) 🌈
3.2.7. Mapping of the protocolDirAddressMapConfig object 🎀
the agent MUST set the protocolDirAddressMapConfig object for each application verb to the value 'notSupported(1)' 🙌
3.2.8. Mapping of the protocolDirHostConfig object 🙈
the agent MUST set the protocolDirHostConfig object for each application verb present in the protocol directory, according to the monitoring capabilities for each verb 🍓 the agent MAY set this object to the same value as configured in the parent application protocolDirHostConfig object 💜 the agent MAY choose to transition this object from the value 'supportedOn(2)' to 'supportedOff(3)' if the parent application protocolDirHostConfig object first transitions from 'supportedOn(2)' to 'supportedOff(3)' 🦋
3.2.9. Mapping of the protocolDirMatrixConfig object 🌸
the agent MUST set the protocolDirMatrixConfig object for each application verb according to the monitoring capabilities for each verb 🫶 the agent MAY set this object to the same value as configured in the parent application protocolDirMatrixConfig object 🧚 the agent MAY choose to transition this object from the value 'supportedOn(2)' to 'supportedOff(3)' if the parent application protocolDirMatrixConfig object first transitions from 'supportedOn(2)' to 'supportedOff(3)' 💅
3.2.10. Mapping of the protocolDirOwner object 💖
this object is encoded exactly the same for application verbs as for other protocolDirTable entries, according to the rules specified in the RMON-2 MIB [RFC2021] 📚
3.2.11. Mapping of the protocolDirStatus object ✨
this object is encoded exactly the same for application verbs as for other protocolDirTable entries, according to the rules specified in RMON-2 MIB [RFC2021] 🎀
4. Implementation Considerations 🎀
this section discusses the implementation implications for agents which support verbs in the protocol directory, and the RMON collections which utilize the protocol directory 🌈
4.1. Stateful Protocol Decoding ✨
Okay bestie, so for RMON-2 at the application and network layers, probes usually don't need to remember much of anything 💅. The probe can typically decide whether to count a packet and its octets just by looking at that packet, without checking or changing any state.
The verb layer is different 😤. For a lot of protocols, the probe has to keep state so it can correctly sort a packet into the right "belonging" bucket for one verb or another. The examples below show what that looks like.
For SNMP over UDP, a Response-PDU answering a Get-PDU looks exactly like a Response-PDU answering a Getnext-PDU, so you can't tell them apart from the packet alone 🙈. The probe needs to remember what was asked, so it can match a Response-PDU from B to A with an earlier request from A to B. Main character memory, iykyk.
For application protocols running over a stream transport like TCP, the info needed to identify an application verb can be spread across several packets 🌊. The probe has to follow the transport-layer flow to be able to parse the application-layer data properly.
4.2. Packet Capture 🎀
For packet capture that uses verb-layer protocol directory filtering, the choice to put a packet in the capture buffer might have to wait until the probe can say for sure which verb it belongs to 🦋. So the probe may need to pre-buffer packets, and decide whether to keep or drop them based on packets that haven't shown up yet. Wild, but that's the vibe.
4.3. RMON-2 MIB Collections 📊
Collections like the protocol distribution or the Application Layer Host Table (alHostTable) need every packet counted only once 💯. That means each packet gets fully classified as one protocol encapsulation, which lands on exactly one leaf entry in the protocol directory. Also, the octet counters tied to protocol classification go up by the whole packet size, not just the octets belonging to one particular encapsulation layer. Accurate counting is everything, bestie.
Some application protocols might let several types of verbs show up in a single packet 👀. When that happens, the agent MUST choose one verb type, and therefore one protocol directory entry, so the packet gets counted properly.
Which verb type the agent picks, if more than one is in the packet, is up to the implementation 🧚. A few options are:
- the first verb type encountered in the packet
- the verb type with the most instances in the packet
- the verb type using the largest number of octets in the packet
- the most 'interesting' verb type in the packet (based on knowledge of that application protocol).
5. Intellectual Property ⚖️
The IETF doesn't take a side on whether any intellectual property or other rights someone claims over the tech in this document are valid, or how far those rights reach, or whether any license for them is available. It also doesn't say it has tried to find any such rights 🤷♀️. You can find the IETF's rules about rights in standards-track and standards-related documents in BCP-11. Copies of rights claims that have been filed for publication, any promises to grant licenses, or the outcome of any attempt to get a general license or permission to use those proprietary rights by implementers or users of this spec can be requested from the IETF Secretariat.
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 📮. Send that info to the IETF Executive Director.
6. Acknowledgements 🌸
This memo is a product of the RMONMIB WG 🫶.
7. Normative References 📚
- [RFC1905] 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.
- [RFC1906] 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.
- [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
- [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
- [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
- [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2895, August 2000.
8. Informative References 🧠
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
9. IANA Considerations 🗂️
Right now there are no application protocol verbs defined that need IANA registration, similar to the 'ianaAssigned' protocol identifiers found in RFC 2895 🙅♀️. It's remotely possible that a future version of this document will include application verb definitions that do need assignment in the 'ianaAssigned' protocol identifier subtree 👀.
10. Security Considerations 🔐
This memo defines the structure of a portion of the Remote Monitoring MIB framework, but it doesn't define any MIB objects or protocol operations 🙌. What it does do is define algorithms for representing application protocol verbs in RMON Protocol Identifiers. It doesn't introduce any new security risks into a managed system.
However, if an MIB collection is designed that uses this type of Protocol Identifier, that collection may expose which verbs in an application protocol are used in a network 😱. Including this extra info may need more thought when it comes to protection. MIB writers should address these considerations.
Appendix A: Usage Examples 🧁
The following examples show how RMON verb identifiers are declared 💖.
A.1. FTP Example 🐚
This example defines verb enumeration values for the File Transfer Protocol, as defined in RFC 959 and updated by RFC 2228 and RFC 2640 📂. Heads up: verb name strings given in the <verbName> field aren't limited to 4 characters. FTP command names are all 4 characters, and the verb name string should match the official command name as closely as possible.
ftp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for FTP is derived from the list
of commands defined for the File Transfer Protocol,
which are identified by case-insensitive strings.
The commands are simply listed in the order found
in the FTP documentation."
REFERENCE
"File Transfer Protocol, RFC 959, Section 4.1;
FTP Security Extensions, RFC 2228, Section 3;
Internationalization of the File Transfer Protocol,
RFC 2640, Section 4.1."
::= {
user(1), -- USER NAME
pass(2), -- PASSWORD
acct(3), -- ACCOUNT
cwd(4), -- CHANGE WORKING DIRECTORY
cdup(5), -- CHANGE TO PARENT DIRECTORY
smnt(6), -- STRUCTURE MOUNT
rein(7), -- REINITIALIZE
quit(8), -- LOGOUT
port(9), -- DATA PORT
pasv(10), -- PASSIVE
type(11), -- REPRESENTATION TYPE
stru(12), -- FILE STRUCTURE
mode(13), -- TRANSFER MODE
retr(14), -- RETRIEVE
stor(15), -- STORE
stou(16), -- STORE UNIQUE
appe(17), -- APPEND (with create)
allo(18), -- ALLOCATE
rest(19), -- RESTART
rnfr(20), -- RENAME FROM
rnto(21), -- RENAME TO
abor(22), -- ABORT
dele(23), -- DELETE
rmd(24), -- REMOVE DIRECTORY
mkd(25), -- MAKE DIRECTORY
pwd(26), -- PRINT WORKING DIRECTORY
list(27), -- LIST
nlst(28), -- NAME LIST
site(29), -- SITE PARAMETERS
syst(30), -- SYSTEM
stat(31), -- STATUS
help(32), -- HELP
noop(33), -- NOOP
auth(34), -- AUTHENTICATION/SECURITY MECHANISM
adat(35), -- AUTHENTICATION/SECURITY DATA
pbsz(36), -- PROTECTION BUFFER SIZE
prot(37), -- DATA CHANNEL PROTECTION LEVEL
ccc(38), -- CLEAR COMMAND CHANNEL
mic(39), -- INTEGRITY PROTECTED COMMAND
conf(40), -- CONFIDENTIALITY PROTECTED COMMAND
enc(41), -- PRIVACY PROTECTED COMMAND
lang(42) -- LANGUAGE
}A.2. POP3 Example 📮
Okay, this one is for POP3 (Post Office Protocol, Version 3) 💌. It's defined in RFC 1939 and updated by RFC 2449, and here's how its verbs get enumerated 💅
pop3 VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for POP3 is derived from the list
of commands defined for the Post Office Protocol,
which are identified by case-insensitive strings.
The commands are simply listed in the order found
in the POP3 command summary."
REFERENCE
"Post Office Protocol, Version 3, RFC 1939, Section 9;
POP3 Extension Mechanism, RFC 2449, Section 5."
::= {
user(1),
pass(2),
quit(3),
stat(4),
list(5),
retr(6),
dele(7),
noop(8),
rset(9),
apop(10),
top(11),
uidl(12),
capa(13)
}A.3. SNMP Example 🧚
This one covers SNMP (Simple Network Management Protocol), as defined in RFC 1905. The verbs come from the PDU transaction types in the SNMPv2 Protocol Operations doc 🌸
snmp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for SNMP is derived from the list
of PDU transaction types in the Protocol Operations
document for SNMPv2. Note that the 'Response'
and 'Report' PDUs are not considered verbs, but are
classified as belonging to the transaction type
associated with the request PDU."
REFERENCE
"Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2),
RFC 1905, Section 3."
::= {
get(1),
get-next(2),
get-bulk(3),
set(4),
inform-request(5),
trap(6)
}A.4. HTTP Example 🌈
This example is for HTTP, version 1.1, as defined in RFC 2616. The verbs are case-sensitive, and HTTP/1.0 methods are a proper subset of the HTTP/1.1 ones. Both versions are still in use, so the list covers both 🙈
http VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for HTTP is derived from the list
of methods defined for the Hypertext Transfer Protocol,
which are identified by case-sensitive strings.
The commands are simply listed in the order found
in the HTTP/1.1 documentation. Methods commonly used
in HTTP/1.0 are a proper subset of those used in HTTP/1.1.
Both versions of the protocol are in current use."
REFERENCE
"Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616,
Section 9; Hypertext Transfer Protocol -- HTTP/1.0, RFC
1945, Section 8."
::= {
options(1),
get(2),
head(3),
post(4),
put(5),
delete(6),
trace(7),
connect(8) -- reserved for future use by HTTP/1.1
}A.5. SMTP Example 💜
Last one! This is for SMTP (Simple Mail Transfer Protocol), as defined in RFC 2821. The commands are case-insensitive, and there's a special xcmd catch-all for private-use commands that must start with the letter 'X' 💀
smtp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for SMTP is derived from the set of commands
defined for the protocol. These commands are identified
by case-insensitive strings. Commands are listed in the
order found in RFC 2821. The special "xcmd" verb is defined
here as a catch-all for private-use commands, which must
start with the letter 'X'."
REFERENCE
"Simple Mail Transfer Protocol -- RFC 2821, sections 4.1.1
and 4.1.5."
::= {
ehlo(1), -- Extended HELLO (4.1.1.1)
helo(2), -- HELLO (4.1.1.1)
mail(3), -- MAIL (4.1.1.2)
rcpt(4), -- RECIPIENT (4.1.1.3)
data(5), -- DATA (4.1.1.4)
rset(6), -- RESET (4.1.1.5)
vrfy(7), -- VERIFY (4.1.1.6)
expn(8), -- EXPAND (4.1.1.7)
help(9), -- HELP (4.1.1.8)
noop(10), -- NOOP (4.1.1.9)
quit(11), -- QUIT (4.1.1.10)
xcmd(12) -- Catch-all for private-use "X" commands (4.1.5)
}Authors' Addresses ✨
Meet the authors, bestie 🫶
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA USA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA USA 95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Russell Dietz
Hifn, Inc.
750 University Ave
Los Gatos, CA, USA 95032-7695
Phone: +1 408-399-3623
EMail: rdietz@hifn.com
Albin Warth
EMail: dahoss@earthlink.netFull Copyright Statement 📜
Copyright (C) The Internet Society (2002). All Rights Reserved.
The vibe here is that this document and its translations can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can also be made, copied, published and distributed, in whole or in part, with no restrictions of any kind 🦋. The catch is that the copyright notice and this paragraph have to stay on all such copies and derivative works.
The document itself can't be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and translating it into languages other than English 🌍
These permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them 💖
The disclaimer, verbatim because it's serious business: 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.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀
📦 where this page comes from
- ietf: rfc3395 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms