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

[Black_David@emc.com]

Frank,

Many thanks for the detailed review.

> 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)".

These three changes will be made, and thank you very much for the
detailed ABNF check.  For URI and OID, the revised draft will use
lower case for ABNF components, and upper case for the usual meaning
of the acronyms.

>   - 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.)

I disagree with this.

Section 3.3 discusses the design rationale for OID groups - the motivation
is to group OIDs that need to be accessed in a single SNMP operation,
hence different suffixes within a group are explicitly disallowed by
the syntax.  Suffixing the group carries the "right" intuition - the suffix
distributes over the operation that accesses the OID group.  Relative URIs
provide a compact way of expressing OIDs with different suffixes on the
assumption that single operation access is not important when the suffixes
are different (more on relative URIs below).

>   - Grep for "Agent" and "Manager" and change to "agent" and "manager"
>     where appropriate.

Ok.

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

Not exactly - this circumlocution was caused by the definitions of
reserved and unreserved characters in RFC 2396 and the rfc2396bis draft.
For example, non-US-ASCII UTF-8 characters are neither reserved nor
unreserved :-).  This will be rephrased to explicitly refer to "reserved
characters as defined in [rfc2396bis] and other characters not
allowed in a URI" to avoid the double-negative.

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

Actually, the right xref is Section 4.2 of [rfc2396bis] where this concept
is specified.
 
>   - 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.

The material on relative URIs in RFC 2396 and/or the rfc2396bis draft
may help, and that paragraph will be rephrased to make it clearer (add
references to [rfc2396bis] and say that a URI authority is a host
plus optional userinfo and/or port).

The basic line of reasoning is:

	1) SNMP URIs of the form snmp://<host>//<oid> are allowed.  URI
		syntax ([rfc2396bis]) has no problem with the second // .
	2) On this basis, [rfc2396bis] would allow relative SNMP URIs of the
		form 	//<oid2> , but those won't work because the initial
//
		causes URI parsers to look for a host in <oid2> .
	4) Therefore relative SNMP URIs of the form //<oid2> are forbidden.
	5) The functionality that would have been obtained from a
		forbidden relative SNMP URI can be obtained by prefixing
		the forbidden URI with either "." or ".." (e.g., .//<oid2>).
 
>   - 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.

The paragraph after those data access descriptions was supposed to convey
this "functional equivalence is ok" concept.  Since that didn't get the
job done, the text will be rearranged as you suggest.
 
>   - 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.

It's close (relative clauses are such a wonderful feature of English).
After "exception", it'll be rephrased to "then the returned variable
bindings are ..." for clarity.

>   - 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.

Will be rephrased along these lines.
 
>   - The last sentence on page 7 is missing some wording close to
>     "... exception or an for which ...".

Oops, that sentence should read:

	Even if
	this does not occur, the last variable binding returned for
	each member of the OID group will generally contain an SNMP
	exception or an OID for which the corresponding URI OID
	is not a lexical prefix.

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

Ok.

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

Ok, but in a different form - the page 7 explicit instructions are
going into a separate subsection following 3.2, so the reader sees
the general information paragraph first.  A statement that any
functionally equivalent operations are ok will also be added to the
new subsection.

>   - 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. 

Yes, the decision to allow relative URIs was made quite a while ago
in RFC 2396.  Relative URIs are frequently used for within-document/page
and within-site references on the web.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------