[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4088

                            URI Scheme for SNMP            December 2004
   
   
      Network Working Group                                       D. Black
      Internet Draft                                       EMC Corporation
      Document: draft-black-snmp-uri-09.txt                  K. McCloghrie
      Expires: May 2005                                      Cisco Systems
                                                          J. Schoenwaelder
                                           International University Bremen
                                                             December 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 - May 2005                  [Page 1]
   

                            URI Scheme for SNMP            December 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. 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. Change History (to be deleted prior to RFC publication).......14
      9. Normative References..........................................15
      10. Informative References.......................................15
      11. Acknowledgments..............................................16
      12. Copyright Notice and Disclaimers.............................16
      13. Author's Addresses...........................................17
   
   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 - May 2005                  [Page 2]
   

                            URI Scheme for SNMP            December 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. Usage
   
      There are two major classes of SNMP URI usage, configuration and
      gateways between SNMP and other protocols that use SNMP URIs.
   
      An SNMP URI used for configuration indicates the location of
      management information as part of configuration of an application
      containing an SNMP manager.  The URI can be obtained from a
      configuration file or may be provided by a managed device (see
      Section 1 for an example).  Management information is exchanged
      between the SNMP manager and agent, but does not flow beyond the
      manager, as shown in the following diagram:
   
   
                                ***********  SNMP-Request   *********
                                *         *================>*       *
                 URI ---------->* Manager *                 * Agent *
                                *         *<================*       *
                                ***********  SNMP-Response  *********
                                     ^
                                     |
       Other Config Info ------------+
   
      Additional configuration information (e.g., a security secret or
      key) may be provided via an interface other than that used for the
      URI.  For example, when a managed device provides an SNMP URI in
      an unprotected fashion, that device should not provide a secret or
      key required to use the URI.  The secret or key should instead be
      pre-configured in or pre-authorized to the manager; see Section 6.
   
      For gateway usage, clients employ SNMP URIs to request management
      information via an SNMP URI to SNMP gateway (also called an SNMP
      gateway in this document).  The SNMP manager within the SNMP
      gateway accesses the management information and returns it to the
      requesting client, as shown in the following diagram:
   
                                 SNMP gateway
            **********     URI    ***********  SNMP-Request   *********
            *        *===========>*         *================>*       *
            * Client *            * Manager *                 * Agent *
            *        *<===========*         *<================*       *
            **********    Info    ***********  SNMP-Response  *********
                                     ^
                                     |
       Other Config Info ------------+
   
   
   Black                     Expires - May 2005                  [Page 3]
   

                            URI Scheme for SNMP            December 2004
   
   
      Additional configuration information (e.g., security secret(s) or
      key(s)) may be provided via an interface other than that used for
      the URI.  For example, some types of security information,
      including secrets and keys, should be pre-configured in or pre-
      authorized to the manager rather than being provided by the
      client; see Section 6.
   
   3. 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 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].  See [RFC 3411] for the
      semantics of securityName, contextEngineID, and contextName.
   
      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
      key required for SNMP access must be provided via other means that
      may be out-of-band with respect to communication of the URI.  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. An SNMP URI encodes a
      contextEngineID as hexadecimal digits corresponding to a sequence
   
   
   Black                     Expires - May 2005                  [Page 4]
   

                            URI Scheme for SNMP            December 2004
   
   
      of bytes.  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 4.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.
   
      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) as needed to represent characters defined as reserved
      in [rfc2396bis] and any characters not allowed in a URI.  SNMP
      permits 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 Sections 2.1 and 2.5 of
      [rfc2396bis].  These requirements are a consequence of reusing 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
      references to URIs (see Section 4.2 of [rfc2396bis]) may 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).
   
   3.1 Relative Reference 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] 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 references to that URI (see
      Section 4.2 of [rfc2396bis]) because a "//" at the start of a
   
   
   Black                     Expires - May 2005                  [Page 5]
   

                            URI Scheme for SNMP            December 2004
   
   
      relative reference always introduces a URI authority component
      (host plus optional userinfo and/or port, see [rfc2396bis]).
      Specifically, a relative reference of the form //<oid2> will not
      work because the "//" will cause <oid2> to be parsed as a URI
      authority, resulting in a syntax error when the parser fails to
      find a host in <oid2> .  To avoid this problem, relative
      references that start with "//" but do not contain a URI authority
      component MUST NOT be used.  Functionality equivalent to any such
      forbidden relative reference can be obtained by prefixing "." or
      ".." to the forbidden relative reference (e.g., ..//<oid2>).  The
      prefix to use depends on the base URI.
   
   4. 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.  The expected means
      of using an SNMP 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.
   
   4.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. If the contextName in the URI is empty or not given,
      "" (the zero-length string) is assumed as it is the default SNMP
      context.
   
      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).
   
   
   Black                     Expires - May 2005                  [Page 6]
   

                            URI Scheme for SNMP            December 2004
   
   
   
   4.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 4.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.
   
      SNMP object URIs designate the data to be accessed, as opposed to
      the specific SNMP operations to be used for access; Section 4.2.1
      provides examples of how SNMP operations can be used to access
      data for SNMP object URIs.  Nonetheless, any applicable SNMP
   
   
   Black                     Expires - May 2005                  [Page 7]
   

                            URI Scheme for SNMP            December 2004
   
   
      operation, including GetBulk, MAY be used to access data for all
      or part of one or more SNMP object URIs (e.g., via use of multiple
      variable bindings in a single operation); it is not necessary to
      use the specific operations described in 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.  The use of
      relative references that do not change the contextName (i.e.,
      ./<oid>) should be viewed as a hint that optimization of SNMP
      access across multiple SNMP URIs may be possible.
   
      An SNMP object 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 object URI.
   
      SNMP object 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 object 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, whether
      and how GetBulk is used for a SNMP object URI with a ".*" suffix
      is implementation-specific.
   
   4.2.1 SNMP Object URI Data Access
   
      Data access based on an SNMP object 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 needed to access data
      designated by an SNMP object URI depend on the OID or OID group
      suffix or absence thereof.  The following descriptions are not the
      only method of performing data access for an SNMP object URI; any
      suitable SNMP operations may be used as long as the results
      (returned variable bindings or error) are functionally equivalent.
   
      (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.
   
   
   
   
   Black                     Expires - May 2005                  [Page 8]
   

                            URI Scheme for SNMP            December 2004
   
   
      (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 a) an OID for which the corresponding
         URI OID is not a lexical prefix or b) an SNMP "endOfMibView"
         exception, then the returned variable 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 repeated
         (save the results and generate a GetNext with newly returned
         OIDs as variable binding names) until all of the returned
         variable bindings from a GetNext contain either a) an OID for
         which the corresponding URI OID is not a lexical prefix or b)
         an SNMP "endOfMibView" exception.  The results from all of
         the GetNext operations are combined to become the overall
         result of URI data access; this may include variable bindings
         whose OID is not a lexical extension of the corresponding URI
         OID.  If the OID subtrees (set of OIDs for which a specific URI
         OID is a lexical prefix) are not the same size for all OIDs in
         the OID group, the largest subtree determines when this
         iteration ends.  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 contain an SNMP
         "endOfMibView" exception or an OID for which the corresponding
         URI OID is not a lexical prefix.
   
   
   
   
   
   
   Black                     Expires - May 2005                  [Page 9]
   

                            URI Scheme for SNMP            December 2004
   
   
   4.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
      overrun can be avoided by using relative references within the
      same context (i.e., ./<oid>.* ) when it is not important to access
      multiple MIB object instances in a single SNMP operation.
   
   4.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
      securityName, contextName and contextEngineID elements of an SNMP
      URI are mapped to/from the community name as described in [RFC
      3584].  When the community name is kept secret as a weak form of
      authentication, this mapping should be configured so that these
      three elements do not reveal information about the community name.
      If this is not done, then any SNMP URI component that would
      disclose significant information about a secret community name
   
   
   Black                     Expires - May 2005                 [Page 10]
   

                            URI Scheme for SNMP            December 2004
   
   
      SHOULD be omitted.  Note that some 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 to permit use of older versions of SNMP,
      as well as any possible future successor to SNMPv3.
   
   5. Examples
   
         snmp://example.com
   
      This example designates the default SNMP context at the SNMP agent
      at port 161 of host example.com .
   
         snmp://tester5@example.com:8161
   
      This example designates the default SNMP context at the SNMP agent
      at port 8161 of host example.com and indicates that the SNMP
      securityName "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://example.com/bridge1
   
      This example designates the "bridge1" SNMP context at example.com.
      Because the contextEngineID component of the URI is omitted, there
      SHOULD be at most one SNMP context engine at example.com that
      supports the "bridge1" context.
   
         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://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.*
   
      These three examples all designate the sysUpTime.0 object instance
      in the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("")
      at 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.
   
   
   
   Black                     Expires - May 2005                 [Page 11]
   

                            URI Scheme for SNMP            December 2004
   
   
      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.
   
   6. 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.
   
      The SNMP architecture includes control of access to management
      information (see Section 4.3 of [RFC 3411]).  An SNMP URI does not
      contain sufficient security information to obtain access in all
      situations, as the SNMP URI syntax is incapable of encoding SNMP
      securityModels, SNMP securityLevels, and credential or keying
      information for SNMP securityNames.  Other means are necessary to
      provide such information; one possibility is out-of-band pre-
      configuration of the SNMP manager, as shown in the diagrams in
      Section 2.
   
      By itself, the presence of a securityName in an SNMP URI MUST NOT
      authorize use of that securityName to access management
      information.  Instead the SNMP manager SHOULD match the
      securityName in the URI to an SNMP securityName and associated
      security information that have been pre-authorized for use by the
      manager.  If an SNMP URI contains a securityName that the SNMP
      manager is not authorized to use, SNMP operations for that URI
      SHOULD NOT be generated.
   
      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
   
   
   Black                     Expires - May 2005                 [Page 12]
   

                            URI Scheme for SNMP            December 2004
   
   
      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.1 SNMP URI to SNMP Gateway Security Considerations
   
      Additional security considerations apply to SNMP gateways that
      generate SNMP operations for SNMP URIs and return the results to
      clients (see Section 2) because management information is
      communicated beyond the SNMP framework.  In general, an SNMP
      gateway should have some knowledge of the structure and function
      of the management information that it accesses via SNMP.  Among
      other benefits, this allows an SNMP gateway to avoid SNMP access
      control failures because the gateway can reject an SNMP URI that
      will cause such failures before generating any SNMP operations.
   
      SNMP gateways SHOULD impose authorization or access control checks
      on all clients.  If an SNMP gateway does not impose authorization
      or access controls, the gateway MUST NOT automatically obtain or
      use SNMP authentication material for arbitrary securityNames, as
      doing so would defeat SNMP's access controls.  Instead, all SNMP
      gateways SHOULD authenticate each client and check the client's
      authorization to use a securityName in an SNMP URI before using
      the securityName on behalf of that client.
   
      An SNMP gateway is also responsible for ensuring that all of its
      communication is appropriately 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 corresponding SNMP access (see Section 3.4.3 of [RFC
      3411] for more information 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 to
      prevent modification of the security information.  In addition, if
      a client provides any key or secret, the SNMP gateway SHOULD
   
   
   
   Black                     Expires - May 2005                 [Page 13]
   

                            URI Scheme for SNMP            December 2004
   
   
      ensure that encryption is used in addition to the integrity check
      for that communication to prevent disclosure of keys or secrets.
   
      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.  SNMP
      gateway 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 via an SNMP gateway
      and possibly to even encrypt the values of these objects when
      sending them over the network.  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.
   
   7. IANA Considerations
   
      The IANA is asked to register the URL registration template found
      in Appendix A in accordance with [RFC 2717].
   
   8. Change History (to be deleted prior to RFC publication)
   
      -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.
      -07: Yet more editing.  Move data access details into a
         separate subsection, and make it clear that functional
         equivalence to their results is all that is required.  Use
         example.com consistently in all examples.
   
   
   
   Black                     Expires - May 2005                 [Page 14]
   

                            URI Scheme for SNMP            December 2004
   
   
      -08: Remove discussion of SNMP security models. Add warning
         about avoiding disclosure of a community name when it's a
         secret.  Change "relative URI" to "relative reference" to match
         final version of rfc2396bis.
      -09: Expand security considerations section to cover SNMP URI
         to SNMP gateways.  Add usage section to help explain this.
   
   9. Normative References
   
      [rfc2396bis] Uniform Resource Identifiers (URI): Generic Syntax.
                  T. Berners-Lee, R. Fielding, L. Masinter.
                  Internet-Draft draft-fielding-uri-rfc2396bis-07.txt .
                  Work in Progress.  September 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.
   
   10. Informative References
   
      [RFC 1738] Uniform Resource Locators (URL). T. Berners-Lee,
                  L. Masinter, M. McCahill. RFC 1738. December 1994.
   
   
   
   Black                     Expires - May 2005                 [Page 15]
   

                            URI Scheme for SNMP            December 2004
   
   
      [RFC 1900] Renumbering Needs Work. B. Carpenter, Y. Rekhter.
                  RFC 1900. February 1996.
   
      [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.
   
   11. Acknowledgments
   
      Portions of this document were adapted from Eliot Lear's TFTP URI
      scheme specification [RFC 3617].  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 draft
      have resulted in significant improvements and are gratefully
      acknowledged.
   
   12. 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."
   
   
   Black                     Expires - May 2005                 [Page 16]
   

                            URI Scheme for SNMP            December 2004
   
   
   
      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."
   
   13. 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
   
   
   
   
   
   Black                     Expires - May 2005                 [Page 17]
   

                            URI Scheme for SNMP            December 2004
   
   
   Appendix A. Registration Template
   
      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 [RFC 3410] and [RFC 3584].  Also SNMP over TCP,
         see [RFC 3430].
      Interoperability considerations: Section 4.4
      Security considerations: Section 6
      Relevant publications: See [RFC 3410] for list.  Also [RFC 3430]
         and [RFC 3584].
      Contact: David L. Black, Section 13
      Author/Change Controller: IESG
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Black                     Expires - May 2005                 [Page 18]
   

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/