[OPS-DIR]draft-hardaker-dns-wgs-at-ietf-06 ietf last call Opsdir review

[Qin Wu via Datatracker <[e-mail]>]

Document: draft-hardaker-dns-wgs-at-ietf
Title: Community considerations on DNS WG structures at IETF
Reviewer: Qin Wu
Review result: Has Issues

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?