Meta comment: As always, thank you very much, RFC Edior…. On Wed, Oct 29, 2025 at 11:04 PM, <[email protected]> wrote:
> Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> > > DNS, rollover, agility > 2) <!--[rfced] In the first sentence, should "an IANA registry" be updated > to "the IANA DNSSEC algorithm registries"? In the second sentence, should > "this registry" be updated to "these registries"? > Yes please! If not, should the registry name be included for clarity? > > Also, please clarify "incremental update RFCs". Is the intended meaning > that future extensions can be made under new, incremental RFCs that update > this document? > TBD > Current: > This document replaces and obsoletes RFC 8624 and moves the canonical > source of algorithm implementation requirements and usage guidance for > DNSSEC from RFC 8624 to an IANA registry. > > Future extensions to this registry can be made under new, incremental > update RFCs. > > Perhaps: > This document replaces and obsoletes RFC 8624 and moves the canonical > source of algorithm implementation requirements and usage guidance for > DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. > > Future extensions to these registries can be made under new, incremental > RFCs that update this document. > --> > > 3) <!--[rfced] We assume that the second instance of "the list" is "the > list of requirements"; therefore, we have updated this sentence for clarity > as shown below. Please let us know if this is incorrect. > > Original: > This is done both to allow the list of requirements to be more easily > updated, and to allow the list to be more easily referenced. > > Current: > This is done to allow the list of requirements to be more easily updated > and referenced. > --> > > Great, thank you! > 4) <!--[rfced] FYI: We added that this document "updates RFC 9157" in the > Abstract as shown below. > > Original: > This document also incorporates the revised IANA DNSSEC considerations > from RFC9157. > > Current: > This document also updates RFC 9157 and incorporates the revised IANA > DNSSEC considerations from that RFC. > --> > > Great, thank you! > 5) <!--[rfced] Should "MUST", "MAY", and "RECOMMENDED" be referred to as > the "recommendation status" or the "DNSSEC delegation, signing, or > validation status" rather than "status" for clarity? > > Original: > The document does not change the status (MUST, MAY, RECOMMENDED, etc.) of > the algorithms listed in RFC8624; that is the work of future documents. > > Perhaps: > This document does not change the recommendation status (MUST, MAY, > RECOMMENDED, etc.) of the algorithms listed in RFC 8624; that is the work > of future documents. > --> > > Yup, thank you! > 6) <!--[rfced] FYI: We updated the second IANA registry listed below to > reflect the registry name rather than the registry group for clarity and > consistency. > > Original: > The columns added to the IANA "DNS Security Algorithm Numbers" > [DNSKEY-IANA] and "DNSSEC Delegation Signer (DS) Resource Record (RR) Type > Digest Algorithms" [DS-IANA] registries target DNSSEC operators and > implementers. > > Current: > The columns added to the IANA "DNS Security Algorithm Numbers" > [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA] registries target DNSSEC > operators and implementers. > --> > > Thanks! > 7) <!--[rfced] Questions about Section 2.2 > > a) In this section, may we put the notes that appear in the IANA registry > within <blockquote>? Should lead-in sentences be added for clarity? If so, > please provide the desired text. > > Perhaps: > The following note describing the procedures for adding and changing > values has been added to the "DNS Security Algorithm Numbers" registry: > > Note: ... > > The following note has been added to the "Digest Algorithms" registry: > > Note: ... > > b) May we update the phrasing of these two paragraphs for ease of reading > as shown below (i.e., make "existing values" singular for consistency and > move the '"any value other than "May"' phrasing up)? If agreeable, we will > ask IANA to make the same updates to the notes in the corresponding > registries. > Yes please! > c) In the first example below, should the "DNS System Algorithm Numbers" > registry be updated to the "DNS Security Algorithm Numbers" registry? Note > that this registry name also appears in the first paragraph in Section 2.2. > > d) Note: Per IANA's note, we have updated the "DNS System Algorithm > Numbers" registry to the "Digest Algorithms" registry in the second example > shown below. > > Original: > Adding a new entry to, or changing existing values in, the "DNS System > Algorithm Numbers" registry for the "Use for DNSSEC Signing", "Use for > DNSSEC Validation", "Implement for DNSSEC Signing", or "Implement for > DNSSEC Validation" columns to any other value than "MAY" requires a > Standards Action. > > Perhaps: > Adding a new entry to, or changing an existing value in, the "DNS Security > Algorithm Numbers" registry that has any value other than > "MAY" in the "Use for DNSSEC Signing", "Use for DNSSEC Validation", > "Implement for DNSSEC Signing", or "Implement for DNSSEC Validation" > columns requires Standards Action. > > ... > Original: > Adding a new entry to, or changing existing values in, the "DNS System > Algorithm Numbers" registry for the "Use for DNSSEC Delegation", "Use for > DNSSEC Validation", "Implement for DNSSEC Delegation", or > "Implement for DNSSEC Validation" columns to any other value than > "MAY" requires a Standards Action. > > Perhaps: > Adding a new entry to, or changing an existing value in, the > "Digest Algorithm Numbers" registry that has any value other than > "MAY" in the "Use for DNSSEC Delegation", "Use for DNSSEC Validation", > "Implement for DNSSEC Delegation", or "Implement for DNSSEC Validation" > columns requires Standards Action. > --> > > Yes to all! > 8) <!--[rfced] Section 3. Since there are multiple registries under the > "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group, > we added the registry name for clarity as shown below. > > Also, to avoid using "recommendation" twice, do you prefer option A, which > matches the title of Table 2, or option B? Note that there is similar text > in Section 4 that we would also apply this update to. > > Original: > Initial recommendation columns of use and implementation recommendations > for the "Domain Name System Security (DNSSEC) Algorithm Numbers" are shown > in Table 2. > > Perhaps A: > Initial values for the use and implementation recommendation columns in > the "DNS Security Algorithm Numbers" registry under the "Domain Name System > Security (DNSSEC) Algorithm Numbers" registry group are shown in Table 2. > > or > Perhaps B: > Initial use and implementation recommendation columns in the > "DNS Security Algorithm Numbers" registry under the "Domain Name System > Security (DNSSEC) Algorithm Numbers" registry group are shown in Table 2. > --> > > Either is fine with me - whatever y'all and my co-author think…. > 9) <!--[rfced] Should "use" be "Use for" and "column" be "columns"? If > not, please clarify which "use" column this is referring to. Note that this > sentence occurs in Sections 3 and 4. > > Original: > When there are multiple RECOMMENDED algorithms in the "use" column, > operators should choose the best algorithm according to local policy. > > Perhaps: > When there are multiple RECOMMENDED algorithms in the "Use for" columns, > operators should choose the best algorithm according to local policy. > --> > > Yes! > 10) <!--[rfced] Questions about Table 2 > > a) In Table 2, some of the values in the "Use for" and > "Implement for" columns are different than what is listed in "DNS Security > Algorithm Numbers" registry (specifically, see numbers 5, 7, and 12). > Should Table 2 be updated to match the IANA registry as shown below, or > should the IANA registry be updated to match Table 2? > > The IANA Registry should be updated (which kicked this off); my co-author and I will discuss…. > b) In Table 2, numbers 17, 23, 253, and 254 use terms from the Description > column in the registry whereas the rest of the numbers use terms from the > Mnemonic column. Should these numbers be updated to use the mnemonic terms > for consistency as shown below, or do you prefer otherwise? > > Registry URL: <https://www.iana.org/assignments/dns-sec-alg-numbers/> > > Original: > > 5 RSASHA1 NOT RECOMMENDED|RECOMMENDED|NOT RECOMMENDED|MUST 7 > RSASHA1-NSEC3-SHA1 NOT RECOMMENDED|RECOMMENDED|NOT RECOMMENDED|MUST 12 > ECC-GOST MUST NOT | MAY |MUST NOT |MAY 17 SM2/SM3 ... > 23 GOST R > 34.10-2012 > 253 private algorithm > 254 private algorithm OID > > Perhaps (to match the IANA registry): > > 5 RSASHA1 MUST NOT |RECOMMENDED |NOT RECOMMENDED |MUST 7 > RSASHA1-NSEC3-SHA1 MUST NOT |RECOMMENDED |NOT RECOMMENDED |MUST 12 ECC-GOST > MUST NOT |MUST NOT |MUST NOT |MUST NOT 17 SM2SM3 ... > 23 ECC-GOST12 > 253 PRIVATEDNS > 254 PRIVATEOID > --> > > Ooooh, good catch. I like your proposal… > 11) <!--[rfced] FYI: We updated the titles of Section 4 and Table 3 to > reflect the registry name rather than the registry group name for clarity > and consistency as shown below. > > Original (Section 4): > 4. DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest > Algorithms Column Values > > Current: > 4. Digest Algorithms Registry Column Values > > ... > Original (Table 3 title): > Initial values for the DNSSEC Delegation Signer (DS) Resource Record (RR) > Type Digest Algorithms columns > > Current: > Initial Values for the Digest Algorithms Registry Columns > --> > > Yes please. > 12) <!--[rfced] We note differences between Table 3 and the "Digest > Algorithms" registry. Should this document be updated to match the registry > as shown below, or should the registry be updated to match this document? > > We also note that this document is listed as a reference for values > 128-252 and 253-254. Should this document be listed as a reference for any > other values in the registry? > > Registry URL: <https://www.iana.org/assignments/ds-rr-types/> > > Original: > > 0 NULL > (CDS only) MUST NOT | MUST NOT | MUST NOT | MUST NOT > > 3 GOST R > 34.11-94 MUST NOT | MAY | MUST NOT | MAY > > Perhaps (to match the IANA registry): > > 0 Reserved MUST NOT | MUST NOT | MUST NOT | MUST NOT > > 3 GOST R > 34.11-94 MUST NOT | MUST NOT | MUST NOT | MUST NOT > --> > > The registry should be updated. My co-author will also reply. > 13) <!--[rfced] In Section 7.1, we made the following text into a bulleted > list to match Section 7.2. We also updated "Section 2" to > "Section 2.2" in both sections. Please let us know of any objection to > these changes. > > Original: > Additionally, the registration policy for the [DNSKEY-IANA] registry > should match the text describing the requirements in this document, and > Section 2's note concerning values not marked as > "RECOMMENDED" should be added to the registry. > > This document should be listed as a reference to the "DNS Security > Algorithm Numbers" registry. > > Current: > Additionally, IANA has completed the following actions for the "DNS > Security Algorithm Numbers" registry [DNSKEY-IANA]: > > * Changed the registration procedure to Standards Action or Specification > Required. > > * Added a note to the registry that describes the values not marked as > "RECOMMENDED" per Section 2.2. > > * Listed this document as an additional reference for the registry. > --> > > No objections / thanks! > 14) <!--[rfced] Terminology > > FYI: We have updated the following terms to the form on the right for > consistency. Please let us know of any objection. > > ciphersuite -> cipher suite (to match the "TLS Cipher Suites" registry) > non-existence -> nonexistence (per RFC 8624) > --> > > Unsurprisingly, no objections…. > 15) <!-- [rfced] FYI: We have added an expansion for the following > abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > this and each expansion in the document carefully to ensure correctness. > > DNS Public Key (DNSKEY) > --> > > Huh. Yes, that looks right — in my brain it is just "DNS Key", but RFC 4034, etc show you to be correct. > 16) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide <https://www.rfc-editor.org/styleguide/part2/ > #inclusive_language> and let us know if any changes are needed. Updates > of this nature typically result in more precise language, which is helpful > for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > > > Thank you. > > Karen Moore > RFC Production Center > > On Oct 29, 2025, at 8:03 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/29 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. If an > author is no longer available, there are several remedies available as > listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing your > approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor that have > been included in the XML file as comments marked as follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your coauthors. We > assume that if you do not speak up that you agree to changes submitted by > your coauthors. > > * Content > > Please review the full content of the document, as this cannot change once > the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in RFC 5378 and > the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> and > <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the formatted > output, as generated from the markup in the XML file, is reasonable. Please > note that the TXT will have formatting limitations compared to the PDF and > HTML. > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all the > parties CCed on this message need to see your changes. The parties include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., IETF Stream > participants are your working group chairs, the responsible ADs, and the > document shepherd). > > * [email protected], which is a new archival mailing list to > preserve AUTH48 conversations; it is not an active discussion list: > > * More info: > https://mailarchive.ietf.org/arch/msg/ietf-announce/ > yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out of the > archiving of messages (e.g., to discuss a sensitive matter). If needed, > please add a note at the top of the message that you have dropped the > address. When the discussion is concluded, [email protected] > will be re-added to the CC list and its addition will be noted at the top > of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, as all > the parties CCed on this message need to see your approval. > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9904.xml > https://www.rfc-editor.org/authors/rfc9904.html > https://www.rfc-editor.org/authors/rfc9904.pdf > https://www.rfc-editor.org/authors/rfc9904.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9904-diff.html https://www. > rfc-editor.org/authors/rfc9904-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9904-xmldiff1.html > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: https://www. > rfc-editor.org/auth48/rfc9904 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9904 (draft-ietf-dnsop-rfc8624-bis-13) > > Title : DNSSEC Cryptographic Algorithm Recommendation Update Process > Author(s) : W. Hardaker, W. Kumari > WG Chair(s) : Benno Overeinder, Ond?ej Surý > > Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
