IETF Last Call Review of draft-hardaker-dns-wgs-at-ietf-06
review-hardaker-dns-wgs-at-ietf-06-opsdir-lc-wu-2026-04-23-00
review-hardaker-dns-wgs-at-ietf-06-opsdir-lc-wu-2026-04-23-00
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-opsarea-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-hardaker-dns-wgs-at-ietf-06 - Reviewer: Qin Wu - Review Date: 24 April 2026 - Intended Status: Informational ## Summary Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis I understand why we use "hope","hopefully" in this operational consideration since currently this DNS restructuring is still just a proposal,hasn't been implemented, without experiment for such DNS WG restructuring,i.e., create 3 new WG working in parrallel, you never know whether such restructuring can work well, so I think using "hope" and "hopefully" are appropriate. On the other hand, I want to understand whether operational consideration in RFC5706bis is applied to WG restructuring or the IETF process improvement since in most cases, the operational consideration is applied to protocols or technologies. If that is the case, should we use "Operational Considerations" Section Boilerplate defined in section 3.2 of RFC5706bis. Similar analogy, is, BCP is only designed for guidelines, administrative processes, and operational policies. ## Major issues None ## Minor issues: 1. When to publish this work as Historic RFC I think recommendations for DNS WG structure have been well documented, I am wondering how and when these recommendations affect how new WG can formed, Suppose one of proposed WG can not be formed, do we need to revisit or revise draft-hardaker-dns-wgs-at-ietf to reflect what has been realized based on this DNS structure proposal. Do we need to wait for draft-hardaker-dns-wgs-at-ietf to get stabilized before moving this work to Historic RFC. 2. Way to move an RFC to Historic status Look at IESG Statement on Designating RFCs as Historic, there are 4 cases or ways to move an RFC to Historic status 1. AD creates a status-change document to explain the reason for status change for one existing published RFC and reclassify it as Historic 2. An Individual or WG posts a I-D to explain the reason for status change for one existing published RFC. AD creates a status change document and incorporate content of I-D. After that the I-D is delcared dead. 3. An Individual or WG posts a I-D to explain the reason for status change for one existing published RFC and also contain other content that aims at publication of one RFC. AD will create a status change document and point to the above RFC. 4. An Individual publish RFC directly as Historic RFC without status change document created by our AD. I think your draft falls into the 4th category. I want to make sure my understanding is correct, i.e., status change document is not needed. 3. Section 3.1 said: " The chairs review and decide that this is a good candidate document for DNSDEP and send a request for comment to the DNSDEP mailing list. " When Chairs send a request for comment to ML, I am wondering whether he as WG chair just solicits comments for such individual draft and encourage others peoples to review or it means WG has already decided to adopt this work without need of consensus building process such as adoption call. ## Nits 1. Section 3, 2nd bullet said: " This WG should have a fairly wide charter that tasks it with work that doesn’t require special processing rules, needs algorithms or other simple IANA actions, or are BCPs that document existing behaviors. " The sentence "needs algorithms or other simple IANA actions" is slightly clunky. It is unclear if the "work" needs these things or if the "charter" specifies that the work must only involve these simple tasks,i.e.,requires only simple algorithms or IANA actions. Suggest to make the following change: " This WG’s charter should be wide enough to cover work that avoids special processing rules, involves only simple IANA actions or algorithms, and consists of BCPs documenting existing behaviors. " 2. Section 3, last bullet said: " * Documents may occasionally (hopefully rarely) need to move after being dispatched when the problem or solution scope changes during its development and refinement. " start the sentence with the plural "Documents," but ended it with the singular "its development." Since "its" refers back to the documents, it needs to be plural. Suggest to make the following change: "Documents may occasionally (hopefully rarely) need to move after being dispatched when the problem or solution scope changes during their development and refinement." 3. Section 3 last bullet said: " - Sometimes, however, the dispatch and adoption location decision might have been wrong, but might as well stay in the current WG. " It is not clear whether DNSDISPATCH WG can adopt one DNS related work when you can not find home for such work, maybe this has already been discussed, but in this draft, I think we should make this clear. When we say "stay in the current WG", is the current WG DNSDISPATCH WG or originally assigned WG?