Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

Kent Watsen <> Wed, 18 March 2020 02:57 UTC

Return-Path: =?utf-8?q?=3C01000170eb9368e1-3f3186d5-9792-492a-8a33-4bb589552?= =?utf-8?q?b6d-000000=40amazonses=2Ewatsen=2Enet=3E?=
Received: from localhost (localhost []) by (Postfix) with ESMTP id A141A3A0F4E for <>; Tue, 17 Mar 2020 19:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o4FTcqRuVMJn for <>; Tue, 17 Mar 2020 19:57:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7D713A0F4B for <>; Tue, 17 Mar 2020 19:57:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1584500271; =?utf-8?q?h=3DContent-Type=3AMime-Version=3ASubject=3AFrom=3AIn-Reply-To=3A?= =?utf-8?q?Date=3ACc=3AContent-Transfer-Encoding=3AMessage-Id=3AReferences?= =?utf-8?q?=3ATo=3AFeedback-ID=3B?= bh=CoY8ETg7HujYuTQ6Q6s5EL/5adUMUfzPzjX1+qC758I=; b=Q2MHt+UN2OXuI9ftplXT0qcTYlPNcV/gzZkXmBBUqUBytg0sREkNpJ+WStv4te04 ua3aJoMSVhjfMJv/O6+yH+aNUTPIBXjpp7jwAlGbBiDzV4kyhLqzv8MZHmXiNkh2Y+M GYmvkSYqywdtspihBkHe1DPy4geEV1yHnWpwjmfg=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <>
In-Reply-To: =?utf-8?q?=3CDB7PR07MB40119ED41717889CFACC08F4F0E30=40DB7PR07MB?= =?utf-8?q?4011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Wed, 18 Mar 2020 02:57:51 +0000
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-ID: =?utf-8?q?=3C01000170eb9368e1-3f3186d5-9792-492a-8a33-4bb589552b?= =?utf-8?q?6d-000000=40email=2Eamazonses=2Ecom=3E?=
References: =?utf-8?q?=3CDB7PR07MB4011402E836C2FABCB3E7F42F0150=40DB7PR07MB4?= =?utf-8?q?011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E_=3C0100017045205157-ba7a?= =?utf-8?q?6e8f-0d4d-4540-b6ca-94d4d81dbe02-000000=40email=2Eamazonses=2Ecom?= =?utf-8?q?=3E_=3CDB7PR07MB40119ED41717889CFACC08F4F0E30=40DB7PR07MB4011=2Ee?= =?utf-8?q?urprd07=2Eprod=2Eoutlook=2Ecom=3E?=
To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.03.18-
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
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: Wed, 18 Mar 2020 02:57:56 -0000

Hi Balazs,

> Have the YANG modules been validated and tested for formatting?
> (i.e., pyang -f yang --keep-comments --yang-line-length 69 filename) 
> BALAZS: yes. With pyang offline and


> Have the examples in the draft validated against the YANG module?
> BALAZS: Only manually. How do you validate samples conforming to a yang data structure ?

Hmmm, seeing that the examples are still not valid, here goes:

	Until such time as tools support validating structure-data-ext, 
	one can rewrite the YANG module via s/sx:structure/container/ 
	and perform the validation against the resulting YANG module.

> Please review the Normative/Informative status of the references.
> Not looking carefully, but RFCs 2119 and 8174 should be Normative, 
> and I think RFCs 3688 and 6020 should be Informative, right?
> BALAZS: OK, changed in rev 08

Did you check all the other references too?  (I’m trying to save having to do another roundtrip when I do the shepherd writeup...)

> All of the “import” statements in the YANG module are missing a
> “reference” statement.
> Added:
> rfc6991 for types added.
> Already present:
> rfc8342 for datastores
> ietf-netmod-yang-data-ext for ietf-yang-structure-ext

Again, all the “import” statements in the YANG module are missing a “reference” statement.

> Please add a paragraph to Section 5.2 preceding the YANG module
> indicating all the aforementioned Normative references.
> BALAZS: OK, I did it, but
> this is not what is required by
> I also see no value in this statement.

I the "reference” statements mentioned above had been added, then s3.9 applies.

> The copyright in the YANG module needs to be 2020 (not 2019)
> Please ensure a blank line between paragraphs in the “description"
> statements.
> Please add a statement to the Introduction regarding why the module
> Isn’t compliant with NMDA.
> BALAZS: Sorry, don’t understand. Why is this not compliant with NMDA ?
> IMHO it is NMDA compliant, or rather it  has nothing to do with NDMA.

Either way but, per, the 
statement should be in the Introduction section.

> The tree diagram does not adhere to the syntax described in 
> draft-ietf-netmod-yang-data-ext.  
> BALAZS: OK I try, but what actually is the problem? Any help would be really appreciated.

I was looking at the “+—rw”, which can’t be right because yang-data is not “configuration”...

> Sadly
> pyang -p ../ietfYams ietf-yang-instance-data\@2020-03-06.yang -f tree --tree-print-yang-data --tree-print-yang-data
> doesn’t print out anything, so I am handcrafting.

`pyang`  supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been updated to support the new "sx:structure” statement.

> I just updated pyang from git. Any idea why this doesn’t work for me?
> It would be good if YangValidator would print out the tree. At some point it did. Not now. :-(

First, use the s/sx:structure/container/ trick mentioned above.

Then s/+--rw/+—/.

Then review and tweak accordingly until all is good.

> Please update the first sentence  in Section 5.1 to also reference draft-ietf-netmod-yang-data-ext.
> Please ensure that the planning-text version of the draft passes
> IDNITS ( at the “verbose output”
> level and correct any issues found, or explain why they shouldn’t
> be corrected.
> BALAZS: OK, corrected

Thanks!  (this is almost always the cause for needing another draft update when doing the shepherd writeup)

NEW: looking at the new "format-version”, please add a pattern statement to constrain the string values appropriately.  Hint, it’s half a "date-and-time” type...

Kent  // contributor (and shepherd)