Subject: [Netconf] :candidate, :writable-running and RESTCONF edits

From: "Jonathan Hansford" <[email-masked]>
Date: Thu, 22 Dec 2016 12:12:30 -0000

draft-ietf-netconf-restconf-18, page 13 states "If the NETCONF server
supports :writable-running, all edits to configuration nodes in
{+restconf}/data are performed in the running configuration datastore.
Otherwise, if the device supports :candidate, all edits to configuration
nodes in {+restconf}/data are performed in the candidate configuration
datastore."

I have been reading through the mail archive on the relationship between
:writable-running and :candidate (see excerpts below) and my understanding
is as follows:

For a NETCONF client to be able to update the configuration of a server, the
server must support :writable-running and/or :candidate.

A NETCONF server can support both :writable-running and :candidate, indeed
there appear to be some in the wild that do, but there is a measure of
unease about this, with the suggestion by some the combination should be
deprecated.

Based on the text from the draft (above) it would appear that, should a
NETCONF server support both capabilities, all RESTCONF edits should be
performed in the running configuration datastore. Is that considered the
lesser of two evils, the other being that all RESTCONF edits should be
performed in the candidate configuration datastore, or was the possibility
overlooked? My gut feel is that it would be safer to use the candidate
configuration datastore and that the two paragraphs in the draft should be
the other way around, i.e. "If the NETCONF server supports :candidate, all
edits to configuration nodes in {+restconf}/data are performed in the
candidate configuration datastore. Otherwise, if the device supports
:writable-running, all edits to configuration nodes in {+restconf}/data are
performed in the running configuration datastore."

Jonathan

---

 <https://www.ietf.org/mail-archive/web/netconf/current/msg00005.html> "Re:
