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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 05 Oct 2021 13:44:42 -0700

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.

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 Oct 2021 10:12:28 +0000

Hello Roman,
Thank you for the thorough review. I used your comments to improve the draft. See my detailed answers below as BALAZS:
Regards Balazs

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: 2021. október 5., kedd 22:45
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Kent Watsen <[email-masked]>; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

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.)

** Section 2.

A syntax for an instance data file name is specified with normative language. 
However, this format is not explained is cited.
BALAZS: The syntax is ABNF. It will be stated and referenced.

** Section 2. Editorial.
OLD

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.
BALAZS: OK, will be updated.

** Section 2.

I found this definition of the description confusing as Figure 1 – 3 don’t seem to describe “whether and how the data” will change.
BALAZS: Good catch. The information will be added to the examples.

** 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”.
BALAZS: OK,  will be updated.

** 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.
BALAZS: OK, will be added to security considerations.

** 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.
BALAZS: OK,  will be updated.

** 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

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.
BALAZS: OK,  will be updated.