[OPS-DIR]Re: draft-ietf-ecrit-lost-planned-changes-18 ietf last call Opsdir review

[Brian Rosen <[e-mail]>]

Sue

Thank you for this review

The text on the relationship between the RelaxNG schema and the XML schema has been debated for a very long time, and has changed several times.  This is the current consensus of the working group, after all that debate.  Everyone reviewing it, so far, has had a different opinion of how to handle the new schema.

The reality is that most implementations (of which there are quite a few) have used an XML schema created by another organization and not reviewed by the iETF.  There is at least one implementation that has used the RelaxNG schema and there may be more.  We have not had any significant interoperability issues even with the non-IETF schema.  So the reality seems to be it doesn’t matter.  Several experts have looked at both schemas and we do believe they are interoperable, but if there were to be a problem, consensus is the RelaxNG schema is definitive. 

There is not consensus within the work group to replace the RelaxNG schema with the XML schema.  

It’s pretty problematic to use RelaxNG for extensions when most implementations are based on the XML schema, and these implementors do not have expertise or tools to manage RelaxNG schemas.  While the reverse is also true, there are far fewer such implementations.

The wording we have presently is the best compromise I could get on how to handle it, and no one is really happy, but they are less happy with other ways.  

I will see if I can come up with some text on fault management and verifying correct operation.

Brian


> On Aug 17, 2026, at 6:12 PM, Sue Hares via Datatracker <[e-mail]> wrote:
> 
> 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".
> 
> ---
> 
>