Re: Please review: draft-black-snmp-uri-06.txt

[Frank Strauß <strauss@ibr.cs.tu-bs.de>]

Wijnen, Bert (Bert) wrote:

> This document is in my queue to consider for publication
> as a Proposed Standard. Before I do a 4-week IETF Last Call
> I would like to get some feedback from the MIB doctors.

Here are a few comments on draft-black-snmp-uri-06.txt:

  - ABNF rules on page 3: Some symbols contain a minus ("-") while
    snmp_URI contains an underscore ("_") while others are written in
    "camel notation". The latter is obviously due to reuse from RFC
    3411, but the first should probably be changed.

  - The abbrev. "URI" is uppercase while "oid" is lowercase. This
    should probably be aligned throughout the whole document.

  - I assume contextEngineID should be a number of bytes in
    hexadecimal representation. Since each byte requires two HEXDIGs
    it should be "1*(HEXDIG HEXDIG)".

  - I think the optional "suffix" should be appended directly to each
    occurance of "oid":

          oids            = "/" ( oid [ suffix ] / oid-group )
          oid-group       = "(" oid [ suffix ] *( "," oid [ suffix ] ) ")"

    And the description in Section 3.2 should be changed accordingly.

    This would (a) make the OIDs with suffixes look a little more
    intuitively interpretable, and (b) allow URIs to contain explicit
    and/or "getnext-style" and/or "subtree-style" OIDs. (On the other
    hand, if that would be beyond the goal of the SNMP URI scheme,
    then one could ask whether oid-groups aren't beyond the scope,
    anyway.)
    
  - Grep for "Agent" and "Manager" and change to "agent" and "manager"
    where appropriate.

  - Page 4: "characters other than unreserved" sounds a bit odd to
    me. Do you mean reserved characters? :-)

  - Give an xref to Section 2.1 for term "relative URIs" in the middle
    of page 4.

  - I didn't try very hard, but for the first and second reading I did
    not really understand what the last paragraph of Section 2.1 says.

  - I suggest to separate out the part starting "Data access based on
    an SNMP URI ..." from Section 3.2 and declare it more as a
    reasonable suggestion than as a fact, e.g. there might be reasons
    to make a URI which designates more than one object instance
    result in more that one SNMP request. Or there might be a
    "GetSubtree" operation sometime in the future (Section 3.4 also
    mentions forward compatibility). Hence, I suggest to clearly
    separate such implementation hints from the core of this document.

  - Page 8, (3): "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." I
    guess this is not correct.

  - Taking the paragraph starting "Otherwise the results..."
    precisely, it says that GetNext operations continue, until *all*
    OIDs result in non-matching prefixes or endOfMibView. Until then
    *all* results are saved an become part of the overall result of
    the URI data access, including potentially some varbinds that are
    not matching "their" prefix, if some subtrees are smaller and
    others are larger, and only the largest one defines when the
    iteration terminates. The last paragraph on page 7 somehow
    addresses this issue, but IMHO not completely.

  - The last sentence on page 7 is missing some wording close to
    "... exception or an for which ...".

  - Start of page 8: "SNMP URIs designate ..." -> "SNMP object URIs
    designate ...". Same in last paragraph of Section 3.2.

  - I suggest to move the more general information of this paragraph
    in front of the more explicit hints on page 7.

  - I am a little concerned about "relative URIs". Do you really want
    to allow URIs that are not self-contained (except for security
    credentials)?! I don't think this is a good idea and could cause
    some trouble. The well accepted purpose of URIs is their
    relatively handy use "as-is" to identify resources.