Hi Thomas, We have noted your approval of the format on the AUTH48 page (https://www.rfc-editor.org/auth48/rfc9953).
We will await approval of the format from Christian, Cent, and Matthias before moving forward with publication. Best regards, Karen Moore RPC Production Center > On Mar 25, 2026, at 11:58 AM, Thomas C. Schmidt <[email protected]> > wrote: > > Hi Karen, > > many thanks and yes, I approve. > > Best, > Thomas > > On 25.03.2026 19:48, Karen Moore wrote: >> 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 >>>>>>>> >>>>> >>>>> > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
