Network Working Group D.Black Internet Draft EMC Corporation Document: draft-black-snmp-uri-06.txt K. McCloghrie Expires: January 2005 Cisco Systems J. Schoenwaelder International University Bremen July 2004 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Black Expires - January 2005 [Page 1] URI Scheme for SNMP July 2004 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. 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.......................................5 3.1 SNMP Service URIs..........................................5 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. Copyright Notice and Disclaimers.............................14 12. Author's Addresses...........................................15 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. Black Expires - January 2005 [Page 2] URI Scheme for SNMP July 2004 For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC 3410]. 2. Syntax of an SNMP URI An SNMP URI has the following ABNF [RFC 2234] syntax, based on the ABNF syntax rules for userinfo, host, port, and (path) segment in [rfc2396bis] and the ABNF syntax rule for HEXDIG in [RFC 2234]: 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 ; 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 reused for syntax only. In contrast, host and port have both the syntax and semantics specified in [rfc2396bis]. securityName, contextEngineID, and contextName are defined in [RFC 3411]. The snmp-authority syntax matches the URI authority syntax in section 3.2 of [rfc2396bis] with the additional restriction that (when present) the userinfo component of an authority MUST be an SNMP securityName. If the securityName is empty or not given, the entity making use of an SNMP URI is expected to know what SNMP securityName to use if one is required. Inclusion of authentication information (e.g., passwords) in URIs has been deprecated (see Section 3.2.1 of [rfc2396bis]), so any secret or password required for SNMP access must be obtained via other means. If the port is empty or not given, port 161 is assumed. If the contextName 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 contextEngineID is empty or not given, the context engine is to be discovered by querying the SNMP Agent at the specified host and port; see Section 3.1 below. The contextEngineID component of the URI SHOULD be present if more than one context engine at the designated host and port supports the designated context. Black Expires - January 2005 [Page 3] URI Scheme for SNMP July 2004 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, as the empty string is not a valid oid for SNMP. The encoding rules specified in [rfc2396bis] MUST be used for SNMP URIs, including the use of percent encoding ("%" followed by two hex digits) to represent characters other than unreserved characters. SNMP allows any UTF-8 character to be used in a securityName or contextName; all multi-byte UTF-8 characters in an SNMP URI MUST be percent encoded as specified in Section 2 of [rfc2396bis]. These requirements are a consequence of reuse of the ABNF syntax rules for userinfo and segment from [rfc2396bis]. SNMP URIs will generally be short enough to avoid implementation string length limits (e.g., that may occur at 255 characters). Such limits may be a concern for large oid groups; relative URIs provide an alternative in some circumstances. 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://// This is allowed by [rfc2396bis] syntax; 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 a URI authority component. Specifically, a relative SNMP URI of the form // is not usable because the "//" causes to be parsed as a URI authority, resulting in a syntax error. To avoid this problem, relative SNMP URIs that start with "//" but do not contain a URI authority component MUST NOT be used. The intended functionality of any such relative URI can be obtained by prefixing "." or "..", depending on the base URI (e.g., ..//). Black Expires - January 2005 [Page 4] URI Scheme for SNMP July 2004 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 contextName is empty or not given in the URI, "" (the zero-length string) is assumed as it is the default SNMP context. The semantics of an SNMP securityName depend on the security model and SNMP protocol version in use. For the SNMPv3 User-based Security Model (USM), an SNMP securityName is an SNMP userName [RFC 3414]. For SNMPv1 and SNMPv2c, the securityName is obtained via mapping from the community name, see [RFC 3584]. Additional SNMP security models may be defined. If a contextEngineID is given in an SNMP service URI, the context engine that it designates is to be used. If the contextEngineID is empty or not given in the URI, the context engine is to be discovered; the context engine to be used is the one that supports the context designated by the URI. The contextEngineID component of the URI SHOULD be present if more than one context engine at the designated host and port supports the designated context. Many common uses of SNMP URIs are expected to omit (i.e., default) the contextEngineID because they do not involve accessing SNMP proxy agents, the most common reason for multiple SNMP context 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 context engine, in which case it is safe to omit the contextEngineID 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 Black Expires - January 2005 [Page 5] URI Scheme for SNMP July 2004 resulting SNMP service URI as specified in Section 3.1 (above) to determine the SNMP context to be accessed. 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 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. In each case, the oid group semantics are the extension of the single oid semantics to each oid in the group (e.g., a URI with a "+" suffix designates the set of MIB object instances consisting of the lexically next instance for each oid in the oid group). When there is a choice among URI 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 or an SNMP error if the operation fails. An SNMP variable binding binds a variable name (oid) to a value or an 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: Black Expires - January 2005 [Page 6] URI Scheme for SNMP July 2004 (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, otherwise the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "noSuchObject" or "noSuchInstance" exception. (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, otherwise the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "endOfMibView" exception. (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 all returned variable bindings contain either an oid for which the corresponding URI oid is not a lexical prefix or an SNMP "endOfMibView" exception, the returned variable binding or bindings are the result of URI data access. 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 an SNMP error is returned or until all returned variable bindings contain either an oid for which the corresponding URI oid is not a lexical prefix or an SNMP "endOfMibView" exception. The result of URI data access consists of the groups of variable bindings from the successful SNMP GetNext operations. SNMP GetBulk operations MAY be used to optimize this iterated access. Whenever a returned variable binding contains an oid for which the corresponding URI oid is not a lexical prefix or an SNMP "endOfMibView" exception, iteration of that element of the oid group MAY cease, reducing the number of variable bindings used in subsequent GetNext operations. In this case the results of URI data access for the SNMP URI will not consist entirely of oid-group-sized sets of variable bindings. Even if this does not occur, the last variable binding returned for each member of the oid group will generally be an SNMP exception or an for which the corresponding URI oid is not a lexical prefix. Black Expires - January 2005 [Page 7] URI Scheme for SNMP July 2004 SNMP URIs designate the data to be accessed, as opposed to the specific SNMP operations to be used for access. Therefore, any applicable SNMP operation, including GetBulk, MAY be used to access data for all or part of one or more SNMP URIs (e.g., via use of multiple variable bindings in a single operation); it is not necessary to use the specific operations in the above descriptions as long as the returned variable bindings or error could have been obtained by following the descriptions. The use of relative SNMP object URIs that do not change the contextName (i.e., ./) should be viewed as a hint that optimization of SNMP access across multiple URIs may be possible. An SNMP URI MAY 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 that MUST NOT generate any SNMP Set operations. Values to be written to the MIB object instance or instances are not specified within an SNMP URI. SNMP URIs designate data in SNMP MIBs, and hence do not provide the means to generate all possible SNMP protocol operations. For example, data access for an SNMP URI cannot directly generate either Snmpv2-Trap or InformRequest notifications, although side effects of data access could cause such notifications (depending on the MIB). In addition, determining whether and how GetBulk is used for a SNMP URI with a ".*" suffix is implementation-specific. 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 or otherwise desirable. Therefore, the oids within an oid group in an SNMP URI SHOULD be accessed by a single SNMP operation containing a variable binding corresponding to each oid in the group. A specific example involves the InetAddress and InetAddressType textual conventions defined in [RFC 3291] where the format of an InetAddress instance is specified by an associated InetAddressType instance. If two such associated instances are read 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 with a ".*" suffix. When members of an SNMP URI oid group differ in the number of oids for which each is a lexical prefix, this iteration may overrun by returning numerous variable bindings for which the corresponding oid in the oid group is not a lexical prefix. Such Black Expires - January 2005 [Page 8] URI Scheme for SNMP July 2004 overrun can be avoided by using relative URIs within the same context (i.e., ./) when it is not important to access multiple MIB object instances in a single SNMP operation. 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 in accordance with [RFC 3584] where usage of such older versions is unavoidable. For SNMPv1 and SNMPv2c, the contextName and contextEngineID elements of an SNMP URI are mapped to and from the community name as described in [RFC 3584]. Note that some SNMPv1 and SNMPv2c community names contain reserved characters (e.g., "@") that require percent encoding when used in an SNMP URI. 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 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 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 contextEngineID component of the URI is omitted, there SHOULD be at most one SNMP context engine at snmp.example.com that supports the "bridge1" context. Black Expires - January 2005 [Page 9] URI Scheme for SNMP July 2004 snmp://snmp.example.com/bridge1;800002b804616263 This example designates the "bridge1" context at snmp.example.com via the SNMP context engine 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 or RFC1213-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 access to this information and possibly even to encrypt 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 - January 2005 [Page 10] URI Scheme for SNMP July 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 (read/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. -02: Reworked engine, context, and oid syntax. Made URI scheme Black Expires - January 2005 [Page 11] URI Scheme for SNMP July 2004 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. -06: Change syntax component names to match SNMP terminology (e.g., contextName, contextEngineID). Back out -04 change to discard SNMP "no data" exceptions. Loosen requirements on group iteration. Drop "engine=" to simplify syntax. Rewrite ABNF for clarity and correctness. 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-05.txt . Work in Progress. April 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. Black Expires - January 2005 [Page 12] URI Scheme for SNMP July 2004 [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. 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 - January 2005 [Page 13] URI Scheme for SNMP July 2004 11. Copyright Notice and Disclaimers Copyright (C) The Internet Society (2004). 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." 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." Black Expires - January 2005 [Page 14] URI Scheme for SNMP July 2004 12. 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 - January 2005 [Page 15]