Subject: Re: [Netconf] NACM: <edit-config> with mix of authorized & non-auth changes

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Feb 2018 18:56:18 +0000

Hi Jason,

Take a look at <edit-config>'s input parameter called "error-option".  It takes values stop-on-error, continue-on-error, and rollback-on-error.   The default is stop-on-error.

I'm fond of rollback-on-error and, in that case, I'd expect an attempt by the client to edit a node it doesn't have access for to cause the entire request to fail.

Kent

On 2/27/18, 12:41 PM, "Netconf on behalf of Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi all,

From reading the NACM RFC6536 it is pretty clear that a <get-config> response simply has the unauthorized nodes filtered out (no error - even if a node that is unauthorized is specifically requested in the filter).

But I'm not clear on how an <edit-config> is supposed to be handled if the request has a mix of authorized changes (a) and unauthorized changes (b).  The RFC uses the term "protocol operation" in section 3.2.3 which seems to imply that each individual node is evaluated and processed/rejected separately.  But is it the intention that the subset of authorized changes are applied while the unauthorized changes are rejected from within a single <edit-config> ?  Or should the contents of the entire <edit-config> be "atomic" as far as NACM success/failure is concerned (i.e. none of the edits should apply if even just a single part of them is unauthorized) ?

Rgds,
Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 27 Feb 2018 19:56:38 +0000

Thx Kent.

I was wondering about whether the error-option would dictate this behavior but the NACM spec didn't refer to it so I figured it wasn't applicable to my question.

stop-on-error would result in somewhat non-deterministic behavior on this.  The "order" of processing the authorized changes vs the unauthorized changes isn't really defined.

Jason

From: Kent Watsen [mailto:[email-masked]]
Sent: Tuesday, February 27, 2018 1:56 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] NACM: <edit-config> with mix of authorized & non-auth changes

Hi Jason,

Kent

Hi all,

Rgds,
Jason

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Feb 2018 21:46:18 +0000

RFC 6536 uses the "access-denied" error tag, which is defined in RFC 6241, which shows that authorization errors are treated like any other.

Stop-on-error has always had a non-deterministic behavior, IMO, because there is no order of processing for any part of the <edit-config> input document.

Kent

On 2/27/18, 2:56 PM, "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>> wrote:

Thx Kent.

Jason

Hi Jason,

Kent

Hi all,

Rgds,
Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 27 Feb 2018 21:57:06 +0000

Ok - I'll buy it.

rollback-on-error has always been a funny beast IMO.  This error-option is a parameter that applies to a single <edit-config> but sometimes I find conversations occur where people use the term rollback-on-error to talk about what happens during/after a commit.

If a NETCONF server is required to process <edit-config> requests from multiple clients/sessions as a single non-parallelized sequential set of operations  (i.e. completely applying a single edit-config before starting the next one), then rollback-on-error can be implemented by taking a snapshot of the candidate before the edit-config and reverting to that snapshot upon an error.

But if multiple edit-config requests are theoretically allowed to be happening in parallel on a server (e.g. from multiple sessions to a single shared global candidate), then rollback-on-error gets a little more complicated.  In theory it should purely undo only the changes from that one edit-config that contained the error (while leaving changes from the other edit-config in the other session alone).

Rgds,
Jason

From: Kent Watsen [mailto:[email-masked]]
Sent: Tuesday, February 27, 2018 4:46 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] NACM: <edit-config> with mix of authorized & non-auth changes

Kent

Thx Kent.

Jason

From: Kent Watsen [mailto:[email-masked]]
Sent: Tuesday, February 27, 2018 1:56 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] NACM: <edit-config> with mix of authorized & non-auth changes

Hi Jason,

Kent

Hi all,

Rgds,
Jason