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

[Joe Clarke <[e-mail]>]

On 10/14/15 23:20, Susan Hares wrote:
> 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.

Sure.

>
> 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.

RESTCONF does do all-or-none, but typically operations apply to one data 
element at a time.  Clients would need to include multiple 
sub-operations for a, say, a PATCH.  So, if I understand correctly, 
there would be burden on the Client that uses RESTCONF and 
multi-messages for a single "transaction" to handle the backout?

Joe

>
> 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
>