Re: [netmod] Comments on NMDA-04

Martin Bjorklund <mbj@tail-f.com> Thu, 14 September 2017 14:34 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C513302D for <netmod@ietfa.amsl.com>; Thu, 14 Sep 2017 07:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cS_wuJCX6bbf for <netmod@ietfa.amsl.com>; Thu, 14 Sep 2017 07:34:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B087A13302B for <netmod@ietf.org>; Thu, 14 Sep 2017 07:34:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F7441AE0383; Thu, 14 Sep 2017 16:34:11 +0200 (CEST)
Date: Thu, 14 Sep 2017 16:32:39 +0200 (CEST)
Message-Id: <20170914.163239.143365521945928900.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ttUxUyza4cB8OfaJ-BhNU5ZOK_U>
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 14:34:14 -0000

Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> Hello,
> 
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
> 
> General) The system often adds data to the <running> or <intended>
> datastore already not just to <operational>: e.g.
> 
> UC1: I have a server configured in running. I need to bind it to an
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to the <operational>, validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
> 
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to <operational> I can not validate the
> selected-interval in my configured job.
> 
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to <operation>.

I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

Also note that the draft says:

  Currently there are no standard mechanisms defined that affect
  <intended> so that it would have different contents than <running>,
  but this architecture allows for such mechanisms to be defined.

which means that you can also define your own mechanisms for adding
things to <intended>, before validation.

> CH 4.4.)  "Validation is performed on the contents of <intended>."
> This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

   In the accessible tree, all leafs and leaf-lists with default values
   in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.

> which would be a backwards incompatible change. Also if validation
> does not consider system configured data that would allow cases like
> multiple interfaces named lo0. One from <intended> one from system
> configuration. IMHO while it is OK to violate uniqueness because of
> remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to <running>, or to <intended>, it will be
validated.

> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
> should not be.

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.

> Ch 5.1) IMHO actions and rpcs should be allowed to include other
> datastores in their XPath evaluation. My suggestion is that they need
> to specify it somehow. (Yang extension?)

This is something that the WG has discussed in the past as well, but
so far no concrete proposal has been made.  I think such extensions
can be done in a separate document in the future, or maybe if we do a
new version of YANG.

But note that for rpc and action, this section only talks about
XPath in input/output parameters.

> UC1) I want to define a convinience action that allows me to do a big
> modification in <running> in one step. I wan't to validate what it is
> doing based on the current contents of running. E.g. configure the OAM
> settings for the system including SNMP/Netconf/FTP in one step, but
> for each step I need to check that I am putting the relevant server on
> an existing interface.

I think this is covered.  If you have an rpc that modifies <running>,
the result will be valdiated according to the must expression in the
data models.

> If specifying the datastore is an overkill, I would still rather chose
> runing as the accessible datastore. XPath is mostly use for
> checks. Checks are done against configuration.
> 
> Appendix B)
> 
> "4. How applied : automatic" This is definitely not enough to
> understand what happens even as an example. I propose:
> Changes are automatically propagated to <operational>

I agree this is better.

> C.1)  During the example the
>     <ip>2001:db8::10</ip>
>      <prefix-length>32</prefix-length>
> is changed to 64 its. Is that intentional? It is not mentioned in the
> text.

No this is a bug, will be fixed!


/martin