IETF Last Call Review of draft-ietf-opsawg-collected-data-manifest-15
review-ietf-opsawg-collected-data-manifest-15-genart-lc-davies-2026-09-25-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-opsawg-collected-data-manifest-15
Reviewer: Elwyn Davies
Review Date: 2026-09-25
IETF LC End Date: 2026-09-26
IESG Telechat date: Not scheduled for a telechat

Summary:Almost ready.  I haven't checked the YANG structures in any detail -
I'll leave those to the YANG experts and the YANG lint tools  I have one
concern which cannot be fixed within the document - The documents that define
yang-catalog and ietf-system in s5.1 are expired drafts.  I am not clear that
these documents can be counted as truly stable references  and they could be
considered as normative references.  Because we are joining these documents and
the structures they define to an RFC, this problem could really only be solved
by resusitating the expired drafts and turning them into RFCs  Given the
current status of of the YANG Catalog, I have a feeling that reactivating the
drafts is the right thing to do as the YANG structure of the YANG-catalog
really ought to be formalized (in my opinion).  The new RFCs would have to
become permitted downrefs.  The remaining issues are minor editoial matters.

Minor Issue
s5: In the third para after Figure 2, it is noted that the fundamental
specification of the YANG Catalog data YANG datastructure is the long expired
ID draft-ietf-clacla-netmod-model-catalog-0 3.  Given that this YANG module and
the resulting YANG catalog (which is apparently supported by the IETF)  is now
to be used as part of this standard, it seems to me that the expired IETF needs
to be resurrected, inspected and if necessary updated, and published as a RFC. 
An expired draft is not really a stable reference.

Similarly draft-claise-netconf-metadata-for-collection is a long expired draft.

Nits

Abstract: Add refererence to RFC 8641 for YANG-Push in form (RFC 8641),

s1:  The concept of subscriptions which is fundamental in both RFC 8641 and
this document should be introduced early on with a pointer to RFC8641.

s1, para1: Probably worth putting a reference to RFC 9232 after Network
Telemetry since this is a fundamental cocept for a YANG-Push system. (OK it is
in the termininology later but...)

s1, para 2:  I suspect that a few words on what is meant by metadata in the
context of this document would be appropriate.

s1, para 11: Definition of 'data lineage':  Whilst this term is in reasonably
common use and various definitions are used but we don't have any stndardiized
definitions in RFCs as far as I can see.  A defintion is being worked on in a
slighty different context in draft-norton-sdlp-lineage(-03) (see Abstract and
Sec1, para 2).  It would be good to get a formal definition in the terminology
in the present document.

s1, last para:  Given their importance, I think it would be worth putting the
'three elements' into bullet point paragraphs.  (I see they are expanded as
bullet points in s6.2).

s2:   s2 should note that the terminology from RFC 8641 is reused.

s3.1, para1: draft-ietf-nmop-terminology is now RFC 8440.  [Not sure why idnits
didn't spot this!]. Does this have definitions of all of the terms now?  If not
where are definitions of any terms tha aren't there?

s3.1, end of para 6: s/Section 5/see Section 5/ (or '(Section 5)')

s3.1, last para: s/helps drawing the informed conclusions/will help in drawing
suitably informed conclusons/

s3.2:  s/is the right one/is of the appropriate form for the device/, s/at the
data collection/at the data collector/

s3.3, para 1: Is the DataMesh web site sufficiently stable for an RFC
reference?  Would an academic paper such as: van der Werf, D., Moreira, J.,
Piest, J.P.S. (2025). Towards a Data Mesh Reference Architecture. In:
Kaczmarek-Heß, M., Rosenthal, K., Suchánek, M., Da Silva, M.M., Proper, H.A.,
Schnellmann, M. (eds) Enterprise Design, Operations, and Computing. EDOC 2024
Workshops . EDOC 2024. Lecture Notes in Business Information Processing, vol
537. Springer, Cham. https://doi.org/10.1007/978-3-031-79059-1_21 be a more
stable reference?

s3.3, para 3: s/to provide the data in useful way/for providing the data in a
useful way/

s3.3, last para: s/as the two YANG data models./through the two YANG daa models
defined in this document./

s4, para 1: Add refererence [RFC8639] to ietf-subscribed-notifications.

s7, para 1: s/lack of normative/lack of a normative/

s7, para3:  This draft-boucadair-nmop-rfc3535-20years-later-03 has been replaed
by draft-ietf-nmop-rfc3535-20years-later-04 and is still in active development.
 Please change reference.

Appendix D:  The abbreviation TSDB shouuld be declared on the first instace of
time-series database at line 3 rather than the instance after Figure 5.  Also
be consistent in usage - time-series datbase instead of time series database

Appendix E:  Whilst this is a handy tool for generating parts of the document,
in my opinion it doesn't beliong in the published RFC.   Please mark it for
deletion by the RFC Editor.

Major issues:

Minor issues:

Nits/editorial comments: