Mohamed Boucadair via Datatracker <[email protected]> writes: Hiya,
Responding to your points inline: > # Process Check > > De we need to do anything given that some of the work we are updating falls > under pre-5378? We don't think so. Specifically this document has no pre-existing text that we're copying from, so don't believe that the pre-5378 stuff applies. This document is entirely written from scratch as new. > # Authoritative source for recommended DNSSEC Algos > > I was naively expecting that we have a document where we say that the > authoritative reference for recommended values is the IANA registry, not > individual RFCs? > > Do we have such document? If so, the explicit updates in the draft may not be > required. The IANA registry table is the table we are trying to update which holds the registry values that indicates the standards level. You may want to review our companion document [1] that progressing at the same time that moves all recommendations into the IANA table because documenting the list only in an RFC turned out to be problematic. This document (must-not-sha1) thus sets the levels to match the recommendation values for implementation and deployment. [1]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/ > # BCP237 Umbrella > > As a big fun of BCP237, I wonder whether we should make this more visible in > our DNSSEC “roadmap” documentation and list this document under the BCP237 > umbrella? So BCP237 currently only has one document within it (RFC9364). I think if we added every future DNSSEC document to the BCP it would likely get overwhelming. I would argue that whether or not and how often we should update BCP237 is a good discussion for the WG as a whole, but it's outside the scope of this particular document (set). But that's very much IMHO. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Expand DNS Public Key (DNSKEY) and resource record digital signature (RRSIG) > in the abstract and introduction. Done. I'm not sure this is standard convention so we'll see if there are others comments about this. > # Introduction > > (1) Reword for better clarity > > s/The security of the SHA-1/The security protection provided by the > SHA-1 Done > > (2) Inappropriate citation > > CURRENT: “DNSSEC [RFC9364] originally [RFC3110]..” > > I would not cite this specific RFC as this may imply that it is RFC that «made > extensive». We could not quite understand what you wanted here, as both references made sense to us. Are you saying the RFC9364 or RFC3110 should be removed? > CURRENT: “Readers are encouraged to consider ..” > > Not sure to parse the intent here? Do you mean implementers? Operators? Both? > Please reword accordingly. Good point, changed to "operators". > (4) > > CURRENT: “has been removed from some systems” > > May cite an example I think the references would all be external and likely changing, thus we can't likely quote them directly. The one that has been talked about the most is RedHat's OSes, but I don't think calling them out in this document would be appropriate. > # Section 2: > > (1) > > CURRENT: “Validating resolver implementations MUST ..” > > Please add a reference to > https://datatracker.ietf.org/doc/html/rfc9499#section-10. done > (2) > > CURRENT: “more security strict environments..” > > Can we characterize this? Or provide an example? Thanks. Not likely, as it's a highly subjective discussion that warrants an RFC or academic or industry white paper in itself. The security community will always disagree on the right level of hammer for the right job. > # IANA Considerations > > CURRENT: “IANA is requested to set the "Use for DNSSEC Signing" column …” > > There is no such column. I guess you meant “Zone Signing”? This document is modifying the table as being modified by the previously discussed companion document above [1]. That document introduces the new columns that we're now changing. This document is, essentially, the first test of that new process. > You have many references that are listed but not sued (RFC4033, RFC4509, > RFC5702, etc.). Please check these. Done. > Also, there is a problem in how the references are classified. For example, > you > list “RFC8174” as informative, while this should be normative. Likewise, > “RFC3110” is listed as normative, while it should be informative. 8174 has been fixed (thanks) 3110 is the basis for what we're modifying as recommended, so IMHO it should be normative (but is not a hill I'll die on either). -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
