Ballot for charter-ietf-dnsop
Block
Yes
No Objection
No Record
Summary: Has 4 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Do we approve of this charter?"
``` Specifically, the WG welcomes insights from those who wish to share operational experience and challenges as well as discuss other DNS-related matters that are within scope of the WG. ``` Are application protocols such as: - https://datatracker.ietf.org/doc/draft-kowalik-domainconnect/ - https://datatracker.ietf.org/doc/draft-hoffman-duj/ In scope? ``` The DNSOP WG is also responsible for maintenance, updates, and extensions to the DNS protocol as well as other narrowly-scoped DNS-related documents. ``` What does "narrowly-scoped" mean in this context? I can read this as very large documents, mostly unrelated to DNS, with very small DNS components. I assume using domain names does not make a document DNS related? Perhaps DNS-related means, new protocols for reading or writing to the DNS, documents which require reading or writing from the DNS, and documents which establish new formats which are written or read from the DNS? Consider: ## Scope The DNSOP WG is chartered to publish documents that fall within the following categories: 0. Updates to existing DNS specifications 1. New protocols for querying or updating the DNS 2. New data models conveyed by the DNS 3. New protocols that make use of (0), (1) or (2) above ## Out of scope The following categories are generally considered out of scope: <whatever above does not make sense>
I like that the charter is short.
I agree with Orie and Roman (and Wes, see https://mailarchive.ietf.org/arch/msg/dnsop/Ecu3-l5NTOWGVYWe0PpGnabnnZs/ ) I would feel better if there was a mandatory review period of the charter after one year, as has been done by other WGs. This would force a regular review of the current state of OP vs development and the DELEG state, and give a bit more guarantee that DNSOP is actually getting its activities split in the (not 5 years away) future. For example, PQUIP has in its charter: The IESG is establishing this working group on an experimental basis, and in 2 years, the IESG intends to review it for rechartering to continue or else closure. Perhaps a similar compromise can be found for the DNSOP charter.
I am in agreement with Orie about the vague nature of the charter. I previously balloted on the -04-00 with the following feedback: ==[ snip ]== ** What DNS topics are out of scope in the WG? As framed, it appears that nearly everything related to the “DNS protocol” would be in scope – BCPs for “DNS protocols (Sentence 1), documents from DNS operators (Sentence 2), and “maintenance, updates, and extensions to the DNS protocol” (Sentence 3). In what way is this scope different than DPRIVE, DELEG, or DNSSD that are also defining elements of the "DNS protocol"? ==[ snip ]== I don’t see any meaningful changes to provide restrictions to the charter. In the discussion on my earlier comment feedback during initial review, this WG was framed as one of last resort. I don’t see that reflected here. Additionally, it isn’t clear under what circumstance a new DNS-focused group would be established. Is there a consolidation opportunity? Do we need other DNS-focused WGs (e.g., DPRIVE, DELEG, and DNSSD)? I suspect that consolidation is not the answer, so this suggests additions scope to capture in this charter text. I appreciate that the addition of the phrase "as well as other narrowly-scoped DNS-related documents" was added to provide scope. For me it did the opposite. The original text "The DNSOP WG is also responsible for maintenance, updates, and extensions to the DNS protocol" seemed to cover nearly everything in DNS by my interpretation. Now, there is additional scope of work that is "DNS-related" which is less clear. What work is "DNS-related"?
I previously balloted on the -04-00 with the following feedback: ==[ snip ]== ** Without specificity, isn’t this statement of “The WG will engage with relevant WGs and other appropriate organizations whenever collaboration is needed” true for any WG. How does this shape the behavior of the WG? Can it be more specific? ==[ snip ]==
As my previous comments were not followed, I have to block the current version. As a WG charter needs to be well scoped, please add the intended publication status for all work items, e.g., standard track for protocol extensions and informational (or BCP) for operational guidance. While I like a short charter, like Orie and Roman I think that the scope is too vague.