Thanks for the review, Alvaro.
(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.
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.
[JMC] Good point. We have been focusing on the standards track, but perhaps
since we have wording to include when Operational Considerations are not
needed, we can extend the recommendation to include it for all document tracks
and explain why they are not needed in specific docs. To be discussed.
(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.
[JMC] That’s fair.
(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?
[JMC] Our point was that we wanted (at least on the Standards Track) one to
consider Operational Considerations when they author their draft. If the WG
and authors determine that no specific considerations are required, then they
can add the section and explain why that is the case. I’ve seen similar done
with Security Considerations.
(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".
[JMC] We’re fixing this. There are still a few issues in -03. The name is
Operational Considerations. I think we’ll be consistent in -04, which we want
to publish when the holddown lifts.
(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.
[May be related to
https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/65]
[JMC] Thanks for the pointer. To my knowledge, we haven’t discussed this point
yet, but it very well could be made out of scope.
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
[JMC] Thanks for the nits! We’ll get those sorted, too.
Joe
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
