Skip to main content

A File Format for YANG Instance Data
draft-ietf-netmod-yang-instance-file-format-21

Revision differences

Document history

Date Rev. By Action
2022-02-10
21 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-01-24
21 (System) RFC Editor state changed to AUTH48
2021-10-29
21 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-10-21
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-10-20
21 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-10-20
21 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-19
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-18
21 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-10-18
21 Tero Kivinen Assignment of request for Last Call review by SECDIR to Watson Ladd was marked no-response
2021-10-15
21 (System) RFC Editor state changed to EDIT
2021-10-15
21 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-10-15
21 (System) Announcement was received by RFC Editor
2021-10-15
21 (System) IANA Action state changed to In Progress
2021-10-15
21 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-10-15
21 Amy Vezza IESG has approved the document
2021-10-15
21 Amy Vezza Closed "Approve" ballot
2021-10-15
21 Robert Wilton Ballot approval text was generated
2021-10-15
21 Robert Wilton IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-10-08
21 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-21.txt
2021-10-08
21 (System) New version approved
2021-10-08
21 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-10-08
21 Balázs Lengyel Uploaded new revision
2021-10-07
20 Jean Mahoney Request closed, assignment withdrawn: Suhas Nandakumar Last Call GENART review
2021-10-07
20 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2021-10-07
20 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2021-10-07
20 Barry Leiba Assignment of request for Last Call review by ARTART to Julian Reschke was marked no-response
2021-10-07
20 (System) Removed all action holders (IESG state changed)
2021-10-07
20 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2021-10-07
20 John Scudder
[Ballot comment]
Thanks for your work on this spec. Thanks also to Kent Watsen for his hard work shepherding it.

