RE: same value operation attributes restriction

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: vrijdag 26 maart 2004 23:42
> To: Wijnen, Bert (Bert)
> Cc: Gilbert Gagnon; Glenn Waters; j.schoenwaelder@iu-bremen.de;
> netconf@ops.ietf.org
> Subject: RE: same value operation attributes restriction
> 
> 
> At 02:28 PM 3/26/2004, Wijnen, Bert (Bert) wrote:
> >Andy, w.r.t. your examples below, you explain (case B) how 
> >difficult it is on the manager site if 3 PDUs need to be used.
> >But if you use case A, does that complexity then not need to
> >be dealth with at the managed device if for exampel an error
> >occurs during the <boo operation="modify"> .... </boo> phase?
> 
> Not if rollback-on-error is used.
> The agent will save the start state and restore it
> if any of the 3 operations fails.  If ignore-error
> or stop-on-error is used, then the manager has to
> closely examine the <rpc-error> response and take
> action accordingly -- this would be the same effort
> whether approach A or B is used.
> 
> 
> >And if so, then why do you think/expect that that is easier on 
> >the managed device?
> 
> It's not easier on the managed device.  Rollback-on-error
> is non-trivial to implement (that's why it's a capability).
> 
So...
- It IS important to make that VERY CLEAR to everyone.
  One of the complaints of SNMP was that WRITE and CREATE support
  was too difficult to implement correctly in an agent.
  So do we evaluate if this is "doable" in a managed device!?
- You say it is a capability. So managers may not assume that the
  facility is available and so in cases where it is not supported
  they would still have to do the complex recovery/correction, no?

> One of the significant reasons that SNMP failed for configuration 
> is the assumption that agents should be dumb and all the transaction
> complexity should fall on the manager.  IMO, the agent needs to 
> provide appropriate transaction capability, even if that's not easy.
> 

Sounds as if it should be mandatory instead of a capability ?

Bert

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>