Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 18:55:47 +0000

Hi Gert,

Please see inline ...

On 05/11/2015 03:53, Gert Grammel wrote:
> Jason,
>
> A synchronous config basically contains two pieces of information in the commit:
> 	1) the intended configuration is valid (i.e. is syntactically correct) and
> 	2) the intended config has been applied
> Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back.
I agree.

> Similarly for asynchronous, however here the information needs to be split into two messages:
> 	1) a commit that the intended config is valid
> 	2) another message when the intended config is fully applied (let's call this 'validated').
> A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached.
I agree.

>
> The real problem is what you called in another email  'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation?
Yes, I agree that handling rollback could be a problem in this scenario, 
and hence I would propose that the behaviour in such a scenario is 
explicitly documented as being undefined in whatever solution is agreed 
upon :-)

Otherwise assuming that all requests are strictly synchronous or 
asynchronous then I think that we should be OK with the following two 
rules on the server:
1) All edit-config requests must strictly be processed in order.
2) You cannot tell a client that a request has been full applied unless 
all previous requests specifying rollback-on-error semantics with any 
overlapping nodes with the current request have either be applied or 
aborted (i.e. rolled back)

Thanks,
Rob

>
> Gert
>
>
>
>
> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Sterne, Jason (Jason)
> Sent: 03 November 2015 08:24
> To: [email-masked]
> Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
>
> Hi all,
>
> The term "rollback on error" (and other error options) has been used during these discussions around the opstate requirements.
>
> That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty close) and IMO it (today) has nothing to do with "applied" config.  It is an error option that has the scope of the contents of a single edit-config request and how those contents get applied (all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running DS (intended) if the <target> is <running/>.
>
> I think we need to clarify this "all or nothing" concept and how it is related to "applied" config.  We may also want to use slightly different terminology so we don't get confused with today's meaning of rollback-on-error.
>
> There are a few transitions to consider when editing a config and applying it to a device (I'll give the example of using the candidate DS):
> (A) config changes   ---> candidate DS   (<edit-config>)
> (B) candidate DS  ----> running (intended)  (<commit>)
> (C) intended ----> applied  (internal processed in the device)
>
> Today rollback-on-error is only applicable to transition (A).
>
> Transition (B) does have all-or-nothing properties (as described in RFC6241) but that isn't related to "rollback-on-error".
>
> Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ?
>
> Would we then remove it all from intended as well ?
>
> I'm not sure how that would work for an async/hybrid (read "real") system.  We've already done an "ack" back to the client before transition (C) so the client may have already sent some additional new config that depends on the previous edit.  That would mean that new config isn't valid.
>
> Jason
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 18:57:31 +0000

Hi Jason,

Picking up this slightly old thread.

The "rollback on error" definition that I added I took directly from 
RFC6241, so it's good that they look similar.  The intention is that the 
NETCONF "rollback-on-error" capability is a valid implementation of this 
requirement :-)

I think that the  rollback-on-error capability defined in RFC6241 can 
also be applied to the running datastore.  Certainly, the example quoted 
is in the context of the edit-config request on the running-config 
datastore, and the RFC description of this feature doesn't appear to 
limit it to the candidate datastore in any way.

Thanks,
Rob

---

From: Gert Grammel <[email-masked]>
Date: Mon, 21 Dec 2015 20:17:03 +0000

Hi Rob,

Seems we are pretty close with our understanding, so snipping the only discussion point left, with further comments:

Gert

<snip>
Gert> sadly, we can’t roll time back. So the best option is indeed to document the issue and move on to improve things

  1.  All edit-config requests must strictly be processed in order.

Gert> yes, although there are corner cases we need to hash out.  I.e. a client may set  a leaf to <x> followed by setting it to <y>. Then a server may skip setting it to <x>, because it is anyhow overwritten by <y>.

Gert> with “have bee full applied” you meant a state that I tentatively named ‘validated’  in my earlier email?  I am a bit sensitive to naming here because of those ‘cheating synchronous nodes’ would return ‘applied’ without actually doing so in full. It would be great if we could quickly converge on some naming convention to remove ambiguity.
The rule holds true but I don’t see a dependency on “rollback-on-error” semantics. In my view it is applicable also in cases of "continue-on-error” and “stop-on-error” in the sense that unless any error has been reported, the client still needs to wait for the ‘validated’ state before it can reliably assume the config was applied.

<snip>

From: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Monday 21 December 2015 19:55
To: Gert Grammel <[email-masked]<mailto:[email-masked]>>, Jason Sterne <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi Gert,

Please see inline ...

Thanks,
Rob

Gert

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Sterne, Jason (Jason)
Sent: 03 November 2015 08:24
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi all,

Jason

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod
.

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Dec 2015 20:31:38 +0000

Hi Gert,

On 21/12/2015 20:17, Gert Grammel wrote:
> Hi Rob,
>
> Seems we are pretty close with our understanding, so snipping the only 
> discussion point left, with further comments:
>
> Gert
>
>
> <snip>
>
>     The real problem is what you called in another email  'hybrid' or
>     cheating-synchronous implementations. This leads to a situation
>     where the client is made to believe the intended config is
>     applied, but the server still didn't apply it yet. Take the case
>     where the server runs into trouble after the synchronous-commit
>     (which lets the client believe that the intended config is
>     applied) and decides to roll-back. From a client perspective this
>     would look like a node randomly losing its committed
>     configuration. There is tons of code required on the client side
>     to cope with that situation. So what was the purpose of
>     implementing it that way in the first place - instead of just
>     applying an asynchronous implementation?
>
> Gert> sadly, we can’t roll time back. So the best option is indeed to 
> document the issue and move on to improve things
>
> Gert> yes, although there are corner cases we need to hash out.  I.e. 
> a client may set  a leaf to <x> followed by setting it to <y>. Then a 
> server may skip setting it to <x>, because it is anyhow overwritten by 
> <y>.

Yes, it might, but from a correctness point of view it will need to able 
to fail the subsequent request to set the value to <y> and hence set it 
to <x> instead.

> Gert> with “have bee full applied” you meant a state that I 
> tentatively named ‘validated’  in my earlier email?  I am a bit 
> sensitive to naming here because of those ‘cheating synchronous nodes’ 
> would return ‘applied’ without actually doing so in full. It would be 
> great if we could quickly converge on some naming convention to remove 
> ambiguity.

Yes, it means the same state as your 'validated'.  I basically just mean 
that the synchronous operation has completed (as per the definition of 
'Synchronous Configuration Operation' defined in 
draft-ietf-netmod-opstate-reqs-01).

> The rule holds true but I don’t see a dependency on 
> “rollback-on-error” semantics. In my view it is applicable also in 
> cases of "continue-on-error” and “stop-on-error” in the sense that 
> unless any error has been reported, the client still needs to wait for 
> the ‘validated’ state before it can reliably assume the config was 
> applied.
I would see that a "continue-on-error" configuration operation is 
processed best effort.  I.e. even if applying one of more config nodes 
failed to be applied, the rest of the configuration contained in a best 
effort operation would always be applied.  As such subsequent operations 
would not need to wait for a best effort request to complete first 
before they can complete.

Thanks,
Rob

>
> <snip>
>
> From: Robert Wilton <[email-masked] <mailto:[email-masked]>>
> To: Gert Grammel <[email-masked] <mailto:[email-masked]>>, 
> Jason Sterne <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Any error that would affect the config before the commit could be
>     rolled back to the old config and a suitable notification sent to
>     the client. After the commit, there is no roll-back.
>
> I agree.
>
>     A rollback can happen before the intended config is fully applied
>     i.e. before the 'validated' state is reached.
>
> I agree.
>
>
>     The real problem is what you called in another email  'hybrid' or
>     cheating-synchronous implementations. This leads to a situation
>     where the client is made to believe the intended config is
>     applied, but the server still didn't apply it yet. Take the case
>     where the server runs into trouble after the synchronous-commit
>     (which lets the client believe that the intended config is
>     applied) and decides to roll-back. From a client perspective this
>     would look like a node randomly losing its committed
>     configuration. There is tons of code required on the client side
>     to cope with that situation. So what was the purpose of
>     implementing it that way in the first place - instead of just
>     applying an asynchronous implementation?
>
>     To: [email-masked] <mailto:[email-masked]>
>     The term "rollback on error" (and other error options) has been
>     used during these discussions around the opstate requirements.
>
>     That term already has some meaning in RFC6241 (or at least
>     rollback-on-error does and that is pretty close) and IMO it
>     (today) has nothing to do with "applied" config.  It is an error
>     option that has the scope of the contents of a single edit-config
>     request and how those contents get applied (all or nothing) to the
>     candidate DS (which is neither intended nor applied config) or to
>     the running DS (intended) if the <target> is <running/>.
>
>     I think we need to clarify this "all or nothing" concept and how
>     it is related to "applied" config.  We may also want to use
>     slightly different terminology so we don't get confused with
>     today's meaning of rollback-on-error.
>
>     There are a few transitions to consider when editing a config and
>     applying it to a device (I'll give the example of using the
>     candidate DS):
>     Transition (B) does have all-or-nothing properties (as described
>     in RFC6241) but that isn't related to "rollback-on-error".
>
>     Is there some intention in the opstate requirements to add some
>     sort of all-or-nothing behavior to transition (C) ?  i.e. if some
>     part of an edit fails during the transition from intended->applied
>     we should "rollback" the other parts that may have already been
>     applied ?
>
>     I'm not sure how that would work for an async/hybrid (read "real")
>     system.  We've already done an "ack" back to the client before
>     transition (C) so the client may have already sent some additional
>     new config that depends on the previous edit.  That would mean
>     that new config isn't valid.
>
>     Jason
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Dec 2015 12:37:40 -0800

On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton <[email-masked]
> wrote:

> cheating-synchronous implementations. This leads to a situation where the
> client is made to believe the intended config is applied, but the server
> still didn't apply it yet. Take the case where the server runs into trouble
> after the synchronous-commit (which lets the client believe that the
> intended config is applied) and decides to roll-back. From a client
> perspective this would look like a node randomly losing its committed
> configuration. There is tons of code required on the client side to cope
> with that situation. So what was the purpose of implementing it that way in
> the first place - instead of just applying an asynchronous implementation?
>
> Gert> yes, although there are corner cases we need to hash out.  I.e. a
> client may set  a leaf to <x> followed by setting it to <y>. Then a server
> may skip setting it to <x>, because it is anyhow overwritten by <y>.
>
>
> to fail the subsequent request to set the value to <y> and hence set it to
> <x> instead.
>
>

What does "processed in order" mean?
NETCONF has a requirement that <rpc> requests on a specific session
are processed in the order received.  There is no such requirement
across multiple sessions doing edits at once.

Andy

> Gert> with “have bee full applied” you meant a state that I tentatively
> named ‘validated’  in my earlier email?  I am a bit sensitive to naming
> here because of those ‘cheating synchronous nodes’ would return ‘applied’
> without actually doing so in full. It would be great if we could quickly
> converge on some naming convention to remove ambiguity.
>
>
> The rule holds true but I don’t see a dependency on “rollback-on-error”
> semantics. In my view it is applicable also in cases of "continue-on-error”
> and “stop-on-error” in the sense that unless any error has been reported,
> the client still needs to wait for the ‘validated’ state before it can
> reliably assume the config was applied.
>
> would not need to wait for a best effort request to complete first before
> they can complete.
>
> Thanks,
> Rob
>
>
>
> <snip>
>
> From: Robert Wilton <[email-masked]>
> To: Gert Grammel < <[email-masked]>[email-masked]>, Jason
> Sterne <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Any error that would affect the config before the commit could be rolled
> back to the old config and a suitable notification sent to the client.
> After the commit, there is no roll-back.
>
> I agree.
>
> cheating-synchronous implementations. This leads to a situation where the
> client is made to believe the intended config is applied, but the server
> still didn't apply it yet. Take the case where the server runs into trouble
> after the synchronous-commit (which lets the client believe that the
> intended config is applied) and decides to roll-back. From a client
> perspective this would look like a node randomly losing its committed
> configuration. There is tons of code required on the client side to cope
> with that situation. So what was the purpose of implementing it that way in
> the first place - instead of just applying an asynchronous implementation?
>
> From: netmod [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Sterne, Jason (Jason)
> The term "rollback on error" (and other error options) has been used
> during these discussions around the opstate requirements.
>
> rollback-on-error does and that is pretty close) and IMO it (today) has
> nothing to do with "applied" config.  It is an error option that has the
> scope of the contents of a single edit-config request and how those
> contents get applied (all or nothing) to the candidate DS (which is neither
> intended nor applied config) or to the running DS (intended) if the
> <target> is <running/>.
>
> I think we need to clarify this "all or nothing" concept and how it is
> related to "applied" config.  We may also want to use slightly different
> terminology so we don't get confused with today's meaning of
> rollback-on-error.
>
> There are a few transitions to consider when editing a config and applying
> it to a device (I'll give the example of using the candidate DS):
> Transition (B) does have all-or-nothing properties (as described in
> RFC6241) but that isn't related to "rollback-on-error".
>
> Is there some intention in the opstate requirements to add some sort of
> all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit
> fails during the transition from intended->applied we should "rollback" the
> other parts that may have already been applied ?
>
> system.  We've already done an "ack" back to the client before transition
> (C) so the client may have already sent some additional new config that
> depends on the previous edit.  That would mean that new config isn't valid.
>
> Jason
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Dec 2015 21:37:17 +0000

HI Andy,

On 22/12/2015 20:37, Andy Bierman wrote:
>
>
> On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Gert,
>
>>     Seems we are pretty close with our understanding, so snipping the
>>     only discussion point left, with further comments:
>>
>>     Gert
>>
>>
>>     <snip>
>>
>>         The real problem is what you called in another
>>         email  'hybrid' or cheating-synchronous implementations. This
>>         leads to a situation where the client is made to believe the
>>         intended config is applied, but the server still didn't apply
>>         it yet. Take the case where the server runs into trouble
>>         after the synchronous-commit (which lets the client believe
>>         that the intended config is applied) and decides to
>>         roll-back. From a client perspective this would look like a
>>         node randomly losing its committed configuration. There is
>>         tons of code required on the client side to cope with that
>>         situation. So what was the purpose of implementing it that
>>         way in the first place - instead of just applying an
>>         asynchronous implementation?
>>
>>     Gert> sadly, we can’t roll time back. So the best option is
>>     indeed to document the issue and move on to improve things
>>
>>     Gert> yes, although there are corner cases we need to hash out. 
>>     I.e. a client may set  a leaf to <x> followed by setting it to
>>     <y>. Then a server may skip setting it to <x>, because it is
>>     anyhow overwritten by <y>.
>
>     Yes, it might, but from a correctness point of view it will need
>     to able to fail the subsequent request to set the value to <y> and
>     hence set it to <x> instead.
>
>
>
>

Thanks for the clarification.  I hope that whatever NETCONF does here 
should be a sufficient solution.  I.e. as long as the error handling 
semantics can be well defined with the request ordering just defined 
relative to particular sessions then that is fine with me.  I think that 
it would only be necessary to refine/modify the NETCONF behaviour if it 
is shown to be insufficiently specified to be robustly implementable, 
and I'm not aware of that being the case.

Otherwise, I think that this discussion can probably be deferred until 
we are discussing the specific solution draft.

As an aside - I also see this as another example where it would be 
useful to define the common semantics and expectations of a YANG 
manageability protocol outside of NETCONF and RESTCONF.

Thanks,
Rob

>>     sensitive to naming here because of those ‘cheating synchronous
>>     nodes’ would return ‘applied’ without actually doing so in full.
>>     It would be great if we could quickly converge on some naming
>>     convention to remove ambiguity.
>
>     Yes, it means the same state as your 'validated'.  I basically
>     just mean that the synchronous operation has completed (as per the
>     definition of 'Synchronous Configuration Operation' defined in
>>     “rollback-on-error” semantics. In my view it is applicable also
>>     in cases of "continue-on-error” and “stop-on-error” in the sense
>>     that unless any error has been reported, the client still needs
>>     to wait for the ‘validated’ state before it can reliably assume
>>     the config was applied.
>     processed best effort.  I.e. even if applying one of more config
>     nodes failed to be applied, the rest of the configuration
>     contained in a best effort operation would always be applied.  As
>     such subsequent operations would not need to wait for a best
>     effort request to complete first before they can complete.
>
>     Thanks,
>     Rob
>
>
>>
>>     <snip>
>>
>>     To: Gert Grammel <[email-masked]
>>     <mailto:[email-masked]>>, Jason Sterne
>>     <[email-masked]
>>         Any error that would affect the config before the commit
>>         could be rolled back to the old config and a suitable
>>         notification sent to the client. After the commit, there is
>>         no roll-back.
>>
>>     I agree.
>>
>>         A rollback can happen before the intended config is fully
>>         applied i.e. before the 'validated' state is reached.
>>
>>     I agree.
>>
>>
>>         The real problem is what you called in another
>>         email  'hybrid' or cheating-synchronous implementations. This
>>         leads to a situation where the client is made to believe the
>>         intended config is applied, but the server still didn't apply
>>         it yet. Take the case where the server runs into trouble
>>         after the synchronous-commit (which lets the client believe
>>         that the intended config is applied) and decides to
>>         roll-back. From a client perspective this would look like a
>>         node randomly losing its committed configuration. There is
>>         tons of code required on the client side to cope with that
>>         situation. So what was the purpose of implementing it that
>>         way in the first place - instead of just applying an
>>         asynchronous implementation?
>>
>>         The term "rollback on error" (and other error options) has
>>         been used during these discussions around the opstate
>>         requirements.
>>
>>         (today) has nothing to do with "applied" config.  It is an
>>         error option that has the scope of the contents of a single
>>         edit-config request and how those contents get applied (all
>>         or nothing) to the candidate DS (which is neither intended
>>         nor applied config) or to the running DS (intended) if the
>>         <target> is <running/>.
>>
>>         I think we need to clarify this "all or nothing" concept and
>>         how it is related to "applied" config.  We may also want to
>>         use slightly different terminology so we don't get confused
>>         with today's meaning of rollback-on-error.
>>
>>         There are a few transitions to consider when editing a config
>>         and applying it to a device (I'll give the example of using
>>         the candidate DS):
>>         Transition (B) does have all-or-nothing properties (as
>>         described in RFC6241) but that isn't related to
>>         "rollback-on-error".
>>
>>         Is there some intention in the opstate requirements to add
>>         some sort of all-or-nothing behavior to transition (C)
>>         ?  i.e. if some part of an edit fails during the transition
>>         from intended->applied we should "rollback" the other parts
>>         that may have already been applied ?
>>
>>         I'm not sure how that would work for an async/hybrid (read
>>         "real") system.  We've already done an "ack" back to the
>>         client before transition (C) so the client may have already
>>         sent some additional new config that depends on the previous
>>         edit.  That would mean that new config isn't valid.
>>
>>         Jason
>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Dec 2015 02:41:34 +0000

[As a contributor]

Hi Robert, I want to go back to Jason’s original questions.  I think we’re aligned on this, but please check my answers below.  

Quoting Jason’s original text now:

>Is there some intention in the opstate requirements to add some sort
>of all-or-nothing behavior to transition (C)?

Yes

>i.e. if some part of
>an edit fails during the transition from intended->applied we should
>"rollback" the other parts that may have already been applied ?

Yes

>Would we then remove it all from intended as well ?

IMO, yes.  This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.

>I'm not sure how that would work for an async/hybrid (read "real”)
>new config that depends on the previous edit.  That would mean that
>new config isn't valid.

I’m not a fan on the “hybrid” term, but in thinking about legacy or existing NETCONF servers, I think that this is a non-issue as the server wouldn’t advertise support for Rollback on Error in the first place.

Kent

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Dec 2015 08:28:41 +0000

Hi Kent,

Yes, I think that we are in agreement.

I've one further comment inline below ...

> I’m not a fan on the “hybrid” term, but in thinking about legacy or existing NETCONF servers, I think that this is a non-issue as the server wouldn’t advertise support for Rollback on Error in the…
I agree that "hybrid" probably isn't a good term.

It is probably worth noting that NETCONF already defines a 
rollback-on-error optional capability, but that shouldn't be a problem 
because I think that we only need to concern ourselves with servers that 
express support for an explicit sync or async capability.

Thanks,
Rob

---

From: Gert Grammel <[email-masked]>
Date: Wed, 23 Dec 2015 10:24:08 +0000

Rob, Kent,

Adding to Rob’s comments:

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi Kent,

Is there some intention in the opstate requirements to add some sort
of all-or-nothing behavior to transition (C)?
Yes
+1 (if rollback-on-error has been requested)

i.e. if some part of
an edit fails during the transition from intended->applied we should
"rollback" the other parts that may have already been applied ?
Yes
+1 (if rollback-on-error has been requested)

Would we then remove it all from intended as well ?
IMO, yes.  This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.
IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can’t apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, …
In other words:

  1.  the client shall not touch the applied config directly,
  2.  the server shall not touch the intended config,
  3.  it’s up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, …)
  4.  Once applied, the server notifies the client about success or failure to do so

+1 in fact it’s a "cheating synchronous” behaviour, probably not the best term either. Let’s find a better term we can agree upon.

+1

Thanks,
Rob

Kent

On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Jason,

Thanks,
Rob

Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Dec 2015 11:45:23 +0100

It seems message quoting is all messed up here (both in mutt and
thunderbird). I can't really follow anymore from this message who said
what and who agrees with whom on what.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Dec 2015 21:24:57 +0000

Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:
> From: netmod <[email-masked] 
> <mailto:[email-masked]>> on behalf of Robert Wilton 
> <[email-masked] <mailto:[email-masked]>>
> To: Kent Watsen <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     Hi Robert, I want to go back to Jason’s original questions.  I
>     think we’re aligned on this, but please check my answers below.
>
>         some sort
>     IMO, yes.  This is more easily understood when thinking about
>     Synchronous Configuration Operations (defined in opstate-reqs),
>     but I believe that it equally applies to Asynchronous
>     Configuration Operations, so long as the client explicitly ops-in
>     for the behavior.
>
> IMO no. The intended config is imposed by the client to the server and 
> other than performing some syntax check, the server has no choice to 
> accept it as-is. If the server can’t apply the intended config, 
> obviously the mismatch between intended and applied config needs to be 
> notified. As a result, it is up to the client to decide what to do. 
> Actions can vary according to the situation naming a few: 1) retry 
> intended config, 2) retry intended config with continue-on-error, 3) 
> re-apply the previous intended config, …
> In other words:
>
>  3. it’s up to the server to align the intended with the applied
>     config in a way requested by the client (i.e. rollback-on-error, …)
I think that it cleaner just to fail and roll back the entire request 
(both intended and applied), i.e. effectively implementing default 
transaction semantics.  The client still has full control as to what to 
do after the failure has occurred.  I'm not sure how leaving it in 
intended config would pragmatically work with subsequent requests that 
may have been queued up.

