Hi Qiufang, Thanks you very much for your comments. The diff is here: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-collected-data-manifest-06 Some answers to your comments are provided inline. Best, Jean > -----Original Message----- > From: Qiufang Ma via Datatracker <noreply@xxxxxxxx> > Sent: Wednesday, December 4, 2024 9:38 AM > To: yang-doctors@xxxxxxxx > Cc: draft-ietf-opsawg-collected-data-manifest.all@xxxxxxxx; last-call@xxxxxxxx; > opsawg@xxxxxxxx > Subject: Yangdoctors last call review of draft-ietf-opsawg-collected-data- > manifest-05 > > Reviewer: Qiufang Ma > Review result: On the Right Track > > Hi, authors, WG, > > This is my YANG Doctor review of draft-ietf-opsawg-collected-data-manifest-05. > > The document defines three YANG modules (though only two of them are > mentioned in the introduction section), two modules leverage the schema > mount mechanism defined in RFC 8528, and the other augments the ietf- > subscribed-notifications defined in RFC 8639. > > Moderate Comments: > 1. The mounted schema cannot be determined at design time. > The schema mount mechanism defined in RFC 8528 doesn’t provide support for > the design time, it might be confusing for the document to provide a normative > tree diagram with the mounted schema specified in the draft. I understand the > document implies it relies on some run time instance configuration to > determine, but it is weird to see some instance data after the YANG module that > is not specified as an example. I would suggest the authors to follow the > instruction from sec.4 in RFC 8340 and give a schema mount tree diagram with > only the mount point being specified and another tree diagram as an example > combined with the instance data to show your intended use, maybe also refer to > some RFCs that uses the schema mount mechanism, e.g., RFC 8529, RFC 8530. Removed schema mount for platform manifest, because it was only needed for the two extra leafs from the YANG revisions (otherwise we can use the grouping defined in ietf-yang-library Data collection manifest is now an example. > 2. The yang module "ietf-data-collection-manifest-statistics" doesn’t seem to fit > in the scope of this draft. I am a little surprised to see a YANG-push extension > module defined in this document (I think the intent is to define current-period > node as ro, rather than rw?), as I understand it is targeting to define network > modules for telemetry context information. And I am also wondering whether > the current-period could be available by reading the exact node in > <operational>, i.e., <running> contains what is configured, but <operational> > holds what is actually applied by the system as per RFC 8342. The new module is mentioned in the introduction. The goal is to have both the current period and the configured period in the data manifest. > 3. Lack of IANA consideration > Please complete the IANA consideration for the newly defined YANG modules, > the document needs to register in the "IETF XML Registry" and "YANG Module > Names" > registry. > Done > Minor comments: > 1. Section 3.1: "As an example, the identifier could be the 'sysname' from the > ietf-notification module presented in [I-D.tgraf-netconf-notif-sequencing]." > Note that the referenced document has been replaced, it would be good it > would be updated accordingly. Done, thanks. > 2. Section 3.2 and Section 4.3, please add description statement for the > yangmnt:mount-point in YANG modules to clarify the intended use, e.g., > mounted schema type, which YANG module is supposed to be mounted, etc. Done, thanks. > 3. Section 3.2, I am unsure I fully understand the definition of software-version, > software-flavor, and os-version and their differences. E.g., if the software- > version refers to the operating system version, does this node has the same > value as os-version? How is the software-flavor node related to the version > information and how to parse "A variation of a specific version where YANG > model support may be different"? Maybe some more clarification would help. This is from the YANG catalog module. By getting the data I can confirm that so far "os-version" is always equal so "software-version". "software-flavor" has two values at the moment "ALL" and "LINUX". > 4. Section 4.2, I was expecting the yang code for the ietf-data-collection- > manifest module. But another module comes first, without the tree diagram > being specified first. Perhaps some structure refinement is needed. Done, thanks. > Nits: > 1.organization > "IETF OPSAWG (Network Configuration) Working Group"; wrong expansion > for OPSAWG. > > 2.reference > "RFC xxxx: Title to be completed"; > Please complete it. > > 3. s/ Copyright (c) 2022 / Copyright (c) 2024/ > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
