Early Review of draft-ietf-opsawg-rfc5706bis-01
review-ietf-opsawg-rfc5706bis-01-dnsdir-early-stenstam-2026-01-20-00

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