Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
RFC 4088
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
09 | (System) | Received changes through RFC Editor sync (changed abstract to 'The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for … Received changes through RFC Editor sync (changed abstract to 'The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need 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), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (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. [STANDARDS-TRACK]') |
|
2017-05-16
|
09 | (System) | Changed document authors from "Keith McCloghrie" to "Keith McCloghrie, Jürgen Schönwälder, David Black" |
|
2015-10-14
|
09 | (System) | Notify list changed from <hardie@qualcomm.com>, <Black_David@emc.com>, <kzm@cisco.com>, <j.schoenwaelder@iu-bremen.de> to <j.schoenwaelder@iu-bremen.de>, <Black_David@emc.com>, <hardie@qualcomm.com … Notify list changed from <hardie@qualcomm.com>, <Black_David@emc.com>, <kzm@cisco.com>, <j.schoenwaelder@iu-bremen.de> to <j.schoenwaelder@iu-bremen.de>, <Black_David@emc.com>, <hardie@qualcomm.com> |
|
2005-06-08
|
09 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2005-06-08
|
09 | Amy Vezza | [Note]: 'RFC 4088' added by Amy Vezza |
|
2005-06-06
|
09 | (System) | RFC published |
|
2005-01-03
|
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2004-12-31
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2004-12-31
|
09 | Amy Vezza | IESG has approved the document |
|
2004-12-31
|
09 | Amy Vezza | Closed "Approve" ballot |
|
2004-12-29
|
09 | Bert Wijnen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen |
|
2004-12-29
|
09 | Bert Wijnen | New revision plus and RFC-Editor note have the approval of Steve Bellovin (no longer IESG member, but he did raise a DISCUSS when he was … New revision plus and RFC-Editor note have the approval of Steve Bellovin (no longer IESG member, but he did raise a DISCUSS when he was on IESG). |
|
2004-12-29
|
09 | Bert Wijnen | Status date has been changed to 2004-12-29 from 2004-11-21 |
|
2004-12-02
|
09 | (System) | New version available: draft-black-snmp-uri-09.txt |
|
2004-11-12
|
09 | Steven Bellovin | [Ballot discuss] The security considerations section needs to be revised. All but the first paragarph is standard MIB boilerplate, which doesn't really fit here -- … [Ballot discuss] The security considerations section needs to be revised. All but the first paragarph is standard MIB boilerplate, which doesn't really fit here -- this isn't a MIB, it's a way to represent them. What needs to be said is this: The communication paths from the URI user to the gateway and from the gateway to the SNMP agent need to be secured appropriately. In particular, the gateway needs to either have a priori knowledge of the SNMP security mechanisms that should be applied, or the information must be supplied to it by the querier with the request. In this case, all requests to the gateway must be integrity-protected. |
|
2004-11-04
|
09 | Bert Wijnen | IESG comments/discuesses have been passed to authors to respond. Did a second ping today. No answer yet. |
|
2004-11-04
|
09 | Bert Wijnen | Status date has been changed to 2004-11-21 from 2004-10-21 |
|
2004-11-04
|
09 | Bert Wijnen | Note field has been cleared by Bert Wijnen |
|
2004-10-29
|
09 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2004-10-29
|
09 | (System) | Removed from agenda for telechat - 2004-10-28 |
|
2004-10-28
|
09 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
|
2004-10-28
|
09 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
|
2004-10-28
|
09 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
|
2004-10-28
|
09 | Harald Alvestrand | [Ballot comment] Reviewed by Joel Halpern, Gen-ART His review: This draft is basically ready for publication as a Proposed Standard RFC, but has nits that … [Ballot comment] Reviewed by Joel Halpern, Gen-ART His review: This draft is basically ready for publication as a Proposed Standard RFC, but has nits that I think should be clarified before publication. minor: This document specifically uses URIs with a second double-slash in them - snmp://<host>//<oid> And then goes on to say roughly, ~if this does not work, the URI parser is broken. Fix it.~ In working on other efforts, we have been cautioned against this construct, and told that it may cause trouble for proxies / parsers. I am not enough of an HTTP / URI expert to know whether the usage in this document is safe. |
|
2004-10-28
|
09 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
|
2004-10-28
|
09 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
|
2004-10-28
|
09 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
|
2004-10-27
|
09 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
|
2004-10-27
|
09 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2004-10-25
|
09 | Steven Bellovin | [Ballot discuss] There's no security mechanism defined. The I-D notes, correctly, that SNMPv3 is a good idea. But it provides no authentication of its own, … [Ballot discuss] There's no security mechanism defined. The I-D notes, correctly, that SNMPv3 is a good idea. But it provides no authentication of its own, nor does it provide any hint about how such requests might be authenticated. |
|
2004-10-25
|
09 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
|
2004-10-25
|
09 | Ted Hardie | [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie by Ted Hardie |
|
2004-10-22
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2004-10-22
|
09 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
|
2004-10-21
|
09 | Bert Wijnen | [Note]: 'IESG, please make sure to review revision 8!' added by Bert Wijnen |
|
2004-10-21
|
09 | Bert Wijnen | Status date has been changed to 2004-10-21 from 2004-09-04 |
|
2004-10-21
|
09 | Bert Wijnen | Placed on agenda for telechat - 2004-10-28 by Bert Wijnen |
|
2004-10-21
|
09 | Bert Wijnen | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bert Wijnen |
|
2004-10-21
|
09 | Bert Wijnen | [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen |
|
2004-10-21
|
09 | Bert Wijnen | Ballot has been issued by Bert Wijnen |
|
2004-10-21
|
09 | Bert Wijnen | Created "Approve" ballot |
|
2004-10-21
|
08 | (System) | New version available: draft-black-snmp-uri-08.txt |
|
2004-10-06
|
09 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2004-10-04
|
09 | Michelle Cotton | IANA Last Call Comments: Upon approval of this document the IANA will register a URL Scheme in the following registry: <http://www.iana.org/assignments/uri-schemes> |
|
2004-09-07
|
09 | Amy Vezza | Last call sent |
|
2004-09-07
|
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2004-09-06
|
09 | Bert Wijnen | Last Call was requested by Bert Wijnen |
|
2004-09-06
|
09 | Bert Wijnen | State Changes to Last Call Requested from AD Evaluation::AD Followup by Bert Wijnen |
|
2004-09-06
|
09 | (System) | Ballot writeup text was added |
|
2004-09-06
|
09 | (System) | Last call text was added |
|
2004-09-06
|
09 | (System) | Ballot approval text was added |
|
2004-09-04
|
09 | Bert Wijnen | -----Original Message----- From: Wijnen, Bert (Bert) Sent: Saturday, September 04, 2004 16:51 To: 'Black_David@emc.com' Cc: Juergen Schoenwaelder (E-mail); Keith McCloghrie (E-mail) Subject: RE: New … -----Original Message----- From: Wijnen, Bert (Bert) Sent: Saturday, September 04, 2004 16:51 To: 'Black_David@emc.com' Cc: Juergen Schoenwaelder (E-mail); Keith McCloghrie (E-mail) Subject: RE: New Version Notification - draft-black-snmp-uri OK, I am ready for IETF Last Call. I have one small thing still. Not sure if you want to fix it now or after IETF Last Call In section 3.1 2nd para I see: 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. And I worry about that first sentence. Because, iirc, we defined the securityName such that it would NOT DEPEND on the security model. In fact the idea was that the security-model dependent security ID would be mapped (via a security model specified algorith/mapping) onto a securityName. See sect 3.2 of RFC 3411. So I think it would be wise to reword that 1st sentence of the 2nd para of sect 3.1 in your document. Maybe what you are saying (or want to say) is that depending on how the securityName maps back onto a specific security mode, based on that different semantics exist as to how to access the snmp entity with that securityName. ... but my wording is nto great either... I hope you can see what I am strugling with here. Thanks, Bert |
|
2004-09-04
|
09 | Bert Wijnen | Status date has been changed to 2004-09-04 from 2004-08-12 |
|
2004-08-23
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2004-08-23
|
07 | (System) | New version available: draft-black-snmp-uri-07.txt |
|
2004-08-12
|
09 | Bert Wijnen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bert Wijnen |
|
2004-08-12
|
09 | Bert Wijnen | Quite a set of comments have been received from review on SNMPv3 and MIB-doctors mailing lists. David is expected to submit a new revision to … Quite a set of comments have been received from review on SNMPv3 and MIB-doctors mailing lists. David is expected to submit a new revision to address all these comments. |
|
2004-08-12
|
09 | Bert Wijnen | Status date has been changed to 2004-08-12 from 2004-07-28 |
|
2004-07-28
|
09 | Bert Wijnen | Asking MIB doctors and SNMPv3 list to do a review of revision 6 |
|
2004-07-28
|
09 | Bert Wijnen | Status date has been changed to 2004-07-28 from |
|
2004-07-09
|
06 | (System) | New version available: draft-black-snmp-uri-06.txt |
|
2004-05-25
|
09 | Bert Wijnen | -----Original Message----- From: Wijnen, Bert (Bert) Sent: dinsdag 25 mei 2004 15:46 To: Black_David@emc.com; kzm@cisco.com; j.schoenwaelder@iu-bremen.de Cc: mankin@psg.com; hardie@qualcomm.com Subject: AD review: … -----Original Message----- From: Wijnen, Bert (Bert) Sent: dinsdag 25 mei 2004 15:46 To: Black_David@emc.com; kzm@cisco.com; j.schoenwaelder@iu-bremen.de Cc: mankin@psg.com; hardie@qualcomm.com Subject: AD review: draft-black-snmp-uri-05.txt OK, so I read over the discussion that the 3 authors/editors had back in November last year. After Nov 17 I was no longer copied on further discussion, and I have to assume that there were more, because it ends somehwta in the middle of a thread. Then I read draft-fielding-uri-rfc2396bis-05.txt, which I think is mandatory reading if you want to understand the SNMP URI draft. It is in fact listed as mandatory reference, so that seems to sync up with that thought. Then I read the SNMP-URI draft draft-black-snmp-uri-05.txt. May I first ask at how many other places this was discussed? I do not recall I saw it discussed on any SNMP or MIB related mailing list. We need to bring it there too I guess. My own questions are as follows: - Do we worry about the fact that your syntax seems to assume the USM security model? We already know that people want to do a SBSM model. How can the URI scheme be extended to support other models? Possibly if you were to use "securityName" instead of "user" that we could be security model agnostic? - In sect 3.1 you do not talk at all about how a user password (secret) is to be found. I guess that that is an implementation issue. I think it would be good to explicitly say that. - You seem to have concluded you want to be snmp version agnostic. So how is SNMPv1 and SNMPv2c handled, that is, there is no user, but there is a communityName. I suspect that this is same as a user password, namely that the implementation needs to figure out how to find community name. So maybe we should state that explicitly. I see sect 3.4 which speaks a bit to SNMPv1/v2c. But... does RFC3584 actaully map to the URI scheme? If we were to use securityName instead of user, then probably it does, but I am not sure it does with "user" - Same for SNMP version number. Seems to be an implementation detail. Except I guess if a username is spaecified, because in that case we can (currently) assume that it is SNMPv3 ?? - Sect 3.2, 1st para Mmmm... Why does the engine component need to be specified if there are multiple contexts that give access to the designated context? I would think, that as long as the default context (i.e. contextEngineID==authoritativeEngineID and contextName=="") gives access to the designated (intended?) context, that then there is no need to specify it. - Page 6, bullet 1. Not sure I understand. If I send an oid group with 3 OIDs, and I get a noSuchObject on the first one, then why cannot the 2nd and 3rd varBind have valid data? That is what a normal SNMP GET would result in, no? Or am I misunderstanding the text here? Your semantics sound like SNMPv1 or maybe even worse!? Seems that it is explained on the next page... but I do not (yet) understand why the "URI user" should be "shielded". Why is it OK here to "shield him/her, while it was not ok in SNMPv1 and why we invented the exceptions in SNMPv2. Even after reading sect 3.3, I am not sure I am convinced why this is a good thing. - Page 6, bullet 2. Same question here. The fact that one varBind returns endOfMibView would (in normal SNMP) not mean that the otehr varBinds do not contain valid data. - Page 6, bullet 3 These semantics (specifically that of the last GetNext iteration) also seem a bit weird to me, but then, we do not have an SNMP protocol equivalent, so I guess I can live with it. - Reading the last para of sect 3.2 I wonder... can TRAPs and INFORMS also be generated based on a URI? Can a real GETBULK be generated ? How about future operations in SNMPvx ?? I guess some text that answers such questions would be useful to add. - I wonder about Security Considerations. Seems some text was taken from the MIB boiler plate. This doc however does not describe a MIB module. So not sure how relevant it all is. I can live with it. But possibly a much shorter section would do as well, namely something aka: This document defines the syntax for an SNMP URI. Such URIs identify SNMP agents or point to MIB objects at SNMP agents. However, an SNMP URI by itself does not provide access. Such access is controlled by the SNMP agent itself and so is outside the scope of this specification. SNMP agents do provide access to MIB objects, and every MIB document does have (or at least SHOULD have) a proper Security Considerations section that explains the sensisitivity of specific objects inside the MIB module. Such a MIB document also recommends what the proper SNMP access considerations are for those objects. Whenever a SNMP Object URI is used, it is wise to lookup the OID(s) in the appropriate MIB document(s) and check the Security Considerations. But that is just my opinion. I can live with the current text too. Some clarifications that may be needed (or at least in my view will help less experienceed readers): - According to RFC3411, sect 3.3.1, a context is unambiguously identified by contextEngineID and contextName. So I would propose that we stick to that erminology. That means that: - in several places in your document, you probably want to change "context" into "contextName". Not in all places though. When you mean "context" as opposed to the "name of the context", then of course "context" needs to stay unchanged. - In the Syntax for the SNNMP URI, I would also change "context" in "contextName" - I wonder why you use: "engine=" engine. Why would this not work: snmp_URI = "snmp:" "//" [ user "@" ] host [ ":" port ] [ "/" contextName [ ";" contextEngineID ] [ "/" ( oid | oid-group ) [ "+" | ".*" ]]] By doing it that way, the terms contextName and contextEngineID now line up with RFC3411 terminology and you save 7 characters (octets) in the URI string length. Of course if you do this, then you also need to change "engine" into "contextEngineID" at various places, but not all of them I think. - I wonder if this context = < SNMP context name as specified by [RFC 3411] > is proper ABNF specification. AS far as I know, RFC3411 does not use ABNF to specify the context(Name). - Page 9 states: 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: And I wonder: is it really SNMPv2-MIB? They equally well designate sysUpTime.0 in MIB-II (or better RFC1213-MIB). So I am not sure if it is wise to qualify them as being the SNMPv2-MIB? Nits/Administrivia/Bureaucracy (sorry): - The citation to [rfc2026] in the boilerplate on cover page is best not used (as per old ID-nits and new ID-Checklist). In fact you do not use it, so there is no such citation, so you have aref to 2026 without a citation. Best to just remove it. - If you do a revision, it would probably be better to use the new RFC3667/3668 boilerplate and disclaimers/copyright etc. Seems like you are not using XML2RFC tool, otherwise you would get it automagically. Thanks, Bert |
|
2004-05-25
|
09 | Bert Wijnen | State Change Notice email list have been change to <hardie@qualcomm.com>, <Black_David@emc.com>, <kzm@cisco.com>, <j.schoenwaelder@iu-bremen.de> from <hardie@qualcomm.com>, … State Change Notice email list have been change to <hardie@qualcomm.com>, <Black_David@emc.com>, <kzm@cisco.com>, <j.schoenwaelder@iu-bremen.de> from <hardie@qualcomm.com>, <Black_David@emc.com> |
|
2004-05-25
|
09 | Bert Wijnen | Note field has been cleared by Bert Wijnen |
|
2004-05-25
|
09 | Bert Wijnen | State Changes to AD Evaluation from Publication Requested by Bert Wijnen |
|
2004-05-24
|
09 | Bert Wijnen | State Changes to Publication Requested from AD is watching by Bert Wijnen |
|
2004-05-24
|
09 | Bert Wijnen | Shepherding AD has been changed to Bert Wijnen from Ted Hardie |
|
2004-05-24
|
09 | Bert Wijnen | Area acronymn has been changed to ops from gen |
|
2004-05-24
|
09 | Bert Wijnen | State Change Notice email list have been change to <hardie@qualcomm.com>, <Black_David@emc.com> from |
|
2004-05-24
|
09 | Bert Wijnen | Intended Status has been changed to Proposed Standard from None |
|
2004-05-17
|
05 | (System) | New version available: draft-black-snmp-uri-05.txt |
|
2004-04-13
|
04 | (System) | New version available: draft-black-snmp-uri-04.txt |
|
2004-02-16
|
03 | (System) | New version available: draft-black-snmp-uri-03.txt |
|
2004-02-11
|
09 | Ted Hardie | The author contacted me to discuss whether this draft should be based on RFC 2396 or draft-fielding-2396bis. Here's my response: After catching up with the … The author contacted me to discuss whether this draft should be based on RFC 2396 or draft-fielding-2396bis. Here's my response: After catching up with the thread, I think it should be based on the 2396bis syntax. There is a moderate risk in that, to be honest, that it will get delayed in "REF" state at the RFC editor, but it should be complete enough to implement at that stage. There is a worse risk on the other side, that you may end up using a production that isn't in the bis document (viz. the text string context); that might cause some general-purpose URI parsers to reject these, which would be a real problem. So this should be based on the -bis draft. |
|
2004-02-11
|
09 | Ted Hardie | Draft Added by Ted Hardie |
|
2004-02-05
|
02 | (System) | New version available: draft-black-snmp-uri-02.txt |
|
2003-10-27
|
01 | (System) | New version available: draft-black-snmp-uri-01.txt |
|
2003-08-29
|
00 | (System) | New version available: draft-black-snmp-uri-00.txt |