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


---