Re: [netconf] Clarification on NETCONF edit-config default-operation replace

Andy Bierman <andy@yumaworks.com> Mon, 11 January 2021 15:53 UTC

Return-Path: <andy@yumaworks.com>
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 A81B83A0FC7 for <netconf@ietfa.amsl.com>; Mon, 11 Jan 2021 07:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 75yk_EIMzfLM for <netconf@ietfa.amsl.com>; Mon, 11 Jan 2021 07:53:14 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF093A0FC4 for <netconf@ietf.org>; Mon, 11 Jan 2021 07:53:14 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id w26so3959742ljo.4 for <netconf@ietf.org>; Mon, 11 Jan 2021 07:53:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pdv/otlbYDOnCl784ne8bM7W4hBBsEKDEL32hwoatyI=; b=Kre9KBt/WG90HtKTftVRh+YcaCKHSwmChw8KYjgLXzD0ySxUmvAJCgECbi3R91trtX zdjrcbfXosh/BamlfCFpSFMkJZnLUgIO0zVHrYGuHA2a1BjXiREPKsTkx7N4aQj2lTUq Qya01pKiE6CBTS/LqJidyfWcyiPbuXlP/H4yDjLfGc1+J/pbn2BTOJIV3AjW5Jo9Vrlm bkMFx19MN40I3qztNpqfOHXhxw1mKxkjpcy33ShU2jbzsWQ3M5UkqD3GmXqDalSbt9/d fVcYHBiVnlW/i71dzuKbUdP4jqTvAwX3vPllQYo+ldTJah4EC7LU3SlV/aeg9csQpKWK XUwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pdv/otlbYDOnCl784ne8bM7W4hBBsEKDEL32hwoatyI=; b=AN20TyIjGfeLdSlI+lb1vPHt9q3dKo+jSwJqukMQfTA/o/+NUzG9XZYoMqWsw03YFW 21boTJCRUTxLp6wZumUrfRBRF4Y8QFsVmYOa3ApQIxVYJz86bf7ajT/I9KHWUY2eP0Qb Nn0WSKfHRQiWK+20R25KSjR5gKBSXmsWLjAsYxMLlZ0QQSXrm2GRsul0dYjyTzCCwe3q As6KC879sQreR70SNseW/xapbeVwzCNRF2m0uvdki08XRMUNF/Q5/oTYlMlF9eKh7QU/ UiND4zdNAjiHcq9hVFlDTY/HWywyNkrgC5S8pMnh6Z5/n12jytWh5dx/n9fPhC5EQI8B y2LA==
X-Gm-Message-State: AOAM532vLZSL61JJ7XeTanqsMqYZz8YFEtFgix0J9kbUsotel6sAuBBu aBINAJHL6kIVybMFzZQTHnJchS1RK9JJ4I0hg1JHyQ==
X-Google-Smtp-Source: ABdhPJxxmzF9LZyfIGZidhf9w2LJ11jWcksgxl/jjvYNmiciHSvF3p/t8wJU2oTzXdmNSC7sPiGuE+q9li4C8zalNeY=
X-Received: by 2002:a2e:9a84:: with SMTP id p4mr68130lji.160.1610380392463; Mon, 11 Jan 2021 07:53:12 -0800 (PST)
MIME-Version: 1.0
References: <b586413eb1a939e144191c07ea8267843ac092bd.camel@intl.att.com> <DM5PR08MB2633A0708C35C95BBB73B9029BFE0@DM5PR08MB2633.namprd08.prod.outlook.com> <MN2PR11MB4366168CEFD579AF9DF2BF91B5AB0@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHRK7G7GL7BWeGqjPnWzOMEJx-kVj=G1SR7SUyV1R1iGQQ@mail.gmail.com> <MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 11 Jan 2021 07:53:01 -0800
Message-ID: <CABCOCHSViunYXjMwsrp0Rhh+qtEt2KGreJ7ji73h=KWco1dWiw@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f10db05b8a1e74b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xxHCMpAhK5EkKDY5vtOrUMJo18o>
Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Mon, 11 Jan 2021 15:53:17 -0000

On Mon, Jan 11, 2021 at 7:33 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

