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

[Susan Hares <[e-mail]>]

Brian: 

The text read like you were in the middle of tensions between RelaxNG and other schemas.  I've been inside these type of tensions in other work. 

At this point, all you can do is be honest and clear in the documentation.   You might want to ask operations Area Directors if they have any suggestions for hints to operators. 

Cheerily, Sue 

-----Original Message-----
From: Brian Rosen <[e-mail]> 
Sent: Tuesday, August 18, 2026 11:05 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: draft-ietf-ecrit-lost-planned-changes-18 ietf last call Opsdir review

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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Drfc5706bis_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=3-biNY6eaxqrA8yE5_98rWwphwiyserFBEIb34jRBqtkOc-aAph_zmdgHylFeh9r&s=ZYPWiT_tDasgRuY5dH1foIkY1fpq8-twe_7_xl2Nzi8&e=.
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2
> Deditor.org_rfc_rfc6123.html&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5
> A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=3-biNY6eaxqrA8yE5_98rWwphwiys
> erFBEIb34jRBqtkOc-aAph_zmdgHylFeh9r&s=5HDoGPZKf708KayxxoZEmu3rvVfEyp7w
> mHPufDH0msM&e=)
> 
> ## 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".
> 
> ---
> 
>