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. 
	
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.
	
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.
	
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.

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.

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. 

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.

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/