[netmod] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this spec. Thanks also to Kent Watsen for his hard work
shepherding it.

I have some comments below which I hope may be helpful.

1. Section 1, nit, s/In Appendix C describes/Appendix C describes/ (delete the
"in")

2. Section 1.4:

   A YANG instance data set is created at a specific point of time.  If
   the data changes afterwards, this is not represented in the instance
   data set anymore.  The current values may be retrieved at run-time

I think "anymore" should be cut, for several reasons, the most important of
which is that it seems to be objectively wrong. The cut would be the minimal
fix, but did you mean something more like this? "If the data changes
afterwards, the instance data will no longer represent the current data, unless
it is updated."

3. Section 2, nit, s/constrains MAY be violated/constraints MAY be violated/

4. Section 2.1: I was amazed that the "external method" option, which is
essentially the "simply don't bother" option, was acceptable to the WG and
other reviewers. To my eye, the URI method option seems functionally just as
good (it keeps the content of the file itself small) while providing a stronger
(though still not very strong) assurance that the schema will actually be
available.
   Was "external method" discussed in the WG? Or am I simply in the rough for
even thinking it surprising?

5. Appendix C: I'm inclined to agree with the shepherd's recommendation to
remove this entire section
(https://mailarchive.ietf.org/arch/msg/netmod/5DfEi8swOmLEPykBpFICJK6398s/)
since readability is problematic and it doesn't seem to add to the usability of
the spec. Since it is, as it says, only a non-normative appendix I don't
insist, but I strongly encourage you to consider trimming or rewriting it.