NETCONF modelled in UML" Andy Bierman (Jun 01 2004) states: "We . thought we
should keep the #candidate and #writable-running capabilities independent.
maybe we should make these capabilities mutually exclusive."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03915.html>
"[Netconf] partial-lock feedback" Phil Shafer (Nov 13 2008) states: "There's
some logic that says the intersection of boxes with :writable-running and
:candidate is (or should be) nil."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03918.html> "Re:
[Netconf] partial-lock feedback" Balazs Lengyel (Nov 17 2008) states: "It is
not stated anywhere that you can't have candidate and writable-running
together."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03960.html>
"[Netconf] :candidate vs :writable-running" Tomasz Mikolajczyk (Nov 28
2008), quotes from http://www.netconfcentral.com/netconf_docs that: "Agent
platforms which support the :candidate capability usually do not also
support the :writable-running  capability, since mixing direct edits to
<running/>  would defeat the purpose of using this scratchpad database to
collect and validate changes before applying them." This text persists,
though "Agent platforms" has been replaced with "Server platforms".

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03985.html> "Re:
[Netconf] :candidate vs :writable-running" Martin Bjorklund (Dec 01 2008)
states: "I don't know about others, but I do know that many (most?) of our
customers have both :candidate and :writable-running.  By having both, you
give the choice to the client application - either make sure you're alone
and work with the candidate or edit running directly. Some changes might be
easier to just edit to running."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03995.html> "Re:
[Netconf] lock/unlock on candidate" Martin Bjorklund (Dec 01 2008) states:
"This is only an issue if the box supports :candidate and
:writable-running."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04436.html> "Re:
[Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Kent Watsen
(Mar 18 2009) states: "can devices advertize both :candidate and
:writable-running?  - aren't those capabilities mutually exclusive?"

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04437.html> "Re:
[Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Martin
Bjorklund (Mar 18 2009) states: "There's nothing in 4741 that says that they
are mutually exclusive. And I don't think they should be.  Some devices
already support this combination."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04582.html> "Re:
[Netconf] :writable-running" WashamFan (May 11 2009) states: "Given session
A with :candidate and session B with :writable-running, it is beneficial for
session A to lock both <candidate> and <running> for consistency."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04822.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25
2009) states: "every agent MUST have exactly 1 database that can be the
target of an <edit-config> operation. (Writing to both <candidate> and
<running> does not work!) therefore the agent MUST support the :candidate
OR: writable-running capabilities, but not both"

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04823.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Phil Shafer (Jul 25
2009) states: "I think Martin's code support this (both)."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04826.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul
25 2009) states: "Yes it does.  I agree that other combinations are more
useful, but also this combination works. If you can copy from candidate to
url X, and from url X to running, why not copy from candidate to running
directly?  (and IMO it means just that).  It only works if you have a
candidate AND :writable-running of course."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04828.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25
2009) states: "I think the standard is poorly specified in this entire
area."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04832.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul
26 2009) states: "<commit> has more parameters than <copy-config>, so I
think it must be kept.  Also, you cannot copy-config to running unless
:writable-running is advertised, so <commit> is needed."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04860.html>
"[Netconf] :writable-running and :candidate" Andy Bierman (Aug 01 2009)
states: "I asked (in email) how the :candidate and :writable-running
capabilities can possibly be supported on the same agent. I never got an
answer. I do not understand how the candidate database stays in synch with
the running database if user B can write to running while user A has the
candidate locked.  Also what happens to the edits made by user A when user B
issues a <commit>? Are the changes just made to running undone (they were
not in the candidate, so they must be undone, right?) Is this part of the
intended database architecture or not? And if user A does a copy-config from
a locked candidate to running? That is allowed of course."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04875.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Andy Bierman (Aug 03
2009) states: "IMO, :candidate and :writable-running do not work together.
They almost work together, and only go horribly wrong sometimes.  If that's
good enough for the NETCONF database architecture, then I guess there is
nothing to fix."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04961.html> "Re:
[Netconf] :writable-running and :candidate" Phil Shafer (Aug 08 2009), in
reply to Andy Bierman's previous email comment "I asked (in email) how the
:candidate and :writable-running capabilities can possibly be supported on
the same agent. I never got an answer.", states: "I believe I answered you,
saying that tail-f's sw does this."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04964.html> "Re:
[Netconf] :writable-running and :candidate" Andy Bierman (Aug 08 2009)
states: "I asked for clarifications on the standard, for specific
corner-cases that IMO indicate that this combination is not supported by the
standard. The thread reached a conclusion that even though any changes made
to running will get wiped-out as soon as the candidate is committed, this is
how the standard is intended to work. I can't imagine that an operator or
NMS developer using :writable-running would reach the same conclusion, but
that's their problem -- not an IETF standards problem, right?"

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04988.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Phil Shafer (Aug 10 2009)
states: "I don't support :writable-running, just :candidate, and the
interaction between the two isn't clear.  Martin, how does this work on your
sw?"

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04999.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Martin Bjorklund (Aug 11
2009) states: "There is no magic going on just because the box is configured
to use both :candidate and :writable-running.  Each operation behaves the
same regardless of the other capabilities.  So <discard-changes> resets
candidate to the contents of running, and <commit> replaces running with the
contents of candidate. I agree that it is a burden on the client software to
support all different combinations of (startup, writable-running,
candidate), and a server developer that has a choice should carefully
consider which combination to implement."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg05005.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Juergen Schoenwaelder
(Aug 11 2009) states: "The candidate design does not work with
:writeable-running unless we find a more precise definition how to determine
whether candidate is in a "good shape" or not."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg07289.html> "Re:
[Netconf] NACM issue?" Martin Bjorklund (Jan 11 2012) states ".only if
:writable-running and :candidate is advertised at the same time, and I think
we have agreed that this is a Bad Idea."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg08275.html> "Re:
[Netconf] The <running> configuration datastore and :writable-running"
Juergen Schoenwaelder (Aug 08 2013) states: "Implementing NETCONF read-only
has obviously little value for real configuration management. The reason why
we have :writable-running and :candidate is that some major vendors use very
different models when it comes to making configuration changes and as such
you will see implementations that either announce :writable-running or
:candidate or :writable-running and :candidate together."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg08276.html> "Re:
[Netconf] The <running> configuration datastore and :writable-running" Andy
Bierman (Aug 08 2013) states: ":candidate and :writable-running together
should be considered deprecated. This is a degenerate use-case for
concurrent transactions.  The WG should standardize this properly at some
point in the future, so clients can use a predictable standard transaction
model."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg11468.html> "Re:
[Netconf] <lock> in a server that supports both writable-running and
candidate" Andy Bierman (Jul 14 2016) states: "The reason nobody implements
:candidate and :writable-running together is because there is no way to
synch the candidate if running has been changed underneath it."

 <https://www.ietf.org/mail-archive/web/netconf/current/msg11473.html> "Re:
[Netconf] <lock> in a server that supports both writable-running and
candidate" Sterne, Jason (Nokia - CA) (Jul 14 2016) states: "Nokia SR OS
supports both writable-running and candidate.  And yes it is complex to
manage.  The two datastores can't be simply treated independently and some
locking/coherency mechanisms are needed between them."

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Dec 2016 11:27:20 -0800

