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.
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.
(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?
(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".
(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]
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 -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
