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

[Balázs Lengyel <[e-mail]>]

Thanks for the comments. Details below.

Balazs

On 2018. 11. 06. 4:25, Joe Clarke wrote:

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.

BALAZS: OK

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.

BALAZS: OK.
yang _BASED_ instance data is removed as it led to confusion. I revert to the more simple "yang instance data".
Added definition for Yang Instance data

Section 2.1.1

s/Capbilites/Capabilities/

s/capabilites/capabilities/g

BALAZS: OK

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.

BALAZS: OK, changed

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.

BALAZS: If we think about independent NMS vendors they may release the NMS update after the new network node version is released.
My point is that, many operators will not wait for the NMS to be developed over some time. They require the NMS on day 1.
Anyway this is only an appendix now.

Section 2.1.2

s/configurationp/configuration/

BALAZS: OK

Section 2.1.3

s/Dcomenting/Documenting/

BALAZS: OK

Section 3

s/returmed/returned/

s/configuraton/configuration/

BALAZS: OK

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.

BALAZS: OK, although I still think it is better to avoid using the date.

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.

BALAZS: OK

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.

BALAZS: This should be a default value. However as the default is a simple value, but
here it really depends on the config=true/false and the existence of writable-running
I put it into the description statement. If you need something else, like in your example, go ahead specify it.
Reworded from imply to default.

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

BALAZS: OK

Section 8

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

BALAZS: Is there a registry for file extensions? I was not aware.

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: 	[e-mail]
To: 	Benoit Claise <[e-mail]>, Balazs Lengyel
<[e-mail]>




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" rel="nofollow">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/" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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: [phone]              email: [e-mail] 


_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]