Hi,

On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford <[email-masked]>
wrote:

> draft-ietf-netconf-restconf-18, page 13 states “If the NETCONF server
> {+restconf}/data are performed in the running configuration datastore…
> datastore.”
> For a NETCONF client to be able to update the configuration of a server,
> the server must support :writable-running and/or :candidate.
>
> the other way around, i.e. “If the NETCONF server supports :candidate, all
> candidate configuration datastore… Otherwise, if the device supports
> performed in the running configuration datastore.”
>
>
>

This seems OK, but we do not support candidate and running as targets at
the same time,
so I do not know how it impacts the implementation to add this constraint.

I do not agree that the strict text in RFC 6241 actually supports this
editing mode.
If it does, then following the spec would lead to an implementation where
the candidate would clobber edits made in running.  There is no text that
seems
to support automatic update of candidate after the edit to running. There
is certainly
no text that describes how edit conflicts in candidate are resolved.

> Jonathan

Andy

> ---
>
>
>
> "Re: NETCONF modelled in UML"
> <https://www.ietf.org/mail-archive/web/netconf/current/msg00005.html>
> Andy Bierman (Jun 01 2004) states: “We … thought we should keep the
> #candidate and #writable-running capabilities independent… maybe we should
> make these capabilities mutually exclusive.”
>
>
>
> "[Netconf] partial-lock feedback"
> Phil Shafer (Nov 13 2008) states: “There's some logic that says the
> intersection of boxes with :writable-running and :candidate is (or should
> be) nil.”
>
>
>
> "Re: [Netconf] partial-lock feedback"
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03918.html>
> Balazs Lengyel (Nov 17 2008) states: “It is not stated anywhere that you
> can't have candidate and writable-running together.”
>
>
>
> “[Netconf] :candidate vs :writable-running”
> Tomasz Mikolajczyk (Nov 28 2008), quotes from
> http://www.netconfcentral.com/netconf_docs that: “Agent platforms which
> support the :candidate capability usually do not also support the
> :writable-running  capability, since mixing direct edits to <running/>
> would defeat the purpose of using this scratchpad database to collect and
> validate changes before applying them.” This text persists, though “Agent
> platforms” has been replaced with “Server platforms”.
>
>
>
> “Re: [Netconf] :candidate vs :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03985.html>
> Martin Bjorklund (Dec 01 2008) states: “I don't know about others, but I do
> know that many (most?) of our customers have both :candidate and
> :writable-running.  By having both, you give the choice to the client
> application - either make sure you're alone and work with the candidate or
> edit running directly. Some changes might be easier to just edit to
> running.”
>
>
>
> “Re: [Netconf] lock/unlock on candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03995.html>
> Martin Bjorklund (Dec 01 2008) states: “This is only an issue if the box
> supports :candidate and :writable-running.”
>
>
>
> “Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04436.html>
> Kent Watsen (Mar 18 2009) states: “can devices advertize both :candidate
> and :writable-running?  - aren't those capabilities mutually exclusive?”
>
>
>
> “Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04437.html>
> Martin Bjorklund (Mar 18 2009) states: “There's nothing in 4741 that says
> that they are mutually exclusive. And I don't think they should be.  Some
> devices already support this combination.”
>
>
>
> “Re: [Netconf] :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04582.html>
> WashamFan (May 11 2009) states: “Given session A with :candidate and
> session B with :writable-running, it is beneficial for session A to lock
> both <candidate> and <running> for consistency.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04822.html>
> Andy Bierman (Jul 25 2009) states: “every agent MUST have exactly 1
> database that can be the target of an <edit-config> operation. (Writing to
> both <candidate> and <running> does not work!) therefore the agent MUST
> support the :candidate OR: writable-running capabilities, but not both”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04823.html>
> Phil Shafer (Jul 25 2009) states: “I think Martin's code support this
> (both).”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04826.html>
> Martin Bjorklund (Jul 25 2009) states: “Yes it does.  I agree that other
> combinations are more useful, but also this combination works… If you can
> copy from candidate to url X, and from url X to running, why not copy from
> candidate to running directly?  (and IMO it means just that).  It only
> works if you have a candidate AND :writable-running of course.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04828.html>
> Andy Bierman (Jul 25 2009) states: “I think the standard is poorly
> specified in this entire area.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04832.html>
> Martin Bjorklund (Jul 26 2009) states: “<commit> has more parameters than
> <copy-config>, so I think it must be kept.  Also, you cannot copy-config to
> running unless :writable-running is advertised, so <commit> is needed.”
>
>
>
> “[Netconf] :writable-running and :candidate”
> Andy Bierman (Aug 01 2009) states: “I asked (in email) how the :candidate
> and :writable-running capabilities can possibly be supported on the same
> agent. I never got an answer. I do not understand how the candidate
> database stays in synch with the running database if user B can write to
> running while user A has the candidate locked.  Also what happens to the
> edits made by user A when user B issues a <commit>? Are the changes just
> made to running undone (they were not in the candidate, so they must be
> undone, right?) Is this part of the intended database architecture or not?
> And if user A does a copy-config from a locked candidate to running? That
> is allowed of course.”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04875.html>
> Andy Bierman (Aug 03 2009) states: “IMO, :candidate and :writable-running
> do not work together.  They almost work together, and only go horribly
> wrong sometimes.  If that's good enough for the NETCONF database
> architecture, then I guess there is nothing to fix.”
>
>
>
> “Re: [Netconf] :writable-running and :candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04961.html>
> Phil Shafer (Aug 08 2009), in reply to Andy Bierman’s previous email
> comment “I asked (in email) how the :candidate and :writable-running
> answer.”, states: “I believe I answered you, saying that tail-f's sw does
> this.”
>
>
>
> “Re: [Netconf] :writable-running and :candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04964.html>
> Andy Bierman (Aug 08 2009) states: “I asked for clarifications on the
> standard, for specific corner-cases that IMO indicate that this combination
> is not supported by the standard. The thread reached a conclusion that even
> though any changes made to running will get wiped-out as soon as the
> candidate is committed, this is how the standard is intended to work. I
> can't imagine that an operator or NMS developer using :writable-running
> would reach the same conclusion, but that's their problem -- not an IETF
> standards problem, right?”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04988.html>
> Phil Shafer (Aug 10 2009) states: “I don't support :writable-running, just
> :candidate, and the interaction between the two isn't clear.  Martin, how
> does this work on your sw?”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04999.html>
> Martin Bjorklund (Aug 11 2009) states: “There is no magic going on just
> because the box is configured to use both :candidate and
> :writable-running.  Each operation behaves the same regardless of the other
> capabilities.  So <discard-changes> resets candidate to the contents of
> running, and <commit> replaces running with the contents of candidate. I
> agree that it is a burden on the client software to support all different
> combinations of (startup, writable-running, candidate), and a server
> developer that has a choice should carefully consider which combination to
> implement.”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg05005.html>
> Juergen Schoenwaelder (Aug 11 2009) states: “The candidate design does not
> work with :writeable-running unless we find a more precise definition how
> to determine whether candidate is in a "good shape" or not.”
>
>
>
> “Re: [Netconf] NACM issue?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg07289.html>
> Martin Bjorklund (Jan 11 2012) states “…only if :writable-running and
> :candidate is advertised at the same time, and I think we have agreed that
> this is a Bad Idea.”
>
>
>
> “Re: [Netconf] The <running> configuration datastore and :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg08275.html>
> Juergen Schoenwaelder (Aug 08 2013) states: “Implementing NETCONF read-only
> has obviously little value for real configuration management. The reason
> why we have :writable-running and :candidate is that some major vendors use
> very different models when it comes to making configuration changes and as
> such you will see implementations that either announce :writable-running or
> :candidate or :writable-running and :candidate together.”
>
>
>
> “Re: [Netconf] The <running> configuration datastore and :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg08276.html>
> Andy Bierman (Aug 08 2013) states: “:candidate and :writable-running
> together should be considered deprecated. This is a degenerate use-case for
> model.”
> “Re: [Netconf] <lock> in a server that supports both writable-running and
> candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg11468.html>
> Andy Bierman (Jul 14 2016) states: “The reason nobody implements :candidate
> and :writable-running together is because there is no way to synch the
> candidate if running has been changed underneath it.”
>
>
>
> “Re: [Netconf] <lock> in a server that supports both writable-running and
> candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg11473.html>
> Sterne, Jason (Nokia - CA) (Jul 14 2016) states: “Nokia SR OS supports both
> writable-running and candidate.  And yes it is complex to manage.  The two
> datastores can’t be simply treated independently and some locking/coherency
> mechanisms are needed between them.”
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: [email-masked]
Date: Thu, 22 Dec 2016 22:05:48 +0000

