Return-Path: 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 DD24C1252BA for ; Fri, 25 May 2018 02:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7_Atd361uCXb for ; Fri, 25 May 2018 02:19:25 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 568EB126579 for ; Fri, 25 May 2018 02:19:23 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id z6-v6so5964765iti.4 for ; Fri, 25 May 2018 02:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=s9eKMjTXSBHeR1nKvOqNyikiyGAZPwpSIeqW5GQ8I1I=; b=ugphiFrV/MpG1W3cY0nDZmN4lVVYraD+KPckvDcdkOpuImUoghuOS7B5RjU/XOQqKW YA3ZHNfuomW+RCNck1muQrX7XdK4L5m1mAOCaNPy0fVisJQfcMD0i7hti6As8Qd11ShF 15++8lfU9j31N0YYFj08SbIOEACeZR+hyD+FRTe+vI15Eoq7PvgK8RaEn++0Itg/55Aq eBj1/ojqTTZgdTxjO3kt+5pU/EyEeV5qGaWfuyt3oF/Yxn960tqN4eQZQuHaIal0QBqU 8OaEQPnDF0DleWcl4UjDOyE14/94BNZyzK8pbea9dTQjIN2Lv13/aPsPmKFHfqZd6N0L vVqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s9eKMjTXSBHeR1nKvOqNyikiyGAZPwpSIeqW5GQ8I1I=; b=gaaviK4xORTjOOaGrQhhN6gDFX82EKhJmIUcb2qmMSOjrUE/e1CLCOsgQ1l5HhLqFR J31FPpjrN8vB3iRkt4hcnuMQaovD/5MZFM63P/+jTYhYqSOLAYr230ijm1KplSALsp7d AAJktHpIsl2pUjAG6Uopgb5KeH0IX0Jl5WdHRZ64RIPc9hcjn7OpWpQ/HLheWtzE3yJ7 WtJTzNjtBBIYrss1NQvty2WqSP5b8yqOKH0NEWsD6S15LI9232AnKNISppp/vx49SmTf DQsLk12DUrpAPAx/qramTUqyDC7rTDvfsrNWHdwAa6sNpCAvExm+S17ldhY6bR59vzuj 4sCA== X-Gm-Message-State: ALKqPwecK9Btwj3lVlSViaChcC+h//e9YeEMzwKFLYQG/SE+dPeLX2Qa Eq31p+02r59QYXIVbuTQFYgRc3R+iTpFjBlLy9RgOg== X-Google-Smtp-Source: ADUXVKJ7pr/EGZfhSGTkDZ642tyxGz5A5OwFCS99cw/s87LBqwqWXnOQbbHGFt1twBo+Og6d3eWDXTAMoHZ/471gx0E= X-Received: by 2002:a24:cfc4:: with SMTP id y187-v6mr1336354itf.26.1527239962365; Fri, 25 May 2018 02:19:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:9ed7:0:0:0:0:0 with HTTP; Fri, 25 May 2018 02:19:21 -0700 (PDT) From: Attila Vangel Date: Fri, 25 May 2018 11:19:21 +0200 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary="0000000000007195b5056d0443e8" Archived-At: Subject: [Netconf] Does do the same thing as -ing 'running' to 'candidate'? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 09:35:20 -0000 --0000000000007195b5056d0443e8 Content-Type: text/plain; charset="UTF-8" Hi, N00b question on netconf. Could somebody please clarify? 1. Does ( https://tools.ietf.org/html/rfc6241#section-8.3.4.2) have totally the same effect as -ing 'running' to 'candidate'? "This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration." If so, was it introduced as a shorter alternative of copying? If not, what is the difference between them? 2. I got confused because I watched a tutorial on youtube which used both commands, first before locking any config datastores, and -ing 'running' to 'candidate' after locking these datastores. (The assumption in this example is that the device supports 'candidate'.) 3. For the first time I was puzzled why to do before doing any locking, but then I read in the RFC that lock would fail if 'candidate' was "dirty" (https://tools.ietf.org/html/rfc6241#section-7.5): A lock MUST NOT be granted if any of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. <...> But still I am not sure about 1. If these commands do the same thing, using in this tutorial was just for showcasing doing it yet another way in 2.? (I was not sure whether to share the link for the tutorial, maybe it would look like as advertising the company/author who did the tutorial.) Best regards, Attila --0000000000007195b5056d0443e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

N00b question on netc= onf. Could somebody please clarify?

1. Does <discard-changes> = (https://to= ols.ietf.org/html/rfc6241#section-8.3.4.2) have totally the same effect= as <copy-config>-ing 'running' to 'candidate'?
"This operation discards any uncommitted ch= anges by resetting the candidate configuration with the content of the running configuration."If so, was it introduced as a shorter alternat= ive of copying?
If not, what is the difference between them?<= br>

2. I got confused because I watched a tutorial on youtub= e which used both commands, first <discard-changes> before locking an= y config datastores, and <copy-config>-ing 'running' to '= candidate' after locking these datastores. (The assumption in this exam= ple is that the device supports 'candidate'.)

3. For t= he first time I was puzzled why to do <discard-changes> before doing = any locking, but then I read in the RFC that lock would fail if 'candid= ate' was "dirty" (https://tools.ietf.org/html/rfc6241#section-7.5):
<= br>
A lock MUST NOT be granted if any of the fo=
llowing conditions is
      true:

      *  A lock is already held by any NETCONF session or another
         entity.

      *  The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.
      <...>
But still I am not sure a=
bout 1. If these commands do the same thing, using <copy-config> in t=
his tutorial was just for showcasing doing it yet another way in 2.?
(I was not sure whether to share the link for the tutori=
al, maybe it would look like as advertising the company/author who did the =
tutorial.)

Best regards,
Attila

--0000000000007195b5056d0443e8--