This is an early requested gen-art review of draft-ietf-opsawg-rfvc5706bis.
Reviewer: Joel M. Halpern
Date: 10-Jan-2026

Summary:  This document seems to be a useful document, mostly well put together.

Major issues:  N/A

Minor issues:
    Reading this document, I repeatedly felt like it wandered beyond its remit.  The approach of providing context, describing management interactions, and including concrete examples is very helpful.  However, I would recommend a careful pass to make sure that the recommendations are generally actionable by protocol / protocol extension specifications.  I have noted a few examples of this issue below.

Section 3.1 says that it applies to all technical specification to be published as IETF RFCs.  As a general matter, I think it is correct that this is not limited to standards track, covering also informational, experimental, or technical BCPs.  On the other hand, I don't wee how these requirements can reasonably be applied to problem statements or gap analysis documents.  I am not even sure they can be applied to gap analysis documents, although operability and manageability gaps are frequently relevant.  It may be that "Technical Specification" is intended to be only "New Protocol, a Protocol Extension, or an architecture".  If so, the wording should probably be clarified.

In section 5, there is text that asks the document authros to consider where the managers are.  I find this expectation confusing.  For any protocol I am familiar with, the managers can be in a variety of different places, delivered via a variety of techniques.  None of which considerations are tied to the specific protocol being documented.  )e.g. for a routing protocol document, whether the managers are on site or remote, whether the access is via the data network or v=ia an out of band network, whether there are or are not intermediate controllers are all parameters outside the scope of the routing protocol manageability considerations.)  While the text after the bulleted list appears to be factual, it also does not appear to be related to the protocol to be described.  I suppose one could recommend being careful not to assume in managability that some single specific management approach will always be taken.  But that is not what the sections seems to ask us to do.

Section 5.3 paragraph 4 is more about how management protocols work than it is about what information should be modeled.   I am not sure it belongs as a consideration for a protocol document management considerations section.  I presume it would be in the advice to the designers of whatever management modeling language is used to define the management model, which is not mandated to be part of this section.

Similarly, in the middle of section 5.5 on configuration management there is a discussion of coordinated configuration across devices.  While that discussion appears to be technically accurate, I am unable to understand how it relates to the managability considerations of a protocol.  Do you expect a protocol to mandate such capabilities?  Those are NMS or OSS level capabilities, not protocol aspects as far as I can tell.


Nit: should there be a note in section 5.1 along with the reference to RFC6632 that SNMP is no longer recommended?

Nit: 5.3 paragraph 2 is quite confusing.   It took me three readings to realize that the text intends to say that the YANG Data Model amplifies the text information model.  Personally, I find that an odd thing to say, as those are different levels of abstraction.