> no text that describes how edit conflicts in candidate are resolved.

Coming to RFC 6241 cold(ish), it is not immediately obvious that (a)  
for a server’s config to be editable it should support either the  
:writable-running or :candidate capability and (b) it is not  
recommended for a server to support both capabilities. Is there  
anywhere that best practice like this is captured? There are so many  
nuggets that have appeared in the mail list over time, some even with  
a measure of consensus(!), that it would be good to capture them for  
the uninitiated and non-gurus.

---

From: t.petch <[email-masked]>
Date: Fri, 23 Dec 2016 10:35:30 +0000

---- Original Message -----
From: <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Thursday, December 22, 2016 10:05 PM
> > On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford
> >

<tp>

Yes, I think that this work has three parts, of which the protocol is
well-defined in RFC6241 and the DDL is well-defined in RFC6020 and the
third part is not well-defined:-)

You will find a little more in RFC6244 but, for me, that was a missed
opportunity.

However, we have a fresh opportunity with
       draft-ietf-netmod-revised-datastores-00
which, since we have no good definition (IMHO) of what is being revised,
needs to make that clear.  Which it goes some way towards doing, so I
suggest you go to that I-D cold-ish and raise anything that you think
has been omitted.

We almost need a third mailing list to discuss these matters since
previous discusssions have floated between the Netconf and netmod lists

