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

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Oct 2015 04:57:53 -0400

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.  

Sue Hares  and Jeff Haas

---

From: Joe Clarke <[email-masked]>
Date: Tue, 13 Oct 2015 08:55:53 -0400

On 10/13/15 04:57, Susan Hares wrote:
> 1)“all-or-nothing”,
> 2)“continue-on-error”, and
>
> 3)“stop-on-error”.
>
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Oct 2015 11:57:45 -0400

I can live with this reduction.  It simplifies the agent implementation 
(as it only has to support one instead of three modes).  The increase in 
effort on the client is small.  If we find out that, as was suspected, 
there are performance issues, then we can add back the other error modes.

Yours,
Joel

On 10/13/15 4:57 AM, Susan Hares wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 14 Oct 2015 07:55:44 +0000

Agree to reduce to "all-or-nothing" at current stage. If later we find use cases for the other two modes, they can be added back.

Best regards,
Jie

> -----Original Message-----
> From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, October 13, 2015 11:58 PM
> To: Susan Hares; [email-masked]
> Cc: [email-masked]; 'Alia Atlas'
> Subject: Re: [i2rs] Call for Input from WG: I2RS error handling simplification for
> initial I2RS protocol
> 
> I can live with this reduction.  It simplifies the agent implementation (as it only
> has to support one instead of three modes).  The increase in effort on the
> client is small.  If we find out that, as was suspected, there are performance
> issues, then we can add back the other error modes.
> 
> Yours,
> Joel
> 
> > 1)"all-or-nothing",
> > 2)"continue-on-error", and
> >
> > 3)"stop-on-error".
> >
> > 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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 14 Oct 2015 23:20:14 -0400

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:[email-masked]] 
Sent: Tuesday, October 13, 2015 8:56 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling
simplification for initial I2RS protocol

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

---

From: Joe Clarke <[email-masked]>
Date: Thu, 15 Oct 2015 11:05:37 -0400

> groupings, then the dependencies may leave the I2RS agent and routing system

Sure.

> based on the Netconf/RESTCONF code base, this will be the simple upward

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Oct 2015 11:45:06 -0400

Joe: 

Joe:

Great questions - see below. 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Thursday, October 15, 2015 11:06 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling

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

>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?
 
Yes - multiple sub-operation in RESTCONF requires a PATCH, and the burden is
on the client to handle the backing out of data in RESTCONF.  You have hit
upon the challenge.  The I2RS client is bearing the burden of this back-out
instead of the I2RS agent (Netconf "server" concept).  

Do you think this is reasonable to keep the I2RS agents simple? Will it make
the I2RS clients unworkable? 

> Is the assumption that most I2RS transactions will have mutual
dependencies,

---

From: Joe Clarke <[email-masked]>
Date: Thu, 15 Oct 2015 13:17:03 -0400

> the I2RS clients unworkable?

I can't answer an behalf of all I2RS Client implementors, but it doesn't 
seem like an undue burden.  It's just critical that they understand that 
the burden is upon them.  How is this decision to be communicated?  Will 
the architecture be updated?

I assume that Agent implementors _could_ do the other two error handling 
techniques if they wanted and advertise this to the Client?

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Oct 2015 13:58:08 -0400

Joe: 

Thank you for letting me know the "all-or-nothing" will be workable for you.

The I2RS architecture will be updated to indicate that the initial pass on
error handling for the I2RS client will only be required "all-or-nothing",
but may do "stop-on-error", or "continue-on-error".   My understanding is
that the hello, module library, and other mechanisms in netconf/restconf can
signal this.  

Give me about 24 hours to check my answers on signaling support with the
NETCONF/RESTCONf methodology for indicating in the NETCONF Hello or modules
library with Andy, Kent and other NETCONF/RESTCONF experts. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Thursday, October 15, 2015 1:17 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling

