Hi Peter (and *Med), [*Med - please review/approve the following text additions in Peter’s mail or the lastdiff files below.]
Thank you for sending along these updates. We have incorporated them in the files as requested. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9975.txt https://www.rfc-editor.org/authors/rfc9975.pdf https://www.rfc-editor.org/authors/rfc9975.html https://www.rfc-editor.org/authors/rfc9975.xml The diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9975-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9975-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9975-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9975-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9975-lastdiff.html (last version to this) https://www.rfc-editor.org/authors/rfc9975-lastrfcdiff.html (side by side) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9975 Thank you. Megan Ferguson RFC Production Center > On May 18, 2026, at 10:31 AM, Peter Thomassen | SSE <[email protected]> > wrote: > > I am sorry, my email client has eaten a bunch of spaces. Retrying: > > Hi Megan, > > Thank you for the update, it all looks good. Meanwhile, I've discussed the > following change with Med, the responsible AD, and we'd like to edit as > follows (Med, I suppose you need to confirm separately): > > OLD > As an example of local policy, the parent may restrict the choice of > hash digest types used when publishing a DS RRset (notwithstanding > the requirements specified in [DS-IANA]). (The set of keys > referenced in the DS RRset is not up to local policy. Only if all > keys from the CDS/CDNSKEY RRsets are included is the DS RRset > considered consistent.) > > NEW > CDS records MUST be considered for consistency only when their digest > type field is designated as "MUST" in the "Implement for DNSSEC > Delegation" column of the "Digest Algorithms" registry [DS-IANA]. > Consistency of records with other digest types need not be verified, > especially when the digest type is unsupported; such records can be > ignored. > > Independently of this, the parent may, as a matter of local policy, > make its own choice regarding the hash digest types used when > publishing a DS RRset (notwithstanding the requirements specified in > [DS-IANA]). (The set of keys referenced in the DS RRset is not up to > local policy. Only if all keys from the CDNSKEY RRset and eligible > CDS records are included is the DS RRset considered consistent.) > > For coherency with the previous paragraphs, the following two changes are > then required there: > > OLD > The Parental Agent MUST also ensure that each key referenced > in any of the received answers is also referenced in all other > received responses or that responses consistently indicate a request > > NEW > The Parental Agent MUST also ensure that each key referenced > in any of the received answers is also referenced in all other > received responses (subject to the CDS digest type considerations below) or > that responses consistently indicate a request > > ... and: > > OLD > determined by the delegation's NS record set. When a key is > referenced in a CDS record set but not the CDNSKEY record set (or > > NEW > determined by the delegation's NS record set. When a key is > referenced in an eligible CDS record but not the CDNSKEY record set (or > > With these changes, I approve the publication of the document. > > Thank you very much, > Peter > > > On 5/18/26 18:28, Peter Thomassen | SSE wrote: >> Hi Megan, >> Thank you for the update, it all looks good. Meanwhile, I've discussed the >> following change with Med, the responsible AD, and we'd like to edit as >> follows (Med, I suppose you need to confirm separately): >> OLD >> As an example of local policy, the parent may restrict the choice of >> hash digest types used when publishing a DS RRset (notwithstanding >> the requirements specified in [DS-IANA]). (The set of keys >> referenced in the DS RRset is not up to local policy. Only if all >> keys from the CDS/CDNSKEY RRsets are included is the DS RRset >> considered consistent.) >> NEW >> CDS records MUST be considered for consistency only when their digest >> type field is designated as "MUST" in the"Implement for DNSSEC >> Delegation" column of the "Digest Algorithms"registry [DS-IANA]. >> Consistency of records with other digest types need not be verified, >> especially when the digest type is unsupported; suchrecords can be >> ignored. >> Independently of this, the parent may, as a matter of local policy, >> make its own choice regarding the hash digest types used when >> publishing a DS RRset (notwithstanding the requirements specified in >> [DS-IANA]).(The set of keys referenced in the DS RRset is not up to >> local policy. Only if all keys from the CDNSKEY RRset and eligible >> CDS records areincluded is the DSRRsetconsidered consistent.) >> For coherency with the previous paragraphs, the following two changes are >> then required there: >> OLD >> The Parental Agent MUST also ensure that each key referenced >> in any of the received answers is also referenced in all other >> received responses or that responses consistently indicate a request >> NEW >> The Parental Agent MUST also ensure that each key referenced >> in any of the received answers is also referenced in all other >> received responses (subject to the CDS digest type considerations below) >> or that responses consistently indicate a request >> ... and: >> OLD >> determined by the delegation's NS record set. When a key is >> referenced in a CDS record set but not the CDNSKEY record set (or >> NEW >> determined by the delegation's NS record set. When a key is >> referenced in an eligible CDS record but not the CDNSKEY record set (or >> With these changes, I approve the publication of the document. >> Thank you very much, >> Peter >> On 5/7/26 19:26, Megan Ferguson wrote: >>> [Sie erhalten nicht häufig E-Mails von [email protected]. >>> Weitere Informationen, warum dies wichtig ist, finden Sie unter >>> https://aka.ms/LearnAboutSenderIdentification ] >>> >>> Hi Peter, >>> >>> Thank you for the reply and guidance. We have updated as requested. >>> >>> Please review carefully as we do not make changes once the document is >>> published as an RFC. >>> >>> Two notes: Please see the update to use “their own copy” for #9 and our >>> update to your organization to shorten it up for the header. Please let us >>> know any objections to either change. >>> >>> We will wait to hear from you further regarding any further changes and/or >>> your approval of the document in its current form. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9975.txt >>> https://www.rfc-editor.org/authors/rfc9975.pdf >>> https://www.rfc-editor.org/authors/rfc9975.html >>> https://www.rfc-editor.org/authors/rfc9975.xml >>> >>> The diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9975-diff.html (comprehensive) >>> https://www.rfc-editor.org/authors/rfc9975-rfcdiff.html (side by side) >>> >>> https://www.rfc-editor.org/authors/rfc9975-auth48diff.html (AUTH48 only) >>> https://www.rfc-editor.org/authors/rfc9975-auth48rfcdiff.html (side by >>> side) >>> >>> The AUTH48 status page for this document is available here: >>> https://www.rfc-editor.org/auth48/rfc9975 >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>> >>>> On May 7, 2026, at 9:39 AM, Peter Thomassen | SSE >>>> <[email protected]> wrote: >>>> >>>> Hi Megan, >>>> >>>> On 5/6/26 16:14, [email protected] wrote: >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the source file. >>>>> 1) <!--[rfced] Please note that we have updated the abbreviated title for >>>>> this document from "cds-consistency" to instead read as "CDS >>>>> Consistency". Please let us know any objections. --> >>>> >>>> Even better would be "CDS/CDNSKEY/CSYNC Consistency", in line with the >>>> long title. >>>> >>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>> the title) for use on https://www.rfc-editor.org/search. --> >>>> >>>> DNSSEC, DS, CDS, CDNSKEY, CSYNC, automation >>>> >>>>> 3) <!--[rfced] We had a few questions regarding the following text: >>>>> Original: >>>>> The corresponding Section 6.1 of [RFC7344] (CDS/CDNSKEY) contains no >>>>> provision for how specifically queries for these records should be >>>>> done. >>>>> a) "The corresponding Section 6.1" sounds a bit strange (as it is being >>>>> compared to Section 3.1 of RFC 7477). May we update as follows? >>>>> Perhaps: >>>>> [RFC7344] has a corresponding section (Section 6.1) (CDS/CDNSKEY) that >>>>> contains no provision for how specifically queries for these records >>>>> should be done. >>>> >>>> Sure. >>>> >>>>> b) How does the parenthetical (CDS/CDNSKEY) relate to the sentence? >>>>> It is not the title of Section 6.1. Please review. >>>> >>>> This is to contrast with the previous section: RFC 7477 is on CSYNC, RFC >>>> 7344 is on CDS/CDNSKEY. Perhaps: >>>> >>>> NEW >>>> For CDS/CDNSKEY, [RFC7344] has a corresponding section (Section 6.1) that >>>> contains no provision for how specifically queries for these records >>>> should be done. >>>> >>>> But now both sentences start with "For". Alternatively, >>>> >>>> NEW >>>> [RFC7344] (on CDS/CDNSKEY) has a corresponding section (Section 6.1) that >>>> contains no provision for how specifically queries for these records >>>> should be done. >>>> >>>> or similar. >>>> >>>>> 4) <!--[rfced] Please review this use of the plural possessive (as >>>>> previous text in the same paragraph used singular possessive). >>>>> Original: >>>>> In any case, a single provider should not be in the position to remove >>>>> the other providers' records from the delegation. >>>>> Perhaps: >>>>> In any case, a single provider should not be in the position to remove >>>>> the other provider's records from the delegation. >>>>> --> >>>> >>>> That was intentional, as the example is with 2 providers (one, and the >>>> other) while the conclusion is generalized (one, and the others). >>>> >>>> Although I prefer the original, this could also work: >>>> >>>> NEW >>>> In any case, a single provider should not be in the position to remove >>>> any other provider's records from the delegation. >>>> >>>> (but it gives us two "any"s.) >>>> >>>>> 5) <!--[rfced] Would it make sense to add a pointer to RFC 2308 or RFC >>>>> 9499 on first use of NODATA for the ease of the reader? >>>>> Original: >>>>> (A NODATA response is a received response.) >>>>> Perhaps: >>>>> (A NODATA response [RFC9499] is a received response.) >>>>> --> >>>> >>>> Yes, good idea! >>>> >>>>> 6) <!--[rfced] Would it make sense to make the following update for a >>>>> parallel between implicitly and explicitly? >>>>> Original: >>>>> Any pending queries can immediately be dequeued when encountering a >>>>> response that confirms the status quo, either implicitly (NODATA) or >>>>> explicitly. >>>>> Perhaps: >>>>> Any pending queries can immediately be dequeued when encountering a >>>>> response that confirms the status quo, either implicitly (NODATA) or >>>>> explicitly (via a response that matches the current delegation state). >>>>> --> >>>> >>>> Sure, why not! >>>> >>>>> 7) <!--[rfced] [AD] May we break up this sentence as follows? As it >>>>> would require repetition of a BCP 14 keyword, please advise: >>>>> Original: >>>>> To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust >>>>> maintenance, the Parental Agent, knowing both the Child zone name and >>>>> its NS hostnames, MUST ascertain that queries are made against all >>>>> nameservers listed in the Child's delegation from the Parent, and >>>>> ensure that each key referenced in any of the received answers is >>>>> also referenced in all other received responses, or that responses >>>>> consistently indicate a request for removal of the entire DS RRset >>>>> ([RFC8078], Section 6). >>>>> Perhaps: >>>>> To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust >>>>> maintenance, the Parental Agent, knowing both the Child zone name >>>>> and its NS hostnames, MUST ascertain that queries are made against >>>>> all nameservers listed in the Child's delegation from the Parent. >>>>> It MUST also ensure that each key referenced in any of the received >>>>> answers is also referenced in all other received responses or that >>>>> responses consistently indicate a request for removal of the entire >>>>> DS RRset ([RFC8078], Section 6). >>>>> --> >>>> >>>> Works for me, and concur with Med about "s/it/The Parental Agent". >>>> >>>> Let's also change the first two words "To retrieve" --> "When retrieving". >>>> >>>>> 8) <!-- [rfced] Would you like the references to be alphabetized >>>>> or left in their current order? >>>>> --> >>>> >>>> Alphabetic is fine. >>>> >>>>> 9) <!--[rfced] Is this a shared copy? >>>>> Original: >>>>> First, the providers include each other's signing keys as DNSKEY and >>>>> CDS/CDNSKEY records in their copy of the zone. >>>>> Perhaps: >>>>> First, the providers include each other's signing keys as DNSKEY and >>>>> CDS/CDNSKEY records in their copies of the zone. >>>>> --> >>>> >>>> Most records in the zone would be identical, but not all (the SOA and >>>> DNSKEY RRsets typically differ, as well as NSEC(3), NSEC3PARAM, RRSIGs and >>>> ZONEMD). >>>> >>>> That said, I'm not sure what you're asking. However, as each provider only >>>> includes stuff in their own copy, singular for the inclusion target seems >>>> appropriate. >>>> >>>>> 10) <!--[rfced] We had the following questions about abbreviations used >>>>> throughout the document: >>>>> a) How may we expand DS? Delegation Signer as used in RFC 4034? >>>>> b) How may we expand EPP? Extensible Provisioning Protocol as used in >>>>> RFC 5730? >>>>> --> >>>> >>>> Yes! >>>> >>>>> 11) <!--[rfced] The following similar forms are used throughout the >>>>> document. Please let us know if/how the >>>>> y may be made uniform: >>>>> child vs. Child >>>>> parent vs. Parent >>>>> --> >>>> >>>> Uppercase is when the acting entity is meant (RFC 7344 terminology that is >>>> included via Section 1.2). Lowercase is the standard DNS use (it can refer >>>> to the zone or the concept of a child domain). >>>> >>>> I think there is no difficulty in understanding this for the typical >>>> reader, and I see no need for harmonization. If you'd prefer that, >>>> however, it should all be lowercase. >>>> >>>>> 13) <!-- [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. >>>>> --> >>>> >>>> Done. I've also reviewed the document generally and it all looks good. >>>> >>>> However, please hold off with publication; I have a minor adjustment to >>>> propose that I will first discuss with the AD. >>>> >>>> Best, >>>> Peter >>>> >>>>> Thank you. >>>>> Megan Ferguson >>>>> RFC Production Center >>>>> *****IMPORTANT***** >>>>> Updated 2026/05/06 >>>>> 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/rfc9975.xml >>>>> https://www.rfc-editor.org/authors/rfc9975.html >>>>> https://www.rfc-editor.org/authors/rfc9975.pdf >>>>> https://www.rfc-editor.org/authors/rfc9975.txt >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9975-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9975-rfcdiff.html (side by side) >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9975-xmldiff1.html >>>>> Tracking progress >>>>> ----------------- >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9975 >>>>> Please let us know if you have any questions. >>>>> Thank you for your cooperation, >>>>> RFC Editor >>>>> -------------------------------------- >>>>> RFC9975 (draft-ietf-dnsop-cds-consistency-11) >>>>> Title : Clarifications on CDS/CDNSKEY and CSYNC Consistency >>>>> Author(s) : P. Thomassen >>>>> 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]
