Document: draft-ietf-opsawg-rfc5706bis Title: Guidelines for Considering Operations and Management in IETF Specifications Reviewer: Tina Tsou Review result: Has Nits
Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-opsawg-rfc5706bis - Reviewer: Tina Tsou - Review Date: 01/24/2026 - Intended Status: Best Current Practice --- ## Summary - Has Nits: This document is basically ready for publication but has nits that should be considered prior to publication. Minor issues and suggestions - Scope/intent: Be explicit early that this document is guidance for WGs and authors, not a protocol-level requirement. Where RFC 2119/8174 terms are used, say they are requirements of this BCP for authors, not for protocol behavior. - Relationship to RFC 5706: In Abstract and Introduction, clearly state whether this document obsoletes or updates RFC 5706 and summarize the key deltas. Consider an appendix mapping old checklist items to the new structure. - Terminology: Define “telemetry,” “monitoring,” “observability,” and “management/control/data plane” on first use to avoid ambiguity. - Encryption vs. manageability: Add a checklist question about operational visibility when end-to-end encryption hides header or payload fields, and expectations for exposing safe metadata or counters. - Automation and rollback: Add explicit items on idempotent operations, transactionality, dry-run/preview, and reliable rollback on failure, since these are frequent sources of outages. - Configuration and state: Encourage separation of intended vs. applied config and clarity on how state is derived and exposed, including convergence timing and failure modes. - Logging and privacy: Include guidance on data minimization, redaction of sensitive fields, log retention, and key/credential rotation procedures as part of operational security. - Telemetry breadth: Call out metrics, events/logs, and traces as first-class signals. Recommend rate limiting, sampling guidance, units, and stability of metric names. - Backwards compatibility and deprecation: Add questions on versioning, feature flags, deprecation notices, and interop during mixed-version rollouts. - IANA and registries: Remind authors to consider registries that impact operations (e.g., error codes, counters, event types) and to document update policies. Nits/editorial - Expand abbreviations on first use (OPS, NMS, KPI, MTTR, etc.). - Normalize section title capitalization and hyphenation (e.g., “end-to-end,” “machine-readable”). - Avoid ambiguous verbs like “support” in checklist items. Prefer testable phrasing (“The protocol exposes...,” “The implementation provides...”). - Provide consistent guidance on whether each checklist item is “Recommended” vs “Optional,” and keep that labeling uniform across sections. Ensure references cited in examples are up to date; mark informative vs normative consistently. - Consider a short “How to use this document” subsection explaining that WGs can paste the checklist into their draft templates. Overall, the document is in good shape for publication after addressing the above clarifications and editorial cleanups. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
