On Oct 20, 2022, at 5:02 AM, Lars Eggert via Datatracker <nore...@ietf.org> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ## 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.
There was no intention in this document to deal with "standards track", only "best current practice". The draft definitely does not attempt to change the status of any of the RFCs it refers to, and there is nothing in the draft that is meant to change the status of the listed RFCs. If there is a good way to say that explicitly, we should add it. > 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. Correct. > > ### 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. Right: the draft hopefully doesn't imply "just because". > 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] Exactly right. Saying "RFC 4033-4035 are a best current practice" is insufficient because the whole practice of DNSSEC is much larger than them. > ### 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. There are certainly people in the IETF community who would disagree with that statement. It is unclear if the IESG would reject such a proposal. Give your DISCUSS comments above, I'm not sure how to move forward. If you have proposed text changes, that's great. If you are wanting text changes from me, I'd like more direction on how they should change the document. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