Thanks,
Rob

---

From: Gert Grammel <[email-masked]>
Date: Mon, 28 Dec 2015 17:40:42 +0000

Rob,

>From a client perspective there should be no difference in the intended state behavior depending on error conditions, if continue-on-error leaves the intended state, a rollback-on-error should keep it as well. Moreover, a client reaction on a unsuccessful application of intended state could be to a) re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those actions would not require any change of intended state.
It shouldn't be the server to decide what the intended state is supposed to be or hoe long it should last.

Gert

Sent from my Apple ][

On 23 Dec 2015, at 22:25, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gert,

Adding to Rob's comments:

From: netmod <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> on behalf of Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi Kent,

Hi Robert, I want to go back to Jason's original questions.  I think we're aligned on this, but please check my answers below.

Quoting Jason's original text now:

i.e. if some part of

Would we then remove it all from intended as well ?
IMO, yes.  This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.
IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can't apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, ...
In other words:

  1.  the client shall not touch the applied config directly,
  2.  the server shall not touch the intended config,
  3.  it's up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, ...)
  4.  Once applied, the server notifies the client about success or failure to do so

I think that it cleaner just to fail and roll back the entire request (both intended and applied), i.e. effectively implementing default transaction semantics.  The client still has full control as to what to do after the failure has occurred.  I'm not sure how leaving it in intended config would pragmatically work with subsequent requests that may have been queued up.

Thanks,
Rob