Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol

["Susan Hares" <[e-mail]>]

Joe: 

There will be some groups of data model have dependencies between objects.
Some Client interactions will be orthogonal to each other.   If there are
groupings, then the dependencies may leave the I2RS agent and routing system
in an unknown state. 

The "all-or-nothing" is the normal case for NETCONF/RESTCONF. If clients are
based on the Netconf/RESTCONF code base, this will be the simple upward
change. 

The I2RS agent needs to provide notification for error on writing for
priority conflict, and for other errors.   The Stop-on-error would also need
to provide this input. 

Sue 

-----Original Message-----
From: Joe Clarke [mailto:[e-mail]] 
Sent: Tuesday, October 13, 2015 8:56 AM
To: Susan Hares; [e-mail]
Cc: [e-mail]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling
simplification for initial I2RS protocol

On 10/13/15 04:57, Susan Hares wrote:
> Currently the I2RS requirements have error handling having three parts:
>
> 1)"all-or-nothing",
>
> 2)"continue-on-error", and
>
> 3)"stop-on-error".
>
> To provide an easier first step for the I2RS Agent for the first 
> implementation of an I2RS protocol,  the I2RS protocol design team 
> suggests reduce this to the "all-or-nothing" for the initial version.
> Later versions of the I2RS protocol can provide the "continue-on-error"
> or "stop-on-error" error handling.  The earlier decision in the I2RS 
> architecture was to support all 3 error handling pieces.

It seems to me the latter two would be easier to implement as the Client
continues to fire (until not told to do so in the stop-on-error case) and
the Agent wouldn't have to track all operations for rollback.

Is the assumption that most I2RS transactions will have mutual dependencies,
and this is the most common error case?

Joe