Skip to main content

Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
draft-black-snmp-uri-09

Revision differences

Document history

Date Rev. By Action
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:////
  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:
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 , , , from ,
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 , 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