Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

Martin Bjorklund <> Thu, 20 February 2020 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EADB31209B4; Thu, 20 Feb 2020 08:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YTT_1K_bKdjp; Thu, 20 Feb 2020 08:59:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 879A51209AA; Thu, 20 Feb 2020 08:59:17 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 2367F1B03C80; Thu, 20 Feb 2020 17:59:14 +0100 (CET)
Date: Thu, 20 Feb 2020 17:58:34 +0100 (CET)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2020 16:59:20 -0000


Joel Jaeggli <> wrote:
> Greetings,
> This was supposed to get processed shortly after IETF 106, however I lost track of it. We are therefore running a 2 week WGLC on draft-ietf-netmod-nmda-diff-03.
> the 02 - 03 diff is available here:
> Please send email to the list indicating your support or concerns.

I have reviewed draft-ietf-netmod-nmda-diff-03 and have some comments.

o  Section 4

      (The filter dow not contain expressions that
      would match values data nodes, as this is not required by most use
      cases and would complicate the scheme, from implementation to
      dealing with race conditions.)

  I don't think it is a good idea to reject filters that match
  values.  For example, suppose I want to compare the config for a
  specific interface.  I could do /interfaces/interfac[name='eth0'],
  or a subtree filter.  Why should this not be possible?

  Besides, the mechanism of rejecting such filters is not defined.
  The only text we have is this sentence within parentheses.

o  leaf all in the YANG module

   s/Specifically, if one/For example, if one/

o  leaf xpath-filter

  The description needs to specify the XPath context, see RFC 6991.

o  container differences

  It is not clear what the YANG patch records reflect.  Is it the
  patches that are required to go from "source" to "target"?  Or the
  other way around?

o  anydata source-value

  This description needs work.  The current text isn't correct
  ('value' is not present when the operation is 'move').

  The description should explain what this is supposed to contain.

o  Section 6

  The example is confusing.  It seems the diff is the patches required
  to go from target to source.  And the source-value contains the
  origin present in the target, is that correct?  And the value
  contains an origin that isn't present in neither the source nor the