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) <maqiufang1@xxxxxxxxxx>; yang-doctors@xxxxxxxx Cc: draft-ietf-opsawg-collected-data-manifest.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx 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 <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
