Document: draft-ietf-opsawg-rfc5706bis
Title: Guidelines for Considering Operations and Management in IETF
Specifications Reviewer: Johan Stenstam Review result: Ready with Nits
dnsdir review of draft-ietf-opsawg-rfc5706bis-01,
"Guidelines for Considering Operations and Management in IETF Specifications"
Reviewer: Johan Stenstam
Date: January 2026
SUMMARY
The document provides guidelines for considering operations and
management in IETF specifications. From a DNS perspective, the
document does not have very much to say, but what is there are
appropriate references DNS as an infrastructure application that may
be impacted by new protocols, including DNS-related examples.
There are several editorial issues that I think ought to be addressed
before publication, but they should all be simple to fix.
DNS-RELATED CONTENT
1. DNS References. There are four references to DNS in the draft:
a) Line 698 - Infrastructure Impact Consideration
"Protocol Designers should consider also the impact on infrastructure
applications like DNS [RFC1034], the registries, or the size of
routing tables."
To me this is appropriate and well-placed in Section 4.5 (Impact on
Network Operation). The reference to RFC 1034 is correct.
b) Lines 705-707 - DNS Example in Operational Context
"For example, Simple Mail Transfer Protocol (SMTP) [RFC5321] servers
use a reverse DNS lookup to filter out incoming connection requests:
when Berkeley installed a new spam filter, their mail server stopped
functioning because of overload of the DNS cache resolver."
This is a good example.
c) Line 421 - DNS over CoAP as Example
The document references DNS over CoAP (DoC) as an example of a
specification with adequate operational considerations documentation:
"[I-D.ietf-core-dns-over-coap], [I-D.ietf-suit-mti],
[I-D.ietf-tcpm-prr-rfc6937bis] [RFC7574], [RFC9877], and [RFC9552]."
While this is appropriate, it would be even more helpful if the document
explained why DNS over CoAP serves as a good example of operational
considerations.
d) Lines 1811-1816 - Reference Entry
The document includes a correct full reference for DNS over CoAP.
2. DNS-Related Options.
When I started to read this document there were several DNS-related issues
that I thought that I might find, but didn't. I'm not suggesting that these
must be addressed, only listing them as food-for-thought in case the editors
think that "DNS Issues" may warrant a more thorough discussion in the
document:
- Adding guidance on considering DNS query patterns and load when
designing protocols that may generate DNS lookups
- Mentioning DNS caching implications when protocols generate frequent
DNS queries
- Considering DNS security (DNSSEC) implications for protocols that
rely on DNS for service discovery or configuration
- Addressing DNS privacy considerations (e.g., DNS over HTTPS, DNS
over TLS) when protocols expose DNS query patterns
Again, these are suggestions for possible enhancement rather than required
changes, as the document is already appropriately scoped.
EDITORIAL NITS
The following editorial nits should be addressed:
1. Line 160 - Capitalization
Location: Section 1, Introduction
Current text:
"Section 2.14 of RFC 2360 [BCP22] on Guide for Internet Standards
Writers. to obsolete references to mandatory MIBs..."
Nit: The sentence that starts with a lowercase "to" suggests a
sentence break or missing capitalization. The text makes sense, so I
don't think there is any missing content.
Suggested fix:
"Section 2.14 of RFC 2360 [BCP22] on Guide for Internet Standards
Writers, to obsolete references to mandatory MIBs..."
OR
"Section 2.14 of RFC 2360 [BCP22] on Guide for Internet Standards
Writers. To obsolete references to mandatory MIBs..."
2. Line 876 - Typo
Location: Section 5, paragraph discussing service management
Current text:
"A service might be network and operational functionality derived from
the implementation and deployment of a New Protocol or Protocol
Exension."
Nit: "Exension" --> "Extension"
3. Line 2142 - Formatting
Location: Appendix A, Operational Considerations Checklist
Current text:
"The decision to incorporate all or part of these items into their
work remains with Protocol Designers and WGs themselves. ##
Documentation Requirements"
Nit: "##" seems misplaced. My guess is that this is intended as a
section separator or header marker.
4. Line 1280 - Incomplete Sentence
Location: Section 5.5, Configuration Management
Current text:
"Is the attachment between them configured compatibly on both ends?
Is the IS-IS metric the same? ... Now answer those questions for 1,000
devices."
Nit: It is not clear to me whether the ellipsis ("...") is placeholder
for missing text or the intended editorial format. I suggest rephrasing to
make this clear.
OVERALL ASSESSMENT
>From a DNS perspective, this document appropriately recognizes DNS as a
critical infrastructure component and includes relevant examples. The DNS
references are accurate and well-placed. The document would benefit from
addressing the editorial issues identified above before publication.
The document serves its intended purpose of providing guidelines for
considering operations and management in IETF specifications, and
hopefully DNS operators will benefit from Protocol Designers in the
future following these guidelines when designing protocols that
interact with or impact DNS infrastructure.
Regards,
Johan Stenstam
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