Tom Petch

---

From: Jonathan Hansford <[email-masked]>
Date: Fri, 23 Dec 2016 11:40:33 +0000

Quoting "t.petch" <[email-masked]>:

>>>> draft-ietf-netconf-restconf-18, page 13 states “If the NETCONF
>>>> server supports :writable-running, all edits to configuration
>>>> nodes in {+restconf}/data are performed in the running
>>>> configuration datastore… Otherwise, if the device supports
>>>> :candidate, all edits to configuration nodes in {+restconf}/data
>>>> are performed in the candidate configuration datastore.”
>>>>
>>>> I have been reading through the mail archive on the relationship
>>>> between :writable-running and :candidate ... and my
>>>> understanding is as follows:
>>>>
>>>> For a NETCONF client to be able to update the configuration of a
>>>> server, the server must support :writable-running and/or
>>>> :candidate.
>>>>
>>>> A NETCONF server can support both :writable-running and
>>>> :candidate, indeed there appear to be some in the wild that do,
>>>> but there is a measure of unease about this, with the suggestion
>>>> by some the combination should be deprecated.
>>>>
>>>> Based on the text from the draft (above) it would appear that,
>>>> should a NETCONF server support both capabilities, all RESTCONF
>>>> edits should be performed in the running configuration
>>>> datastore. Is that considered the lesser of two evils, the
>>>> other being that all RESTCONF edits should be performed in the
>>>> candidate configuration datastore, or was the possibility
>>>> overlooked? My gut feel is that it would be safer to use the
>>>> candidate configuration datastore and that the two paragraphs
>>>> in the draft should be the other way around, i.e. “If the
>>>> NETCONF server supports :candidate, all edits to configuration
>>>> nodes in {+restconf}/data are performed in the candidate
>>>> configuration datastore… Otherwise, if the device supports
>>>> :writable-running, all edits to configuration nodes in
>>>> {+restconf}/data are performed in the running configuration
>>>> datastore.”
>>>
>>> This seems OK, but we do not support candidate and running as
>>> targets at the same time, so I do not know how it impacts the
>>> implementation to add this constraint.
>>>
>>> I do not agree that the strict text in RFC 6241 actually supports
>>> this editing mode.  If it does, then following the spec would
>>> lead to an implementation where the candidate would clobber
>>> edits made in running.  There is no text that seems to support
>>> automatic update of candidate after the edit to running.  There
>>> is certainly no text that describes how edit conflicts in
>>> candidate are resolved.
>>>
>>
>> Coming to RFC 6241 cold(ish), it is not immediately obvious that
>> (a) for a server’s config to be editable it should support either
>> the :writable-running or :candidate capability and (b) it is not
>> anywhere that best practice like this is captured? There are so
>> many nuggets that have appeared in the mail list over time, some
>> even with a measure of consensus(!), that it would be good to
>> capture them for the uninitiated and non-gurus.
>
> <tp>
>
> Yes, I think that this work has three parts, of which the protocol
> is well-defined in RFC6241 and the DDL is well-defined in RFC6020
> and the third part is not well-defined:-)
>
> You will find a little more in RFC6244 but, for me, that was a
> missed opportunity.
>
> which, since we have no good definition (IMHO) of what is being
> revised, needs to make that clear.  Which it goes some way towards
> doing, so I suggest you go to that I-D cold-ish and raise anything
> that you think has been omitted.
>