> Hi Andy,
>
>
>
> Perhaps we are crossing wires here.
>
>
>
> I’m not trying to change the behaviour, just trying to ensure that the
> spec describes the behaviour unambiguously.  My proposed text was intended
> to clarify the behaviour to be consistent with Jason’s statement below and
> the conclusion of this thread:
> https://mailarchive.ietf.org/arch/msg/netconf/DTPlkJf4enKNHXkBWn49np2e-8c/
>
>
>
> Are you disagreeing with Jason’s statement “An edit-config can't be used
> as a replacement for a full "replace at root" of the entire config like a
> copy-config” or the prior conclusion to the linked thread above?
>
>
>

No.

I guess the wording in both cases is not correct.
There is a description of the operation attribute in sec 7.2 (not very
good, but normative).
The default-operation text should just say that "merge" or "replace" is the
assigned value of
the operation when the attribute is not present in the representation of
the data node.
The value "none" indicates that no operation is assigned if the attribute
is not present.




> Regards,
>
> Rob
>

Andy


>
>
>
>
> *From:* Andy Bierman <andy@yumaworks.com>
> *Sent:* 11 January 2021 15:18
> *To:* Rob Wilton (rwilton) <rwilton@cisco.com>
> *Cc:* Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>om>;
> netconf@ietf.org
> *Subject:* Re: [netconf] Clarification on NETCONF edit-config
> default-operation replace
>
>
>
>
>
>
>
> On Mon, Jan 11, 2021 at 6:48 AM Rob Wilton (rwilton) <rwilton=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> Sorry, digging up an old thread here.
>
>
>
> I agree with the outcome of the referenced thread, but I wonder whether it
> wouldn’t be helpful to have an errata to clarify the NETCONF RFC, at least
> so that we fix this text in future?
>
>
>
> One of my colleagues read the NETCONF RFC and took “default-operation
> replace” to be equivalent to a copy-config operation.  I also note that
> some of the references on the web seem to the describe the wrong behaviour.
>
>
>
> Specifically, I wonder whether we should change:
>
>
>
>          replace:  The configuration data in the <config> parameter
>
>             completely replaces the configuration in the target
>
>             datastore.  This is useful for loading previously saved
>
>             configuration data.
>
>
>
> to:
>
>
>
>          replace:  The configuration data in the <config> parameter
>
>             replaces the related configuration in the target
>
>             datastore.
>
>
>
>
>
>
>
> No this should not be changed.
>
> It has been in use for  about a decade.
>
> You propose to remove the only way to replace the entire config and make a
> huge NBC-change
>
> to provide a redundant mechanism instead.
>
>
>
> Regards,
> Rob
>
>
>
> Andy
>
>
>
>
>
>
>
> *From:* netconf <netconf-bounces@ietf.org> *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 09 March 2020 13:20
> *To:* Ivory, William <william.ivory@intl.att.com>om>; netconf@ietf.org
> *Subject:* Re: [netconf] Clarification on NETCONF edit-config
> default-operation replace
>
>
>
> Hello William,
>
>
>
> There was a discussion about this on the list a few years ago.  See the
> thread with subject:
>
>
>
> Clarification request for NETCONF edit-config default-operation replace
>
>
>
> An edit-config can't be used as a replacement for a full "replace at root"
> of the entire config like a copy-config.
>
>
>
> Jason
>
>
>
> *From:* netconf <netconf-bounces@ietf.org> *On Behalf Of *Ivory, William
> *Sent:* Thursday, March 5, 2020 7:35 AM
> *To:* netconf@ietf.org
> *Subject:* [netconf] Clarification on NETCONF edit-config
> default-operation replace
>
>
>
> Hi,
>
>
>
> I'd appreciate clarification on the following NETCONF operations relating
> to copy-config and edit-config:
>
>
>
> My understanding is as follows:
>
>
>
> - <copy-config> completely replaces any existing configuration
>
>
>
> - <edit-config> with operation:replace attribute will replace any existing
> configuration with new configuration for nodes specified inside the
> <config> operation. The attribute may be at any level in the request, and
> applies only to the node specified and nodes under that node.
>
>
>
> Where I'm not clear is the <edit-config> operation with the
> default-operation parameter set to replace. RFC 6241 section 7.2 states:
>
>
>
>          replace:  The configuration data in the <config> parameter
>
>             completely replaces the configuration in the target
>
>             datastore.  This is useful for loading previously saved
>
>             configuration data.
>
>
>
> Does this mean that this is the equivalent of the <copy-config> operation,
> ie ALL existing configuration should be removed, even if there is no
> explicit replacement in the new <config> section?
>
>
>
> Thanks,
>
>
>
> William
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>