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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

Should we register media-types for the file formats being specified?

Section 2

   Two formats are specified based on the XML and JSON YANG encodings.
   Later, as other YANG encodings (e.g., CBOR) are defined, further
   instance data formats may be specified.

I don't remember seeing a clear description of the specifics of these
two specified formats.  (I assume it's just "use the XML/JSON encoding
for YANG structures", but I don't remember that stated anywhere.)

   The name of the instance data file SHOULD be of the form:

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

This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do
we want to say that and reference RFC 5234 for the interpretation of the
symbols?

   If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name".  If the "revision-
   date" is present in the filename it MUST conform to the format of the
   revision-date leaf in the YANG model.  [...]

This seems unenforcable, and contrary to the Unix ethos.  Why is it
necessary to try to have consistency betwen the contents of the file and
its name in the file system, as opposed to letting the type and contents
of a file speak for itself regardless of the name in the file system?

   Metadata, information about the data set itself SHOULD be included in
   the instance data set.  Some metadata items are defined in the YANG
   module "ietf-yang-instance-data", but other items MAY be used.

   Metadata MUST include:

      -  Version of the YANG Instance Data format

Doesn't the latter (MUST) effectively make the former (SHOULD) also into
a "MUST"?

Also, if this is actually mandatory, shouldn't that be reflected in the
YANG module?

Section 2.1.2

   import-only dependencies MAY be excluded from the leaf-list.  If they
   are excluded then the consumer of the instance data set has to apply
   the YANG language rules to resolve the imports.  An example of the

Do we want to say something like "Accordingly, recipients of the
instance data set must be prepared to perform this processing, absent
prior knowledge about the files they will be processing"?

Section 2.2.1

    <contact>[e-mail]</contact>

Unfortunately, acme.com is a real domain name; we should probably use a
BCP 32 name.  Likewise for urn:rdns:acme.com:oammodel:acme-system-ext,
etc.

Section 2.2.2

     <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
       <enable-nacm>true</enable-nacm>
       <read-default>deny</read-default>
       <exec-default>deny</exec-default>

Is there a <write-default> that should be set as well?  Or do we just
implicitly rely on the default from RFC 8341?

Section 3

         description
           "An arbitrary name for the YANG instance data set.  This
            value is primarily used for descriptive purposes.  However,
            when the instance data set is saved to a file, then the
            filename MUST encode the name's value, per Section 3
            of RFC XXXX.";

I think this requirement is currently stated in Section 2, not 3 (though
in my previous comment I suggest that the requirement should be
removed).

Section 4

(I wrote, then deleted as duplicate, essentially all of the same things
that Roman commented on.  Thanks for updating in response to his
comments.)

   The document does not specify any method to influence the behavior of
   a server.

A few of the listed use cases seem to involve loading configuration into
a server, which could perhaps be considered to influence the behavior of
the server in question.

   The header part is not security sensitive with one possible
   exception.  If the URI method is used for specification of the
   content schema and the URI includes a username and/or a password, the
   instance data file needs to be handled securely as mentioned below.

In the terminology of RFC 3986 this is the "userinfo subcomponent", as
in "the URI includes a userinfo subcomponent".

NITS

Section 2.2.1, 2.2.2

It's a bit challenging to get the <revision> of the file to be much
older than the <revision> of the YANG modules it uses.