Re: [Netconf] Solicit comments on inline action capability for NETCONF

Robert Wilton <rwilton@cisco.com> Tue, 17 July 2018 12:08 UTC

Return-Path: <rwilton@cisco.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 4F696130DE3 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 05:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Q5JQlqe_q-kT for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 05:08:50 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F217130E48 for <netconf@ietf.org>; Tue, 17 Jul 2018 05:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9414; q=dns/txt; s=iport; t=1531829330; x=1533038930; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=4a3lQJi/QddQNPGEvP2Ml+13FPv6tcrLL2c6/Hqxw3I=; b=Wfh+LnnFQU/tFL5e9sZyKFTbVXou2OULGJxZQk9SFMmSpkmkk4UgsXOK zoIy8nycGFCOrpsieTf/4dJgvrUp4rWA2o3ukUagMdMF4SdPoAMWezTkQ 2OkCRtiycIHYL8Wy+Y9cGawEA5eMTmHIMw7sK4SdOIKORYR50LbCkNufM w=;
X-IronPort-AV: E=Sophos;i="5.51,365,1526342400"; d="scan'208,217";a="5229897"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 12:08:48 +0000
Received: from [10.61.227.226] ([10.61.227.226]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6HC8lme024499; Tue, 17 Jul 2018 12:08:47 GMT
To: Qin Wu <bill.wu@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABA9AEC24AC@nkgeml513-mbx.china.huawei.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <b8fbfc3a-ff80-df51-60d4-c97458b3d1af@cisco.com>
Date: Tue, 17 Jul 2018 08:08:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AEC24AC@nkgeml513-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------83E8639217F155D863D1CFE1"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/fWPGaY9JoKLX1_zHq7wYvV9WSm8>
Subject: Re: [Netconf] Solicit comments on inline action capability for NETCONF
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 12:08:52 -0000

Hi Qin,

Having read this draft, I can understand what the draft is proposing, 
but I don't currently understand why this is useful. Specifically, I 
don't find the example that is in the draft as compelling.  If the 
desire is to set the MTU and enable the interface as one configuration 
operation, then wouldn't the client just configure both mtu and enabled 
leaves at the same time.  Why is a separate action required here to 
enable the interface?

So I'm struggling to think of actions that apply to configuration 
datastores where the same behaviour cannot just be achieved via a simple 
configuration manipulation.  One use case could be wanting to repeat the 
same configuration on many interfaces at the same time, but for this, I 
think that a configuration templating solution would be preferable 
rather than using actions, and a templating would probably just reused 
edit-config/edit-data.  So, if you have some other more concrete 
examples of actions that apply to configuration datastores, that might 
be helpful.

Another question (which I think is similar to the one that Eric has also 
asked) is whether to have transactions that mix configuration operations 
and action operations on <operational>.  E.g. perhaps enable an 
interface and reset the counters at the same time, or perform some 
config change and establish a dynamic subscription at the same time.  
But I question how robust this would end up being (I'm not generally a 
fan of distributed transactions - they never seem to be as robust as 
they claim to be).  Perhaps one for future thought and discussion.

Thanks,
Rob


On 03/07/2018 22:01, Qin Wu wrote:
>
> Hi, Folks:
>
> We have posted inline action capability draft on Jun 28:
>
> https://www.ietf.org/mail-archive/web/netconf/current/msg14823.html
>
> One comment we received from the list is:
> https://www.ietf.org/mail-archive/web/netconf/current/msg14863.html
> The v-(01) is uploaded to address this comment.
>
> Therefore we would like to draw you attention again on this draft
>
> https://tools.ietf.org/html/draft-zheng-netconf-inline-action-capability-01
>
> We would like to receive more review and feedback on this draft, thanks.
>
> -Qin
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf