Hello Martine and *coauthors, We have updated "Section 2.7" to "Section 2.9” (in Section 7). With this change, we have noted your approval of the format on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9953).
*Christian, Cenk, Thomas, and Matthias, please review the XML file and its TXT, HTML, and PDF outputs, and let us know if any changes are required or if you approve the RFC for publication. While this is your approval of the XML and its outputs, we consider this your final assent that the document is ready for publication. To request changes or approve your RFC for publication, please reply to this email. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Note that we will only make changes in the XML file from this point on. —Files (please refresh)— XML file: https://www.rfc-editor.org/authors/rfc9953.xml Output files: https://www.rfc-editor.org/authors/rfc9953.html https://www.rfc-editor.org/authors/rfc9953.pdf https://www.rfc-editor.org/authors/rfc9953.txt Lastdiff of the text (shows only the format changes): https://www.rfc-editor.org/authors/rfc9953-lastdiff.html https://www.rfc-editor.org/authors/rfc9953-lastrfcdiff.html (side by side) Comprehensive diff file of the text: https://www.rfc-editor.org/authors/rfc9953-diff.html https://www.rfc-editor.org/authors/rfc9953-rfcdiff.html (side by side) Thank you, Karen Moore RFC Production Center > On Mar 24, 2026, at 11:50 PM, Martine Sophie Lenders > <[email protected]> wrote: > > Hello Karen, hello co-authors, > > again only non-rendered parts are removed and the PRE-RFC9952 reference is > changed to RFC9952. However, the versions of [COAP-CORR-CLAR] and > [RFC7228bis] also changed. With [COAP-CORR-CLAR] this means that the Section > reference in the first paragraph of Section 7 needs to be changed. While > checking that, I noticed that I made a mistake in the content review. The > section that needs to be referenced is now 2.9 in corr-clar-04 (was 2.8 in > -03, NOT 2.7), see [1] where the reference was originally introduced and > pointed to the then Section 2.6 "RFC 7252-9.1/11.3: Handling outdated > addresses and security contexts" (which is Section 2.9 in corr-clar-04). As > such, please make the following change in Section 7: > > Current: > Section 2.7 of > [CoAP-CORR-CLAR] provides insights on what can be done when those are > resumed from a new endpoint. > > Change: > Section 2.9 of > [CoAP-CORR-CLAR] provides insights on what can be done when those are > resumed from a new endpoint. > > The [RFC7228bis] reference does not refer to a specific section and the > information we are referencing is still in the document. So, after the change > above, we are good to go, I believe. > > Best > Martine > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap-10#section-8 > > On 3/25/26 06:57, Karen Moore wrote: >> Hello authors, >> We have converted the kramdown-rfc file to RFCXML. Note that we have updated >> “[PRE-RFC9952]” to “[RFC9952]”, and we have updated the title of RFC-to-be >> 9952 to match the edited document. >> Please review the XML file and its TXT, HTML, and PDF outputs, and let us >> know if any changes are required or if you approve the RFC for publication. >> While this is your approval of the XML and its outputs, we consider this >> your final assent that the document is ready for publication. To request >> changes or approve your RFC for publication, please reply to this email. >> Please use ‘REPLY ALL’, as all the parties CCed on this message need to see >> your approval. >> Note that we will only make changes in the XML file from this point on. >> XML file: >> https://www.rfc-editor.org/authors/rfc9953.xml >> Output files: >> https://www.rfc-editor.org/authors/rfc9953.html >> https://www.rfc-editor.org/authors/rfc9953.pdf >> https://www.rfc-editor.org/authors/rfc9953.txt >> Lastdiff of the text (shows only the format changes): >> https://www.rfc-editor.org/authors/rfc9953-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9953-lastrfcdiff.html (side by side) >> Comprehensive diff file of the text: >> https://www.rfc-editor.org/authors/rfc9953-diff.html >> https://www.rfc-editor.org/authors/rfc9953-rfcdiff.html (side by side) >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9953 >> Thank you, >> Karen Moore >> RFC Production Center >>> On Mar 24, 2026, at 9:49 PM, Karen Moore <[email protected]> >>> wrote: >>> >>> Hi Mike, Martine, and Marco, >>> >>> Thank you for your replies. We have noted Mike’s approval of the beyond >>> editorial changes on the AUTH48 status page >>> (https://www.rfc-editor.org/auth48/rfc9953). >>> >>> Given the current status of RFC-to-be 9846 and that no author approvals >>> have been received to date, we will leave references to RFC 8446 in this >>> document as is. >>> >>> Authors, now that we have received all necessary approvals of the content, >>> we will be proceeding with Part 2 of AUTH48; we will contact you shortly >>> regarding the format of the XML and output files. >>> >>> Best regards, >>> >>> Karen Moore >>> RFC Production Center >>> >>> >>>> On Mar 24, 2026, at 3:52 PM, Mike Bishop <[email protected]> wrote: >>>> >>>> Works for me. >>>> >>>> >>>> From: Marco Tiloca <[email protected]> >>>> Sent: Tuesday, March 24, 2026 4:42:55 PM >>>> To: Martine Sophie Lenders <[email protected]>; Mike Bishop >>>> <[email protected]> >>>> Cc: Karen Moore <[email protected]>; >>>> [email protected]<[email protected]>; Matthias >>>> Waehlisch <[email protected]>; [email protected] >>>> <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; [email protected]<[email protected]>; >>>> [email protected] <[email protected]> >>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9953 >>>> <draft-ietf-core-dns-over-coap-20> for your review >>>> Hi, >>>> >>>> Speaking as Document Shepherd, I also think that either answer is fine, >>>> but I would like to point out that RFC9846-to-be is a complex document >>>> that has already spent more than three months in AUTH48, now with a >>>> pending proposed update (see [1][2][3] and the related ongoing consensus >>>> call [4] until April 6). >>>> >>>> Because of that, and since the reference to RFC 8446 is rather specific >>>> (in the context of RFC 8323 and of the possible use of SNI), there is no >>>> need to queue up behind RFC9846-to-be, and keeping the reference RFC 8846 >>>> feels like preferable. >>>> >>>> Best, >>>> /Marco >>>> >>>> [1] https://mailarchive.ietf.org/arch/msg/tls/zWP2Q4fAjL6KdX2pOX3ekduOQOU/ >>>> >>>> [2] https://github.com/tlswg/tls13-spec/pull/1410 >>>> >>>> [3] https://mailarchive.ietf.org/arch/msg/tls/jpSC_G9chvSpL34X7pH3oCKh6cE/ >>>> >>>> [4] https://mailarchive.ietf.org/arch/msg/tls/HXlf6FvX4B6NmH0zeffiTiXCXw8/ >>>> >>>> From: Martine Sophie Lenders >>>> Sent: Tuesday, March 24, 2026 9:15 PM >>>> To: Mike Bishop >>>> Cc: Karen Moore; [email protected]; Matthias Waehlisch; >>>> [email protected]; [email protected]; >>>> [email protected]; [email protected]; [email protected]; Marco >>>> Tiloca; [email protected] >>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9953 >>>> <draft-ietf-core-dns-over-coap-20> for your review >>>> >>>> On 3/24/26 15:10, Mike Bishop wrote: >>>>> Given that 8446-bis is also in AUTH48, might it make sense to update the >>>>> references from 8446 to 9846 and avoid referencing a newly- or nearly- >>>>> obsoleted document? >>>>> >>>>> I'm fine with either answer; the changes in this diff are approved. >>>> >>>> Discussed this with Christian offline today. He and I would leave it in >>>> the end to the RFC editor. But considering that RFC-to-be 9846 is >>>> already in AUTH48 for quite a while, we would prefer that if it's just a >>>> week of delay, update the reference, otherwise we would prefer it to >>>> leave it as is. >>>> >>>> Best >>>> Martine >>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Martine Sophie Lenders >>>>> *Sent:* Thursday, March 19, 2026 9:55 PM >>>>> *To:* Mike Bishop >>>>> *Cc:* Karen Moore; [email protected]; Matthias Waehlisch; >>>>> [email protected]; [email protected]; rfc-editor@rfc- >>>>> editor.org; [email protected]; [email protected]; [email protected]; >>>>> [email protected] >>>>> *Subject:* Re: [AD] Re: AUTH48: RFC-to-be 9953 <draft-ietf-core-dns- >>>>> over-coap-20> for your review >>>>> >>>>> Hi Mike, >>>>> >>>>> On 3/18/26 19:00, Karen Moore wrote: >>>>>> Hi Martine, Thomas, Matthias, Christian, Cenk, and *Mike (AD), >>>>>> >>>>>> Thank you for your replies. We have noted all of your approvals for >>>>> the content of this document on the AUTH48 status page (https://www.rfc- >>>>> editor.org/auth48/rfc9953 <https://www.rfc-editor.org/auth48/rfc9953>). >>>>> Note that we will remove any hidden comments prior to publication. Once >>>>> Mike approves the beyond editorial changes made, we will contact you >>>>> regarding approving the format of the document. >>>>>> >>>>>> *Mike, as AD, please review the updates to the following sections and >>>>> let us know if you approve. The changes can be viewed here: <https:// >>>>> www.rfc-editor.org/authors/rfc9953-auth48diff.html <https://www.rfc- >>>>> editor.org/authors/rfc9953-auth48diff.html>>. >>>>>> >>>>>> Section 3.2 (review "has a length between 0 and 23 octets, inclusive”) >>>>>> Section 3.2.1 (updates to the figures) >>>>>> [Note from Martine]: >>>>>> a) The hexadecimal TTL `00 00 06 6b` in the third example parses >>>>> to 1643, not 643. >>>>>> b) The RDATA in the last example contains 44 bytes (00 2c), not >>>>> 43 bytes (00 2b) >>>>> >>>>> These changes to the examples should be confirmable with any DNS parser >>>>> as the actual SVCB record data is not touched. However, there is also an >>>>> update in the current main branch of the Python-based DNS toolkit >>>>> `dnspython` [1] which specifically allows for parsing the docpath >>>>> SvcParam, in case you need output similar to the "human-readable" one. >>>>> >>>>> Hope that can help you with your review. >>>>> >>>>> Martine >>>>> >>>>> [1] >>>>> https://github.com/rthalley/dnspython/ >>>>> commit/08c5a9e6914b63eafb3a8b959c463a9213714ca3 <https://github.com/ >>>>> rthalley/dnspython/commit/08c5a9e6914b63eafb3a8b959c463a9213714ca3> >>>>> >>>>>> >>>>>> Section 4.3 (added “OPTIONAL”) >>>>>> Section 5.1 (updated "do so” to "unsubscribe or close the session”) >>>>>> Acknowledgements (new text added) >>>>>> >>>>>> >>>>>> —Files (please refresh)— >>>>>> Updated MD file: >>>>>> https://www.rfc-editor.org/authors/rfc9953.md <https://www.rfc- >>>>> editor.org/authors/rfc9953.md> >>>>>> >>>>>> Updated output files: >>>>>> https://www.rfc-editor.org/authors/rfc9953.html <https://www.rfc- >>>>> editor.org/authors/rfc9953.html> >>>>>> https://www.rfc-editor.org/authors/rfc9953.pdf <https://www.rfc- >>>>> editor.org/authors/rfc9953.pdf> >>>>>> https://www.rfc-editor.org/authors/rfc9953.txt <https://www.rfc- >>>>> editor.org/authors/rfc9953.txt> >>>>>> >>>>>> Diff files of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9953-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-diff.html> (all changes) >>>>>> https://www.rfc-editor.org/authors/rfc9953rfcdiff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953rfcdiff.html> (all changes side by side) >>>>>> https://www.rfc-editor.org/authors/rfc9953-auth48diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-auth48diff.html> (AUTH48 changes) >>>>>> https://www.rfc-editor.org/authors/rfc9953-auth48rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-auth48rfcdiff.html> (AUTH48 >>>>> changes side by side) >>>>>> >>>>>> Diff files of the kramdown: >>>>>> https://www.rfc-editor.org/authors/rfc9953-md-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-md-diff.html> (all changes) >>>>>> https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html> (all changes side by >>>>> side) >>>>>> https://www.rfc-editor.org/authors/rfc9953-md-auth48diff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md-auth48diff.html> (AUTH48 >>>>> changes) >>>>>> https://www.rfc-editor.org/authors/rfc9953-md-auth48rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md- >>>>> auth48rfcdiff.html> (AUTH48 changes side by side) >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9953 <https://www.rfc- >>>>> editor.org/auth48/rfc9953> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>> >>>>>>> On Mar 17, 2026, at 11:02 PM, Martine Sophie Lenders >>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi Karen and team, >>>>>>> >>>>>>> thanks for processing this. >>>>>>> >>>>>>> One minor thing I noticed is, that there is still a list of >>>>> references no longer used (from the deleted appendices and >>>>> implementation status sections) at the very bottom of the markdown >>>>> version from line 809. Also there is still the comment on the too long >>>>> TXT output. From what I can see this resolved. >>>>>>> >>>>>>> But neither those references nor the comment references show up in >>>>> the final HTML or TXT, so I count them as formatting updates and approve >>>>> the publication of the current version. >>>>>>> >>>>>>> Best >>>>>>> Martine >>>>>>> >>>>>>> On 3/18/26 00:58, Karen Moore wrote: >>>>>>>> Hello Martine, >>>>>>>> Thank you for your reply. We have updated our files accordingly. >>>>> Please note that we updated one instance of “Lenders, M.” To “Lenders, >>>>> M. S.” per your request. Please review and let us know if any further >>>>> changes are needed or if you approve the document in its current form. >>>>>>>> Note that we will await approvals from each author prior to moving >>>>> forward with formatting updates. >>>>>>>> —Files— >>>>>>>> Note that it may be necessary for you to refresh your browser to >>>>> view the most recent version. Please review the contents of the document >>>>> carefully as we do not make changes once it has been published as an RFC. >>>>>>>> For details of the AUTH48 process in kramdown-rfc (including the >>>>> two-part approval process), see https://www.rfc-editor.org/rpc/wiki/ >>>>> doku.php?id=pilot_test_kramdown_rfc <https://www.rfc-editor.org/rpc/ >>>>> wiki/doku.php?id=pilot_test_kramdown_rfc>. >>>>>>>> Updated MD file: >>>>>>>> https://www.rfc-editor.org/authors/rfc9953.md <https://www.rfc- >>>>> editor.org/authors/rfc9953.md> >>>>>>>> Updated output files: >>>>>>>> https://www.rfc-editor.org/authors/rfc9953.html <https://www.rfc- >>>>> editor.org/authors/rfc9953.html> >>>>>>>> https://www.rfc-editor.org/authors/rfc9953.pdf <https://www.rfc- >>>>> editor.org/authors/rfc9953.pdf> >>>>>>>> https://www.rfc-editor.org/authors/rfc9953.txt <https://www.rfc- >>>>> editor.org/authors/rfc9953.txt> >>>>>>>> Diff files of the text: >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-diff.html> (all changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953rfcdiff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953rfcdiff.html> (all changes side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-auth48diff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-auth48diff.html> (AUTH48 >>>>> changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-auth48rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-auth48rfcdiff.html> (AUTH48 >>>>> changes side by side) >>>>>>>> Diff files of the kramdown: >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-md-diff.html> (all changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html> (all >>>>> changes side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-auth48diff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md-auth48diff.html> (AUTH48 >>>>> changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-auth48rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md- >>>>> auth48rfcdiff.html> (AUTH48 changes side by side) >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9953 <https://www.rfc- >>>>> editor.org/auth48/rfc9953> >>>>>>>> Best regards, >>>>>>>> Karen Moore >>>>>>>> RFC Production Center >>>>>>>>> On Mar 16, 2026, at 4:54 PM, Martine Sophie Lenders >>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Dear RFC editor team, >>>>>>>>> >>>>>>>>> here too, sorry for the late reply. Find our answers, additional >>>>> nits and errors found, and additional requests inline. >>>>>>>>> >>>>>>>>> On 3/6/26 04:15, [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] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to >>>>> [PRE-RFC9952] >>>>>>>>>> for now. We will make the final updates in RFCXML (i.e., remove >>>>> "PRE-"). >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> ACK. >>>>>>>>> >>>>>>>>>> 2) <!--[rfced] Please note that the title of the document has been >>>>>>>>>> updated as follows. The abbreviation has been expanded per >>>>> Section 3.6 >>>>>>>>>> of RFC 7322 ("RFC Style Guide"). We also added "the". Please review. >>>>>>>>>> Original: >>>>>>>>>> DNS over CoAP (DoC) >>>>>>>>>> Current: >>>>>>>>>> DNS over the Constrained Application Protocol (DoC) >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> See remarks in the reply on RFC-to-be-9952 with regards to "CoAP" >>>>> in the title. Our preferred title would be >>>>>>>>> >>>>>>>>>> DNS over CoAP (DoC) >>>>>>>>> >>>>>>>>> If adding CoAP to the well-known abbreviation list is not >>>>> possible, your proposal is fine. >>>>>>>>> >>>>>>>>>> 3) <!--[rfced] May we remove "(CoAPS)" in the Abstract as this >>>>>>>>>> term/abbreviation is not used elsewhere in the document? Please >>>>>>>>>> review. >>>>>>>>>> Original: >>>>>>>>>> These CoAP messages can be protected by (D)TLS-Secured CoAP >>>>> (CoAPS) >>>>>>>>>> or Object Security for Constrained RESTful Environments >>>>> (OSCORE) to >>>>>>>>>> provide encrypted DNS message exchange for constrained devices in >>>>>>>>>> the Internet of Things (IoT). >>>>>>>>>> Perhaps: >>>>>>>>>> These CoAP messages can be protected by (D)TLS-Secured CoAP or >>>>>>>>>> Object Security for Constrained RESTful Environments (OSCORE) to >>>>>>>>>> provide encrypted DNS message exchange for constrained devices in >>>>>>>>>> the Internet of Things (IoT). >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> ACK. >>>>>>>>> >>>>>>>>>> 4) <!--[rfced] FYI: draft-ietf-iotops-7228bis has not been >>>>> published yet >>>>>>>>>> (currently, its IESG state is "I-D Exists"). Thus, we have left >>>>>>>>>> references to RFC 7228 and draft-ietf-iotops-7228bis as is. >>>>>>>>>> Author note: >>>>>>>>>> Please remove the {{-constr-nodes}} reference and replace >>>>>>>>>> it with {{I-D.ietf-iotops-7228bis}} throughout the document >>>>> in case >>>>>>>>>> {{I-D.ietf-iotops-7228bis}} becomes an RFC before publication. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes, sadly draft-ietf-iotops-7228bis will take a little longer >>>>> until publication. >>>>>>>>> >>>>>>>>>> 5) <!--[rfced] FYI - We updated "authoritive name server" to >>>>> "authoritative name >>>>>>>>>> server" to match other usage in this document and in other RFCs. >>>>>>>>>> Original: >>>>>>>>>> That DoC server can be the authoritive name server for the >>>>> queried >>>>>>>>>> record or a DNS client (i.e., a stub or recursive resolver) that >>>>>>>>>> resolves DNS information by using other DNS transports such >>>>> as DNS >>>>>>>>>> over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC >>>>>>>>>> [RFC9250] when communicating with the upstream DNS >>>>> infrastructure. >>>>>>>>>> Updated: >>>>>>>>>> That DoC server can be the authoritative name server for the >>>>> queried >>>>>>>>>> record or a DNS client (i.e., a stub or recursive resolver) that >>>>>>>>>> resolves DNS information by using other DNS transports such >>>>> as DNS >>>>>>>>>> over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC >>>>>>>>>> [RFC9250] when communicating with the upstream DNS >>>>> infrastructure. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> ACK. >>>>>>>>> >>>>>>>>>> 6) <!-- [rfced] Please clarify "is of length 0 and 24 octets" in >>>>> this sentence. >>>>>>>>>> Original: >>>>>>>>>> As long as each docpath- >>>>>>>>>> segment is of length 0 and 24 octets, it is easily >>>>> transferred into >>>>>>>>>> the path representation in CRIs [I-D.ietf-core-href] by >>>>> masking each >>>>>>>>>> length octet with the CBOR text string major type 3 (0x60 as an >>>>>>>>>> octet, see [RFC8949]). >>>>>>>>>> Perhaps: >>>>>>>>>> As long as each docpath- >>>>>>>>>> segment has a length between 0 and 24 octets, it is easily >>>>> transferred into >>>>>>>>>> the path representation in CRIs [CRI] by masking each length >>>>> octet >>>>>>>>>> with the CBOR text string major type 3 (0x60 as an octet; see >>>>>>>>>> [RFC8949]). >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes, it must be "between 0 and ...", however there is also a >>>>> technical error in that sentence (thanks Marco, for noticing last >>>>> minute!). To avoid ambiguity it is probably also best, to spefify that >>>>> the range is inclusive. It must read >>>>>>>>> >>>>>>>>> As long as each docpath- >>>>>>>>> segment has a length between 0 and 23 octets, inclusive, it is >>>>>>>>> easily transferred into >>>>>>>>> the path representation in CRIs [CRI] by masking each length octet >>>>>>>>> with the CBOR text string major type 3 (0x60 as an octet; see >>>>>>>>> [RFC8949]). >>>>>>>>> >>>>>>>>> 24 is already the marker for that the value of the argument is >>>>> held in the following 1 byte (see [RFC8949, section 3]) and would thus >>>>> not be as easily transferable as stated. >>>>>>>>> >>>>>>>>>> 7) <!--[rfced] We are having trouble parsing this sentence. >>>>> Please let us >>>>>>>>>> know if it can be revised as shown below for clarity. >>>>>>>>>> Original: >>>>>>>>>> Likewise, it can be transferred into a URI path-abempty form by >>>>>>>>>> replacing each length octet with the "/" character None of the >>>>>>>>>> abovementioned prevent longer docpath-segments than the >>>>> considered, >>>>>>>>>> they just make the translation harder, as they require to >>>>> make space >>>>>>>>>> for the longer delimiters, in turn requiring to move octets. >>>>>>>>>> Perhaps: >>>>>>>>>> Likewise, it can be transferred into a URI path-abempty form by >>>>>>>>>> replacing each length octet with the "/" character. None of the >>>>>>>>>> abovementioned prevent longer docpath-segments than the >>>>> considered >>>>>>>>>> ones; they just make the translation harder as space is required >>>>>>>>>> for the longer delimiters, which in turn require octets to be >>>>>>>>>> moved. >>>>>>>>>> --> >>>>>>>>> Due to the line ending in the Markdown file we failed to spot the >>>>> missing period between "character" and "None". Yes, please go ahead with >>>>> the proposed version. >>>>>>>>> >>>>>>>>>> 8) <!-- [rfced] May we update "going through" to "with" here to >>>>> improve clarity? >>>>>>>>>> Original: >>>>>>>>>> The construction algorithm for DoC >>>>>>>>>> requests is as follows, going through the provided records in >>>>> order >>>>>>>>>> of their priority. >>>>>>>>>> Perhaps: >>>>>>>>>> The construction algorithm for DoC >>>>>>>>>> requests is as follows, with the provided records in order >>>>>>>>>> of their priority. >>>>>>>>>> --> >>>>>>>>> ACK. >>>>>>>>> >>>>>>>>>> 9) <!-- [rfced] How may we update the third item in the series >>>>> for parallel >>>>>>>>>> structure? Would either removing "from" or adding "information" >>>>> be correct? >>>>>>>>>> Original: >>>>>>>>>> This may include (1) A >>>>>>>>>> or AAAA RRs associated with the target name and delivered >>>>> with the >>>>>>>>>> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >>>>>>>>>> from the SVCB RR (see [RFC9461]), or (3) from IPv4 or IPv6 >>>>>>>>>> addresses provided if DNR [RFC9463] is used. >>>>>>>>>> Perhaps A (cut "from"): >>>>>>>>>> This may include (1) A >>>>>>>>>> or AAAA RRs associated with the target name and delivered >>>>> with the >>>>>>>>>> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >>>>>>>>>> from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 >>>>>>>>>> addresses provided if DNR [RFC9463] is used. >>>>>>>>>> or >>>>>>>>>> Perhaps B (add "information"): >>>>>>>>>> This may include (1) A >>>>>>>>>> or AAAA RRs associated with the target name and delivered >>>>> with the >>>>>>>>>> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >>>>>>>>>> from the SVCB RR (see [RFC9461]), or (3) information from >>>>> IPv4 or IPv6 >>>>>>>>>> addresses provided if DNR [RFC9463] is used. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Proposal A is the more accurate one, so please use that one. >>>>>>>>> >>>>>>>>>> 10) <!--[rfced] Per the following note, we have replaced "ff 0a" >>>>> with "00 0a" in >>>>>>>>>> the examples in Section 3.2.1 (per IANA's assignment of "10" for >>>>>>>>>> "docpath"). Please confirm that this is correct and let us know >>>>> if any further >>>>>>>>>> updates are needed. >>>>>>>>>> Author note: >>>>>>>>>> Since the number for "docpath" was not assigned at the time of >>>>>>>>>> writing, we used the hex `ff 0a` (in decimal 65290; from the >>>>>>>>>> private use range of SvcParamKeys) throughout this section. >>>>> Before >>>>>>>>>> publication, please replace `ff 0a` with the hexadecimal >>>>>>>>>> representation of the final value assigned by IANA in this >>>>>>>>>> section. Please remove this paragraph after that. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Your replacements here are correct. However, while checking the >>>>> parsibility of the hexadecimal examples, we noticed several errors we >>>>> introduced: >>>>>>>>> >>>>>>>>> a) The hexadecimal TTL `00 00 06 6b` in the third example parses to >>>>>>>>> 1643, not 643. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> _dns.example.org. 643 IN SVCB 1 dns.example.org ( >>>>>>>>> >>>>>>>>> Corrected: >>>>>>>>> _dns.example.org. 1643 IN SVCB 1 dns.example.org ( >>>>>>>>> >>>>>>>>> b) The RDATA in the last example contains 44 bytes (00 2c), >>>>>>>>> not 43 bytes (00 2b) >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Resource record (binary): >>>>>>>>> 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 >>>>>>>>> 67 00 00 40 00 01 00 00 01 ad 00 2b 00 01 03 64 >>>>>>>>> >>>>>>>>> Corrected: >>>>>>>>> Resource record (binary): >>>>>>>>> 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 >>>>>>>>> 67 00 00 40 00 01 00 00 01 ad 00 2c 00 01 03 64 >>>>>>>>> >>>>>>>>>> 11) <!--[rfced] We note that "Cache-Key" appears as "cache key" >>>>> in RFC >>>>>>>>>> 8132. Would you like to match use in RFC 8132? >>>>>>>>>> Original: >>>>>>>>>> This ensures that the CoAP Cache-Key (see [RFC8132], Section 2) >>>>>>>>>> does not change when multiple DNS queries for the same DNS data, >>>>>>>>>> carried in CoAP requests, are issued. >>>>>>>>>> Perhaps: >>>>>>>>>> This ensures that the CoAP cache key (see [RFC8132], Section 2) >>>>>>>>>> does not change when multiple DNS queries for the same DNS data, >>>>>>>>>> carried in CoAP requests, are issued. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> We used the spelling from [RFC7252] here. As this is also used in >>>>> many other documents except [RFC8132] (e.g., RFC 9668, draft-ietf-core- >>>>> groupcomm-bis, or draft-ietf-core-cacheable-oscore), we would prefer the >>>>> original spelling "Cache-Key". >>>>>>>>> >>>>>>>>>> 12) <!-- [rfced] Please review the text starting with "OPCODE—a DNS >>>>>>>>>> Update ...". Should this be updated as follows or in some other way? >>>>>>>>>> Original: >>>>>>>>>> As described in Section 4.1, a DoC server uses NotImp (RCODE >>>>> = 4) if >>>>>>>>>> it does not support an OPCODE—a DNS Update (OPCODE = 5) for >>>>>>>>>> "example.org" in this case. >>>>>>>>>> Perhaps: >>>>>>>>>> As described in Section 4.1, a DoC server uses NotImp (RCODE >>>>> = 4) if >>>>>>>>>> it does not support an OPCODE - in this case, a DNS Update >>>>> (OPCODE = 5) for >>>>>>>>>> "example.org" is used. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> It is not used, but the NotImp (RCODE = 4) rejects the DNS Update >>>>> (OPCODE = 5). As we are not sure, if "reject" is the correct DNS >>>>> terminology, how about the following. >>>>>>>>> >>>>>>>>> Proposal: >>>>>>>>> As described in Section 4.1, a DoC server uses NotImp (RCODE = >>>>> 4) if >>>>>>>>> it does not support an OPCODE - in this case it errors on a DNS >>>>>>>>> Update (OPCODE = 5) for "example.org". >>>>>>>>> >>>>>>>>>> 13) <!--[rfced] Please clarify what "a failure to do so" refers >>>>> to in the >>>>>>>>>> following sentence. >>>>>>>>>> Original: >>>>>>>>>> As there is no CoAP observer anymore from the perspective of the >>>>>>>>>> DoC server, a failure to do so cannot be communicated back to any >>>>>>>>>> DoC observer. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> A failure to unsubscribe or close the session. >>>>>>>>> >>>>>>>>> Proposal: >>>>>>>>> As there is no CoAP observer anymore from the perspective of the >>>>>>>>> DoC server, a failure to unsubscribe or close the session >>>>> cannot be >>>>>>>>> communicated back to any DoC observer. >>>>>>>>> >>>>>>>>>> 14) <!--[rfced] FYI: We added "to protect" to this sentence for >>>>>>>>>> clarity. Please let us know if it changes the intended meaning. >>>>>>>>>> Original: >>>>>>>>>> For secure communication via (D)TLS or OSCORE, an >>>>> unpredictable ID >>>>>>>>>> against spoofing is not necessary. >>>>>>>>>> Updated: >>>>>>>>>> For secure communication via (D)TLS or OSCORE, an >>>>> unpredictable ID >>>>>>>>>> to protect against spoofing is not necessary. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> ACK. >>>>>>>>> >>>>>>>>>> 15) <!-- [rfced] FYI: We removed the change log, which included a >>>>>>>>>> reference to RFC 2136. If RFC 2136 should be mentioned elsewhere in >>>>>>>>>> the running text, please let us know. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Section 4.1 clarifies that OPCODEs other than 0 are not supported, >>>>> as such (and as pointed out in the change log entry for `-10`), the >>>>> reference to single out DNS Update (OPCODE = 5, RFC 2136) is not >>>>> necessary. DNS Update is only mentioned as an example for the NotImp >>>>> RCODE now. We do not think that justifies the reference either. If you >>>>> think otherwise, please add an informational reference there, e.g., >>>>> adapting our proposal from 12): >>>>>>>>> >>>>>>>>> As described in Section 4.1, a DoC server uses NotImp (RCODE = >>>>> 4) if >>>>>>>>> it does not support an OPCODE - in this case it errors on a DNS >>>>>>>>> Update (OPCODE = 5, see [RFC2138]) for "example.org". >>>>>>>>> >>>>>>>>>> 16) <!--[rfced] We note that "draft-amsuess-core-cachable-oscore" is >>>>>>>>>> expired and has been replaced by "draft-ietf-core-cacheable-oscore". >>>>>>>>>> May we replace the current entry below with the entry for >>>>>>>>>> "draft-ietf-core-cacheable-oscore"? >>>>>>>>>> Current: >>>>>>>>>> [I-D.amsuess-core-cachable-oscore] >>>>>>>>>> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress, >>>>>>>>>> Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July >>>>> 2025, >>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-amsuess-core- >>>>> cachable- >>>>>>>>>> oscore-11>. >>>>>>>>>> Perhaps: >>>>>>>>>> [CACHABLE-OSCORE] >>>>>>>>>> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in >>>>>>>>>> Progress, Internet-Draft, draft-ietf-core-cacheable- >>>>>>>>>> oscore-00, 22 September 2025, >>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-core- >>>>>>>>>> cacheable-oscore-00>. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes, but the title changed as well in the most current version of >>>>> that draft. >>>>>>>>> >>>>>>>>> Perhaps (also note the extra “E” in the reference): >>>>>>>>> [CACHEABLE-OSCORE] >>>>>>>>> Amsüss, C. and M. Tiloca, "End-to-End Protected and Cacheable >>>>>>>>> Responses for the Constrained Application Protocol (CoAP) using >>>>>>>>> Group Object Security for Constrained RESTful Environments (Group >>>>>>>>> OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core- >>>>>>>>> cacheable-oscore-01, 2 March 2026, >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-core- >>>>>>>>> cacheable-oscore-01>. >>>>>>>>> >>>>>>>>>> 17) <!--[rfced] Sourcecode and artwork >>>>>>>>>> a) Some lines in Figure 1 are too long for the TXT output. This >>>>> figure is >>>>>>>>>> marked as artwork, so it needs to have a width of 72 characters >>>>> or less. How >>>>>>>>>> may we revise this figure to fit these parameters? We tested >>>>> removing some >>>>>>>>>> space in the figure; please check out the following test files >>>>> and let us know >>>>>>>>>> if this would work (see TXT file for ascii art and HTML for SVG). >>>>> If not, please >>>>>>>>>> provide an updated figure. >>>>>>>>>> Test files: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953test.md <https:// >>>>> www.rfc-editor.org/authors/rfc9953test.md> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953test.txt <https:// >>>>> www.rfc-editor.org/authors/rfc9953test.txt> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953test.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953test.html> >>>>>>>>> >>>>>>>>> Your proposal is still recognizable as the original when parsed to >>>>> SVG and readable when shown in TXT, so ACK for taking the proposal in >>>>> rfc9953test.md. >>>>>>>>> >>>>>>>>>> b) We have updated the blocks in Sections 3.2, 3.2.1, 4.2.3, and >>>>> 4.3.3 to be >>>>>>>>>> marked as sourcecode. We set the type for the block in Section >>>>> 3.2 as "abnf" >>>>>>>>>> (i.e., "~~~ abnf"). Please let us know if the type should be set >>>>> for the other >>>>>>>>>> sourcecode blocks. For example, should the ones in Section 3.2.1 >>>>> be marked as >>>>>>>>>> type "dns-rr"? If the current list of preferred values (see link >>>>> below) does >>>>>>>>>> not contain an applicable type, feel free to let us know. Also, it is >>>>>>>>>> acceptable to leave the type not set. >>>>>>>>>> List of sourcecode types: >>>>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types >>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> >>>>>>>>> >>>>>>>>> As far as we can tell, marking them as “sourcecode” in Markdown, >>>>> makes these blocks rendered into a <sourcecode> XML element, rather than >>>>> an <artwork> element. That is definitely more correct. >>>>>>>>> >>>>>>>>> All of them are merely textual representations of DNS messages or >>>>> resource records, so we would not assign any type to them (except maybe >>>>> "txt", but that does not seem to exist and we see it as equivalent to >>>>> having no type). >>>>>>>>> >>>>>>>>> Looking at other RFCs, "dns-rr" only is used for zone-file-like >>>>> DNS resource records (which we also use after `Resource record (human- >>>>> readable):`). However, our examples include a hexadecimal part (as well >>>>> as the labels for each). We fear that this might confuse parsers more >>>>> than it is helpful, so these examples should stay pure text blocks as >>>>> well. >>>>>>>>> >>>>>>>>>> c) The blocks in Section 4.3.3 are too long for the TXT output. >>>>> We marked >>>>>>>>>> these as sourcecode, so they should have a width of 69 characters >>>>> or less. The >>>>>>>>>> long lines are currently 70 characters. Would moving all the >>>>> lines with >>>>>>>>>> semicolons over to the left one space (in just this section or in >>>>> all the >>>>>>>>>> sourcecode in the document) be a good solution? We tried this in >>>>> the test >>>>>>>>>> files listed above so you can see what the output will look like. >>>>> Feel free to >>>>>>>>>> offer other suggestions as well. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes that is acceptable. However, for reasons of consistency it >>>>> should also be applied to _all_ examples in Sections 3.2.1, 4.2.3, and >>>>> 4.3.3, including the indent under `Resource record (binary):`, `Resource >>>>> record (human-readable):` and `Payload (binary):`, e.g., in Section 3.2.1 >>>>>>>>> >>>>>>>>> ~~~ >>>>>>>>> Resource record (binary): >>>>>>>>> 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 >>>>>>>>> 67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64 >>>>>>>>> 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 >>>>>>>>> 01 00 03 02 63 6f 00 0a 00 00 >>>>>>>>> >>>>>>>>> Resource record (human-readable): >>>>>>>>> _dns.example.org. 1576 IN SVCB 1 dns.example.org ( >>>>>>>>> alpn=co docpath ) >>>>>>>>> ~~~ >>>>>>>>> {: gi="sourcecode"} >>>>>>>>> >>>>>>>>> or in Section 4.2.3 >>>>>>>>> >>>>>>>>> ~~~ >>>>>>>>> FETCH coaps://[2001:db8::1]/ >>>>>>>>> Content-Format: 553 (application/dns-message) >>>>>>>>> Accept: 553 (application/dns-message) >>>>>>>>> Payload (binary): >>>>>>>>> 00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61 >>>>>>>>> 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 >>>>>>>>> >>>>>>>>> Payload (human-readable): >>>>>>>>> ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 >>>>>>>>> ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >>>>>>>>> >>>>>>>>> ;; QUESTION SECTION: >>>>>>>>> ;example.org. IN AAAA >>>>>>>>> ~~~ >>>>>>>>> {: gi="sourcecode"} >>>>>>>>> >>>>>>>>>> 18) <!--[rfced] Please review the "Inclusive Language" portion of >>>>> the online >>>>>>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/ >>>>> #inclusive_language <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. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Thanks! To the best of our abilities, we did not find any >>>>> potentially remaining non-inclusive wordings in the document. >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>> # Additional Nits and Errors Found >>>>>>>>> >>>>>>>>> The current version of RFC-to-be 9953 effectively replaced an "or" >>>>> with an "and". Furthermore, that the more related DTLS and TLS separated >>>>> by OSCORE read a little bit weird on final read-through. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Each CoAP message can be secured by DTLS 1.2 or newer [RFC6347] >>>>>>>>> [RFC9147] as well as Object Security for Constrained RESTful >>>>>>>>> Environments (OSCORE) [RFC8613] but also TLS 1.3 or newer [RFC8323] >>>>>>>>> [RFC8446] to ensure message integrity and confidentiality. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Each CoAP message can be secured by DTLS 1.2 or newer [RFC6347] >>>>>>>>> [RFC9147] as well as Object Security for Constrained RESTful >>>>>>>>> Environments (OSCORE) [RFC8613] and TLS 1.3 or newer [RFC8323] >>>>>>>>> [RFC8446] to ensure message integrity and confidentiality. >>>>>>>>> >>>>>>>>> Since the "or" is meant to be inclusive (nothing speaks against, >>>>> e.g., combining DTLS and OSCORE), we would prefer the following: >>>>>>>>> >>>>>>>>> Proposal: >>>>>>>>> Each CoAP message can be secured by any combination of DTLS 1.2 or >>>>>>>>> newer [RFC6347] [RFC9147], TLS 1.3 or newer [RFC8323] [RFC8446], or >>>>>>>>> Object Security for Constrained RESTful Environments (OSCORE) >>>>>>>>> [RFC8613] to ensure message integrity and confidentiality. >>>>>>>>> >>>>>>>>> --------------------------------------- >>>>>>>>> >>>>>>>>> In paragraph 7 of Section 3.2 of -20 (see https://www.ietf.org/ >>>>> archive/id/draft-ietf-core-dns-over-coap-20.html#section-3.2-7) >>>>> <https://www.ietf.org/archive/id/draft-ietf-core-dns-over- >>>>> coap-20.html#section-3.2-7)> it states in HTML and TXT form: >>>>>>>>> >>>>>>>>> The same considerations for the "," and "" characters in >>>>>>>>> docpath-segments [...] >>>>>>>>> >>>>>>>>> There is a render error here due to the original Markdown having >>>>> only one `\` inserted between the quotation-mark pair `""` which results >>>>> in an interpretation as an escaped `"`. The Markdown must be corrected >>>>> as follows. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The same considerations for the "," and "\" characters in >>>>>>>>> docpath-segments [...] >>>>>>>>> >>>>>>>>> Proposal: >>>>>>>>> The same considerations for the "," and "\\" characters in >>>>>>>>> docpath-segments [...] >>>>>>>>> >>>>>>>>> (Thanks Marco for spotting this) >>>>>>>>> >>>>>>>>> --------------------------------------- >>>>>>>>> >>>>>>>>> The "optional" with regards to the Accept option in Section 4.3 >>>>> should be normative >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The use of the Accept option in the request is optional. >>>>>>>>> >>>>>>>>> Proposed change: >>>>>>>>> The use of the Accept option in the request is OPTIONAL. >>>>>>>>> >>>>>>>>> --------------------------------------- >>>>>>>>> >>>>>>>>> The two ndashes in Section 4.3.3 should actually be "–" (– >>>>> as XML character entity reference) not two minuses (--) >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> When a DNS error -- NxDomain (RCODE = 3) for "does.not.exist" in >>>>> this case -- is noted in the DNS response, the CoAP response still >>>>> indicates success. >>>>>>>>> >>>>>>>>> Proposed change: >>>>>>>>> When a DNS error – NxDomain (RCODE = 3) for "does.not.exist" in >>>>> this case – is noted in the DNS response, the CoAP response still >>>>> indicates success. >>>>>>>>> >>>>>>>>> --------------------------------------- >>>>>>>>> >>>>>>>>> In Section 5.1 the capitalization of "DNS push [notification(s)]" >>>>> is mixed. E.g., >>>>>>>>> >>>>>>>>> DNS Push Notifications [RFC8765] provide the capability to >>>>>>>>> asynchronously notify clients about resource record changes. >>>>>>>>> >>>>>>>>> vs. >>>>>>>>> >>>>>>>>> The DoC server MAY subscribe to DNS push notifications for that >>>>>>>>> record. >>>>>>>>> >>>>>>>>> Since [RFC8765] capitalizes "DNS Push Notification(s)" >>>>> consistently, we prefer the consistent spelling of "DNS Push", "DNS Push >>>>> Notifications", etc. in RFC-to-be 9953 as well. "Notification" on its >>>>> own (as well as its plural) or in conjunction with CoAP Observe should >>>>> remain uncapitalized, as per Section 2. >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>> >>>>>>>>> In Section 7, RFC-to-be 9953 refers to considerations on the >>>>> maintenance of long-lived security contexts. In the cited version >>>>> (`-03`) of [CoAP-CORR-CLAR], these considerations moved to Section 2.7. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Additionally, DoC uses request patterns that require >>>>>>>>> the maintenance of long-lived security contexts. Section 2.6 of >>>>>>>>> [CoAP-CORR-CLAR] provides insights on what can be done when >>>>> those are >>>>>>>>> resumed from a new endpoint. >>>>>>>>> >>>>>>>>> Proposed change: >>>>>>>>> Additionally, DoC uses request patterns that require >>>>>>>>> the maintenance of long-lived security contexts. Section 2.7 of >>>>>>>>> [CoAP-CORR-CLAR] provides insights on what can be done when >>>>> those are >>>>>>>>> resumed from a new endpoint. >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>> >>>>>>>>> # Additional Requests >>>>>>>>> >>>>>>>>> Please append the following sentence to the acknowledgements: >>>>>>>>> >>>>>>>>> This work was supported in parts by the German Federal Ministry of >>>>>>>>> Research, Technology and Space (BMFTR) under the grant numbers >>>>>>>>> 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the >>>>>>>>> research project PIVOT and under the grant numbers 16KIS1694K (TU >>>>>>>>> Dresden) and 16KIS1695 (HAW Hamburg) within the research project >>>>>>>>> C-ray4edge. >>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> Martine >>>>>>>>> >>>>>>>>>> Karen Moore and Rebecca VanRheenen >>>>>>>>>> RFC Production Center >>>>>>>>>> On Mar 5, 2026, at 7:10 PM, [email protected] wrote: >>>>>>>>>> *****IMPORTANT***** >>>>>>>>>> Updated 2026/03/05 >>>>>>>>>> RFC Author(s): >>>>>>>>>> -------------- >>>>>>>>>> Your document has now entered AUTH48. >>>>>>>>>> The document was edited in kramdown-rfc as part of the RPC pilot >>>>> test (see >>>>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php? >>>>> id=pilot_test_kramdown_rfc) <https://www.rfc-editor.org/rpc/wiki/ >>>>> doku.php?id=pilot_test_kramdown_rfc)>. >>>>>>>>>> Please review the procedures for AUTH48 using kramdown-rfc: >>>>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php? >>>>> id=pilot_test_instructions_completing_auth48_using_kramdown <https:// >>>>> www.rfc-editor.org/rpc/wiki/doku.php? >>>>> id=pilot_test_instructions_completing_auth48_using_kramdown> >>>>>>>>>> Once your document has completed AUTH48, it will be published as >>>>>>>>>> an RFC. >>>>>>>>>> Files >>>>>>>>>> ----- >>>>>>>>>> The files are available here: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953.md <https://www.rfc- >>>>> editor.org/authors/rfc9953.md> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953.html <https://www.rfc- >>>>> editor.org/authors/rfc9953.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953.pdf <https://www.rfc- >>>>> editor.org/authors/rfc9953.pdf> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953.txt <https://www.rfc- >>>>> editor.org/authors/rfc9953.txt> >>>>>>>>>> Diff file of the text: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-diff.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953-rfcdiff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-rfcdiff.html> (side by side) >>>>>>>>>> Diff of the kramdown: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-diff.html <https:// >>>>> www.rfc-editor.org/authors/rfc9953-md-diff.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html> (side by >>>>> side) >>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9953 <https://www.rfc- >>>>> editor.org/auth48/rfc9953> >>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>> Thank you for your cooperation, >>>>>>>>>> RFC Editor >>>>>>>>>> -------------------------------------- >>>>>>>>>> RFC9953 (draft-ietf-core-dns-over-coap-20) >>>>>>>>>> Title : DNS over CoAP (DoC) >>>>>>>>>> Author(s) : M. S. Lenders, C. Amsüss, C. Gündoğan, T. C. >>>>> Schmidt, M. Wählisch >>>>>>>>>> WG Chair(s) : Jaime Jimenez, Marco Tiloca >>>>>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop >>>>>> >>> >>> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
