[Netconf] 4741bis - data stores

Martin Bjorklund <mbj@tail-f.com> Thu, 30 April 2009 14:02 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 595F13A68CC for <netconf@core3.amsl.com>; Thu, 30 Apr 2009 07:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4L6i53YQyBDa for <netconf@core3.amsl.com>; Thu, 30 Apr 2009 07:02:19 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se []) by core3.amsl.com (Postfix) with ESMTP id 8E8193A6A06 for <netconf@ietf.org>; Thu, 30 Apr 2009 07:02:19 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se []) by mail.tail-f.com (Postfix) with ESMTPSA id 4550E616010 for <netconf@ietf.org>; Thu, 30 Apr 2009 16:03:42 +0200 (CEST)
Date: Thu, 30 Apr 2009 16:03:42 +0200
Message-Id: <20090430.160342.82409955.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [Netconf] 4741bis - data stores
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 30 Apr 2009 14:02:20 -0000


There has been some discussion whether different combinations of
capabilities are allowed or not.  A clarification could be that we
explicitly state that any combination is allowed unless otherwise

One such combination is :confimed-commit and :startup.  The text on
:confimed-commit says:

   If the device reboots for any reason before the confirm timeout
   expires, the server MUST restore the configuration to its state
   before the confirmed commit was issued.

But this seems to contradict the fact that the startup configuration
is used when the device boots.


  Describe that the startup configuration is used also in this case.

  This means that if the client wants to make a config change
  persistent when using the candidate and confirmed commit on a device
  which also has startup, it needs to:

       commit confirmed
       <verify the change>
       copy running to startup