On 10/15/15 11:45, Susan Hares wrote:
> Yes - multiple sub-operation in RESTCONF requires a PATCH, and the 
> burden is on the client to handle the backing out of data in RESTCONF.  
> You have hit upon the challenge.  The I2RS client is bearing the 
> burden of this back-out instead of the I2RS agent (Netconf "server"
concept).
>
> Do you think this is reasonable to keep the I2RS agents simple? Will 
> it make the I2RS clients unworkable?

I can't answer an behalf of all I2RS Client implementors, but it doesn't
seem like an undue burden.  It's just critical that they understand that the
burden is upon them.  How is this decision to be communicated?  Will the
architecture be updated?

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Oct 2015 16:38:39 -0400

In terms of making clear this constraint, I would expect whatever RFC 
describes the protocol to be used for I2RS would indicate that although 
the archtiecture requested the three behaviors, the current protocol 
only supports "all-or-none."  Assuming we can find ways to use NetConf 
or RestConf, I presume that will be an applicability / usage document 
rather than a protocol definition document.

Yours,
Joel

On 10/15/15 1:17 PM, Joe Clarke wrote:
>> burden is

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Oct 2015 16:41:09 -0400

Actually Sue, I would strongly prefer NOT to update the archtiecture.
My primary reason is stability.
My secondary reason is that I believe the working group would still like 
to see the other behaviors, but is compromising on the protocol delivery.

Which is why my email suggested that the protocol document is the right 
place to clearly state the choice.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Oct 2015 17:52:12 -0400

Joel: 
+1 to Joel's comments. 

As always, thank you for clarifying my feeble words,

Sue Hares 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 4:39 PM
To: Joe Clarke; Susan Hares; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling

In terms of making clear this constraint, I would expect whatever RFC
describes the protocol to be used for I2RS would indicate that although the
archtiecture requested the three behaviors, the current protocol only
supports "all-or-none."  Assuming we can find ways to use NetConf or
RestConf, I presume that will be an applicability / usage document rather
than a protocol definition document.

Yours,
Joel

On 10/15/15 1:17 PM, Joe Clarke wrote:
>> burden is on the client to handle the backing out of data in 
>> RESTCONF.  You have hit upon the challenge.  The I2RS client is 
>> bearing the burden of this back-out instead of the I2RS agent 
>> (Netconf "server" concept).
>>
> I can't answer an behalf of all I2RS Client implementors, but it 
> doesn't seem like an undue burden.  It's just critical that they 
> understand that the burden is upon them.  How is this decision to be 
> communicated?  Will the architecture be updated?
>
> I assume that Agent implementors _could_ do the other two error 
> handling techniques if they wanted and advertise this to the Client?
>
> Joe
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Oct 2015 18:44:26 -0400

Joel: 

I OK with this approach as well - because we can note the reduction in the
combined protocol requirements document.   We will eventually get to the
architecture full scope after getting experience.  

Joe - what do you think?  Will this work for you? 

Sue 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 4:41 PM
To: Susan Hares; 'Joe Clarke'; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling

Actually Sue, I would strongly prefer NOT to update the archtiecture.
My primary reason is stability.
My secondary reason is that I believe the working group would still like to
see the other behaviors, but is compromising on the protocol delivery.

Yours,
Joel

On 10/15/15 1:58 PM, Susan Hares wrote:
> The I2RS architecture will be updated to indicate that the initial 
> pass on error handling for the I2RS client will only be required
"all-or-nothing",
> that the hello, module library, and other mechanisms in 
> netconf/restconf can signal this.
>
> Give me about 24 hours to check my answers on signaling support with 
> the NETCONF/RESTCONf methodology for indicating in the NETCONF Hello 
> or modules library with Andy, Kent and other NETCONF/RESTCONF experts.
>
> Sue
>

---

From: Joe Clarke <[email-masked]>
Date: Fri, 16 Oct 2015 08:26:19 -0400

> Joe - what do you think?  Will this work for you?

Yes.  This makes good sense.

Joe