Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-opsawg-rfc5706bis-01
Reviewer: Dhruv Dhody
Review Date: 2026-02-04
IETF LC End Date: -
Intended Status: BCP

## Summary

I have some concerns about this document that I think should be resolved before publication.

## Comments

The document provides comprehensive and largely well-written guidance on operational and management considerations for IETF specifications. Most sections are clear, pragmatic, and well aligned with current operational practice especially from RTG area perspective. But I wonder how would protocol that are more library-style or generic-purpose would interpret it.

The comments below focus mainly on scope clarity, terminology consistency, and audience expectations, rather than technical correctness.

### Major

- The Abstract frames this as guidance for “New Protocols or Protocol Extensions,” but later text introduces a requirement for an “Operational Considerations” section in “new RFCs in the IETF Stream,” and Section 3.1 further scopes this to “all Internet-Drafts that document a technical specification” (and also mentions architectures and data models/schema). Please align these statements. 

- Further, the draft states that its guidance applies to “New Protocols, Protocol Extensions, or architectures”, but the subsequent guidance is largely written from the perspective of protocol specifications. It is not entirely clear how the requirements and expectations around an “Operational Considerations” section should be interpreted for architecture documents, which are often Informational and may not define concrete protocol mechanisms or management solutions. Some additional clarification on what is expected for architecture documents (e.g., scope, level of detail, and whether purely descriptive operational assumptions are sufficient) would help avoid inconsistent interpretation during reviews.

- Also, the document appears to apply to YANG data model specifications (as implied by Section 3.1), but these do not clearly fit into the “new protocol / protocol extension / architecture” categorization used elsewhere. I am unsure if they should. Anyways it needs a brief clarification and how the guidance applies to them. 

### Minor

- Throughout the document, the terms “operational”, “manageability”, and “operational and manageability” are used somewhat interchangeably. Section 1.1 establishes “operational considerations” as the broader concept, with manageability as a subset, but later usage is not always consistent with this framing. As a result, it is sometimes unclear whether references to “manageability” alone are intentional (i.e., specifically limited to management aspects) or simply shorthand for the broader operational scope. For example, in Section 1.2: “It provides a framework for WGs to ensure that manageability considerations are an integral part of the protocol design process…”. Clarification would improve consistency.

- Section 5.3 appears to blur the distinction between IMs and YANG DMs. It is not always clear whether authors are expected to provide an explicit IM (e.g., described in English text), whether a reference to a YANG data model is sufficient, whether YANG is intended to serve as the IM itself, whether suggesting changes to future YANG extension is enough, or how the guidance should be interpreted when no standalone IM is defined. Some clarification would be helpful.

- Sections 6 and 6.1 introduce guidance on operational tooling and AI-driven management, but it is not always clear who the intended audience is or what concrete actions are expected from a protocol designer. Much of the discussion (e.g., aggressive querying patterns, telemetry access, overload prevention, AI-driven data consumption) appears to relate more directly to the design and behavior of management protocols, implementations, or tooling, rather than to protocol specification choices themselves. While the concerns raised are reasonable, either rephrase in a way that explicitly tie these considerations back to specific protocol design decisions or move it to appendix.

### Query

- Is there a reason beyond updating RFC 2360 (BCP 22) that this I-D is a BCP? The document is largely framed as guidance, guidelines, and recommendations for authors and reviewers, similar in style and intent to RFC 5706, which was published as Informational. 

### Nits

- s/on Guide for Internet Standards Writers. to obsolete/on "Guide for Internet Standards Writers" to obsolete/

- s/Protocol Exension/Protocol Extension/

- fix "troubleshooting of New Protocols or Protocol Extensions and their extensions"

- Appendix A, I am guessing this is meant to be a section header - ## Documentation Requirements? 

Thanks! 
Dhruv