URI Scheme for SNMP May 2004
Network Working Group D.Black
Internet Draft EMC Corporation
Document: draft-black-snmp-uri-05.txt K. McCloghrie
Expires: November 2004 Cisco Systems
J. Schoenwaelder
International University Bremen
May 2004
Uniform Resource Identifier (URI) Scheme for the
Simple Network Management Protocol (SNMP)
Status of this Memo
This document is an Internet-Draft and is subject to all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
SNMP and the Internet-Standard Management Framework are widely
used for management of communication devices, creating needs to
specify SNMP access (including access to SNMP MIB object
instances) from non-SNMP management environments. For example,
when out-of-band IP management is used via a separate management
interface (e.g., for a device that does not support in-band IP
access) there is a need for a uniform way to indicate how to
contact the device for management. URIs fit this need well, as
they allow a single text string to indicate a management access
communication endpoint for a wide variety of IP-based protocols.
This document defines a URI scheme so that SNMP can be designated
as the protocol used for management. The scheme also allows a URI
to designate one or more MIB object instances.
Black Expires - November 2004 [Page 1]
URI Scheme for SNMP May 2004
Conventions used in this document
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].
Table of Contents
1. Introduction...................................................2
2. Syntax of an SNMP URI..........................................3
2.1 Relative URI Considerations................................4
3. Semantics and Operations.......................................4
3.1 SNMP Service URIs..........................................4
3.2 SNMP Object URIs...........................................5
3.3 OID Groups in SNMP URIs....................................8
3.4 Interoperability Considerations............................9
4. Examples.......................................................9
5. Security Considerations.......................................10
6. IANA Considerations...........................................11
7. Change History (to be deleted prior to RFC publication).......11
8. Normative References..........................................12
9. Informative References........................................13
10. Acknowledgments..............................................13
11. Author's Addresses...........................................14
1. Introduction
SNMP and the Internet-Standard Management Framework were
originally devised to manage IP devices via in-band means where
management access is primarily via the same interface(s) used to
send and receive IP traffic. SNMP's wide adoption has resulted in
its use to manage communication devices that do not support in-
band IP access (e.g., Fibre Channel devices); a separate out-of-
band IP interface is often used for management. URIs provide a
convenient way to locate that interface and specify the protocol
to be used for management; one possible scenario is for an in-band
query to return a URI that indicates how the device is managed.
This document specifies a URI scheme to permit SNMP (including a
specific SNMP context) to be designated as the management protocol
by such a URI. This scheme also allows a URI to refer to specific
object instances within an SNMP MIB.
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7
of [RFC 3410].
Black Expires - November 2004 [Page 2]
URI Scheme for SNMP May 2004
2. Syntax of an SNMP URI
An SNMP URI has the following ABNF [RFC 2234] syntax:
snmp_URI = "snmp:" "//" [ user "@" ] host [ ":" port ]
[ "/" context [ ";" "engine=" engine ]
[ "/" ( oid | oid-group ) [ "+" | ".*" ]]]
user = < SNMP user name as specified by [RFC 3414] >
host = < as specified by [rfc2396bis] >
port = < as specified by [rfc2396bis] >
engine = hex [ (hex)* ] ; SNMP contextEngineID as
; specified by [RFC 3411]
hex = < Hex digit, as specified by [rfc2396bis] >
context = < SNMP context name as specified by [RFC 3411] >
oid-group = "(" oid [ ( "," oid )* ] ")"
oid = < as specified by [RFC 3061] >
The [ user "@" ] host [ ":" port ] portion of the above syntax
matches the URI authority syntax specified in section 3 of
[rfc2396bis] with the additional restriction that (when present)
the user component (userinfo in [rfc2396bis]) MUST be an SNMP user
name. If the user is empty or not given, the entity making use of
an SNMP URI is expected to know what SNMP user name to use if one
is required. If the port is empty or not given, port 161 is
assumed. If the context is empty or not given, the zero-length
string ("") is assumed, as it is the default SNMP context.
An SNMP contextEngineID is a variable-format binary element that
is usually discovered by an SNMP Manager. If the engine is empty
or not given, the engine is to be discovered by interrogating the
SNMP Agent at the specified host and port; see Section 3.1.
An SNMP URI that designates the default SNMP context ("") MAY end
with the "/" character that introduces the context component. An
SNMP URI MUST NOT end with the "/" character that introduces the
oid or oid-group component, as the empty string is not a valid oid
for SNMP.
The encoding rules specified in [rfc2396bis] apply to SNMP URIs,
including the use of percent encoding ("%" character followed by
two hex digits) to represent characters other than unreserved
characters. SNMP allows any UTF-8 character to be used in a user
name or context name; all multi-byte UTF-8 characters in an SNMP
URI MUST be percent encoded as specified in Section 2.4 of
[rfc2396bis].
SNMP URIs will generally be short enough to avoid implementation
string length limits (e.g., that may occur at 255 characters).
Black Expires - November 2004 [Page 3]
URI Scheme for SNMP May 2004
Use of IP addresses in SNMP URIs is acceptable in situations where
dependence on availability of DNS service is undesirable or must
be avoided; otherwise IP addresses should not be used (see [RFC
1900] for further explanation).
2.1 Relative URI Considerations
Use of the SNMP default context (zero-length string) within an
SNMP URI can result in a second instance of "//" in the URI, e.g.:
snmp://<host>//<oid>
This is allowed by [rfc2396bis]; if a URI parser does not handle
the second "//" correctly, the parser is broken and needs to be
fixed. This example is important because use of the SNMP default
context in SNMP URIs is expected to be common.
On the other hand, the second occurrence of "//" in an absolute
SNMP URI affects usage of relative URIs because a "//" at the
start of a relative URI always introduces an authority component.
Specifically, a relative SNMP URI of the form //<oid2> is not
usable because the "//" causes <oid2> to be parsed as an
authority, resulting in a syntax error. To avoid this problem,
relative SNMP URIs that start with "//" but do not contain an
authority component MUST NOT be used. The intended functionality
of such relative URIs can be achieved by prefixing a "." or "..",
depending on the base URI (e.g., ..//<oid2>).
3. Semantics and Operations
An SNMP URI that does not include any oids is called an SNMP
service URI because it designates a communication endpoint for
access to SNMP management service. An SNMP URI that includes one
or more oids is called an SNMP object URI because it designates
one or more object instances in an SNMP MIB.
3.1 SNMP Service URIs
An SNMP service URI does not designate a data object, but rather
an SNMP context to be accessed by a service; the telnet URI scheme
[RFC 1738] is another example of URIs that designate service
access. The expected means of using an SNMP service URI is to
employ an SNMP Manager to access the SNMP context designated by
the URI via the SNMP Agent at the host and port designated by the
URI; if the context is empty or not given in the URI, "" (the
zero-length string) is assumed as it is the default SNMP context.
If an engine is given in an SNMP service URI, the context is to be
accessed via that SNMP engine. If the engine is empty or not
Black Expires - November 2004 [Page 4]
URI Scheme for SNMP May 2004
given in the URI, the engine is to be discovered; the engine to be
used is the one that supports the context designated by the URI.
The engine component of the URI SHOULD be present if more than one
engine at the designated host and port supports the designated
context.
Many common uses of SNMP URIs are expected to omit (i.e., default)
both the engine and the context because they do not involve
accessing SNMP proxy agents, the most common reason for multiple
SNMP engines to exist at a single host and port. Specifically,
when an SNMP Agent is local to the network interface that it
manages, the agent will usually have only one engine, in which
case it is safe to omit the engine component of an SNMP URI. In
addition, many SNMP Agents that are local to a network interface
support only the default SNMP context (zero-length string).
3.2 SNMP Object URIs
An SNMP object URI contains one or more oids. The URI is used by
first separating the oid or oid group (including its preceding
slash plus any parentheses and/or suffix), and then processing the
resulting SNMP service URI as specified in Section 3.1 (above) to
determine the SNMP context to be accessed. The engine component
of the URI SHOULD be present if more than one engine at the
designated host and port supports the designated context. The oid
or oid group is then used to generate SNMP operations directed to
that SNMP context.
The semantics of an SNMP object URI depend on whether the oid or
oid group has a suffix and what that suffix is. There are three
possible suffix formats; in each case, the MIB object instances
are designated within the SNMP context specified by the service
URI portion of the SNMP object URI. The semantics of an SNMP
object URI that contains a single oid are:
(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 in an SNMP URI consists of a set of oids in
parentheses. For cases (1) and (2), the oid group semantics are
the extension of the single oid semantics to each oid in the group
(e.g., in case (2) the URI designates the set of MIB object
instances consisting of the lexically next object instance for
each oid in the group). For case (3), the oid group semantics are
Black Expires - November 2004 [Page 5]
URI Scheme for SNMP May 2004
an iterated version of case (2) where the iteration ceases when
any element of the group fails to yield a valid MIB object
instance.
When there is a choice among suffix formats to designate the same
MIB object instance or instances, the above list is in order of
preference (no suffix is most preferable) as it runs from most
precise to least precise. This is because an oid without a suffix
precisely designates an object instance, whereas a "+" suffix
designates the next object instance, which may change, and the
".*" suffix could designate multiple object instances. 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.
Data access based on an SNMP URI returns an SNMP variable binding
for each MIB object instance designated by the URI. An SNMP
variable binding binds a variable name (oid) to a value or SNMP
exception (see [RFC 3416]). The SNMP operation or operations
generated to access data designated by an SNMP object URI depend
on the oid or oid group suffix or absence thereof:
(1) For an oid or oid group without a suffix, an SNMP Get
operation is generated using each oid as a variable binding
name. If an SNMP error occurs, that error is the result
of URI data access. If any returned variable binding
contains a "noSuchObject" exception or a "noSuchInstance"
exception, all bindings are ignored and URI data access is
successful but returns no data. Otherwise the returned
variable bindings are the result of URI data access.
(2) For an oid or oid group with a "+" suffix, an SNMP GetNext
operation is generated using each oid as a variable binding
name. If an SNMP error occurs, that error is the result
of URI data access. If any returned variable binding contains
an "endOfMibView" exception, all bindings are ignored and URI
data access is successful but returns no data. Otherwise the
returned variable bindings are the result of URI data access.
(3) For an oid or oid group with a ".*" suffix, an SNMP GetNext
operation is initially generated using each oid as a variable
binding name. If the result is an SNMP error, that error is
the result of URI data access. If any returned variable
binding contains an oid for which the corresponding URI oid is
not a lexical prefix or contains an "endOfMibView" exception,
all bindings are ignored and the URI data access is successful
but returns no data.
Black Expires - November 2004 [Page 6]
URI Scheme for SNMP May 2004
Otherwise the results of the GetNext operation are saved, and
another SNMP GetNext operation is generated using the newly
returned oids as variable binding names; this is iterated until
a GetNext operation returns one of the following:
a) an SNMP error
b) a variable binding containing an oid for which the
corresponding URI oid is not a lexical prefix
c) a variable binding containing an "endOfMibView" exception
The iteration ceases at this point, and the results of this
final SNMP GetNext operation are ignored. The result of URI
data access consists of the groups of variable bindings from
the preceding successful SNMP GetNext operations. SNMP
GetBulk operations MAY be used to optimize this iterated
access.
Any applicable SNMP operation, including GetBulk, MAY be used to
access data for all or part of multiple SNMP URIs (e.g., via use
of multiple variable bindings in a single operation). The use of
relative object URIs that do not change context (i.e., ./oid)
should be viewed as a hint that optimization is possible. This
can be useful when independent iteration is desired on multiple
oids in the same context, as use of two URIs (e.g., base and
relative) with the ".*" suffix will cause both iterations to run
to their respective ends. In contrast, when ".*" is applied to an
oid group the iteration stops when any oid in the group can no
longer be iterated.
SNMP operations can bind oids to SNMP exceptions ("noSuchObject",
"noSuchInstance", and "endOfMibView") that indicate no data is
available for the requested binding. The design of SNMP URIs
shields URI users from such exceptions for simplicity. The
results of any successful SNMP operation that returns such an
exception are ignored; that SNMP operation is considered to have
succeeded and returned no data. This is analogous to successful
HTTP access to an empty web page (e.g., an HTTP 204 No Content
status code as opposed to a 404 Not Found status code for a page
that does not exist [RFC 2616]).
An SNMP URI can also be used to specify a MIB object instance or
instances to be written; this causes generation of an SNMP Set
operation instead of a Get. The "+" and ".*" suffixes MUST NOT be
used in this case; any attempt to do so is an error and MUST NOT
generate any SNMP Set operations. The values to be written to the
MIB object instances are not specified within the SNMP URI.
Black Expires - November 2004 [Page 7]
URI Scheme for SNMP May 2004
3.3 OID Groups in SNMP URIs
Parenthesized oid groups in SNMP URIs are intended to support MIB
object instances for which access via a single SNMP operation is
required to ensure consistent results. Therefore, the oids within
an oid group in an SNMP URI SHOULD be accessed by a single SNMP
operation with a variable binding corresponding to each oid in the
group. A specific example involves the InetAddress and
InetAddressType textual conventions defined in [RFC 3291]; the
format of an InetAddress instance is specified by an associated
InetAddressType instance. If two such associated instances are
accessed via separate SNMP operations, the resulting values could
be inconsistent (e.g., due to an intervening Set) causing the
InetAddress value to be incorrectly interpreted. This single
operation requirement ("SHOULD") also applies to each oid group
resulting from iterated access for an SNMP URI that contains ".*".
The data designated by a ".*" format SNMP URI is based on
iterating until at least one iterated oid fails to return data
designated by the URI (original oid is not a lexical prefix of the
returned oid, or an SNMP exception is returned). This behavior
differs from the corresponding behavior of the SNMP GetBulk
operation which is only allowed to cease iterating early when no
iterated oid returns useful data. When any of a GetBulk's
iterated oids stop returning useful data, bindings to
"endOfMibView" exceptions are returned for those oids until
iteration reaches the point that no iterated oid returns useful
data (or the GetBulk operation is complete). This approach is not
applicable when an iterated oid from a ".*" format SNMP URI
reaches the end of its lexical scope because the end of the MIB
has not been reached, so using "endOfMibView" would be incorrect
and risk misinterpretation by SNMP code. Rather than inventing a
new SNMP exception solely for ".*" format SNMP URIs, SNMP
exceptions are hidden from URI users for simplicity.
Given this approach, if the iteration for a ".*" format SNMP URI
were to continue after an iterated oid has hit the end of its
lexical prefix match, the size of subsequent groups of variable
bindings would be smaller than the number of oids in the URI.
This is counter to a more important aspect of GetBulk, namely that
iteration results in matched sets of variable bindings (e.g., if
there are three oids to be iterated [repeated], a set of three
variable bindings for each iteration is returned). In order to
avoid returning smaller oid sets, the definition of a ".*" URI
ceases iteration when any oid hits the end of its lexical prefix
match or returns an SNMP exception. This ensures that the
structure of the information designated by a URI matches the
structure of the URI's oid group (e.g., if the URI's oid group
Black Expires - November 2004 [Page 8]
URI Scheme for SNMP May 2004
contains three oids, the designated information consists of groups
with three MIB object instances in each group).
Relative URIs using ".*" provide almost as compact a specification
of the independent iteration behavior of GetBulk, and as indicated
above, use of relative URIs within the same context should be
regarded as a hint that optimizations such as the use of GetBulk
are possible.
3.4 Interoperability Considerations
This document defines a transport-independent "snmp:" scheme that
is intended to accommodate SNMP transports other than UDP. UDP is
the default transport for access to information specified by an
SNMP URI for backwards compatibility with existing usage, but
other transports MAY be used. If more than one transport can be
used (e.g., SNMP over TCP [RFC 3430] in addition to SNMP over UDP)
the information or SNMP service access designated by an SNMP URI
SHOULD NOT depend on which transport is used (for SNMP over TCP,
this is implied by Section 2 of [RFC 3430]).
An SNMP URI designates use of SNMPv3 as specified by [RFC 3416],
[RFC 3417] and related documents, but older versions of SNMP MAY
be used for access designated by an SNMP URI in accordance with
[RFC 3584] where usage of such older versions is unavoidable.
SNMP versions (e.g., v3) have been omitted from the SNMP URI
scheme for forwards compatibility with any possible future
successor to SNMPv3.
4. Examples
snmp://snmp.example.com
This example designates the default SNMP context at the SNMP Agent
at UDP port 161 of host snmp.example.com .
snmp://tester5@snmp.example.com:8161
This example designates the default SNMP context at the SNMP Agent
at UDP port 8161 of host snmp.example.com and indicates that the
SNMP user name "tester5" is to be used to access that Agent. A
possible reason for use of a non-standard port is testing of a new
version of SNMP Agent code.
snmp://snmp.example.com/bridge1
This example designates the "bridge1" SNMP context at
snmp.example.com. Because the engine component of the URI is
Black Expires - November 2004 [Page 9]
URI Scheme for SNMP May 2004
omitted, there SHOULD be at most one SNMP context engine at
snmp.example.com that supports the "bridge1" context.
snmp://snmp.example.com/bridge1;engine=800002b804616263
This example designates the "bridge1" context at snmp.example.com
via the SNMP contextEngineID 800002b804616263 (string
representation of a hexadecimal value). This avoids ambiguity if
any other context engine supports a "bridge1" context. The above
two examples are based on the figure in Section 3.3 of [RFC 3411].
snmp://snmp.example.com//1.3.6.1.2.1.1.3.0
snmp://snmp.example.com//1.3.6.1.2.1.1.3+
snmp://snmp.example.com//1.3.6.1.2.1.1.3.*
These three examples all designate the sysUpTime.0 object instance
in the SNMPv2-MIB for the default SNMP context ("") at
snmp.example.com as 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 examples are provided for illustrative purposes only,
as multiple syntactically distinct URIs SHOULD NOT be used to
designate the same MIB object instance in order to avoid
unexpected results in URI-based systems that use string comparison
to test URIs for equality.
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
This example 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 example designates all (ifAdminStatus, ifOperStatus) pairs in
the IF-MIB in the default SNMP context at example.com.
5. Security Considerations
An intended use of this URI scheme is designation of the location
of management access to communication devices. Such location
information may be considered sensitive in some environments,
making it important to control even read access and possibly even
to encrypt the information when sending it over the network. All
uses of this URI scheme should provide security mechanisms
appropriate to the environments in which such uses are likely to
be deployed.
Black Expires - November 2004 [Page 10]
URI Scheme for SNMP May 2004
There are management objects defined in SNMP MIBs whose MAX-ACCESS
is read-write and/or read-create. Such objects may be considered
sensitive or vulnerable in some network environments. The support
for SNMP SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. The
individual MIB module specifications, and especially their
security considerations, should be consulted for further
information.
Some readable objects in some MIB modules (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive
or vulnerable in some network environments. It is thus important
to control even GET access to these objects and possibly to even
encrypt the values of these objects when sending them over the
network via SNMP. The individual MIB module specifications, and
especially their security considerations, should be consulted for
further information. This consideration also applies to objects
for which read operations have side effects.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example via use of
IPsec), there is no control over who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects in MIB modules. It is RECOMMENDED that implementers
consider the security features as provided by the SNMPv3 framework
(see [RFC 3410], section 8 for an overview), including full
support for SNMPv3 cryptographic mechanisms (for authentication
and privacy). This is of additional importance for MIB elements
considered sensitive or vulnerable because GETs have side effects.
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to a
MIB module instance is properly configured to give access to the
objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
6. IANA Considerations
The IANA is asked to register the URL registration template found
in Appendix A in accordance with [RFC 2717].
7. Change History (to be deleted prior to RFC publication)
-00: Initial version - user, host and port only.
-01: Initial attempt to add engine, context, and oid, plus
support for alternate (non-UDP) transports.
Black Expires - November 2004 [Page 11]
URI Scheme for SNMP May 2004
-02: Reworked engine, context, and oid syntax. Made URI scheme
transport-independent. Added more examples. Significant text
editing and rearrangement.
-03: Update to reference rfc2396bis draft instead of RFC 2396.
Context and engine syntax changed to comply with rfc2396bis
authority component restrictions. Minor text editing.
-04: Remove "0x" engine prefix. Add discussion of relative
URI impacts of embedded //. Add oid groups to support
MIB object instances that need to be accessed together.
Always discard SNMP "no data" response exceptions. More edits.
-05: Spell out acronyms in title. Correct wording to refer to
SNMP exceptions. More editing.
8. Normative References
[rfc2396bis] Uniform Resource Identifiers (URI): Generic Syntax.
T. Berners-Lee, R. Fielding, L. Masinter.
Internet-Draft draft-fielding-uri-rfc2396bis.
Work in Progress. February 2004.
[RFC 2119] Key words for use in RFCs to Indicate Requirement
Levels. S. Bradner. RFC 2119, BCP 14. March 1997.
[RFC 2234] Augmented BNF for Syntax Specifications: ABNF.
D. Crocker, Ed., P. Overell. RFC 2234. November 1997.
[RFC 3061] A URN Namespace of Object Identifiers. M. Mealling.
February 2001.
[RFC 3411] An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks.
D. Harrington, R. Presuhn, B. Wijnen. December 2002.
[RFC 3414] User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3).
U. Blumenthal, B. Wijnen. RFC 3414. December 2002.
[RFC 3416] Version 2 of the Protocol Operations for the Simple
Network Management Protocol (SNMP). R. Presuhn, Ed.
RFC 3416. December 2002.
[RFC 3417] Transport Mappings for the Simple Network Management
Protocol (SNMP). R. Presuhn, Ed. RFC 3417.
December 2002.
[RFC 3584] Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework.
R. Frye, D. Levi, S. Routhier, B. Wijnen. RFC 3584.
August 2003.
Black Expires - November 2004 [Page 12]
URI Scheme for SNMP May 2004
9. Informative References
[RFC 1738] Uniform Resource Locators (URL). T. Berners-Lee,
L. Masinter, M. McCahill. RFC 1738. December 1994.
[RFC 1900] Renumbering Needs Work. B. Carpenter, Y. Rekhter.
RFC 1900. February 1996.
[RFC 2026] The Internet Standards Process -- Revision 3.
S. Bradner. RFC 2026, BCP 9. October 1996.
[RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding,
J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, T. Berners-Lee. RFC 2616. June 1999.
[RFC 2717] Registration Procedures for URL Scheme Names. R. Petke,
I. King. RFC 2717. November 1999.
[RFC 3291] Textual Conventions for Internet Network Addresses.
M. Daniele, B. Haberman, S. Routhier,
J. Schoenwaelder. RFC 3291. May 2002.
[RFC 3410] Introduction and Applicability Statements for Internet-
Standard Management Framework. J. Case, R. Mundy,
D. Partain, B. Stewart. RFC 3410. December 2002.
[RFC 3430] Simple Network Management Protocol Over Transmission
Control Protocol Transport Mapping. J. Schoenwaelder.
December 2002.
[RFC 3617] Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer
Protocol (TFTP). E. Lear. October 2003.
10. Acknowledgments
Portions of this draft were adapted from Eliot Lear's TFTP URI
scheme specification [RFC 3617]. The security considerations text
was adapted from the widely used security considerations
"boilerplate" for MIB modules. Comments from Ted Hardie, Michael
Mealing, Larry Masinter, and the uri@w3c.org mailing list on
earlier versions of this draft have resulted in significant
improvements and are gratefully acknowledged.
Black Expires - November 2004 [Page 13]
URI Scheme for SNMP May 2004
11. Author's Addresses
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.de
Appendix A. Registration Template
URL scheme name: snmp
URL scheme syntax: Section 2
Character encoding considerations: Section 2
Intended usage: Section 1
Applications and/or protocols which use this scheme: SNMP, all
versions, see [RFC 3410] and [RFC 3584]. Also SNMP over TCP,
see [RFC 3430].
Interoperability considerations: Section 3.4
Security considerations: Section 5
Relevant publications: See [RFC 3410] for list. Also [RFC 3430]
and [RFC 3584].
Contact: David L. Black, Section 11
Author/Change Controller: IESG
Black Expires - November 2004 [Page 14]
