[Ecrit] draft-ietf-ecrit-lost-planned-changes-18 ietf last call Opsdir review

[Sue Hares via Datatracker <[e-mail]>]

Document: draft-ietf-ecrit-lost-planned-changes
Title: Validation of Locations Around a Planned Change
Reviewer: Sue Hares
Review result: Has Issues

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-ecrit-lost-planned-changes-18
- Reviewer: Susan Hares
- Review Date: August 17, 2026
- Intended Status: Proposed Standard

## Summary - Has issues

Reviewer comment: Has Issues with section 6, but no issues with extension.
Operational issues with 1) Section 6 and 2) security considerations.

Issue 1: Section 6 states that  RelaxNG scheme remains authoritative for LoST,
but that this new schema is the basis for additions.

Normally, if one updated a more usable schema, the implementations have a
choice for using either old or new. New additions only go on the new schema.

This paragraph makes a different choice where RelaxNG is normative, and this
schema is not even registered.  Errors may be found in this schema. OK, so how
is the implementer and the operator deploying this suppose to trust the
results. Why did the authors not create a schema registered in IANA to replace
RelaxNG that has some guarantee of correctly operating?

Why would an operator spend money on an implementation that the standard says
might have bugs?  This approach has me worried and confused. Explicitly
evaluate compliance with operational guidelines (optional but recommended):

Check list:
- Fault Management: Are failure detection/recovery mechanisms specified?  No
fault for section 6, - Configuration Management: Are configuration changes to
enable/disable the feature clearly defined? No configuration options for asOf
or new schema usage.

- Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly
identified? No - Deployment management: No strong description. - Installation
and initial set-up: No strong description - No migration path for replacement
to RelaxNG. - Requirements on Other Protocols: Replacement to RelaxNG or
parallel running needs additional requirements. | Impact on Network Operation:
asOf - good idea that reduces impact on network.  Replacement of RelaxNG -
could be a lot of problems. | Verifying Correct Operation: No indication of
operational tests. It would be good go include something on what's been tried
so that operators know what issues.

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

---