Lars Eggert has entered the following ballot position for draft-ietf-dnsop-dnssec-bcp-05: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-dnsop-dnssec-bcp-05 CC @larseggert Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/TNMpPSf36E8i5Nt96FoRSlbjPFA). ## Discuss ### "Abstract", paragraph 1 ``` This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. ``` I don't understand what "move DNSSEC to Best Current Practice status" means in terms of the standards track. I'm all for advancing the RFC set that makes up DNSSEC along the standards track, but BCP it not part of that track. Publishing a BCP that normatively references some DNSSEC RFCs isn't doing anything in terms of moving them forward. ### Section 1.1, paragraph 2 ``` The DNSSEC set of protocols is the best current practice for adding origin authentication of data in the DNS. To date, no standards- track RFCs offer any other method for such origin authentication of data in the DNS. ``` Just because no other standards track RFCs compete with DNSSEC does not mean it is a BCP. A BCP is something else, i.e. "The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations." [RFC2026] ### Section 1.1, paragraph 1 ``` However, this low level of implementation does not affect whether DNSSEC is a best current practice; it just indicates that the value of deploying DNSSEC is often considered lower than the cost. ``` Protocols aren't BCPs. HTTP isn't the "best current practice" for transporting HTML either. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Outdated references Reference `[RFC2535]` to `RFC2535`, which was obsoleted by `RFC4033`, `RFC4034`, and `RFC4035` (this may be on purpose). Reference `[RFC2065]` to `RFC2065`, which was obsoleted by `RFC2535` (this may be on purpose). ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
