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.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
