Hi Wes and Warren, Thank you for your replies. We have updated our files accordingly; please review. We noted Warren’s approval of the document on the AUTH48 status page. We now await approval from Wes.
--Files-- Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Updated XML file: https://www.rfc-editor.org/authors/rfc9906.xml Updated output files: https://www.rfc-editor.org/authors/rfc9906.txt https://www.rfc-editor.org/authors/rfc9906.pdf https://www.rfc-editor.org/authors/rfc9906.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9906-auth48diff.html https://www.rfc-editor.org/authors/rfc9906-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9906-diff.html https://www.rfc-editor.org/authors/rfc9906-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9906 Best regards, Karen Moore RFC Production Center > On Nov 4, 2025, at 12:49 PM, Warren Kumari <[email protected]> wrote: > > > > > > On Tue, Nov 04, 2025 at 12:22 PM, Wes Hardaker <[email protected]> wrote: > [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. > > > Yup, seems fine. > > > 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 > > > Warren snarkily points at "(beyond those that appear in the title)" :-) > > > 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. > > ¯\_(ツ)_/¯. I believe that the current wording was chosen because GOST 94 was > already retired (I believe by 2001) and so this doesn't doesn't **really** do > the above. But it does seem helpful to the reader, so even if it is not > technically 100% right it seems good…. > > > > > 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. > > Yup. This whole situation is complicated, but Wes is correct… 5933 is already > historic, so we are updating a historic doc…which is weird, but… Removing > "now" seems helpful… > > > > 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! > > > +1! > > > 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! > > Errrrr… I disagree — the IANA registry calls it "ECC-GOST", and we want it to > be clear that that is the one that is being deprecated. We saw many instances > where people (including ourselves!) got confused by the similarity of the > strings "GOST R 34.10-2001" and "GOST R 34.10-2012". > > Perhaps: > "The GOST R 34.10-2001 algorithm [RFC5933] (mnemonic "ECC-GOST ") MUST NOT be > used…" > Or something… > > Note: This is not a hill I'm willing to die on. I approve publication > whatever y'all decide... > > > 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). > > +1. > > > 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. > > > Also +1. > > > 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. > > > Yah! > > > 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. > > > Yup! > > > Thanks for the help! > > +many lots! > Thanks RFC Ed! > > W > > > > > -- > Wes Hardaker > Google > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
