[netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02

Kent Watsen <kent@watsen.net> Mon, 25 March 2019 07:03 UTC

Return-Path: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 83425120360 for <netmod@ietfa.amsl.com>; Mon, 25 Mar 2019 00:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XU_TFCF29Smr for <netmod@ietfa.amsl.com>; Mon, 25 Mar 2019 00:03:17 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9812120353 for <netmod@ietf.org>; Mon, 25 Mar 2019 00:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553497395; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=jzHeKjXh7TEjOs07yC6bwffMMq6C4SFMVD3tHm/SGJA=; b=jCFhbL6RTqXwkhzsU/nGAS9ApPaHcgdf5t22FblyxNu1cPmqVKR5pvj4qq2SzyyQ ckbfdM5h4dt6gOKv12znfYc4bXJ4KL1+rbLvi1i0UHbqOUi4Q4W7/VP1goL4yIqymqp aVCMO6EVM99vGC8AR1CmYCdFWhPNd9QghyyqMCS4=
From: Kent Watsen <kent@watsen.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-FDA390A7-954E-47C1-853D-7F3C42EFBA89
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 07:03:15 +0000
Message-ID: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com>
To: netmod@ietf.org
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3yro9JGgRxvi5K5qmhcvka1ytZ0>
Subject: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Mar 2019 07:03:20 -0000

The Abstract says “re-using the same format as the reply to a <get> operation/request”.  At first, I was going to suggest replacing <get> with <get-data>, but I question if this is correct since the draft supports JSON, which neither NETCONF RPC is able to return. 

The Terminology section is missing an entry for “instance data set”. 

I don’t understand what P3 means.  Add info text to draft.

Re: P4, if file == 1 “set”, then the distinction becomes unclear (see earlier comment about missing “set” term).  I understand that it’s intended to mean instance data for a set of modules but, if there’s a 1:1 relationship between file and set, then just pick one term for the draft.

I don’t understand what P7 means.  Add more text to draft.

Section 3 says this about Content data: “It MAY include entity-tags and timestamps as defined in [RFC8040]”.  How is this possible?  RFC 8040 only returns such data in HTTP headers; there’s no defined encoding for putting the data into instance data.

Section 3 also says “It MAY include an explicit tag for default values as defined in
[RFC6243] and [RFC8040]”.   Do you mean, the “default” attribute defined in Section 6 in RFC 6243 and Section 4.8.9 in RFC 8040?  The text should be more explicit.

Section 3 also contains paragraphs beginning with: “It MAY include implementation specific metadata.”  and “It MAY include implementation specific XML attributes.”  I think these two paragraphs should be merged and a sentence added noting how metadata is encoded for JSON and XML.

s/A single instance data set/An instance data set/  (since already there is only one)

Section 3 says: “Instance data files MAY contain partial data sets. This means mandatory, min-elements or require-instance=true constrains MAY be violated.”  Why?  This means validations may fail.

Generally, I feel that the part of Section 3 describing the content should be replaced with a statement that any valid response for <get-data> or GET on a top-level resource is okay.  If this is not the case, then the draft should still start with this statement and them list out any exceptions.

“Metadata” is a general term, please use another term in Section 3, or spell out what is intended.  BTW, there isn’t a node in the YANG module called “metadata”, leading the extra confusion.

Where is the tree diagram?  All drafts defining YANG modules should include a YANG tree diagram for each module. 

Actually, reverting on my comment above, I recommend replacing Section 3 with the familiar 3-tuple: tree-diagram, example, YANG module.  In particular, I would delete all the text that can be described (and better at that) by the YANG module.  This eliminates duplication of content, which is both less to read and eliminates possibly conflicting information.

Stopping my review before section 3.1.

Kent // contributor