[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?! :-)