On Oct 20, 2022, at 5:02 AM, Lars Eggert via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-dnsop-dnssec-bcp-05 > ## 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. >
I have just submitted -06 which I believe addresses your concerns. If so, please lift the DISCUSS position and let the draft wing its way towards the RFC Editor. If not, please let me know which parts still could be clarified, and I will do so after the draft cutoff window opens again. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
