Re: Transactional semantics and it's effect on the SMI

On Tuesday 04 June 2002 11:27 am, Steve Waldbusser wrote:

> The purpose of this message is to bring up another requirement for our
> new SMI and to discuss some of the alternatives for meeting this
> requirement.

Steve, I am glad that the issue of transactions is being taken up, 
particularly in the way you suggest - a holistic one including the SMI 
and protocol. I have read through the posting and I may be missing some 
subtile points that cover my concerns, if true, you may want to expand the 
description next time. If these suggestions are incremental to your 
proposal, then consider them as requests for more function :-)

My primary concern is with the definition of the scope of the transaction 
- we need to span PDUs.

An agent is often a reflection of the underlying operational software and 
hardware that it manages. Thinking in terms of varbinds and PDUs is 
helpful from the SNMP perspective but needs to be expanded a bit.

Some transactions will necessarily span PDUs and indeed may span process 
spaces as would be the case when multiple sub-agents are involved. This is 
much more likely to be the case when configuring a large system - large 
here means both number of instances and technologies.  CLIs have evolved 
in managed systems so that interdependencies are dealt with as part of the 
development of each command.  We can not assume, even for a single 
technology, that all elements of a configuration transaction can or should 
fit into a single PDU or part of a single table.  Two technologies where 
this is likely to be the case that come to mind are routing and 
differentiated services.

So, the protocol and SMI level enhancements you suggest, if I understand 
correctly, are helpful, but do not go far enough. I think want something 
that will allow a transaction to have the wider scope that I describe 
above.

You wrote:

> There's another dimension to this. What about other transactions in
> the same PDU. Let's say that ABCD are the names of columns in one
> table and RTSU are columns in another table.

This is one of the reasons I thought that the proposal did not span PDUs 
and we need more context for a transaction at the protocol and/or object 
level. I agree that we may want to have several transactions open on a 
managed device at one time. This becomes more complex if we span PDUs.

Here are some proposals/ideas:

1. We could use your CREATE-TRANSACTION to span tables, or create an 
UBER-TRANSACTION to span tables. 

2. We could use at the protocol level, a CREATE-TRANSACTION that would 
cause the agent to return a handle that the manager would use for all 
subsequent SETs that are to be part of the transaction. We would then need 
a COMPLETE-TRANSACTION that lets the agent know the manager is finished. 
If you think of this as analogous to getting the next available instance 
number common today, this is not too far a stretch. We could even do this 
without too much disrution to the protocol.

3. I like your CREATE-OPTIONAL, it would need to be expanded as well to 
deal with multiple tables.

/jon

-- 
Jon Saperia                         
				
[email protected]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/