Early Review of draft-ietf-opsawg-rfc5706bis-01
review-ietf-opsawg-rfc5706bis-01-genart-early-halpern-2026-01-10-00

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.