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

[Joel Halpern <[e-mail]>]

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.
>
>