RFC 4088
Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) 🦋
- Who wrote it: D. Black (EMC Corporation), K. McCloghrie (Cisco Systems), and J. Schoenwaelder (International University Bremen) 🧚
- RFC number and stream: RFC 4088, from the Network Working Group 🎀
- Category: Standards Track ✨
- Date: June 2005 📅
- Obsoletes / Updates: this header doesn't list either one 🙈
Status of This Memo
okay so this is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions 🗣️ For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 💌
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
okay this is the big picture 🌸 SNMP and the Internet Standard Management Framework are everywhere for managing communication devices, so we need a way to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments 🖥️ Like, if out-of-band IP management goes through a separate management interface (say, for a device that doesn't support in-band IP access), there needs to be one uniform way to say how to contact the device for management 📡 URIs are perfect for this because one single text string can name a management access communication endpoint for a whole bunch of IP-based protocols 💅
This document defines a URI scheme so SNMP can be designated as the protocol used for management 🦋 The scheme also lets a URI point at one or more MIB object instances ✨
Table of Contents
1. Introduction.................................................. 2
2. Usage......................................................... 3
3. Syntax of an SNMP URI......................................... 4
3.1. Relative Reference Considerations........................ 5
4. Semantics and Operations...................................... 6
4.1. SNMP Service URIs........................................ 6
4.2. SNMP Object URIs......................................... 7
4.2.1. SNMP Object URI Data Access....................... 8
4.3. OID Groups in SNMP URIs.................................. 10
4.4. Interoperability Considerations.......................... 10
5. Examples...................................................... 11
6. Security Considerations....................................... 12
6.1. SNMP URI to SNMP Gateway Security Considerations......... 13
7. IANA Considerations........................................... 14
8. Normative References.......................................... 14
9. Informative References........................................ 15
10. Acknowledgements............................................. 16
Appendix A. Registration Template................................ 171. Introduction 🎀
so SNMP and the Internet-Standard Management Framework were originally built to manage IP devices in-band 🖥️ That means management goes through the same interface(s) that carry the IP traffic 🛣️ But SNMP got so popular that people started using it on devices that don't do in-band IP at all (Fibre Channel devices are the example here) 🧊 So a separate out-of-band IP interface is often used for management 🔌 URIs are a super handy way to find that interface and name the protocol for managing it 🗺️ One possible scenario: an in-band query returns a URI that tells you how the device is managed 🔍 This document specifies a URI scheme that lets SNMP (including a specific SNMP context) be the management protocol named by a URI like that 💖 The scheme also lets a URI point at specific object instances inside an SNMP MIB 🦋
If you want a detailed tour of the documents that make up the current Internet-Standard Management Framework, go read Section 7 of [RFC3410] 📖
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 [RFC2119] 🫶
2. Usage 🌈
there are two big classes of SNMP URI usage: configuration, and gateways between SNMP and other protocols that use SNMP URIs 💅
First up, configuration. An SNMP URI used for configuration tells an application containing an SNMP manager where to find management information 🗂️ The URI can come from a configuration file, or a managed device can hand it over (see Section 1 for an example) 🎁 The manager and agent swap management information with each other, but that info never leaves the manager, like this:
*********** SNMP-Request *********
* *================>* *
URI ---------->* Manager * * Agent *
* *<================* *
*********** SNMP-Response *********
^
|
Other Config Info ------------+Extra configuration info (like a security secret or key) can come through some interface other than the one used for the URI 🔐 For example, if a managed device hands out an SNMP URI in an unprotected way, that device should not provide a secret or key needed to use the URI 🙅♀️ Instead, the secret or key should be pre-configured in the manager, or pre-authorized to it. See Section 6 for the full scoop 🔍
Now gateway usage. Clients use SNMP URIs to ask for management information through an SNMP URI to SNMP gateway (which this document also calls an SNMP gateway) 🌉 The SNMP manager sitting inside the gateway goes and gets the management information, then sends it back to the client who asked, like so:
SNMP gateway
********** URI *********** SNMP-Request *********
* *===========>* *================>* *
* Client * * Manager * * Agent *
* *<===========* *<================* *
********** Info *********** SNMP-Response *********
^
|
Other Config Info ------------+Extra configuration info (like security secrets or keys) can again come through an interface other than the URI one 🔑 For example, some kinds of security info, including secrets and keys, should be pre-configured in the manager or pre-authorized to it, instead of being handed over by the client. See Section 6 🫧
3. Syntax of an SNMP URI 💎
an SNMP URI follows the ABNF [RFC2234] syntax below 📝 It's built on the ABNF syntax rules for userinfo, host, port, and (path) segment in [RFC3986], plus the ABNF syntax rule for HEXDIG in [RFC2234] 🧩
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
context = "/" contextName [ ";" contextEngineID ]
contextName = segment ; SNMP contextName
contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
oids = "/" ( oid / oid-group ) [ suffix ]
oid-group = "(" oid *( "," oid ) ")"
oid = < as specified by [RFC 3061] >
suffix = "+" / ".*"The userinfo and (path) segment ABNF rules are only borrowed for their syntax 🫰 host and port are different, since they have both syntax and semantics spelled out in [RFC3986] 🌟 If you want to know what securityName, contextEngineID, and contextName mean, see [RFC3411] 🔎
The snmp-authority syntax matches the URI authority syntax in Section 3.2 of [RFC3986], with one extra rule on top: when the userinfo part of an authority is there, it MUST be an SNMP securityName 🔒 If the securityName is empty or missing, the entity using the SNMP URI is expected to know which SNMP securityName to use, if one is needed 🤷♀️ Putting authentication info (like passwords) right into URIs is deprecated (see Section 3.2.1 of [RFC3986]), so any secret or key needed for SNMP access must come through other means, which can be out-of-band compared to how the URI itself is shared 🚫 And if the port is empty or missing, port 161 is assumed 🎯
If the contextName is empty or missing, the zero-length string ("") is assumed, since that's the default SNMP context 🧸 An SNMP contextEngineID is a variable-format binary element that an SNMP manager usually discovers on its own 🕵️♀️ An SNMP URI writes a contextEngineID as hexadecimal digits, one pair per byte 🔢 If the contextEngineID is empty or missing, the context engine gets discovered by querying the SNMP agent at the specified host and port. See Section 4.1 below 🔍 The contextEngineID part of the URI SHOULD be present if more than one context engine at the designated host and port supports the designated context 🫶
An SNMP URI that designates the default SNMP context ("") MAY end with the "/" character that introduces the contextName component 💫 An SNMP URI MUST NOT end with the "/" character that introduces an oid or oid-group component, because the empty string isn't a valid OID for SNMP 🚫💀
The encoding rules in [RFC3986] MUST be used for SNMP URIs 🫧 That includes percent encoding ("%" followed by two hex digits), wherever it's needed to represent characters that [RFC3986] calls reserved, along with any characters a URI doesn't allow 🔤 SNMP lets any UTF-8 character appear in a securityName or contextName, so all multi-byte UTF-8 characters in an SNMP URI MUST be percent encoded, as specified in Sections 2.1 and 2.5 of [RFC3986] 🌸 These rules exist because the userinfo and segment ABNF rules are reused from [RFC3986] 🧠
SNMP URIs are usually short enough to dodge implementation string-length limits (for example, the ones that can kick in around 255 characters) ✂️ Those limits could be a worry for big OID groups, though. Relative references to URIs (see Section 4.2 of [RFC3986]) might be a workaround in some situations 🧚
Using IP addresses in SNMP URIs is fine when depending on DNS availability is undesirable or has to be avoided 🌐 Otherwise, IP addresses should not be used (see [RFC1900] for more explanation) 🙃
3.1. Relative Reference Considerations ✨
okay so this one is such a plot twist 🫣 using the SNMP default context (that's the zero-length string) can give you a second // in the URI, like this:
snmp://<host>//<oid>and that's totally allowed by [RFC3986] syntax 💅 if a URI parser can't handle that second // correctly, the parser is broken and needs a glow-up 😤 this one matters a LOT because using the SNMP default context is expected to be super common 🌸
BUT (lowkey the drama 😭) that second // in an absolute SNMP URI messes with relative references to that URI (see Section 4.2 of [RFC3986]). a // at the start of a relative reference always starts a URI authority component (host plus optional userinfo and/or port; see [RFC3986]) 💀 so a relative reference like //<oid2> is NOT gonna work, because the parser treats <oid2> as an authority, can't find a host in it, and throws a syntax error. not me being dramatic about it 🙈
so to avoid that mess, relative references that start with // but don't have a URI authority component MUST NOT be used 🚫 you can get the same result from any forbidden one by putting . or .. in front of it (for example, ..//<oid2>) ✨ which prefix works depends on the base URI, so check that first bestie 🎀
4. Semantics and Operations 🧚
okay the big picture 🖼️ an SNMP URI with no OIDs is called an SNMP service URI, because it points to a communication endpoint for getting into the SNMP management service 📡 an SNMP URI with one or more OIDs is an SNMP object URI, since it points at one or more object instances in an SNMP MIB 💖 the usual way to use one is to have an SNMP manager reach the SNMP context the URI designates, through the SNMP agent at the host and port the URI names 🫶
4.1. SNMP Service URIs 🦋
an SNMP service URI doesn't point at a data object, it points at an SNMP context that a service gets to use 🔑 the telnet URI scheme [RFC1738] is another example of a URI that's all about service access, so it's giving family 👯♀️ if the contextName is empty or missing, "" (the zero-length string) is assumed, since that's the default SNMP context 💅
if a contextEngineID is in the URI, the context engine it names is the one to use 🎯 if the contextEngineID is empty or missing, the context engine has to be discovered, and the one to use is whichever context engine supports the context the URI designates 🔍 the contextEngineID component SHOULD be there if more than one context engine at the designated host and port supports the designated context 🙌
most real-world SNMP URIs are gonna skip the contextEngineID (aka let it default) 🙃 that's because they don't involve SNMP proxy agents, and proxies are the most common reason for several context engines to live at one host and port 😌 so when an SNMP agent is local to the network interface it manages, it usually has just one context engine, which means it's totally safe to leave the contextEngineID out of an SNMP URI 💜 also, a lot of local SNMP agents only support the default SNMP context (the zero-length string) 🍓
4.2. SNMP Object URIs 🌈
an SNMP object URI has one or more OIDs 🔢 the way it works is you split off the OID or OID group (along with its leading slash, any parentheses, and the suffix) and then process what's left as an SNMP service URI, as described in Section 4.1 (above), to figure out which SNMP context to access ✂️ then the OID or OID group is used to generate SNMP operations aimed at that context 🎯
what an SNMP object URI means depends on whether the OID or OID group has a suffix, and which one it is 🧐 there are three possible formats, and in every case the MIB object instances are designated within the SNMP context that the service URI portion of the object URI specifies 🗂️ for an SNMP object URI with a single OID, here's the tea:
(1) An OID without a suffix designates the MIB object instance
named by the OID.
(2) An OID with a "+" suffix designates the lexically next MIB
object instance following the OID.
(3) An OID with a ".*" suffix designates the set of MIB object
instances for which the OID is a strict lexical prefix; this
does not include the MIB object instance named by the OID.an OID group is a set of OIDs in parentheses 👑 for groups, the semantics just extend the single-OID meaning to every OID in the group (so a URI with a "+" suffix designates the set made of the lexically next instance for each OID in the group) 🫧
if more than one URI format could designate the same MIB object instance or instances, the list above is in order of preference (no suffix is the most preferable one), going from most precise to least precise 🎯 that's because an OID with no suffix pins down one exact object instance, a "+" suffix points at the next instance (which can change, so it's a bit slippery 🫠), and the ".*" suffix could cover multiple object instances 🌸 multiple syntactically different SNMP URIs SHOULD NOT be used to designate the same MIB object instance or set of instances, because it can cause unexpected results in URI-based systems that compare URIs as strings to check equality 💀
SNMP object URIs say what data to access, not which SNMP operations to use to get it 🕵️ Section 4.2.1 has examples of how SNMP operations can access data for SNMP object URIs. still, any applicable SNMP operation, GetBulk included, MAY be used to access data for all or part of one or more SNMP object URIs (for example, with several variable bindings in one operation) 🫶 you don't have to use the exact operations from Section 4.2.1 as long as the results (returned variable bindings or error) could have been obtained by following Section 4.2.1's descriptions ✨ and a relative reference that doesn't change the contextName (that's ./<oid>) SHOULD be treated as a hint that optimizing SNMP access across several SNMP URIs might be possible 👀
an SNMP object URI MAY also be used to specify a MIB object instance or instances to be written 📝 that makes an SNMP Set operation happen instead of a Get 💅 the "+" and ".*" suffixes MUST NOT be used in this case, and any attempt to use them is an error that MUST NOT generate any SNMP Set operations 🚫 the values to be written are NOT specified inside an SNMP object URI 🙅♀️
SNMP object URIs designate data in SNMP MIBs, so they can't generate every possible SNMP protocol operation 💔 for example, data access for an SNMP object URI can't directly generate Snmpv2-Trap or InformRequest notifications, though side effects of data access could trigger such notifications (depending on the MIB) 🔔 and whether and how GetBulk is used for an SNMP object URI with a ".*" suffix is up to the implementation 🤷♀️
4.2.1. SNMP Object URI Data Access 💖
data access for an SNMP object URI gives back an SNMP variable binding for each MIB object instance the URI designates, or an SNMP error if the operation fails 📦 a variable binding ties a variable name (an OID) to a value or an SNMP exception (see [RFC3416]) 🎀 the SNMP operation (or operations) needed depends on the OID or OID group suffix, or on there being no suffix at all 🧩 the descriptions below are NOT the only way to do data access for an SNMP object URI 🙅♀️ any suitable SNMP operations are fine as long as the results (returned variable bindings or error) are functionally equivalent ✨
(1) for an OID or OID group with no suffix, an SNMP Get operation is generated with each OID as a variable binding name 📬 if an SNMP error happens, that error is the result of URI data access; otherwise the returned variable binding or bindings are the result 💌 heads up that any returned variable binding might contain an SNMP "noSuchObject" or "noSuchInstance" exception 👀
(2) for an OID or OID group with a "+" suffix, an SNMP GetNext operation is generated with each OID as a variable binding name ➡️ same deal: an SNMP error becomes the result if one happens, otherwise the returned variable binding or bindings are the result 🎁 any returned variable binding might contain an SNMP "endOfMibView" exception 🏁
(3) for an OID or OID group with a ".*" suffix, this one's a whole journey 🗺️ first, an SNMP GetNext operation is generated with each OID as a variable binding name 🌱 if the result is an SNMP error, that error is the result of URI data access 🚨 if all the returned variable bindings contain either a) an OID where the corresponding URI OID is NOT a lexical prefix, or b) an SNMP "endOfMibView" exception, then the returned variable bindings are the result 🎉
otherwise, you save the GetNext results and generate another GetNext, using the newly returned OIDs as the variable binding names 🔁 you keep doing that (save the results, then GetNext with the newly returned OIDs) until every returned variable binding from a GetNext has either a) an OID where the corresponding URI OID is NOT a lexical prefix, or b) an SNMP "endOfMibView" exception 🛑 all the GetNext results get combined into the overall result of URI data access 🧺 and that can include variable bindings whose OID is NOT a lexical extension of the corresponding URI OID 🤯 if the OID subtrees (the set of OIDs where a specific URI OID is a lexical prefix) aren't the same size for every OID in the group, the largest subtree decides when the iteration ends 📏 SNMP GetBulk operations MAY be used to optimize this iterated access ⚡
whenever a returned variable binding has an OID where the corresponding URI OID is NOT a lexical prefix, or an SNMP "endOfMibView" exception, iteration for that element of the OID group MAY stop 🛑 that cuts down the number of variable bindings used in later GetNext operations 📉 when this happens, the results of URI data access for the SNMP URI won't all be OID-group-sized sets of variable bindings 🧩 and even if it doesn't happen, the last variable binding returned for each member of the OID group will usually contain an SNMP "endOfMibView" exception or an OID where the corresponding URI OID is NOT a lexical prefix 🫶
4.3. OID Groups in SNMP URIs 🧚
okay so parenthesized OID groups in SNMP URIs exist for MIB object instances where you need a single SNMP operation to get consistent results 💅 The OIDs inside an OID group SHOULD be accessed by one SNMP operation that has a variable binding for each OID in the group.
The main example is the InetAddress and InetAddressType textual conventions from [RFC4001] 🌸 An InetAddress instance's format is set by its associated InetAddressType instance. If you read those two pieces in separate SNMP operations, the values could come back inconsistent (say, because of a Set that happened in between), and then the InetAddress gets interpreted wrong 😭
This single operation requirement ("SHOULD") also applies to each OID group that comes out of iterated access for an SNMP URI with a ".*" suffix ✨ When the members of an OID group have different numbers of OIDs they're a lexical prefix of, the iteration can overrun and return a bunch of variable bindings where the matching OID in the group isn't a lexical prefix at all 🙈 You can dodge that overrun by using relative references in the same context, like ./<oid>.*, when you don't need to grab several MIB object instances in one SNMP operation 🦋
4.4. Interoperability Considerations 🎀
This document defines a transport-independent "snmp" scheme, and it's built to fit SNMP transports other than UDP 🌈 UDP is the default transport for getting info from an SNMP URI, for backward compatibility with how people already do it, but other transports MAY be used. If more than one transport is available (like SNMP over TCP [RFC3430] alongside SNMP over UDP), the information or SNMP service access an SNMP URI points to SHOULD NOT depend on which transport is picked (for SNMP over TCP, Section 2 of [RFC3430] already implies this) 💜
An SNMP URI means SNMPv3, as specified by [RFC3416], [RFC3417], and related documents 👑 Older SNMP versions MAY be used under [RFC3584] when they're unavoidable. For SNMPv1 and SNMPv2c, the securityName, contextName, and contextEngineID parts of an SNMP URI map to and from the community name, as [RFC3584] describes 🙈 If the community name is a secret that's being used as a weak form of authentication, this mapping should be configured so those three parts don't reveal anything about the community name. If that isn't done, then any SNMP URI component that would leak significant info about a secret community name SHOULD be omitted 🔥 Also, some community names have reserved characters (like "@") that need percent encoding when they go in an SNMP URI 🧚 And SNMP versions (like v3) were left out of the SNMP URI scheme so older versions can still be used, along with any possible future successor to SNMPv3 ✨
5. Examples 💖
snmp://example.comThis one designates the default SNMP context at the SNMP agent on port 161 of host example.com 🌸
snmp://tester5@example.com:8161This one designates the default SNMP context at the SNMP agent on port 8161 of host example.com, and says the SNMP securityName "tester5" is the one to use for that agent 🔥 A non-standard port is handy when you're testing a new version of SNMP agent code 🧪
snmp://example.com/bridge1This designates the "bridge1" SNMP context at example.com 🌈 Since the contextEngineID component is left out, there SHOULD be at most one SNMP context engine at example.com that supports the "bridge1" context 🫶
snmp://example.com/bridge1;800002b804616263This designates the "bridge1" context at snmp.example.com through the SNMP context engine 800002b804616263 (a string representation of a hexadecimal value) 👑 That kills any ambiguity if some other context engine also supports a "bridge1" context 💅 The above two examples are based on the figure in Section 3.3 of [RFC3411] ✨
snmp://example.com//1.3.6.1.2.1.1.3.0
snmp://example.com//1.3.6.1.2.1.1.3+
snmp://example.com//1.3.6.1.2.1.1.3.*All three of these designate the sysUpTime.0 object instance in the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("") at example.com 🦋 That's because sysUpTime.0 is:
a) designated directly by OID 1.3.6.1.2.1.1.3.0,
b) the lexically next MIB object instance after the OID 1.3.6.1.2.1.1.3, and
c) the only MIB object instance whose OID has 1.3.6.1.2.1.1.3 as a lexical prefix.
These three are just for illustration 🙈 Multiple syntactically different URIs SHOULD NOT be used to designate the same MIB object instance, so you don't get weird results in URI-based systems that use string comparison to check URIs for equality 🧚
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*This designates the ifOperStatus column of the IF-MIB in the bridge1 SNMP context at example.com 🍓
snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*This designates all (ifAdminStatus, ifOperStatus) pairs in the IF-MIB in the default SNMP context at example.com 🌈
6. Security Considerations 🔐
okay this part is SERIOUS bestie 😭 One intended use of this URI scheme is pointing to where management access to communication devices lives. That location info can be sensitive in some environments, so it's really important to control who can access it and maybe even encrypt it when it goes over the network 💀 Every use of this URI scheme should bring security mechanisms that fit the environments where it's likely to be deployed 🛡️
The SNMP architecture includes control of access to management information (see Section 4.3 of [RFC3411]) 💜 An SNMP URI doesn't carry enough security info to get access in every situation, since the SNMP URI syntax can't encode SNMP securityModels, SNMP securityLevels, or the credential or keying info for SNMP securityNames 🙈 Other means are needed to provide that info. One option is out-of-band pre-configuration of the SNMP manager, like in the diagrams in Section 2 ✨
Just having a securityName in an SNMP URI does NOT authorize using that securityName to access management information, periodt 💅 Instead, the SNMP manager SHOULD match the securityName in the URI to an SNMP securityName and its associated security info that have been pre-configured for the manager to use 🔥 If an SNMP URI has a securityName the SNMP manager isn't provisioned to use, SNMP operations for that URI SHOULD NOT be generated 🙅♀️
SNMP versions before SNMPv3 didn't have adequate security 😭 Even if the network is secure (say, through IPsec), there's no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in MIB modules 💀 It is RECOMMENDED that implementers look at the security features of the SNMPv3 framework (see Section 8 of [RFC3410] for an overview), including full support for SNMPv3 cryptographic mechanisms (for authentication and privacy) 🔒 This matters even more for MIB elements that are sensitive or vulnerable, because GETs have side effects 🫶
Also, deploying SNMP versions before SNMPv3 is NOT RECOMMENDED 🚫 Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security. Then it's a customer or operator responsibility to make sure the SNMP entity giving access to a MIB module instance is set up so only the principals (users) with legitimate rights can GET or SET (read/change/create/delete) those objects 👑
6.1. SNMP URI to SNMP Gateway Security Considerations 🚪
There are extra security considerations for SNMP gateways that generate SNMP operations for SNMP URIs and send the results back to clients (see Section 2), because management information gets communicated beyond the SNMP framework 🌸 In general, an SNMP gateway should know about the structure and function of the management information it accesses via SNMP. Among other perks, that lets the gateway avoid SNMP access control failures, since it can reject an SNMP URI that would cause one before generating any SNMP operations ✨
SNMP gateways SHOULD impose authorization or access-control checks on all clients 🛡️ If an SNMP gateway doesn't impose authorization or access controls, the gateway MUST NOT automatically obtain or use SNMP authentication material for arbitrary securityNames, because that would defeat SNMP's access controls 🚨 Instead, all SNMP gateways SHOULD authenticate each client and check that the client is authorized to use a securityName in an SNMP URI before using that securityName on the client's behalf 🔑
An SNMP gateway is also responsible for making sure all of its communication is properly secured 💅 Specifically, an SNMP gateway SHOULD ensure that communication of management information with any client is protected to at least the SNMP securityLevel used for the matching SNMP access (see Section 3.4.3 of [RFC3411] for more on securityLevel) 🔒 If the client provides SNMP security information, the SNMP gateway SHOULD authenticate the client and SHOULD ensure that an authenticated cryptographic integrity check is used for that communication, so nobody can modify the security information 🫶 And if a client provides any key or secret, the SNMP gateway SHOULD ensure that encryption is used on top of the integrity check, so keys or secrets don't get disclosed 🤐
Some MIB objects are read-write and/or read-create in MAX-ACCESS 👀 Those can be sensitive or vulnerable in some network environments. Supporting SNMP SET operations on a gateway in a non-secure environment, without proper protection, can have a negative effect on network operations 💀 The individual MIB module specifications, especially their security considerations, should be consulted for more info 📚
Some readable objects in some MIB modules (that is, objects with a MAX-ACCESS other than not-accessible) can be sensitive or vulnerable in some network environments 😱 So it's important to control even GET access to these objects through an SNMP gateway, and maybe even encrypt their values when they go over the network 🔐 The individual MIB module specifications, especially their security considerations, should be consulted for more info. This also applies to objects where reading them has side effects 🧐
7. IANA Considerations 🦋
IANA has registered the URL registration template found in Appendix A in accordance with [RFC2717] 💖
8. Normative References ✨
okay so these are the docs this spec literally cannot function without 📚 you need them to implement anything at all. Here they are, verbatim:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC
3061, February 2001.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework", BCP
74, RFC 3584, August 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.9. Informative References 🧚
these are the bonus reads 💅 helpful for context, but the spec doesn't need you to read them to get the main idea:
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over
Transmission Control Protocol Transport Mapping", RFC 3430,
December 2002.
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer
Protocol (TFTP)", RFC 3617, October 2003.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.10. Acknowledgements 🫶
this section is the big thank-you list 💖 the way the authors gave credit to everyone who helped make this spec better, literally iconic behaviour.
Portions of this document were adapted from Eliot Lear's TFTP URI scheme specification [RFC3617]. Portions of the security considerations were adapted from the widely used security considerations "boilerplate" for MIB modules. Comments from Ted Hardie, Michael Mealing, Larry Masinter, Frank Strauss, Bert Wijnen, Steve Bellovin, the mreview@ops.ietf.org mailing list and the uri@w3c.org mailing list on earlier versions of this document have resulted in significant improvements and are gratefully acknowledged.
Appendix A. Registration Template 📝
this is the form you fill in to register the snmp URL scheme 🎀 every field points back to a section of this doc, so it's basically a cheat sheet:
URL scheme name: snmp
URL scheme syntax: Section 3
Character encoding considerations: Section 3
Intended usage: Sections 1 and 2
Applications and/or protocols which use this scheme: SNMP, all
versions, see [RFC3410] and [RFC3584]. Also SNMP over TCP,
see [RFC3430].
Interoperability considerations: Section 4.4
Security considerations: Section 6
Relevant publications: See [RFC3410] for list. Also [RFC3430]
and [RFC3584].
Contact: David L. Black, see below
Author/Change Controller: IESGAuthors' Addresses 🌸
here's where to find the people who wrote this 🧚 three authors, all with their contact details:
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.deFull Copyright Statement ⚖️
okay the legal bit 🙈 this one is important, so the wording stays exactly as written:
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property 🦋
this part is about patents and other rights that might be tangled up with the tech 💜 the IETF doesn't take a side on those, and the exact text is below:
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.Acknowledgement 💐
last but not least, the funding note ✨ it's short and sweet, just like a good bestie:
Funding for the RFC Editor function is currently provided by the
Internet Society.📦 where this page comes from
- ietf: rfc4088 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms