[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! > > 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. > > 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. > > > (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. > > > (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. > > > (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 > OPS Dir checklist. IMO, both potential uses should be outside the scope > of > 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]
