Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
Extracted elements (24)
Parenthesized OID groups were introduced to support atomic access to related MIB object instances (e.g., InetAddressType and InetAddress pairs from RFC 4001) that must be read in a single SNMP operation to ensure consistent interpretation.
SNMP version numbers were intentionally omitted from the URI scheme syntax to permit use of both older SNMP versions (v1, v2c via RFC 3584) and any possible future successor to SNMPv3, keeping the scheme forward-compatible.
The preference ordering for URI formats (no suffix > '+' > '.*') reflects precision: an OID without a suffix precisely designates one instance, while '+' and '.*' designate instances that may change or include multiple values.
The SNMP URI scheme designates SNMPv3 by default, but older SNMP versions (v1, v2c) MAY be used per RFC 3584 when unavoidable. For SNMPv1/v2c, securityName, contextName, and contextEngineID are mapped to/from the community name; SNMP version is intentionally omitted from the URI to allow forward compatibility.
The 'snmp' URI scheme is transport-independent; UDP is the default transport for backward compatibility, but other transports (e.g., SNMP over TCP per RFC 3430) MAY be used. The information designated by the URI SHOULD NOT depend on which transport is used.
Use of the SNMP default context (zero-length string) results in a second '//' in the URI (e.g., snmp://<host>//<oid>). This is syntactically valid per RFC 3986; parsers that fail to handle it correctly are broken.
An SNMP URI MUST NOT end with the '/' character that introduces an oid or oid-group component, because the empty string is not a valid OID for SNMP.
Multiple syntactically distinct SNMP URIs SHOULD NOT be used to designate the same MIB object instance or set of instances, as this may cause unexpected results in URI-based systems that use string comparison to test URIs for equality.
OIDs within an OID group in an SNMP URI SHOULD be accessed by a single SNMP operation containing a variable binding for each OID, in order to ensure consistent results (e.g., for InetAddress/InetAddressType pairs).
Relative references that start with '//' but do not contain a URI authority component MUST NOT be used in SNMP URIs, because the '//' will be parsed as a URI authority, causing a syntax error.
The '+' and '.*' suffixes MUST NOT be used when an SNMP object URI is used to specify MIB object instances to be written (Set operation); any attempt to do so is an error that MUST NOT generate any SNMP Set operations.
The contextEngineID component of an SNMP URI SHOULD be present if more than one context engine at the designated host and port supports the designated context, to avoid ambiguity.
The encoding rules specified in RFC 3986 MUST be used for SNMP URIs, including percent encoding for reserved characters; all multi-byte UTF-8 characters in securityName or contextName MUST be percent encoded.
The userinfo component of the URI authority, when present, MUST be an SNMP securityName. Authentication credentials (passwords) MUST NOT be included in the URI; any required secret or key must be provided via out-of-band means.
An OID group in an SNMP URI consists of a parenthesized, comma-separated set of OIDs, e.g., (oid1,oid2). Group semantics extend single-OID semantics to each OID in the group, and are intended to support atomic access to related MIB object instances.
An SNMP object URI includes one or more OIDs after the context component. Three suffix forms are defined: no suffix designates the named instance; '+' designates the lexically next instance; '.*' designates all instances for which the OID is a strict lexical prefix.
An SNMP service URI designates a communication endpoint (host, port, SNMP context) without specifying any OIDs. If contextEngineID is omitted, it must be discovered by querying the SNMP agent; if port is omitted, port 161 is assumed.
The SNMP URI scheme syntax is defined as: snmp-uri = "snmp://" snmp-authority [ context [ oids ]], where snmp-authority includes an optional securityName, host, and port. The context component includes a contextName and optional contextEngineID encoded as hexadecimal digits.
IANA registered the 'snmp' URL scheme name in accordance with RFC 2717, based on the registration template in Appendix A of this document.
An SNMP gateway SHOULD ensure that client communication is protected to at least the SNMP securityLevel used for the corresponding SNMP access. If a client provides keys or secrets, the gateway SHOULD use encryption in addition to integrity checks to prevent disclosure.
An SNMP URI does not contain sufficient security information for all access scenarios; it cannot encode SNMP securityModels, securityLevels, or credential/keying material. The SNMP manager SHOULD match the securityName in the URI to pre-configured security information and SHOULD NOT generate SNMP operations for unrecognized securityNames.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. It is RECOMMENDED to deploy SNMPv3 with cryptographic security (authentication and privacy) enabled, and to configure access controls appropriately.
SNMP gateways SHOULD impose authorization or access-control checks on all clients. If no access controls are imposed, the gateway MUST NOT automatically obtain or use SNMP authentication material for arbitrary securityNames, as this would defeat SNMP's access controls.
The contextEngineID field in an SNMP URI is encoded as a sequence of HEXDIG pairs (1*(HEXDIG HEXDIG)), representing a variable-length binary value as a hexadecimal string. Multi-byte UTF-8 characters in securityName or contextName must be percent-encoded.