[Netconf] :candidate, :writable-running and RESTCONF edits
"Jonathan Hansford" <jonathan@hansfords.net> Thu, 22 December 2016 12:12 UTC
Return-Path: <jonathan@hansfords.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E5129959 for <netconf@ietfa.amsl.com>; Thu, 22 Dec 2016 04:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYWeWq0-vCCC for <netconf@ietfa.amsl.com>; Thu, 22 Dec 2016 04:12:32 -0800 (PST)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201A5129952 for <netconf@ietf.org>; Thu, 22 Dec 2016 04:12:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e79LZYV8B4bSSWVlr/P+J2yepg7RBe+L9VijyZLhV3Q=; b=oWODwsG281BBv5D3vhoqqjC672 x09+T/pyIYcatgB7HxmDN6d+yVdfm0idGYGDLVXIWFDObq0oEdNG2lYivYkJDJLKk/GfTtHRbShku McEbErmkxnJGf79XYmH86ATYyf6GbbtedfyzLGxQqtmNCugdXGqW6S1CZICkL2fOjjq4FAhd7N6EZ 5Z7xvSFuiSzzQVoD4xvSqYDRRc4wLXLpfxtTuOlb8cKAhruf9C+w8OgMf/8F3LDpuZL5CrCvyDGwA Lpx04bCJ/8VPA9rpRvvtra+GgFqXt7NNnVmf44BaCAH5XYz+4JaIXxKpl0TERdgxAnhpcjhSgilkv Xvzro02Q==;
Received: from hansfords.plus.com ([84.92.116.209]:39884 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from <jonathan@hansfords.net>) id 1cK2EW-001IQy-TQ for netconf@ietf.org; Thu, 22 Dec 2016 12:12:29 +0000
From: Jonathan Hansford <jonathan@hansfords.net>
To: 'Netconf' <netconf@ietf.org>
Date: Thu, 22 Dec 2016 12:12:30 -0000
Message-ID: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01D25C4C.AB79C5C0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdJb+2dYNiDGrFcrRNO/H9B8RvAZTg==
Content-Language: en-gb
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0tTkecbhi1eHmcrZNUvKZIK-zgs>
Subject: [Netconf] :candidate, :writable-running and RESTCONF edits
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 12:12:36 -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."
- [Netconf] :candidate, :writable-running and RESTC… Jonathan Hansford
- Re: [Netconf] :candidate, :writable-running and R… Andy Bierman
- Re: [Netconf] :candidate, :writable-running and R… jonathan
- Re: [Netconf] :candidate, :writable-running and R… t.petch
- Re: [Netconf] :candidate, :writable-running and R… Jonathan Hansford
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… t.petch
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… Andy Bierman
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Andy Bierman
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Juergen Schoenwaelder
- Re: [Netconf] :candidate, :writable-running and R… Ladislav Lhotka
- Re: [Netconf] :candidate, :writable-running and R… Andy Bierman