Though some best practice could be captured in the revised datastores
draft, this specific example concerns the interaction of NETCONF
capabilities with both the datastores and RESTCONF. Is the revised
datastores draft the best place to address this?

Jonathan

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Dec 2016 14:57:53 +0100

"t.petch" <[email-masked]> writes:

> server
> datastore…
> configuration
> between
> server,
> should a
> candidate
> {+restconf}/data are
> targets at
> this

Both 6241 and 6020/7950 address the third part to some extent but the
result isn't very clear and consistent. In fact, 6020/7950 also
"patches" the NETCONF protocol, e.g. with "insert" and "value"
attributes.

In retrospect, the status quo is quite understandable but eventually it
would be extremely useful to have clean and separate specifications of
all three parts.

> suggest you go to that I-D cold-ish and raise anything that you think

I agree and, moreover, I think that it makes sense to allow for multiple
datastore architectures because there is nothing like one size fits all:
what's good for big routers doesn't work for SOHO devices or IoT.

We can take an analogy from WWW: whilst the protocol (HTTP) and content
rules (HTML) are now pretty standard, there are zillions of web
application architectures.

Perhaps our aim could be to have one DDL (YANG), several protocols
(NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application
architectures. That's why I also support Mehmet's proposal to make the
datastore document infomational.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Dec 2016 17:41:01 +0100

> datastore document infomational.

For me, datastores are an architectural concept binding the protocols
and the data modeling language together. As we understand better now,
the datastore model also impacts how you write data models.

/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: t.petch <[email-masked]>
Date: Sat, 24 Dec 2016 13:08:22 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, December 23, 2016 4:41 PM

> the datastore model also impacts how you write data models.

Yes, there is an architectural concept but it might not be datastores.

The DDL needs a scope, a boundary within which validation is applied,
and ability to join pieces together but whether or not that is a single
datastore, or could be several joined by such as URL, a distributed
database,  needs defining, even if at the moment it seems obvious.  We
have an object class, I am unsure what the attributes of it are, to use
an analogy

Likewise, the protocol needs something at the other end to target, and
that could be a single something or linked somethings or ...  again, a
starting point could be what attributes it needs.

I find talking to those unfamiliar with history yet wanting to do
something (such as I2RS) have some interesting misunderstandings,
bringing in 'obvious' concepts from other places - as I doubtless do
from my history with SMI.

I find that the addition of a second something makes me aware of the
true characteristics of a something, so the addition of RESTCONF
alongside NETCONF as a second protocol makes it clearer to me what is
protocol and what is something else.  Is :writable-running anything to
do with NETCONF?
Nope:-) (but that is where it is currently defined:-(

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Dec 2016 10:08:58 +0100

> the datastore model also impacts how you write data models.

I think that protocols can and should remain reasonably general, and a
data modelling language even more so. Tying a protocol to a set of
datastores with detailed relationships and semantics would make the
protocol just a remote API for a particular management application.

The power and universality of HTTP stems also from the clever
abstraction of resources and representations, and IMO it is possible to
do something similar, albeit less general. Apart from resources and
representations (aka encodings), we probably also need the concept of an
(abstract) datastore. Protocols should define CRUD operations, RPCs and
notifications and needn't care about semantics of datastores. And a data
model should just tell whether a datastore content is valid or not, and
not much more.

In fact, NETCONF, as it is defined in RFC 6241, can work this way - by
design it is possible to use it for retrieving and editing any data from
any datastore. Those parts that talk about particular datastores can be
moved to another document without affecting the protocol, and made more
precise.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Dec 2016 15:29:19 +0100

> protocol just a remote API for a particular management application.

A remote API for management applications was our original target and
this is where YANG is doing well (and we apparently still have work to
do to improve things).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Dec 2016 15:47:10 +0100

> On 27 Dec 2016, at 15:29, Juergen Schoenwaelder <[email-masked]> wrote:
> 

By "management application" I mean a specific implementation with a fixed set of datastores and precise semantics. I do argue that neither RFC 6241, nor "revised-datastores" nor any other *specific* setup of datastores is going to work for all use cases, yet the protocols and YANG can be pretty universal.

We have already seen YANG being used in areas that are, strictly speaking, not supported by 6020/7950. Rather than tolerating such uses (which is a slippery slope), I would prefer to make them - within reasonable limits - officially supported.  

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Dec 2016 16:37:06 +0100

> We have already seen YANG being used in areas that are, strictly speaking, not supported by 6020/7950. Rather than tolerating such uses (which is a slippery slope), I would prefer to make them - wi…

This is too abstract for me. What do you suggest to change in the
revised datastore architecture? I do believe that having a number of
well defined datastores with specific semantics is necessary for
having interoperability.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Dec 2016 09:13:52 -0800

On Tue, Dec 27, 2016 at 7:37 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > By "management application" I mean a specific implementation with a
> fixed set of datastores and precise semantics. I do argue that neither RFC
> 6241, nor "revised-datastores" nor any other *specific* setup of datastores
> is going to work for all use cases, yet the protocols and YANG can be
> pretty universal.
> >
> > We have already seen YANG being used in areas that are, strictly
> speaking, not supported by 6020/7950. Rather than tolerating such uses
> (which is a slippery slope), I would prefer to make them - within
> reasonable limits - officially supported.
> >
>
>
So what?
We have a very open standards process.
If people think the YANG-based protocols need improvement,
they can write a draft and try to get people to support it.

> well defined datastores with specific semantics is necessary for

IMO the revised datastores draft is clean, not over-engineered, and easy
to integrate into systems that need the new datastores.  (Let's see how
long that lasts once the WG starts on it ;-)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Dec 2016 19:01:44 +0100

> On 27 Dec 2016, at 16:37, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I wrote it already several times: I support(ed) Mehmet's proposal to make the revised-datastores I-D informative. The document was adopted as a Standard Track WG item although I didn't see anything close to rough consensus during the adoption poll.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Dec 2016 19:14:54 +0100

> On 27 Dec 2016, at 18:13, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Dec 27, 2016 at 7:37 AM, Juergen Schoenwaelder <[email-masked]> wrote:

Of course, rewriting RFC 7950 on my own makes no sense at all, and you know it very well.

> long that lasts once the WG starts on it ;-)

I am not against it provided other alternatives remain possible.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Dec 2016 10:34:20 -0800

On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka <[email-masked]> wrote:

> I wrote it already several times: I support(ed) Mehmet's proposal to make
> the revised-datastores I-D informative. The document was adopted as a
> Standard Track WG item although I didn't see anything close to rough
> consensus during the adoption poll.
>
>

It appears to me that there is consensus to making this a standards track
solution.

Datastores allow universal concepts about managed data to be standardized
across multiple protocols.  In a protocol, the datastore name serves as
an input parameter value.  It needs to be normative in order for a
standards-track protocol to use it.

Changing standards track status never addresses real technical problems.
I do not understand your objections or alternate proposals.

My Applicability Statement concerns are related to developers deciding
if a server implementation needs to expose 'intended' and 'applied'.
I would like a definitive statement like "If an intended value takes more
than 5 seconds
to become applied (due to implementation, not missing hardware), then
the 'intended' and 'applied' datastores SHOULD be supported."

I think the definitions of the datastores apply to all servers, and the
set of new datastores is the correct and the semantics are clear.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Dec 2016 10:06:05 +0100

> On 27 Dec 2016, at 19:34, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> It appears to me that there is consensus to making this a standards track solution.

Where is any evidence of this?

> standards-track protocol to use it.

For the protocol, the RPC parameter needs to be normative, not a particular datastore name or semantics.

> I do not understand your objections or alternate proposals.

I think this proposal will lead to rather significant changes to the protocols and YANG, and their extent IMO isn't clear yet. For one, the draft aims at moving validation from "running" to "intended". But if "intended" is optional to implement (sec. 6.1), I don't get how validation in YANG can be (re)defined to apply also to implementations that don't have "intended".

What I would like to do is to make protocols and YANG work equally well for all datastore architectures so that the protocols and YANG needn't be changed each time the current architecture is found to require adjustments.

> I would like a definitive statement like "If an intended value takes more than 5 seconds

For some servers running-intended-applied is way too complicated, and good old "running" may be all that's needed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Dec 2016 10:11:03 +0100

> For the protocol, the RPC parameter needs to be normative, not a particular datastore name or semantics.

Datastores have associated behaviour, as you discuss below...

> I think this proposal will lead to rather significant changes to the protocols and YANG, and their extent IMO isn't clear yet. For one, the draft aims at moving validation from "running" to "intend…

It is a conceptual datastore model. A device may not expose <intended>
and on some implementations <running> is the same as <intended>. The
I-D says:

   On a traditional NETCONF implementation, <running> and <intended> are
   always the same.

> What I would like to do is to make protocols and YANG work equally well for all datastore architectures so that the protocols and YANG needn't be changed each time the current architecture is found…

Datastores have	associated behaviour.

> For some servers running-intended-applied is way too complicated, and good old "running" may be all that's needed.

And this is all fine:
 
   On a traditional NETCONF implementation, <running> and <intended> are
   always the same.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Dec 2016 10:33:12 +0100

> On 28 Dec 2016, at 10:11, Juergen Schoenwaelder <[email-masked]> wrote:
> 

My question was about changes in sec. 8 of RFC 7950. 

> Datastores have	associated behaviour.

Yes, so it's important for the management application to know available datastores and their behaviour, not necessarily for the protocol or data modelling language. Using again the web analogy, a web application has to know the structure and semantics of resources but these are completely transparent to HTTP and schema languages, if they are used.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Dec 2016 10:42:44 +0100

> Yes, so it's important for the management application to know available datastores and their behaviour, not necessarily for the protocol or data modelling language. Using again the web analogy, a w…

The NETCONF goal is interoperable data model driven management of
configuration of devices. This goes a bit beyond what you find
commonly on the web, where the expectation for an exchange to lead to
the same result across multiple independent implementations and
deployments is usually low.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Dec 2016 11:12:57 +0100

> On 28 Dec 2016, at 10:42, Juergen Schoenwaelder <[email-masked]> wrote:
> 

It doesn't mean that similar separation of concerns is impossible in this area. YANG could just define what (different levels of) validity means for a data tree, and it would be up to documents defining particular datastore architectures to state ro/rw properties for individual datastores, validation requirements etc. And servers could advertise the datastore architecture they use as a capability.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Dec 2016 11:20:55 +0100

> It doesn't mean that similar separation of concerns is impossible in this area. YANG could just define what (different levels of) validity means for a data tree, and it would be up to documents def…

You would have to define a proper meta-model and make implementations
capable of interpreting such a meta-model. Whether this is overall
easier than simply agreeing on a common set of datastores remains to
be seen. Write and I-D defining such a meta-model.

A key goal is that clients can manage different servers and there is a
trade-off between forcing some commonality on the servers in order to
allow simpler clients or to allow for more flexibility on the server
side at the expense that clients will become more complex since they
have to be able to adapt to server semantics or we will face clients
that stop to work across multiple implementations.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Dec 2016 11:54:46 +0100

> On 28 Dec 2016, at 11:20, Juergen Schoenwaelder <[email-masked]> wrote:
> 

For the time being, I am going to wait for changes to 6241 and 7950 that will be induced by revised-datastores.

> that stop to work across multiple implementations.

Yes. In fact, various combinations of :writable-running, :candidate and :startup define several different datastore architectures (some make more sense than others). As there is no requirement that clients have to support all of them, we already have different client-server management applications that still use the same protocol and data modelling language.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Dec 2016 09:36:30 -0800

On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder <
> > I wrote it already several times: I support(ed) Mehmet's proposal to
> make the revised-datastores I-D informative. The document was adopted as a

I think there was approval in the room in Seoul, and it is being confirmed
on the mailing list.

> I think this proposal will lead to rather significant changes to the
> protocols and YANG, and their extent IMO isn't clear yet. For one, the
> draft aims at moving validation from "running" to "intended". But if
> "intended" is optional to implement (sec. 6.1), I don't get how validation
> in YANG can be (re)defined to apply also to implementations that don't have
> "intended".
>

It should be possible to add new operations to NETCONF and
new query parameters to RESTCONF that support the operator requirements,
and still preserve existing operations.

I am not in favor of rewriting operations that move the validation to
'intended'.
That would not be backward-compatible so it is a non-starter.

> What I would like to do is to make protocols and YANG work equally well
> for all datastore architectures so that the protocols and YANG needn't be
> changed each time the current architecture is found to require adjustments.
>
>

This does not make sense to me.
First, I do not care about non-standard, private architectures, just the
standard architecture.  Applications cannot be forced to hard-wire all the
details about configuration management.  Let's not go back to data silo
architecture.

The standards need to expose the details in a common framework to enable
data-driven automation tools.  That means the protocols and the data models
have to support a standard datastore framework.

> old "running" may be all that's needed.

Agreed.  These servers do not need to implement the new datastores.
The same is true for the 'candidate' and 'startup' datastores already.

Andy