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]
