Alvaro, Mahesh, Team, Please find some follow-ups inline, marked with “[CMP]”.
Carlos Pignataro (He/Him) Founder and Principal Blue Fern Consulting<https://bluefern.consulting/> Email: [email protected]<mailto:[email protected]> From: Mahesh Jethanandani <[email protected]> Date: Saturday, July 12, 2025 at 2:57 AM To: Alvaro Retana <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [OPSAWG]Initial Shepherd Review of draft-opsarea-rfc5706bis-03 [Speaking as a contributor] Hi Alvaro, First of all, thanks for your shepherd review. I have additional comments, which I will provide separately. For now, I just want to piggyback on some of your comments. On Jul 11, 2025, at 3:02 PM, Alvaro Retana <[email protected]> wrote: Dear authors: First of all, thanks for taking on this work! [CMP] Thanks to you, Alvaro, for your thorough, useful review! I started reading the document, but before getting into the substantive sections (4 and 5), I want to initiate a conversation on a couple of points where the draft could be clearer and provide better guidance. Some of these points require a wider discussion. (1) When is the Operational Considerations section required? The document "introduces a requirement to include an "Operational Considerations" section in new IETF Standard Track RFCs." Section §3.1 (Operational Considerations Section) is more descriptive: All Internet-Drafts that are advanced for publication as Standards Track IETF RFC are required to include an "Operational Considerations" section. It is recommended that Internet-Drafts advanced for publication as Experimental protocol specifications also include such sections. "Operational Considerations" sections will also often be appropriate in Internet-Drafts advanced for publication as Informational RFCs, for example, in protocol architecture and protocol requirements documents. Documents of any status can define New Protocols or Protocol Extensions, so it is not clear to me why only documents on the Standards Track are required to include an "Operational Considerations" section. The document's status doesn't eliminate the need to consider how New Protocols or Protocol Extensions will fit into the network or be managed. Agree that operational (and management) considerations should not be limited to Standards Track documents. More on it below. [CMP] Ack. We will update. Also, does "often be appropriate in...Informational RFCs" mean that including the "Operational Considerations" section is optional, or that there may be cases where it is required? IMO, the "Operational Considerations" section should be required in all RFCs. §3.2 (Null Operations and Manageability Considerations Section) offers text to be used in cases where it is truly determined that no "Operational Considerations" are needed. I would agree. I think we should remove this statement, and generalize that all non-PS documents are recommended to carry an operational (and management) considerations section. [CMP] Agree as well. (2) rfc2119 keywords §2 (Key Concepts, Terminology, and Technological Landscape) says: This document does not describe interoperability requirements. As such, it does not use the capitalized keywords defined in [BCP14]. I agree with not using rfc2119 keywords when talking about the considerations themselves. However, they should be used when defining the specific requirements for when the Operational Considerations section is needed (see above) to avoid confusion. (3) Null Considerations section not required? §3.2 (Null Operations and Manageability Considerations Section) says that "[i]f there are no new manageability or deployment considerations, it is recommended that an "Operations and Manageability Considerations" section contain a simple statement..." Populating a null section is not required. Does this mean that an RFC can be published without Operational Considerations? Even in the Standards Track? Hmm. That is now how I am reading this. If anything it says that a simple statement saying "There are no new operations or manageability requirements introduced by this document,” should be added. That in my mind is not a null section. It goes on to say that an explanation for why no new considerations are being introduced. [CMP] I think the nuance here is that we (authors) mean "null considerations", whereas Alvaro wrote a “null section”. We do not want a null section. We provide text for a non-null section describing null considerations. Does that clarify? (4) What is the name of the new section? Is it one section or two? The title of §3.2, for example, calls out what appears to be one section ("Operations and Manageability Considerations Section"), but they are mentioned independently in other places. And still in other cases, only the Operational Considerations section is mentioned (in §3.1, for example). Is the intent that one section covers both topics? If so, please be clear and consistent about it. Also, most of the document talks about "manageability considerations", but a couple of places use "management considerations". The same for "operations" and "operational". The section should be called “Operational and Management Considerations” to make clear that both operational and managment considerations are being discussed in the section. The section is often referred to as “Operational Considerations”, but that does not make it clear that both operations and management issues are being discussed. And as the document itself clarifies, operational considerations != management considerations. [CMP] This is a bit tricky… [CMP] “Management” is a noun, with associated adjective as “Managerial”. [CMP] While I always wrote "Operational and Management Considerations”, and I think this is the most widely used variation, I feel this might benefit from some thinking. [CMP] The title of the document is "Considering Operations and Management”. [CMP] Are there implications of non-modifying-noun versus adj-modifying-noun constructs? [CMP] “Operational and Management Considerations" [CMP] “Operational and Managerial Considerations" [CMP] “Operations and Management Considerations" [CMP] I’d say that ‘manageability’ is not an option here as it’s a subset of management of the how manageable but not the act of managing. Thanks, Carlos. (5) Scope creep? §1.2 (Audience) mentions several potential uses of this document beyond documenting the operational and manageability considerations for New Protocols or Protocol Extensions, for example: "Area Director who is in the process of creating a new WG Charter...OPS Directorate can use this document to guide performing reviews". But there is no guidance on how ADs should use the document when chartering. A reference is provided to the the document. The chairs of OPSDIR are coming up with a template to guide reviewers of the directorate, and I expect them to derive that template from this document. In that sense, the scope is redundant. Cheers. [May be related to https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/65] I included below a couple of nits. Thanks!! Alvaro. [Line numbers from idnits.] ... 309 * Data Model: A set of mechanisms for representing, organizing, 310 storing and handling data within a particular type of data store 311 or repository. This usually comprises a collection of data 312 structures such as lists, tables, relations, etc., a collection of 313 operations that can be applied to the structures such as 314 retrieval, update, summation, etc., and a collection of integrity 315 rules that define the legal states (set of values) or changes of 316 state (operations on values). A Data Model may be derived by 317 mapping the contents of an Information Model or may be developed 318 ab initio. Further discussion of Data Models can be found in 319 [RFC3444], Section 5.1, and Section 5.2. [] s/found in [RFC3444], Section 5.1, and Section 5.2./found in Section 5.1, Section 5.2 and [RFC3444]. I first read this as pointing at Sections 5.1 and 5.2 of rfc3444, which don't exist. ... 452 After a Protocol Designer has considered the manageability 453 requirements of a New Protocol or Protocol Extension, they may 454 determine that no management functionality or operational best- 455 practice clarifications are needed. It would be helpful to 456 reviewers, those who may update or write extensions to the protocol 457 in the future, or to those deploying the protocol, to know the 458 rationale regarding the decisions on manageability of the protocol at 459 the time of its design. [] "management functionality or operational best-practice clarifications" Not all operational considerations are best practices (and the term may get confused with a BCP). s/.../manageability or operational considerations _______________________________________________ OPSAWG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
