[Gen-art] Re: draft-ietf-opsawg-rfc5706bis-01 early Genart review

["Joe Clarke (jclarke)" <[e-mail]>]

Hey, Joel.  We’ve published -04 of this draft, which I believe has addressed your comments.  When you get a chance, please look over the modified Section 5.3 and let us know if you have other comments.

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-04

Thanks.

Joe

From: Joel Halpern <[e-mail]>
Date: Monday, January 12, 2026 at 16:52
To: Joe Clarke (jclarke) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: draft-ietf-opsawg-rfc5706bis-01 early Genart review


Thank you for the attentive responses.  I think you understood and are working to address my concerns.

Yours,

Joel

On 1/12/2026 4:11 PM, Joe Clarke (jclarke) wrote:
Thanks for the review, Joel!  Comments in line 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.

[JMC] We used the word “technical” to be specific enough as not to cover things like policy or process documents, but we didn’t want to be overly prescriptive otherwise.  If a gap analysis or problem statement doesn’t need any management or operational considerations, they could employ the text that simply states that.

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.

[JMC] I believe the intent of that phrase was to have one consider the case where managers might be geographically remote (thus latency and bandwidth may become issues).  You’re right the subsequent bullets don’t quite get to that.  I’ll raise a GH issue to track this.

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.

[JMC] You’re right.  Some of this is probably not needed for the core Protocol designer.  That said, some of the text around a clear separation of config and state might be useful.  I’ll raise an issue so we can clean this up (and I’ve taken your nit in 5.3 as well).

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.

[JMC] Likely for many (most?) new protocols, their configuration could be modeled in such a way that *CONF protocols and their datastores could accommodate them.  As such, I agree, there is little for the Protocol Designer to consider here.  Still, is it bad to make them consider that operators wish to think of things more at service levels?

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

[JMC] That would make sense to remind the reader in this context.  I’ll create an issue for it.

Joe

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.