[email protected] writes: Greetings, below inline are my thoughts. Thanks for all the help!
> 1) <!--[rfced] We have updated the short title that spans the header of > the PDF file to more closely match the title. Please let us know > of any objection. > > Original: > MUST NOT DNSSEC with ECC-GOST > > > Current: > Deprecate Usage of ECC-GOST > --> Agreed, thank you. > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> I propose these: DNS, DNSSEC, GOST, algorithm, rollover, agility > 3) <!--[rfced] This document discusses no longer using the GOST R 34.10-2001 > and GOST R 34.11-94 algorithms but only "GOST R 34.10-2001" is > mentioned in the first sentence of the Abstract. Is that > intended, or should GOST R 34.11-94 also be included? > > Original: > This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- > GOST") within DNSSEC. > > Perhaps: > This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- > GOST") and GOST R 34.11-94 within DNSSEC. > --> I agree that referencing both is correct. I need to speak with Warren to double check this though. > 4) <!--[rfced] We note that this document does not "update" RFC 5933 but > rather moves it to Historic status. For clarity, may we update > the Abstract to reflect this as shown below? My understanding is that RFC5933 is already historic, so our document doesn't make it so -- we're only making the IANA registries match the status (and stating that it should not be used). Thus the current text is right: > Current: > RFC 5933 (now historic) defined the use of GOST R 34.10-2001 and GOST > R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This > document updates RFC 5933 by deprecating the use of ECC-GOST. Though we could remove "now" to take away any confusion that it's this document that is making it historic. > 5) <!--[rfced] This sentence reads oddly as it sounds like the DNS > Security Extensions were documented in RFC 5933 yet there is a > reference to RFC 9364. For clarity, may we rephrase this as shown > below? [...] > > Perhaps: > The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are > documented in [RFC5933] and their use with DNS Security > Extensions (DNSSEC) is further described in [RFC9364]. Looks good! > 6) <!--[rfced] Would it be clearer to include the descriptive name "GOST > R 34.10-2001" (instead of the mnemonic "ECC-GOST") here for clarity? > We ask because "GOST R 34.11-94" was used in the previous paragraph. [...] > Perhaps: > The GOST R 34.10-2001 algorithm [RFC5933] MUST NOT be used when creating > DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. > Validating resolvers MUST treat RRSIG records created from DNSKEY > records using this algorithm as an unsupported algorithm. Looks good! > 7) <!--[rfced] Section 5. For clarity, may we update this text to reflect > all of IANA's updates? Also, should "DEPRECATED" be added to the > Description column for "GOST R 34.11-94" (to match the entry for > "GOST R 34.10-2001 (DEPRECATED)") as shown below? [...] > Perhaps: [.......] Yep, I am fine with that (and matches what you suggested for sha1 too). > 8) <!-- [rfced] FYI: We updated the reference entries for the IANA > registries to reflect the names of the registries rather than the > registry group names to match the running text. Please let us > know of any objection. Sounds good, thank you. > 9) <!--[rfced] Since most of the names in the Acknowledgments were in > alphabetical order, we reordered a few names so that the full > list is now in alphabetical order. If this is not desired, > please let us know. Good idea, thank you. > 10) <!-- [rfced] FYI - To match the companion documents, we have added > expansions for the following abbreviations per Section 3.6 of RFC > 7322 ("RFC Style Guide"). Please review these and each expansion > in the document carefully to ensure correctness. > > DNS Public Key (DNSKEY) > Delegation Signer (DS) > Resource Record Signature (RRSIG) Yep, also good. Thanks for the help! -- Wes Hardaker Google -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
