IETF Last Call Review of draft-ietf-opsawg-collected-data-manifest-16
review-ietf-opsawg-collected-data-manifest-16-opsdir-lc-hares-2026-10-08-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-opsawg-collected-data-manifest-16
- Reviewer: Susan Hares
- Review Date: October 8
- Intended Status: [Proposed Status - standard track]
---
## Summary: Has NITS
Excellent draft.  I found the content to be well described.
I walked through all of the references to trace the references.

For a "fresh eyes reader" the only concept that was hard to grasp is the
"design time schema mount" based [pper RFC8528].  The Data Mesh architecture
was an interesting reference and the definitions were useful.  It is "open"
terminology - so that it can be freely used in RFC?

English Editorial: A few terms "bonded context" could use articles, but RFC
editors will argue that point with authors. the term posteriori may be an
specific but unfamilar term for many people.

I look forward to the model catalog (draft-clacla-netmod-model-catolog,
draft-ietf-ivy-network-inventory-yang,draft-kll-yang-label-tsdb, and
draft-netana-netconf-notif-envelope, draft-ietf-opsawg-yang-provenanceand
draft-claise-netconf-metadata-for-collection) being standardized.

## General Operational Comments Alignment with RFC 5706bis

Provide an overview of the draft’s operational feasibility, readability, and
alignment with RFC5706bis guidelines. Example:

> This document defines a mechanism for providing metadata to assure the data
collected by Network Telemetry (e.g. Yang Push) is interpreted correctly. - >
The Operational Considerations section (Section 6) seems to contain everything
I expected from this draft.

Explicitly evaluate compliance with operational guidelines (optional but
recommended):

For example the check list:

- Fault Management: Failure conditions are explained in "MUST/MAY" per section.
Three cases of failure: generating, transmitting and recombining after saving. 
It might be nice to provide a failure description per case.  Perhaps in the
operations section. However, the authors might f

- Configuration Management: No summary of configuration knobs necessary beyond
Yang module is given. - Performance Monitoring: It is unclear how performance
of the telemetry systems is impact by adding this feature.

| Review Item                    | RFC 5706 Considerations
|--------------------------------|--------------------------------
| Deployment                     | yes - deployment described
| Installation and Initial Setup | Configuration knobs needed outside yang
modules not specified. Yang modules specified. | Migration Path                
| Migration path is self-evident.  If you want the TSDB, use this. |
Requirements on Other Protocols| Other protocols are described in section. 
Summary of needed protocols not in specific section. | Impact on Network
Operation    | Yes, the traffic load will increase given the addition of this
technology.  This is |                                | the cost of creating
long-term useable data with context.  A good trade-off.  However, |            
                   | as with all NM, the question is what limits during network
crisis are needed. | Verifying Correct Operation    | Test cases are given in
text. Unclear if tests have gone beyond this point.

For routing protocols, example as

[RFC 6123 – Inclusion of Manageability Sections in Path Computation Element
(PCE) Working Group Drafts](https://www.rfc-editor.org/rfc/rfc6123.html)

## Major Issues

List critical problems blocking publication (e.g., protocol flaws, missing
operational safeguards, or lack of manageability considerations). Include
section/paragraph references.

- Example:

 > Section 4.2 describes [feature] but does not specify how operators can
 monitor its performance (RFC 5706 Section 3.6). This omission could lead to
 undiagnosed failures in production networks.

- If none:

 > No major issues found.

---

## Minor Issues

List non-blocking but important clarifications (e.g., ambiguous terminology or
incomplete examples).

- Example:

 > Section 2.1 uses "node" without defining its scope (physical/virtual). Add a
 reference to RFC 8345 for consistency.

- If none:

 > No minor issues found.

---

## Nits

Optional editorial suggestions (e.g., acronym expansions or grammar fixes).

- Example:

 > Abstract: Expand "NFV" on first use.

 > Section 3.1: "it’s" -> "its".

---