[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"Thomas, Steven C (Steve)" wrote:
> In draft-ietf-eos-snmp-rowops-00.txt section 3.2.2, you wrote:
> In cases of CreateRow, at least one column definition in each of the
> affected tables must have a MAX-ACCESS of read-create and the the
> affected rows MUST NOT already exist (in whole or part). If zero
> operands are provided in a rowOp, then the row must be able to be
> created in whole or part using only default values.
> Is there a reason to not allow the operation if the row already exists? I
> think it would be a help in some cases to have the
> "create-only-if-not-exists" functionality. (For example "creating" a row in
> snmpNotifyTable, where an entry may not exists or may exist but have
> RowState of NotInService.) Or is the intent that for those operations we
> should use the traditional SetRequest?
There is indeed a reason for the specified behavior. In multi-mgr
environments it is critical to be able to guarantee a command
generator can create a row (but not modify an existing one).
Otherwise, if two mgrs issue CreateRow requests based on the
same index at the same time, they both may think they succeeded
in creating the row. Thus, CreateRow can only succeed if the row
doesn't exist. And EditRow succeeds only if the row already exists.
In other words, the request names indicate the desired behavior.
> Also in Appendix D, "Known Issues"
> - Do we need a GetBulkRow request that makes use of similar OID
> suppression techniques as defined herein? It might be argued
> this would be the most effective use of OID suppression.
> Yes that would be very desirable!
Noted! I think a future version will probably include this.