HI Qiufang, Many thanks for your comments, indeed the "current-period" should be ro. I addressed your comments in our working version (not published yet), the diff is here: https://htmlpreview.github.io/?https://raw.githubusercontent.com/JeanQuilbeufHuawei/draft-collected-data-manifest/refs/heads/qiufang_comments/docs/latest-diff.html
Best, Jean > -----Original Message----- > From: maqiufang (A) <maqiufa...@huawei.com> > Sent: Friday, March 7, 2025 6:39 AM > To: Jean Quilbeuf <jean.quilb...@huawei.com>; yang-doct...@ietf.org > Cc: draft-ietf-opsawg-collected-data-manifest....@ietf.org; > last-c...@ietf.org; > opsawg@ietf.org > Subject: RE: Yangdoctors last call review of draft-ietf-opsawg-collected-data- > manifest-05 > > Hi, Jean, > > Thanks you for the update, one thing I am still unsure is that why the > current- > period in "ietf-yp-current-period" module is defined as "rw". If this is > intended > to indicate the actual period used by the platform, I don’t think this is > something > configurable. Another follow-up comment is that if you define data collection > manifest module as an example module, this should be non-normative, could > you please tweak some text accordingly (e.g., in the abstract, introduction, > and > sec.6) to make it clear? > > Best Regards, > Qiufang > > -----Original Message----- > From: Jean Quilbeuf > Sent: Monday, March 3, 2025 11:06 PM > To: maqiufang (A) <maqiufa...@huawei.com>; yang-doct...@ietf.org > Cc: draft-ietf-opsawg-collected-data-manifest....@ietf.org; > last-c...@ietf.org; > opsawg@ietf.org > Subject: RE: Yangdoctors last call review of draft-ietf-opsawg-collected-data- > manifest-05 > > 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 <nore...@ietf.org> > > Sent: Wednesday, December 4, 2024 9:38 AM > > To: yang-doct...@ietf.org > > Cc: draft-ietf-opsawg-collected-data-manifest....@ietf.org; > > last-c...@ietf.org; opsawg@ietf.org > > 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/ > > _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
