Warren approves of all 3 documents in [C544]: draft-ietf-dnsop-rfc8624-bis-13.txt draft-ietf-dnsop-must-not-sha1-10.txt draft-ietf-dnsop-must-not-ecc-gost-07.txt
Thank you very much! W On Wed, Nov 05, 2025 at 8:19 PM, Karen Moore <[email protected]> wrote: > Hi Wes, > > We have noted your approval on the AUTH48 status page (https://www. > rfc-editor.org/auth48/rfc9904). We now require Warren’s approval prior to > moving forward with publication. > > Thank you! > > Karen Moore > RFC Production Center > > On Nov 5, 2025, at 2:34 PM, Wes Hardaker <[email protected]> wrote: > > Karen Moore <[email protected]> writes: > > We have updated the reference entry for "[DS-IANA]” to reflect the direct > registry name. Please review and let us know if any further updates are > needed or if you approve the document in its current form. Once we receive > approvals, we will ask IANA to update the notes in the registries to match > the edited document. > > Thank you. I think with that final change we're good. > -- > Wes Hardaker > Google > > On Nov 5, 2025, at 11:30 AM, Karen Moore <[email protected]> > wrote: > > Hi Wes and Warren, > > We have updated the reference entry for "[DS-IANA]” to reflect the direct > registry name. Please review and let us know if any further updates are > needed or if you approve the document in its current form. Once we receive > approvals, we will ask IANA to update the notes in the registries to match > the edited document. > > —Files (please refresh)— > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9904.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9904.txt > https://www.rfc-editor.org/authors/rfc9904.pdf > https://www.rfc-editor.org/authors/rfc9904.html > > Diff files showing all changes made during AUTH48: https://www.rfc-editor. > org/authors/rfc9904-auth48diff.html https://www.rfc-editor.org/authors/ > rfc9904-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9904-diff.html https://www. > rfc-editor.org/authors/rfc9904-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: https://www. > rfc-editor.org/auth48/rfc9904 > > Best regards, > > Karen Moore > RFC Production Center > > On Nov 5, 2025, at 3:17 AM, Wes Hardaker <[email protected]> wrote: > > Karen Moore <[email protected]> writes: > > 2) We note that in the Normative References section, [DNSKEY-IANA] lists > the direct registry name and [DS-IANA] lists the top registry name. Should > [DS-IANA] list the direct registry name for consistency? > > I think that is best yes. It had to be done for DNSKEY-IANA since there > are two sub-registries within that page and we needed to refer to only the > first. DS-IANA didn't need to be as specific, so we used the more > descriptive (IMHO) longer name. > > But, you're right that consistency is probably better. Thanks for the > suggestion and the switch. > -- > Wes Hardaker > Google > > On Nov 4, 2025, at 1:57 PM, Karen Moore <[email protected]> > wrote: > > Dear Warren and Wes, > > Thank you for your replies (and Wes, thank you for stopping by the RFC > Editor desk at IETF 124!). We have updated our files accordingly. We have > an additional clarification and question. > > 1) Thanks for the clarifications regarding Tables 2 and 3. The only > changes we made were to Table 2 - we updated values 17, 23, 252, and 254 to > reflect the mnemonic names. > > 2) We note that in the Normative References section, [DNSKEY-IANA] lists > the direct registry name and [DS-IANA] lists the top registry name. Should > [DS-IANA] list the direct registry name for consistency? > > --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. We will await approvals from each author prior to moving forward with > the publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9904.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9904.txt > https://www.rfc-editor.org/authors/rfc9904.pdf > https://www.rfc-editor.org/authors/rfc9904.html > > Diff files showing all changes made during AUTH48: https://www.rfc-editor. > org/authors/rfc9904-auth48diff.html https://www.rfc-editor.org/authors/ > rfc9904-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9904-diff.html https://www. > rfc-editor.org/authors/rfc9904-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: https://www. > rfc-editor.org/auth48/rfc9904 > > Best regards, > > Karen Moore > RFC Production Center > > On Nov 4, 2025, at 8:02 AM, Wes Hardaker via auth48archive <auth48archive@ > rfc-editor.org> wrote: > > Warren Kumari <[email protected]> writes: > > I'm following up with some additional comments but any items I didn't > respond to I agreed with Warren (which was generally: good suggestions and > thank you). > > 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 > > Again, add DNSSEC too please. > > 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 > > Yes, and since that's common terminology maybe just "future RFCs" instead > and we'll just stop trying to add "incremental" as it's confusing and > doesn't really help anyway. > > 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. > > [...] > > 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. > > Either is fine with me - whatever y'all and my co-author think…. > > I think A is a bit clearer IMHO. Thanks! > > 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…. > > So these ended up becoming different because we added more columns in the > long run than was originally specified. > > 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. > > Agreed, we should be consistent and mnemonic values should be used. > > 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? > > So I believe that the confusion here is that: > > 1. this document defines the values at the time the RFC is to be > published, but the other two related documents immediately change the > values to more restrictive. Hence, for example, the MUST NOT values for > GOST in the current table exist because IANA has already taken the actions > defined in these algorithms. So in steps they: > > 1. took the values from this document (rfc8624-bis-13) and made columns > for them. > > THEN > > 2. took the values from the must-not-gost document and applied the new > values. > > Thus, the values in the original table are correct because they document > what existed before any of the tables changed as a result of all our > documents. So the history is properly preserved by leaving our values in > the bis document the same, as it's the later must-not-gost and > must-not-sha1 documents that create the new values that have already been > placed into the document. > > Clear as mud? > > In other words: > > 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 > > This is wrong, because those values come from a later-numbered RFC that > changes the values to MUST NOT from the values in this table. > > 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. > > Yep, DNSKEY is correct. thanks. > > -- > Wes Hardaker > Google > > -- > auth48archive mailing list -- [email protected] To unsubscribe > send an email to [email protected] > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
