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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

** Section 2.
instance-data-set-name ['@' ( revision-date / timestamp ) ]
                     ( '.xml' / '.json' )

A syntax for an instance data file name is specified with normative language. 
However, this format is not explained is cited.

** Section 2. Editorial.
OLD
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name"

NEW
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name" in the filename.

** Section 2.

Description of the instance data set.  The description SHOULD
         contain information whether and how the data can change during
         the lifetime of the server

I found this definition of the description confusing as Figure 1 – 3 don’t seem
to describe “whether and how the data” will change.

** Section 2.1.1.  Per “The inline-yang-library anydata data node carries
instance data (conforming to ietf-yang-library@2019-01-04)”, please provide a
reference to “ietf-yang-library@2019-01-04”.

** Section 4.  Please note the risk of using same-schema-as-file, especially if
these configs are not integrity protected or received from outside sources. 
Per https://, there are the risks of loading remote content.  Section 7 of
RFC3986 is a good reference.  Per file://, there are things list directory
traversal.

** Section 4.  Per “The header part is not security sensitive with one possible
exception … the URI method”, I’m not sure that such a strong statement can be
made given the lack of application context.  For example, the description leaf
in the header could include sensitive information, say ‘Latest test router
config for new super secret Aqua-Violet flying car project’.  This text needs
to either have a caution that that this header is "unprotected so do not put in
sensitive information unless this file is protected", or clarify that more in
the header than the URI could be sensitive.

** Section 4.  Thanks for the language trying to create equivalency between the
protections of the file and the YANG store that would house it on a live
system.  Recommend making this text clear to say this applies to both at rest
and in motion data.

OLD
The same kind of handling should be applied, that would be
   needed for the result of a read operation returning the same data.

NEW (roughly)
The same kind of handling should be applied to this file at rest and in transit
that would be needed for the result of a read operation returning the same
data.  These in-transit protection mechanisms will also mitigate integrity
issues when transporting the file.