Ballot for draft-hardaker-dns-wgs-at-ietf
Discuss
Yes
No Objection
Abstain
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
To the document authors: Thank you for the patience with my unintended surprise of converting my ABSTAIN ballot to a DISCUSS. In preparing for the telechat this morning, I found two more ABSTAIN ballots filed by other ADs similar to my own position and began to explore more history on the document. To the responsible AD: DNS discussions occur in many forums in the IETF and this document is at this nexus. As it is AD sponsored, there is no obvious venue like a WG mailing list to see the WGLC that established the rough consensus to publish this document. Is there some venue (e.g., non-wg or non-wg mailing? proceedings?) I could be reviewing where most of the discussion that established rough consensus to publish? I’m guided primarily by RFC8789 (which constrained ADs on sponsored informational and experimental status documents). The one tangible set of discussions I can find is on IETF LC thread/set of feedback (starting at https://mailarchive.ietf.org/arch/msg/last-call/4UPfZ6pQU24Iof3Ic5pt5L3zDi0/). I can see a few objections to publication, responses from authors/ADs, a process discussion, and assigned Last Call Directorate feedback. I’m not disputing that there aren’t responses to objections. I’m hunting for the affirmative basis of the more foundational rough consensus to say that this should be published at all (rather than lack of objections).
==[ PRIOR ABSTAIN TEXT ]== I applaud the community engagement on considering what organizational structure should be used to standardize DNS-related topics. I can see how this style analysis could be input to inform future organizational design. Nevertheless, I am balloting ABSTAIN on this document because I don’t believe it should be published as an RFC. (1) It isn’t clear what it means to have community consensus on a series of facilitated consultations. There is nothing for the community to evaluate or find consensus on beyond agreeing that the facilitation process collected what it did (whether you agree or not) and on the utility of publication. (2) The motivating premise of needing a stable reference for future assessments only being possible with an RFC seems to be challenged by the practical reality of I-Ds in fact being permanent with our archiving system, and that I-Ds are already service as these stable reference regularly for “Specification Required” code point registrations.
Thanks for the work done including the interviews and the aggregation. I fully support the publication of this document for archiving/historical purposes. I also appreciate the mention of dnsdir with its future role in DNSdispatch. Minor comments anyway: ### Section 1.2 I was unable to find any use of BCP14 terms in the text, so, let's remove this section ? ### Section 2.2 This section mentions DNSAPP, which is not part of the list of groups of section 1.1.
Thanks to the author team for taking on this task. Thanks to Thomas Fossati for the ARTART review.
I see no concerns from the WIT Area about this document.
Thanks to the authors, the members of this team, and everyone that participated in this exercise. This is very helpful and you have my gratitude for this service that you have done to the community. I see this document as a recommendation from the community to the IESG to organize DNS related work across areas and WGs. I believe that the document has achieved that goal and I am very optimistic that the IESG will act on it. That said, I see no purpose or value for this to be published as an RFC. It is a record for history but is Informational and not Historic. I-Ds are archived and so will this document along with the IESG ballot as a matter of records for history. I will request the sponsoring AD to consider not publishing this document, but will not stand in the way if they decide to do so anyway.
I want to thank the authors (and everyone they worked with) for doing the hard work of understanding what is needed from an overhaul of DNS WGs. This was super valuable as guidance. Unrelated to the value of the work, I do not believe this needs or even should be published as an RFC. Since this is exactly limited to guidance for IETF participants and leadership internally, with absolutely no affect on implementers of DNS standards, there is no need for publication. Doing so just creates noise in the RFC series for those searching for RFCs relevant to a product or technology they work on, not to mention takes space in the RFC editor queue without benefit to the technical community beyond the IETF. To me, this is the same as WGs publishing their internal requirements documents that show WG consensus on what they need from their future standards as RFCs, where only the WG needs the information. The document lives forever in the archive, so the information is just as safe and immutable, it just doesn't require review process for publication. I know this is also a practice where the community and IESG members have differing opinions. This document may be the kick I need to propose some formal guidance on this larger topic.