I have some comments below …
[Ballot 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.
2021-10-07
20 John Scudder Ballot comment text updated for John Scudder
2021-10-07
20 John Scudder
[Ballot comment]
Thanks for your work on this spec. Thanks also to Kent Watsen for his hard work shepherding it.

I have some comments below …
[Ballot 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.
2021-10-07
20 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-10-06
20 Benjamin Kaduk
[Ballot comment]
Should we register media-types for the file formats being specified?

Section 2

  Two formats are specified based on the XML and JSON …
[Ballot 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

    info@acme.com

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

   
      true
      deny
      deny

Is there a  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  of the file to be much
older than the  of the YANG modules it uses.
2021-10-06
20 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-10-06
20 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-10-06
20 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-10-05
20 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts on this document.

I have following comments, by addressing them I believe will improve the document quality

- Section …
[Ballot comment]
Thanks for the efforts on this document.

I have following comments, by addressing them I believe will improve the document quality

- Section 2.1 : Should it not say if the "content-schema" node exists then one of the methods MUST be used? as I see the specification of content schema is a SHOULD, hence may not be included for whatever reason.

- Section 4 : it says

    Instance data files may contain sensitive data.

  OK, but what should be taken into consideration when putting the sensitive data in the data file. It feels like there should be more information provided to the user of the specification for actually materialize the statement made here.
2021-10-05
20 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-10-05
20 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-10-05
20 Roman Danyliw
[Ballot comment]
** Section 2. 
instance-data-set-name ['@' ( revision-date / timestamp ) ]
                    ( '.xml' …
[Ballot 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.
2021-10-05
20 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-10-05
20 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-10-05
20 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-05
20 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-20.txt
2021-10-05
20 (System) New version approved
2021-10-05
20 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-10-05
20 Balázs Lengyel Uploaded new revision
2021-10-05
19 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if …
[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in a file system for me) rather than something more generic (no suggestion to offer though) ?

-- Section 1 --
The first 2 sentences are quite repetitive.

Is it about "offline delivery" or "exchange" ? At this point of reading the document, it is still unclear in my mind what it is about... The rest of the I-D made it clear.

Unclear which UC is either implemented or potential (even with the appendix); could also add forward references to the appendix UC). Should the implementation(s) be referenced if they are public ?


-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem the best fit (even though if I have no suggestions).


-- Section 2 --
Like some other ADs, I wonder why "The context data part MUST... except" is not a "SHOULD" as there are exceptions.

What is the expected behaviour when the timestamp in the filename does not match the meta data ?

-- Section 2.1 --
There is a "SHOULD" so when are exceptions/deviations acceptable ?

The description of "simplified" is really too simple ;-)

I would also appreciate that the order of the list matches the following sub-sections order.

Thank you for using RFC 8792.

-- Section 4 --
Did the authors think about adding the party creating the file and adding an optional signature in the file itself?

== NITS ==

-- Section 1 --
The first 2 sentences are quite repetitive. Missing "." At the end of the 1st §

Why is "Factory Default Setting" capitalised ?

-- Section 1.2 --
Why using the future tense "shall be" rather than "are" ?

-- Section 2.1.1 and others --
Suggest to warn the reader that the examples are further in the text in a different section.

-- Section 6 --
A "," is missing.
2021-10-05
19 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-10-04
19 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-10-04
19 Murray Kucherawy
[Ballot comment]
The shepherd writeup is incomplete with respect to the first question.

All of the SHOULDs in Section 2 leave me wondering under what …
[Ballot comment]
The shepherd writeup is incomplete with respect to the first question.

All of the SHOULDs in Section 2 leave me wondering under what conditions one might legitimately deviate from what they are saying.  Since SHOULD offers a choice, I recommend making this more clear.
2021-10-04
19 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-10-04
19 Lars Eggert
[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as …
[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.2. , paragraph 4, nit:
> ance data; the instance data itself is is contained only in the 'content-data
>                                    ^^^^^
Possible typo: you repeated a word.

Section 3.2. , paragraph 5, nit:
> ove if the module gets changed // in anyway during reviews or RFC editor proc
>                                  ^^^^^^^^^
Did you mean "in any way"?

Section 3.2. , paragraph 19, nit:
>  data file needs to be handled in a secure way as mentioned below. The secur
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.2. , paragraph 1, nit:
>  v08 - v09 * Removed reference to similar to get reply * Introduced artwork
>                                ^^^^^^^^^^^^^
Typo. Did you mean "too similar to"?

These URLs in the document did not return content:
* https://datatracker.ietf.org/wg/netmodf/
2021-10-04
19 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-10-04
19 Robert Wilton Telechat date has been changed to 2021-10-07 from 2021-10-21
2021-10-01
19 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-10-01
19 Amy Vezza Placed on agenda for telechat - 2021-10-21
2021-10-01
19 Robert Wilton Ballot has been issued
2021-10-01
19 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2021-10-01
19 Robert Wilton Created "Approve" ballot
2021-10-01
19 Robert Wilton IESG state changed to IESG Evaluation from Waiting for Writeup
2021-10-01
19 Robert Wilton Ballot writeup was changed
2021-10-01
19 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-09-30
19 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-09-30
19 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-09-30
19 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netmod-yang-instance-file-format-19. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netmod-yang-instance-file-format-19. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-yang-instance-data
URI: urn:ietf:params:xml:ns:yang:ietf-yang-instance-data
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-yang-instance-data
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-instance-data
Prefix: yid
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-09-30
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2021-09-30
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2021-09-23
19 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2021-09-23
19 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2021-09-23
19 Barry Leiba Request for Last Call review by ARTART is assigned to Julian Reschke
2021-09-23
19 Barry Leiba Request for Last Call review by ARTART is assigned to Julian Reschke
2021-09-17
19 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-09-17
19 Amy Vezza
The following Last Call announcement was sent out (ends 2021-10-01):

From: The IESG
To: IETF-Announce
CC: Kent Watsen , draft-ietf-netmod-yang-instance-file-format@ietf.org, kent+ietf@watsen.net, netmod-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2021-10-01):

From: The IESG
To: IETF-Announce
CC: Kent Watsen , draft-ietf-netmod-yang-instance-file-format@ietf.org, kent+ietf@watsen.net, netmod-chairs@ietf.org, netmod@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Instance Data File Format) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Instance Data File Format'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-10-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  There is a need to document data defined in YANG models at design
  time, implementation time or when a live server is unavailable.  This
  document specifies a standard file format for YANG instance data,
  which follows the syntax and semantics of existing YANG models, and
  annotates it with metadata.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



No IPR declarations have been submitted directly on this I-D.




2021-09-17
19 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-09-17
19 Robert Wilton Last call was requested
2021-09-17
19 Robert Wilton Ballot approval text was generated
2021-09-17
19 Robert Wilton Ballot writeup was generated
2021-09-17
19 Robert Wilton IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-09-17
19 Robert Wilton Last call announcement was generated
2021-09-16
19 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-19.txt
2021-09-16
19 (System) New version approved
2021-09-16
19 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-09-16
19 Balázs Lengyel Uploaded new revision
2021-09-09
18 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-18.txt
2021-09-09
18 (System) New version approved
2021-09-09
18 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-09-09
18 Balázs Lengyel Uploaded new revision
2021-07-28
17 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-17.txt
2021-07-28
17 (System) New version approved
2021-07-28
17 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-07-28
17 Balázs Lengyel Uploaded new revision
2021-07-12
16 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-16.txt
2021-07-12
16 (System) New version approved
2021-07-12
16 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-07-12
16 Balázs Lengyel Uploaded new revision
2021-07-09
15 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-15.txt
2021-07-09
15 (System) New version approved
2021-07-09
15 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-07-09
15 Balázs Lengyel Uploaded new revision
2021-07-05
14 (System) Changed action holders to Robert Wilton (IESG state changed)
2021-07-05
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-05
14 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-14.txt
2021-07-05
14 (System) New version approved
2021-07-05
14 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise , netmod-chairs@ietf.org
2021-07-05
14 Balázs Lengyel Uploaded new revision
2021-06-21
13 (System) Changed action holders to Benoît Claise, Balázs Lengyel, Robert Wilton (IESG state changed)
2021-06-21
13 Robert Wilton IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2021-05-11
13 Kent Watsen
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

  There is a need to document data defined in YANG models when a live
  server is unavailable.  Data is often needed at design or
  implementation time or needed when a live running server is
  unavailable.  This document specifies a standard file format for YANG
  instance data, which follows the syntax and semantics of existing
  YANG models, and annotates it with metadata.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was nothing in the process worth noting.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  Ericsson implemented an earlier version of this draft and plans to
  implement the final version once it's published.

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Robert Wilton.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -13 update.



  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.

  That said, please be aware that the document was in an
  attrociuos state when the shepherd was first asked to
  review it.  The shepherd was suprised that the document
  could exit WGLC is such a shape, suggesting that the
  WG did not review the document carefully enough.

  The shepherd requested a number of changes to bring
  the document into alignment with IETF standards:
  https://mailarchive.ietf.org/arch/msg/netmod/kLLWzTWoOg374jGSaBjXAt4Hx1I/



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  All authors confirmed that they are not aware any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/AO1Ne8smeeKNAh3KGSHy82OxMMY



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as it
  seemed that a number of folks engaged in discussions over the
  course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -13, which has one "warning" and one
  "comment", both of which are innocuous.

  That said, I noticed that the example in 2.2.1 that uses the
  RFC-folding from RFC 8792 has not been updated to reflect the
  current RFC-folding header.  It SHOULD say "NOTE: '\' line
  wrapping per RFC 8792"...


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to by correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document will not change the status
  of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG module
  and the module's namespace.  The registrations look proper, except
  the following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETCONF WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  Neither of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using the command:

    $ pyang -f yang --keep-comments --yang-line-length 69 ietf-yang-instance-data\
      @2021-03-23.yang > new.yang && diff ietf-yang-instance-data\@2021-03-23.yang new.yang

  Which produced the following innocuous diffs:

        76,77c76,77
        <      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*' +
        <        '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        ---
        >      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'
        >            + '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        85c85
        <  sx:structure "instance-data-set" {
        ---
        >  sx:structure instance-data-set {


2021-05-10
13 Kent Watsen
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

  There is a need to document data defined in YANG models when a live
  server is unavailable.  Data is often needed at design or
  implementation time or needed when a live running server is
  unavailable.  This document specifies a standard file format for YANG
  instance data, which follows the syntax and semantics of existing
  YANG models, and annotates it with metadata.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was nothing in the process worth noting.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  The Shepherd is unaware of implementations or commitments.

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Robert Wilton.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -13 update.



  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.

  That said, please be aware that the document was in an
  attrociuos state when the shepherd was first asked to
  review it.  The shepherd was suprised that the document
  could exit WGLC is such a shape, suggesting that the
  WG did not review the document carefully enough.

  The shepherd requested a number of changes to bring
  the document into alignment with IETF standards:
  https://mailarchive.ietf.org/arch/msg/netmod/kLLWzTWoOg374jGSaBjXAt4Hx1I/



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  All authors confirmed that they are not aware any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/AO1Ne8smeeKNAh3KGSHy82OxMMY



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as it
  seemed that a number of folks engaged in discussions over the
  course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -13, which has one "warning" and one
  "comment", both of which are innocuous.

  That said, I noticed that the example in 2.2.1 that uses the
  RFC-folding from RFC 8792 has not been updated to reflect the
  current RFC-folding header.  It SHOULD say "NOTE: '\' line
  wrapping per RFC 8792"...


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to by correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document will not change the status
  of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG module
  and the module's namespace.  The registrations look proper, except
  the following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETCONF WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  Neither of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using the command:

    $ pyang -f yang --keep-comments --yang-line-length 69 ietf-yang-instance-data\
      @2021-03-23.yang > new.yang && diff ietf-yang-instance-data\@2021-03-23.yang new.yang

  Which produced the following innocuous diffs:

        76,77c76,77
        <      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*' +
        <        '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        ---
        >      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'
        >            + '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        85c85
        <  sx:structure "instance-data-set" {
        ---
        >  sx:structure instance-data-set {


2021-05-10
13 Kent Watsen Responsible AD changed to Robert Wilton
2021-05-10
13 Kent Watsen IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-05-10
13 Kent Watsen IESG state changed to Publication Requested from I-D Exists
2021-05-10
13 Kent Watsen IESG process started in state Publication Requested
2021-05-10
13 Kent Watsen Tag Doc Shepherd Follow-up Underway cleared.
2021-05-10
13 Kent Watsen Tag Revised I-D Needed - Issue raised by WGLC cleared.
2021-05-10
13 Kent Watsen IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-05-10
13 Kent Watsen
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

  There is a need to document data defined in YANG models when a live
  server is unavailable.  Data is often needed at design or
  implementation time or needed when a live running server is
  unavailable.  This document specifies a standard file format for YANG
  instance data, which follows the syntax and semantics of existing
  YANG models, and annotates it with metadata.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was nothing in the process worth noting.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  The Shepherd is unaware of implementations or commitments.

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Robert Wilton.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -13 update.



  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.

  That said, please be aware that the document was in an
  attrociuos state when the shepherd was first asked to
  review it.  The shepherd was suprised that the document
  could exit WGLC is such a shape, suggesting that the
  WG did not review the document carefully enough.

  The shepherd requested a number of changes to bring
  the document into alignment with IETF standards:
  https://mailarchive.ietf.org/arch/msg/netmod/kLLWzTWoOg374jGSaBjXAt4Hx1I/



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  All authors confirmed that they are not aware any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/AO1Ne8smeeKNAh3KGSHy82OxMMY



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as it
  seemed that a number of folks engaged in discussions over the
  course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -13, which has one "warning" and one
  "comment", both of which are innocuous.

  That said, I noticed that the example in 2.2.1 that uses the
  RFC-folding from RFC 8792 has not been updated to reflect the
  current RFC-folding header.  It SHOULD say "NOTE: '\' line
  wrapping per RFC 8792"...


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document went through a YANG Doctor review as part of the
  Last Call process.  Here is a direct link to that review:

      https://datatracker.ietf.org/doc/review-ietf-netmod-yang-instance-file-format-04-yangdoctors-lc-lindem-2019-10-30/



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to by correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document will not change the status
  of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG module
  and the module's namespace.  The registrations look proper, except
  the following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETCONF WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  Neither of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint --strict ietf-yang-instance-data\@2021-03-23.yang
      $ pyang --strict --ietf ietf-yang-instance-data\@2021-03-23.yang



(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using the command:

    $ pyang -f yang --keep-comments --yang-line-length 69 ietf-yang-instance-data\
      @2021-03-23.yang > new.yang && diff ietf-yang-instance-data\@2021-03-23.yang new.yang

  Which produced the following innocuous diffs:

        76,77c76,77
        <      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*' +
        <        '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        ---
        >      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'
        >            + '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
        85c85
        <  sx:structure "instance-data-set" {
        ---
        >  sx:structure instance-data-set {


2021-03-29
13 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-13.txt
2021-03-29
13 (System) New version approved
2021-03-29
13 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2021-03-29
13 Balázs Lengyel Uploaded new revision
2020-10-16
12 (System) Document has expired
2020-06-08
12 Kent Watsen Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set.
2020-04-14
12 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-12.txt
2020-04-14
12 (System) New version approved
2020-04-14
12 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2020-04-14
12 Balázs Lengyel Uploaded new revision
2020-04-08
11 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-11.txt
2020-04-08
11 (System) New version approved
2020-04-08
11 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2020-04-08
11 Balázs Lengyel Uploaded new revision
2020-03-20
10 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-10.txt
2020-03-20
10 (System) New version approved
2020-03-20
10 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2020-03-20
10 Balázs Lengyel Uploaded new revision
2020-03-17
09 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-09.txt
2020-03-17
09 (System) New version approved
2020-03-17
09 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2020-03-17
09 Balázs Lengyel Uploaded new revision
2020-03-09
08 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-08.txt
2020-03-09
08 (System) New version approved
2020-03-09
08 (System) Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise
2020-03-09
08 Balázs Lengyel Uploaded new revision
2020-02-14
07 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-07.txt
2020-02-14
07 (System) New version approved
2020-02-13
07 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2020-02-13
07 Balázs Lengyel Uploaded new revision
2020-01-07
06 Kent Watsen IETF WG state changed to In WG Last Call from WG Document
2020-01-07
06 Kent Watsen Changed consensus to Yes from Unknown
2020-01-07
06 Kent Watsen Intended Status changed to Proposed Standard from None
2019-12-04
06 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-06.txt
2019-12-04
06 (System) New version approved
2019-12-03
06 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2019-12-03
06 Balázs Lengyel Uploaded new revision
2019-11-17
05 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-05.txt
2019-11-17
05 (System) New version approved
2019-11-17
05 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2019-11-17
05 Balázs Lengyel Uploaded new revision
2019-11-11
04 Lou Berger Notification list changed to Kent Watsen <kent+ietf@watsen.net>
2019-11-11
04 Lou Berger Document shepherd changed to Kent Watsen
2019-10-30
04 Acee Lindem Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Acee Lindem. Sent review to list.
2019-10-16
04 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2019-10-16
04 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2019-10-15
04 Kent Watsen Requested Last Call review by YANGDOCTORS
2019-08-12
04 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-04.txt
2019-08-12
04 (System) New version approved
2019-08-12
04 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2019-08-12
04 Balázs Lengyel Uploaded new revision
2019-07-05
03 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-03.txt
2019-07-05
03 (System) New version approved
2019-07-05
03 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2019-07-05
03 Balázs Lengyel Uploaded new revision
2019-02-26
02 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-02.txt
2019-02-26
02 (System) New version approved
2019-02-26
02 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2019-02-26
02 Balázs Lengyel Uploaded new revision
2018-12-06
01 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-01.txt
2018-12-06
01 (System) New version approved
2018-12-06
01 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2018-12-06
01 Balázs Lengyel Uploaded new revision
2018-12-06
01 (System) Request for posting confirmation emailed to previous authors: Benoit Claise , Balazs Lengyel
2018-12-06
01 Balázs Lengyel Uploaded new revision
2018-11-05
00 Kent Watsen This document now replaces draft-lengyel-netmod-yang-instance-data instead of None
2018-11-05
00 Balázs Lengyel New version available: draft-ietf-netmod-yang-instance-file-format-00.txt
2018-11-05
00 (System) WG -00 approved
2018-11-04
00 Balázs Lengyel Set submitter to "Balazs Lengyel ", replaces to draft-lengyel-netmod-yang-instance-data and sent approval email to group chairs: netmod-chairs@ietf.org
2018-11-04
00 Balázs Lengyel Uploaded new revision