Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt

Joe Clarke <jclarke@cisco.com> Tue, 06 November 2018 03:25 UTC

Return-Path: <jclarke@cisco.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 142A312F295 for <netmod@ietfa.amsl.com>; Mon, 5 Nov 2018 19:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 wB9H4wE0yfkA for <netmod@ietfa.amsl.com>; Mon, 5 Nov 2018 19:25:15 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ACC12D4EA for <netmod@ietf.org>; Mon, 5 Nov 2018 19:25:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5664; q=dns/txt; s=iport; t=1541474715; x=1542684315; h=to:references:from:subject:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=pFUB6SGw5ufxr3d7D2RY3E80GHVrLD2r/RnCMuXBQj8=; b=RsrmtQE7KPCH5/O0hMNSRuZY77xmVWWx7fO5K7NFFu9znokTmoXnVQwN a68/4U6w+cowmKxnAvxxb7j9RnnhcMMBkxlPshk5FjIfBCjCieZPLbZ/b 5+Luj0ab92sdhenl91IsaR1pdQzA8edgRTYLzAA4RFJXspOB0nNWSJFw5 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADCCOFb/51dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmA3wog3aIGI4mly0UgWYNGA2EAUY?= =?us-ascii?q?Cg1EiNA0NAQMBAQIBAQJtHAyFOgEBAQECAQEBIQ8BOwkSCxEDAQIBAgImAgI?= =?us-ascii?q?nKAgGAQwGAgEBgx0BgXkID6lWgS6EMQIMQIU0gQuKaxeBQT+BOIJrgxsBAQI?= =?us-ascii?q?BAYEqARIBCRaDBII1IgKJFSOFPHaFHooqCYZuih0GGIFVTIQ0gnyHD40Iij6?= =?us-ascii?q?BQzhkcU0jFRohgmwJgh4XEohLhVwhMAGLVII+AQE?=
X-IronPort-AV: E=Sophos;i="5.54,470,1534809600"; d="scan'208";a="196952142"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 03:25:14 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id wA63PBuO003808; Tue, 6 Nov 2018 03:25:12 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com>
From: Joe Clarke <jclarke@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com>
Date: Mon, 5 Nov 2018 22:25:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PPUwQ7CtIroinbaw2EsZHrpUEk4>
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
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: Tue, 06 Nov 2018 03:25:18 -0000

On 11/5/18 21:54, Balázs Lengyel wrote:
> The first WG version of the document is stored. It is the same as 
> draft-lengyel-netmod-yang-instance-data-05 except for the change of title.

Thanks, Balazs.  Here is an itemized review of this draft.  Thank you
for acknowledging my requirements around augmenting YANG data/structure.
 You will definitely need that when you start to document server
capabilities.

I agree with Lada and Rob that moving the use case examples to an
appendix would make it easier to get to the meat of the document.

===

In your terminology section, you define an instance data set as
essentially a set of instance data.  I might incorporate the text from
your abstract to call instance data, data that is returned from a YANG
server.  This, too, isn't ideal, but I think it's worth being a bit more
descriptive here.

===

You use "YANG Based Instance Data" as something that feels like a term
throughout the document, but you do not define this exactly.

===

Section 2.1.1

s/Capbilites/Capabilities/

s/capabilites/capabilities/g

You say, "While it is good practice to allow a client to query these
capabilities from the live YANG server, that is often not enough."

"Not enough" doesn't sound right.  I would say, "that is sometimes not
possible."  You may mention examples like the server is not currently
available or the code driving the server is not publicly available, etc.

You say that, "Often when a network node is released an associated NMS
is released with it."

I don't know that this coupling happens "often."  I'd say that when new
network element code is released, operators want to understand the
capabilities that come within that new code.  Other NMS/OSS vendors want
to be able to understand the model provided by the new code so they can
adjust their client code.

You go on to say, "Network operators often build their own home-grown
NMS systems that needs to be integrated with a vendor's network node."

Again, the word "often" doesn't resonate with me.  I do agree that there
are NMS vendors that need to understand how to modify their NMS to
support other vendors' network elements and there are some operators
that are building their own NMS/OSS.

===

Section 2.1.2

s/configurationp/configuration/

===

Section 2.1.3

s/Dcomenting/Documenting/

===

Section 3

s/returmed/returned/

s/configuraton/configuration/

You say, "It SHOULD NOT be used if the file is stored in a version
control system (e.g. git) because the change of file names will break
the connection between the different revisions of the file."

I think you should drop this requirement.  I can use "git mv" or create
tags if I want to retain history.  I wouldn't try and legislate what
people do with their VCS.

You use "meta data" in a number of locations.  Might I suggest
"metadata."  I think that is a more common way to write that term.

===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can assume
the source datastore for config=true nodes.

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

===

Section 8

Do you have to register the ".yid" file extension as well?

Thanks.

Joe

> 
> Balazs
> 
> -------- Forwarded Message --------
> Subject: 	New Version Notification for
> draft-ietf-netmod-yang-instance-file-format-00.txt
> Date: 	Mon, 5 Nov 2018 18:12:04 -0800
> From: 	internet-drafts@ietf.org
> To: 	Benoit Claise <bclaise@cisco.com>om>, Balazs Lengyel
> <balazs.lengyel@ericsson.com>
> 
> 
> 
> 
> A new version of I-D, draft-ietf-netmod-yang-instance-file-format-00.txt
> has been successfully submitted by Balazs Lengyel and posted to the
> IETF repository.
> 
> Name: draft-ietf-netmod-yang-instance-file-format
> Revision: 00
> Title: YANG Instance Data File Format
> Document date: 2018-11-04
> Group: netmod
> Pages: 14
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
> 
> 
> Abstract:
> There is a need to document data defined in YANG models without the
> need to fetch it from a live YANG server. Data is often needed
> already in design time or needed by groups that do not have a live
> running YANG server available. This document specifies a standard
> file format for YANG Based Instance data, that is data that could be
> stored in a datastore and whose syntax and semantics is defined by
> YANG models. Most important use cases foreseen include documenting
> server capabilities, factory-default settings, or vendor provided
> default configurations.
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>