[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed row ops requirements
Juergen Schoenwaelder wrote:
> >>>>> Steve Moulton writes:
> Steve> 7a. RowOp requests MUST support creation, deletion and
> Steve> modification semantics as in draft-ietf-eos-snmp-rowops-00.txt.
> Steve> (Whether these operations are specified as new PDUs is not
> Steve> considered in this question.)
> I could not figure out what the EditRow semantics in
> draft-ietf-eos-snmp-rowops-00.txt really are since the elements of
> procedure are just empty. So I can't say whether I agree or disagree.
The idea is that EditRow is allowed to succeed only if the row
already exists (in part or whole). CreateRow only succeeds
if the row doesn't yet exist (in part or whole). We'll be in better
position to determine the elements of procedure once we can agree
upon some basic requirements.
> These two seem to contradict themself.
Yes. Many of the listed requirements
intentionally contradict each other.
Everyone please let us know your
opinions as to which ones you agree with.
> Question: What happens if I implement a command responder which
> supports all row new operations plus the RFC 1905 operations without
> the set operation? The motivation for doing this is that sets on
> arbitrary combinations of objects is way to expensive. If we have row
> operations, then I could get away with doing sets on arbitrary
> objects. Well, I could allow sets on those objects that map to row
> operations. Does it make sense to allow for this, e.g. by returning a
> suitable error code on all sets that do not map to row operations?
I hope the answer to your question is buried somewhere
One of the key issues is whether or not all the new operations
MUST be translatable to conventional SET requests. For example,
must proxy entities be able to translate them, and must current AgentX
master agents be able to translate them into current AgentX PDUS?
It is my belief that new semantics such as
creation and deletion operations may not be translatable
and that a transitition to an EOS network becomes more difficult.
However, without such semantics, then what we are largely left with
is simply newer request formats that do the same thing
as before (but with smaller PDU sizes).
Anyway, I'm thinking that we should add new CreateRow and DeleteRow
requests. Yes, it's difficult to evolve to these, but they seem
to achieve numerous benefits -- especially as we try to make
SNMP viable as a configuration technology.
Also thinking we should add new GetRow and EditRow requests.
These requests MAY be able to be directly translatable to older
Thus, for impls that do not yet support significant abilities
to config the device using SNMP SETs, an EOS network is fairly
easily achievable by simply adding the GetRow and EditRow translation
feature (in the proxy or in the master agent). And for impls that
want to add SNMP configuration operations for the first time, well,
they might as well support the new CreateRow and DeleteRow requests
instead of conventional SETS.
I think a command responder (CR) should be able to support
any combination of conventional and EOS operations. How
they behave maybe depends on whether RowStatus or RowState (or other
similar objects are supported in a table).
RowStatus: conventional SETs work as before. CreateRow behaves
as CreateAndGo, DeleteRow behaves as destroy. EditRow behaves
as conventional SET.
RowState: CreateRow can create a row but not alter existing one.
DeleteRow deletes row. EditRow can modify existing row but not
create new one. Conventional SETs can create a new row if all
specified conditions in the RowState description are satisfied,
and otherwise may edit an existing row. Note that conventional
SETs do not provide safety in multi-mgr environments nor do they
offer other benefits provided by the new rowOps.
There is also the requirement to support random reads (allow
scalar and/or singular table object retrieval along with
row-oriented operations. I guess we should have asked
whether random SETs are also allowed. Anyway, can a CR return
as error code for an unsupported SET, yet support the SetRow
requests? Sure Why not? The extended protocol MIB that Sharon
is devising allows us to indicate which rowOp requests are supported.
And from a conventional SET perspective, everything works as before:
i.e. you never know if a SET will work until you try it!