Hi Carlos, See responses inline with [mj].
> On Jul 13, 2025, at 3:00 PM, Carlos Pignataro <[email protected]> > wrote: > > 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? [mj] Ack, and yes, “null considerations” is better than “null section”. > > > (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. [mj] Thanks for laying out all the options. My vote is still with “Operational and Management Considerations”. Cheers. > > 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 > <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] > > > > > > Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
