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

[Black_David@emc.com]

Frank,

-- OID groups

> I assumed, that the URI shall NOT imply any SNMP operations
> (though some reasonable implementations are quite obvious).
> I can imagine situations where a scalar object and a table
> row are related, so that it might be meaningful to represent
> them together in a single URI, e.g., ifNumber along with a
> column of ifTable that holds a number of rows.

That makes sense, but the general notion of "related" is handled
reasonably well by relative URIs.  OID groups were added to the
design to deal with tighter relationships, where incorrect results
are possible if the members of the group aren't accessed by a
single SNMP operation.  This possibility of incorrect results
motivates the need to tell implementers that a single SNMP operation
SHOULD be used for an OID group (because multiple operations may
not be functionally equivalent).  The corresponding statement for
relative URIs is necessarily weaker - they "should" be viewed as
an opportunity for optimization.

> However, I don't really feel a strong need for allowing such URIs.

Ok, thanks.

-- Empty subtrees for subtree (.*) URIs

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

[... snip ...]

> It is my understanding that the two conditions in the first part if the
> sentence cause the result of the SNMP operation (a varbind with an
out-of-range
> OID or an exception) *NOT* to be part of the URI data access result. But
this
> sentence says the opposite. Am I totally confused?! :-)

The sentence is correct as written - those varbinds are part of the
result; GetNext behaves this way, as does GetBulk when a repetition
overruns a subtree.  In all honesty, I had guessed roughly the same
thing a while back, and following that guess to its logical conclusion,
an earlier version of the draft (-04) specified discarding of all SNMP
exceptions and all out-of-subtree variable bindings.

While that approach works and can be made consistent, it caused
the results of data access via SNMP object URIs to differ from
data access via SNMP software.  It also necessitated some peculiar
text about data access succeeding but returning no data; while HTTP is
capable of exhibiting this behavior, it's not something one expects of
SNMP.  Given the newness of SNMP object URIs plus some uncertainty about
how they're going to be used, the eventual conclusion was that
introducing this behavioral difference now was not a good idea.

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

> -----Original Message-----
> From: Frank Strauß [mailto:strauss@ibr.cs.tu-bs.de] 
> Sent: Friday, July 30, 2004 2:48 AM
> To: Black_David@emc.com
> Cc: bwijnen@lucent.com; mreview@ops.ietf.org; kzm@cisco.com
> Subject: RE: Please review: draft-black-snmp-uri-06.txt
> 
> 
> Black_David@emc.com wrote:
> 
> Thanks for your detailed response. Below, I just quoted the parts on which
I
> have additional minor comments. I am completely according with the rest of
your
> response.
> 
> >>   - 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.
> 
> I assumed, that the URI shall NOT imply any SNMP operations (though some
> reasonable implementations are quite obvious). I can imagine situations
where a
> scalar object and a table row are related, so that it might be meaningful
to
> represent them together in a single URI, e.g., ifNumber along with a
column of
> ifTable that holds a number of rows.
> 
> However, I don't really feel a strong need for allowing such URIs.
> 
> >>   - 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.
> 
> It is my understanding that the two conditions in the first part if the
> sentence cause the result of the SNMP operation (a varbind with an
out-of-range
> OID or an exception) *NOT* to be part of the URI data access result. But
this
> sentence say s the opposite. Am I totally confused?! :-)