Dear Dan and *AD (Paul), Dan, thank you for your prompt reply! We have added the missing slash and posted the latest files.
* Paul, please review the item below, and let us know if you approve: > 1) <!-- [rfced] *AD, text was added to the Acknowledgments section after the > document was approved for publication. Please review the changes, and > let us know if you approve. > > Diff between v14 and v15: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-wg-coap-eap-15 --> The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9820.txt https://www.rfc-editor.org/authors/rfc9820.pdf https://www.rfc-editor.org/authors/rfc9820.html https://www.rfc-editor.org/authors/rfc9820.xml https://www.rfc-editor.org/authors/rfc9820-diff.html https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-auth48diff.html https://www.rfc-editor.org/authors/rfc9820-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-lastdiff.html https://www.rfc-editor.org/authors/rfc9820-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html https://www.rfc-editor.org/authors/rfc9820-xmldiff2.html Thanks again! RFC Editor/lb > On Aug 13, 2025, at 5:47 AM, Dan Garcia Carrillo <garcia...@uniovi.es> wrote: > > Dear RFC Editor, > > Please, see answer inline. > > > El 12/8/25 a las 19:34, Lynne Bartholomew escribió: >> Dear Dan, >> >> Thank you very much for your responses to our additional questions. >> >> This item is still pending: >> >>>> Also, please confirm that the single instance of "a/eap/1" is correct >>>> (i.e., "would be "a/eap/1" should not be "would be /a/eap/1"). >> >> Should the single instance of "a/eap/1" be "/a/eap/1"? In other words, is >> it correct that this one instance does not include a slash before the "a"? >> We ask because of the entries we see in Figure 3. >> >> Currently: >> So, per Figure 3, the URI for the first resource would be "a/eap/1". >> >> = = = = = > > > [Authors] It is missing the /. So, it would be > > So, per Figure 3, the URI for the first resource would be "/a/eap/1". > > Thank you. > > Best regards, > > Dan. > > >> The latest files are posted here. Please refresh your browser: >> >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.txt__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-c7PkfZW$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.pdf__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-XVrunA0$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-fsUaGv7$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.xml__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-TpW5UJZ$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-diff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-VoOjY-R$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-Tgq0UBI$ >> (side by side) >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48diff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-VICEum7$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48rfcdiff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-Rfie6Ux$ >> (side by side) >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-lastdiff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-TXoId9x$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-lastrfcdiff.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-YbcEQdR$ >> (side by side) >> >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-R7GbhlI$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff2.html__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-X18OhGE$ >> >> Thanks again! >> >> RFC Editor/lb >> >> >>> On Aug 8, 2025, at 3:39 AM, Dan Garcia Carrillo <garcia...@uniovi.es> wrote: >>> >>> Dear RFC Editor, >>> Please see responses inline. >>> El 4/8/25 a las 21:02, Lynne Bartholomew escribió: >>>> [You don't often get email from lbartholo...@staff.rfc-editor.org. Learn >>>> why this is important at >>>> https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!D9dNQwwGXtA!SZQDUX0GnyaAQikfXmG6ZSZKDBfSBWd7o00UKLtavSWcoUoLjpxOR05XCXbkjfoo9r2Wmc9-wuyl3aTi0R5zxCke-eZaWWpJ$ >>>> ] >>>> >>>> Dear Dan, >>>> >>>> Thank you very much for the updated XML file and answers to our questions! >>>> >>>> We have some follow-up items for you. Please let us know how this document >>>> should be further updated. >>>> >>>> = = = = = >>>> >>>> * Please note that per post-6000 published RFCs (except for RFC 8995), we >>>> changed '4.04 Not found' to '4.04 Not Found'. Please let us know any >>>> objections. >>>> >>> [AUTHORS] No objections to the update. >>> >>>> = = = = = >>>> >>>> * Regarding our question 13) and your reply: As it appears that "Finally, >>>> sends" means "Finally, the CoAP-EAP application sends", per your note that >>>> the CoAP-EAP application takes control, we updated the "Step 2" text >>>> accordingly. If this is incorrect, please clarify the "Finally, sends" >>>> sentence. >>>> >>> [AUTHORS] No objections to the text update. Yes, it is the CoAP-EAP >>> application. >>> >>> >>>>>> 13) <!-- [rfced] Section 3.2: Do "assigns" and "sends" refer to the >>>>>> EAP peer or the EAP peer state machine? If the suggested text is not >>>>>> correct, please provide clarifying text. >>>>>> >>>>>> Original (previous text is included for context): >>>>>> * Step 2. The EAP peer processes the POST message sending the EAP >>>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>>> an EAP response (EAP Resp/Id). Then, assigns a new resource to >>>>>> the ongoing authentication process (e.g., '/a/eap/2'), and deletes >>>>>> the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' >>>>>> response with the new resource identifier in the Location-Path >>>>>> (and/or Location-Query) options for the next step. >>>>>> >>>>>> Suggested (guessing the EAP peer state machine): >>>>>> * Step 2. The EAP peer processes the POST message, sending the EAP >>>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>>> an EAP response (EAP Resp/Id). Then, the EAP peer state machine >>>>>> assigns a new resource to the ongoing authentication process >>>>>> (e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1'). >>>>>> Finally, the EAP peer state machine sends a '2.01 Created' >>>>>> response with the new resource identifier in the Location-Path >>>>>> (and/or Location-Query) options for the next step. --> >>>>>> >>>>>> >>>>> [Authors] We believe the best way to specify this is to differentiate >>>>> between "EAP peer state machine" and the CoAP-EAP application of the EAP >>>>> peer. >>>>> The EAP peer state machine only deals with EAP messages. Processes EAP >>>>> requests and returns an EAP response. >>>>> With that, the CoAP-EAP application within the EAP peer takes control and >>>>> manages everything CoAP related. Assigns a new resource to the ongoing >>>>> authentication process (e.g., '/a/eap/2') and deletes the previous one >>>>> ('/a/eap/1') >>>>> So, a suggested new text. >>>>> Step 2. The EAP peer processes the POST message sending the EAP >>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>> an EAP response (EAP Resp/Id). Then, the CoAP-EAP application >>>>> assigns a new resource to the ongoing authentication process >>>>> (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). >>>>> Finally, sends a '2.01 Created'response with the new resource >>>>> identifier in the Location-Path (and/or Location-Query) options >>>>> for the next step. >>>>> >>>>> >>>> = = = = = >>>> >>>> * Regarding our question 25) and your reply: Because of the preceding >>>> sentence ("The other supported and negotiated cipher suites are as >>>> follows:"), it was not clear to us how best to update this text. Please >>>> review our update, and let us know if anything is incorrect: >>>> >>> [AUTHORS] No objections to the text update. >>> >>> >>>>>> 25) <!-- [rfced] Sections 6.1 and Appendix A: Do these algorithms need >>>>>> to be numbered? If yes, will this numbering scheme be clear to >>>>>> readers? >>>>>> >>>>>> Original: >>>>>> * 0) AES-CCM-16-64-128, SHA-256 (default) >>>>>> >>>>>> * 1) A128GCM, SHA-256 >>>>>> >>>>>> * 2) A256GCM, SHA-384 >>>>>> >>>>>> * 3) ChaCha20/Poly1305, SHA-256 >>>>>> >>>>>> * 4) ChaCha20/Poly1305, SHAKE256 >>>>>> ... >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 >>>>>> >>>>>> Perhaps: >>>>>> * AES-CCM-16-64-128, SHA-256 (default) >>>>>> >>>>>> * A128GCM, SHA-256 >>>>>> >>>>>> * A256GCM, SHA-384 >>>>>> >>>>>> * ChaCha20/Poly1305, SHA-256 >>>>>> >>>>>> * ChaCha20/Poly1305, SHAKE256 >>>>>> ... >>>>>> * TLS_SHA256 >>>>>> >>>>>> * TLS_SHA384 >>>>>> >>>>>> * TLS_SHA512 >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>> [Authors] The numbers on Sections 6.1 match the values in “9.1. CoAP-EAP >>>>> Cipher Suites”. >>>>> The numbers in Appendix A are the expected continuation of these, but are >>>>> not in the specification, and not in the IANA section. This text should >>>>> also solve issue 42 as well. >>>>> Suggested update text: >>>>> The following hash algorithms are considered in case the specification >>>>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>>>> >>>> = = = = = >>>> >>>> * Regarding our question 38) and your reply: Please review our updates >>>> related to the removal of the Zigbee reference, and let us know if >>>> anything is incorrect. >>>> >>>> >>> [AUTHORS] No objections to the text update. >>> >>> >>>>>> 38) <!-- [rfced] [ZigbeeIP]: We could not find this document number. >>>>>> We also found that >>>>>> <https://urldefense.com/v3/__https://www.zigbee.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4xoZxesQ$ >>>>>> > steers to >>>>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>>>> >. When we searched >>>>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>>>> > for >>>>>> the number 095023r34, the result was "Nothing found, please try >>>>>> adjusting your search." >>>>>> >>>>>> Should a different paper be listed here and cited in Appendices B and >>>>>> C.5.1? >>>>>> >>>>>> Original: >>>>>> [ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document >>>>>> 095023r34)", 2014. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] Certainly, this seems to be an old reference. We have other >>>>> examples, the best course of action would be to remove this reference and >>>>> the associated text. >>>>> Forced removal can be done by sending new specific key material to the >>>>> devices that still belong to the network, excluding the removed device, >>>>> following a model similar to CoJP for 6TiSCH [RFC9031] or Zigbee IP >>>>> [ZigbeeIP]. >>>>> – >>>>> Another example would be when a shared Network Key is required by the >>>>> devices that join a network. An example of this Network Key can be found >>>>> in Zigbee IP [ZigbeeIP] or the THREAD protocol [THREAD]. >>>>> >>>> = = = = = >>>> >>>> * Regarding our question 42) and your reply: Because TLS_SHA256, >>>> TLS_SHA384, and TLS_SHA512 are already in the list, is it necessary to >>>> also mention them in the preceding text? >>>> >>>> >>>>>> 42) <!-- [rfced] Appendix A: Should "considered" be "supported" in this >>>>>> sentence, along the lines of "The other supported and negotiated >>>>>> cipher suites are the following" as seen in Section 6.1? >>>>>> >>>>>> Original: >>>>>> The hash algorithms considered are the following: >>>>>> >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 >>>>>> >>>>>> Possibly: >>>>>> The following hash algorithms are supported: >>>>>> >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 --> >>>>>> >>>>>> >>>>> [Authors] Following the previous issue (point 25) >>>>> Proposed text. >>>>> The following hash algorithms are considered in case the specification >>>>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>>>> >>>> Possibly: >>>> The following hash >>>> algorithms are considered in cases where the specification includes DTLS >>>> support in the future: >>>> >>> [AUTHORS] Having the ciphersuites already in the list, it is ok not to >>> mention them in the preceding text. >>> >>> >>>> = = = = = >>>> >>>> * Regarding our question 57) and the following items: >>>> >>>> >>>>>> b) The following terms appear to be used inconsistently in this >>>>>> document. Please let us know which form is preferred. >>>>>> >>>>>> "a/eap/1" (the URI for the first resource would be "a/eap/1") / >>>>>> '/a/eap/1' >>>>>> >>>>>> >>>>> [AUTHORS] "a/eap/1" >>>>> >>>> Apologies for missing this earlier: We see the following: >>>> >>>> >>>>> So, per Figure 3, the URI for the first resource would be "a/eap/1". >>>>> >>>> We also see the following: >>>> >>>> >>>>> '/a/eap/1' >>>>> "/a/eap/1" >>>>> >>>> Are single quotes or double quotes preferred? >>>> Also, please confirm that the single instance of "a/eap/1" is correct >>>> (i.e., "would be "a/eap/1" should not be "would be /a/eap/1"). >>>> >>> [AUTHORS] Please, consider changing to double quotes. >>> >>> >>> >>>> = = = >>>> >>>> >>>>>> EAP-Request/Identity / EAP Req/Id / EAP-Req/Id >>>>>> >>>>>> >>>>> [AUTHORS] EAP-Request/Identity >>>>> >>>>>> EAP-Response/Identity / EAP Resp/Id / EAP Response/Id >>>>>> >>>>>> >>>>> [AUTHORS] EAP-Response/Identity >>>>> >>>> Apologies for not realizing earlier that using the longer forms >>>> "EAP-Request/Identity" and "EAP-Response/Identity" in Figures 3, 5, and 8 >>>> could cause spacing issues in the SVG. >>>> >>>> To avoid such spacing issues and define these terms properly where first >>>> used, we suggest the following: >>>> >>>> - In Section 3.2, define the abbreviated forms by changing "(EAP >>>> Request/Identity)" to >>>> "(EAP-Request/Identity, or EAP-Req/Id)" and changing "an EAP response (EAP >>>> Resp/Id)" to >>>> "an EAP response (EAP-Response/Identity, or EAP-Resp/Id)". >>>> - In Section 6.1, change "both the EAP-Request/Identity and >>>> EAP-Response/Identity" to >>>> "both the EAP-Req/Id and EAP-Resp/Id". >>>> - In Section 8.6, change "EAP Request/Id" to "EAP-Req/Id", and change "EAP >>>> Response/Id" to "EAP-Resp/Id". >>>> >>>> >>> [AUTHORS] No objections to the text update. >>> >>> >>>> = = = >>>> >>>> Regarding this item: >>>> >>>> >>>>>> EAP response / EAP Response (used generally in text, e.g., >>>>>> "an EAP response", "an EAP Response") >>>>>> (We also see "EAP Response header" in Section 7.1.) >>>>>> >>>>>> >>>>> [AUTHORS] EAP Response >>>>> >>>> Please confirm that "EAP Response" when used generally in text is as >>>> desired. We ask because we see "EAP request" used consistently throughout >>>> the text when used generally. >>>> >>>> >>> [AUTHORS] Both should be Capitalized. EAP Response and EAP Request. >>> >>> >>>> = = = = = >>>> >>>> Regarding this item: >>>> >>>> >>>>>> Session-Lifetime / Session-lifetime / Session Lifetime / >>>>>> session lifetime (in running text) >>>>>> (Figure 3 and Table 4 use "Session-Lifetime".) >>>>>> >>>>>> >>>>> [AUTHORS] Session-Lifetime >>>>> >>>> After updating "session lifetime" to "Session-Lifetime", this sentence is >>>> now a bit confusing, as RFC 5247 >>>> does not mention "Session-Lifetime". Should this sentence be rephrased, or >>>> will it be clear to readers? >>>> >>>> Original: >>>> * Step 7. When the EAP authentication ends successfully, the EAP >>>> authenticator obtains the Master Session Key (MSK) exported by the >>>> EAP method, an EAP Success message, and some authorization >>>> information (e.g., session lifetime) [RFC5247]. >>>> >>>> Currently: >>>> * Step 7. When the EAP authentication ends successfully, the EAP >>>> authenticator obtains the MSK exported by the EAP method, an EAP >>>> Success message, and some authorization information (e.g., >>>> Session-Lifetime) [RFC5247]. >>>> >>>> Possibly: >>>> * Step 7. When the EAP authentication ends successfully, the EAP >>>> authenticator obtains the MSK exported by the EAP method, an EAP >>>> Success message, and some authorization information [RFC5247] (e.g., >>>> Session-Lifetime). >>>> >>>> >>> [AUTHORS] It is correct that Session-Lifetime is not specified in RFC5247, >>> but it is something we propose to use as an authorization information >>> instance so the “Possibly” text is correct for us. >>> >>> Thank you. >>> Best regards. >>> >>>> = = = = = >>>> >>>> The latest files are posted here. Please refresh your browser: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.txt__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbJZA27Ts$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.pdf__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbMyfW1jC$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbLKsqN1X$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.xml__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbP80vQJQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-diff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbH0Jmnq8$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbEun-yU8$ >>>> (side by side) >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48diff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbJC23Knu$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48rfcdiff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbN_-hSIL$ >>>> (side by side) >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbLA__aeT$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff2.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbNa1m-S9$ >>>> >>>> Thanks again for your help and patience! >>>> >>>> RFC Editor/lb >>>> >>>> >>>> >>>>> On Jul 29, 2025, at 10:09 AM, Dan Garcia Carrillo <garcia...@uniovi.es> >>>>> wrote: >>>>> >>>>> Dear RFC Editor, >>>>> Please see answers inline. For the requested clarifications in Figures, >>>>> we attach a .xml version with the figures updated. >>>>> Please, let us know if anything else is required. >>>>> >>>>> El 18/7/25 a las 19:53, rfc-edi...@rfc-editor.org escribió: >>>>> >>>>>> Authors and AD*, >>>>>> >>>>>> *AD, please see question #1 below. >>>>>> >>>>>> Authors, while reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> >>>>>> >>>>>> 1) <!-- [rfced] *AD, text was added to the Acknowledgments section after >>>>>> the >>>>>> document was approved for publication. Please review the changes, and >>>>>> let us know if you approve. >>>>>> >>>>>> Diff between v14 and v15: >>>>>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-wg-coap-eap-15__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH77QRYqZw$ >>>>>> --> >>>>>> >>>>>> >>>>>> 2) <!-- [rfced] Please note that the title of the document has been >>>>>> updated as >>>>>> follows. We expanded abbreviations per Section 3.6 of RFC 7322 ("RFC >>>>>> Style Guide"), recast "-based" to avoid using a hyphen with an expansion, >>>>>> and added "for Use with". Please review. >>>>>> >>>>>> Original: >>>>>> EAP-Based Authentication Service for CoAP >>>>>> >>>>>> Current: >>>>>> Authentication Service Based on the Extensible Authentication Protocol >>>>>> (EAP) for Use with the Constrained >>>>>> Application Protocol (CoAP) >>>>>> --> >>>>>> >>>>>> >>>>> [Authors] This change is ok. >>>>> >>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>>> the >>>>>> title) for use on >>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7N7e55Gg$ >>>>>> >. --> >>>>>> >>>>>> >>>>> [Authors] We believe that these could be keywords representing the work: >>>>> >>>>> CoAP, EAP, EAP lower layer, Internet of Things, IoT, Constrained Node, >>>>> Smart Object >>>>> >>>>> >>>>>> 4) <!-- [rfced] Abstract: We had trouble following the meaning of >>>>>> "transported" in this sentence. If the suggested text is not >>>>>> correct, please provide clarifying text. >>>>>> >>>>>> Original: >>>>>> This document specifies an authentication service that uses the >>>>>> Extensible Authentication Protocol (EAP) transported employing >>>>>> Constrained Application Protocol (CoAP) messages. >>>>>> >>>>>> Suggested: >>>>>> This document specifies an authentication service that uses the >>>>>> Extensible Authentication Protocol (EAP) as a transport method that >>>>>> employs Constrained Application Protocol (CoAP) messages. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text can be misleading as the protocol being >>>>> carried is EAP and the one that carries EAP is CoAP. >>>>> Next, our suggested text would be: >>>>> This document specifies an authentication service that uses the >>>>> Constrained Application Protocol (CoAP) as a transport method to >>>>> carry the Extensible Authentication Protocol (EAP). >>>>> >>>>> >>>>> >>>>>> 5) <!-- [rfced] We found quite a few undefined abbreviations in this >>>>>> document. For ease of the reader, we expanded as many of them as we >>>>>> could find. Most were straightforward (e.g., SAML per RFC 7833, >>>>>> PANA per RFC 5191), but please confirm that our expansions for MIC >>>>>> (currently "Message Integrity Check") and LoRa (currently "Long >>>>>> Range") are correct. >>>>>> >>>>>> Original: >>>>>> EAP relies on lower layer error >>>>>> detection (e.g., CRC, checksum, MIC, etc.). >>>>>> ... >>>>>> Given that EAP is also used for network access authentication, this >>>>>> service can be adapted to other technologies. For instance, to >>>>>> provide network access control to very constrained technologies >>>>>> (e.g., LoRa network). >>>>>> >>>>>> Currently (fixed the incomplete sentence in the "LoRa" text): >>>>>> EAP relies on lower-layer error >>>>>> detection (e.g., CRC, checksum, Message Integrity Check (MIC), >>>>>> etc.). >>>>>> ... >>>>>> Given that EAP is also used for network access authentication, this >>>>>> service can be adapted to other technologies - for instance, to >>>>>> provide network access control to very constrained technologies >>>>>> (e.g., Long Range (LoRa) networks). --> >>>>>> >>>>>> >>>>> [Authors] Yes, these suggestions are correct. >>>>> >>>>> >>>>>> 6) <!-- [rfced] Section 2: These sentences did not parse. We updated >>>>>> the text. If this is incorrect, please provide clarifying text. >>>>>> >>>>>> Original: >>>>>> The rationale behind this decision >>>>>> is that EAP requests direction is always from the EAP server to the >>>>>> EAP peer. Accordingly, EAP responses direction is always from the >>>>>> EAP peer to the EAP server. >>>>>> >>>>>> Currently: >>>>>> The rationale behind this decision is that EAP requests will always >>>>>> travel from the EAP server to the EAP peer. Accordingly, EAP >>>>>> responses will always travel from the EAP peer to the EAP server. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] Yes, these suggestions are correct. >>>>> >>>>> >>>>> >>>>>> 7) <!-- [rfced] Please review each artwork element. Should any artwork >>>>>> element be tagged as sourcecode? If the current list of preferred >>>>>> values for "type" on >>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5spEm40g$ >>>>>> > >>>>>> does not contain an applicable type, please let us know. Also, it is >>>>>> acceptable to leave the "type" attribute unset. --> >>>>>> >>>>>> >>>>> [Authors] We assume that this is in reference to "Figure 6: CBOR Data >>>>> Structure for CoAP-EAP". >>>>> It is not our intention to specify sourcecode, it could be left as type >>>>> unset. >>>>> >>>>> >>>>>> 8) <!-- [rfced] Figure 1: We see "(SCOPE OF THIS DOCUMENT)" in the >>>>>> ASCII art but "SCOPE OF THIS DOCUMENT" in the SVG. If you prefer the >>>>>> parentheses, please correct the SVG in the edited copy of the XML. >>>>>> If you prefer that the parentheses be removed, let us know, and we >>>>>> will update the ASCII art accordingly. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] There are no need for parentheses, the message is clear without >>>>> them. >>>>> >>>>> >>>>>> 9) <!-- [rfced] Figure 2: We changed "Request/Responses/Signaling" to >>>>>> "Request / Responses / Signaling", to match the spacing style of the >>>>>> other entries in the figure. However, the "Request / Responses / >>>>>> Signaling" line now looks a bit crowded in the SVG renderings in the >>>>>> HTML and PDF output files. We cannot determine where in the SVG a >>>>>> coordinate should be modified to correct the spacing. Please correct >>>>>> the SVG in the edited copy of the XML. --> >>>>>> >>>>>> >>>>> [Authors] The line should say >>>>> Requests / Responses / Signaling >>>>> >>>>> We have provided a new <artwork> code in the attached document >>>>> rfc9820_modified.xml that is not so crowded and tries to convey the >>>>> improvements. >>>>> This is also updated in svg in the attached file rfc9820_modified.xml >>>>> >>>>> >>>>>> 10) <!-- [rfced] Sections 3.1 and subsequent: We see phrases such as >>>>>> "an intermediary proxy", "intermediary (i.e., proxy)", and >>>>>> "intermediaries such as proxies" in this document. Will the >>>>>> distinction regarding whether or not intermediaries are sometimes or >>>>>> always proxies be clear to readers? --> >>>>>> >>>>>> >>>>> [Authors] We are following CoAP terminology, being according to rfc7252 >>>>> Intermediary >>>>> A CoAP endpoint that acts both as a server and as a client towards an >>>>> origin server (possibly via further intermediaries). A common form of an >>>>> intermediary is a proxy; several classes of such proxies are discussed in >>>>> this specification. >>>>> Maybe the following modifications would make this clearer to the reader. >>>>> 3.1. Discovery >>>>> Before the CoAP-EAP exchange takes place, the EAP peer needs to discover >>>>> the EAP authenticator or the entity that will enable the CoAP-EAP >>>>> exchange (e.g.i.e., an intermediary proxy). >>>>> —- >>>>> 8.3. Allowing CoAP-EAP Traffic to Perform Authentication >>>>> Since CoAP is an application protocol, CoAP-EAP assumes certain IP >>>>> connectivity in the link between the EAP peer and the EAP authenticator >>>>> to run. This link MUST authorize exclusively unprotected IP traffic to be >>>>> sent between the EAP peer and the EAP authenticator during the >>>>> authentication with CoAP-EAP. Once the authentication is successful, the >>>>> key material generated by the EAP authentication (MSK) and any other >>>>> traffic can be authorized if it is protected. It is worth noting that if >>>>> the EAP authenticator is not in the same link as the EAP peer and an >>>>> intermediate entity (i.e.e.g., a CoAP proxy) helps with this process, >>>>> this concept also applies to the communication between the EAP peer and >>>>> the intermediary. >>>>> —- >>>>> When the EAP peer intends to be admitted into the network, it would >>>>> search for an entity that offers the CoAP-EAP service, be it directly via >>>>> the EAP authenticator or through an intermediary (i.e.e.g., proxy). See >>>>> Section 3.1. >>>>> — >>>>> If the EAP peer cannot connect to the EAP authenticator directly, the EAP >>>>> peer can follow the same process as that described in Section 3.6 to >>>>> perform the authentication (i.e., can connect via an intermediary entity >>>>> (e.g., proxy) that is already part of the network (already shares key >>>>> material and communicates through a secure channel with the >>>>> authenticator) and can aid in running CoAP-EAP). >>>>> — >>>>> When CoAP-EAP is completed and the OSCORE security association is >>>>> established with the EAP authenticator, the EAP peer receives the local >>>>> configuration parameters for the network (e.g., a network key) and can >>>>> configure a global IPv6 address. Moreover, there is no need for a CoAP >>>>> proxy an intermediary entity after a successful authentication. >>>>> >>>>> >>>>>> 11) <!-- [rfced] Section 3.1: This sentence does not parse. If neither >>>>>> suggestion below is correct, please clarify the meaning of "hence". >>>>>> >>>>>> Original: >>>>>> For >>>>>> example, on a 6LoWPAN network, the Border Router will typically act >>>>>> as the EAP authenticator hence, after receiving the Router >>>>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>>>> engage on the CoAP-EAP exchange. >>>>>> >>>>>> Suggestion #1: >>>>>> For >>>>>> example, in a 6LoWPAN network, the Border Router will henceforth >>>>>> typically act as the EAP authenticator. After receiving the Router >>>>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>>>> engage in the CoAP-EAP exchange. >>>>>> >>>>>> Suggestion #2: >>>>>> For >>>>>> example, in a 6LoWPAN network, the Border Router will typically act >>>>>> as the EAP authenticator. Hence, after receiving the Router >>>>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>>>> engage in the CoAP-EAP exchange. --> >>>>>> >>>>>> >>>>> [Authors] Suggestion #2 >>>>> >>>>> >>>>>> 12) <!-- [rfced] Section 3.2: Please confirm that the "Implementation >>>>>> notes" paragraph and bullet list should remain independent of Step 0 >>>>>> (i.e., should not be indented so that it is part of Step 0). We see >>>>>> "resource of a step of the authentication" in the text, which seems >>>>>> to indicate that this information applies to all steps and not just >>>>>> Step 0, but we would still like you to confirm that the current >>>>>> indentation levels are correct. >>>>>> >>>>>> Original: >>>>>> * Step 0. The EAP peer MUST start the CoAP-EAP process by sending a >>>>>> "POST /.well-known/coap-eap" request (trigger message). This >>>>>> message carries the 'No-Response' [RFC7967] CoAP option to avoid >>>>>> waiting for a response that is not needed. This is the only >>>>>> message where the EAP authenticator acts as a CoAP server and the >>>>>> EAP peer as a CoAP client. The message also includes a URI in the >>>>>> payload of the message to indicate the resource where the EAP >>>>>> authenticator MUST send the next message. The name of the >>>>>> resource is selected by the CoAP server. >>>>>> >>>>>> Implementation notes: When generating the URI for a resource of a >>>>>> step of the authentication, the resource could have the following >>>>>> format as an example "path/eap/counter", where: >>>>>> >>>>>> * "path" is some local path on the device to make the path unique. >>>>>> This could be omitted if desired. >>>>>> >>>>>> * "eap" is the name that indicates the URI is for the EAP peer. >>>>>> This has no meaning for the protocol but helps with debugging. >>>>>> >>>>>> * "counter' which is an incrementing unique number for every new EAP >>>>>> request. >>>>>> >>>>>> So, in Figure 3 for example, the URI for the first resource would be >>>>>> “a/eap/1" >>>>>> >>>>>> * Step 1. ... --> >>>>>> >>>>>> >>>>> [Authors] Yes, the "Implementation notes" paragraph and bullet list >>>>> should remain independent of Step 0 >>>>> >>>>> >>>>>> 13) <!-- [rfced] Section 3.2: Do "assigns" and "sends" refer to the >>>>>> EAP peer or the EAP peer state machine? If the suggested text is not >>>>>> correct, please provide clarifying text. >>>>>> >>>>>> Original (previous text is included for context): >>>>>> * Step 2. The EAP peer processes the POST message sending the EAP >>>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>>> an EAP response (EAP Resp/Id). Then, assigns a new resource to >>>>>> the ongoing authentication process (e.g., '/a/eap/2'), and deletes >>>>>> the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' >>>>>> response with the new resource identifier in the Location-Path >>>>>> (and/or Location-Query) options for the next step. >>>>>> >>>>>> Suggested (guessing the EAP peer state machine): >>>>>> * Step 2. The EAP peer processes the POST message, sending the EAP >>>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>>> an EAP response (EAP Resp/Id). Then, the EAP peer state machine >>>>>> assigns a new resource to the ongoing authentication process >>>>>> (e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1'). >>>>>> Finally, the EAP peer state machine sends a '2.01 Created' >>>>>> response with the new resource identifier in the Location-Path >>>>>> (and/or Location-Query) options for the next step. --> >>>>>> >>>>>> >>>>> [Authors] We believe the best way to specify this is to differentiate >>>>> between "EAP peer state machine" and the CoAP-EAP application of the EAP >>>>> peer. >>>>> The EAP peer state machine only deals with EAP messages. Processes EAP >>>>> requests and returns an EAP response. >>>>> With that, the CoAP-EAP application within the EAP peer takes control and >>>>> manages everything CoAP related. Assigns a new resource to the ongoing >>>>> authentication process (e.g., '/a/eap/2') and deletes the previous one >>>>> ('/a/eap/1') >>>>> So, a suggested new text. >>>>> Step 2. The EAP peer processes the POST message sending the EAP >>>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>>> an EAP response (EAP Resp/Id). Then, the CoAP-EAP application >>>>> assigns a new resource to the ongoing authentication process >>>>> (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). >>>>> Finally, sends a '2.01 Created'response with the new resource >>>>> identifier in the Location-Path (and/or Location-Query) options >>>>> for the next step. >>>>> >>>>> >>>>> >>>>>> 14) <!-- [rfced] Section 3.2: Please clarify the meaning of "response to >>>>>> carry the EAP response" in this sentence. >>>>>> >>>>>> Original: >>>>>> The EAP peer will use a response to carry the EAP response in the >>>>>> payload. --> >>>>>> >>>>>> >>>>> [Authors] The text should say: >>>>> The EAP peer will use a CoAP response to carry the EAP response in the >>>>> payload. >>>>> >>>>> >>>>>> 15) <!-- [rfced] Section 3.5: The second sentence was incomplete and >>>>>> difficult to follow. Per Sections 3.5.1 through 3.5.3, we updated >>>>>> this section as noted below. If this is incorrect, please clarify. >>>>>> >>>>>> Original: >>>>>> This section elaborates on how different errors are handled. From >>>>>> EAP authentication failure, a non-responsive endpoint lost messages, >>>>>> or an initial POST message arriving out of place. >>>>>> >>>>>> Currently: >>>>>> This section elaborates on how different errors are handled: EAP >>>>>> authentication failure (Section 3.5.1), a non-responsive endpoint >>>>>> (Section 3.5.2), and duplicated messages (Section 3.5.3). --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 16) <!-- [rfced] Section 3.5.2: We could not follow the meaning of this >>>>>> run-on sentence. If the suggested text is not correct, please >>>>>> provide clarifying text. >>>>>> >>>>>> Original: >>>>>> By default, CoAP-EAP adopts the >>>>>> value of EXCHANGE_LIFETIME as a timer in the EAP peer and >>>>>> Authenticator to remove the CoAP-EAP state if the authentication >>>>>> process has not progressed in that time, in consequence, it has not >>>>>> been completed. >>>>>> >>>>>> Suggested: >>>>>> By default, CoAP-EAP adopts the >>>>>> value of EXCHANGE_LIFETIME as a timer in the EAP peer and >>>>>> authenticator to remove the CoAP-EAP state if the authentication >>>>>> process has not progressed to completion during that time. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>>> 17) <!-- [rfced] Section 3.5.3: Does "Step 0" here refer to Step 0 in >>>>>> Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest >>>>>> adding a citation for the appropriate figure. >>>>>> >>>>>> Original: >>>>>> The reception of the trigger message in Step 0 containing the URI >>>>>> /coap-eap needs some additional considerations, as the resource is >>>>>> always available in the EAP authenticator. --> >>>>>> >>>>>> >>>>> [Authors] This first instance of Step 0 is referring to the complete Flow >>>>> in Figure 3. >>>>> The last instance refers to Figure 5. >>>>> For clarity the text would be: >>>>> The reception of the trigger message (Step 0 in Figure 3) containing the >>>>> URI /coap-eap needs some additional considerations, as the resource is >>>>> always available in the EAP authenticator. >>>>> If a trigger message arrives at the EAP authenticator during an ongoing >>>>> authentication with the same EAP peer, the EAP authenticator MUST >>>>> silently discard this trigger message. >>>>> If an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives at >>>>> the EAP authenticator and there is no authentication ongoing, the EAP >>>>> authenticator may understand that a new authentication process is >>>>> requested. Consequently, the EAP authenticator will start a new EAP >>>>> authentication. However, if the EAP peer did not start any authentication >>>>> and therefore, it did not select any resource for the EAP authentication. >>>>> Thus, the EAP peer sends a '4.04 Not Found' in the response. >>>>> >>>>> >>>>>> 18) <!-- [rfced] Section 3.5.3: The "However, if ..." sentence is >>>>>> incomplete; it appears that some words are missing. Please clarify >>>>>> this text. >>>>>> >>>>>> Original (the previous and next sentences are included for context): >>>>>> Consequently, the EAP authenticator will start a new EAP >>>>>> authentication. However, if the EAP peer did not start any >>>>>> authentication and therefore, it did not select any resource for the >>>>>> EAP authentication. Thus, the EAP peer sends a '4.04 Not found' in >>>>>> the response (Figure 5). --> >>>>>> >>>>>> >>>>> [Authors] Maybe this is simpler, >>>>> “However, if the EAP peer did not start any authentication, it will send >>>>> a '4.04 Not found' in the response (Figure 5).” >>>>> >>>>>> 19) <!-- [rfced] Section 3.6: The following sentences do not parse. >>>>>> >>>>>> If the suggested text for the first sentence is not correct, please >>>>>> provide clarifying text. >>>>>> >>>>>> We cannot follow the meaning of the second sentence. Please clarify >>>>>> "the proxy will act as forward, and as reverse for the rest". >>>>>> >>>>>> Original (the first sentence is included for context): >>>>>> After that, in the >>>>>> remaining exchanges the roles are reversed, being the EAP peer, the >>>>>> CoAP server, and the EAP authenticator, the CoAP client. When using >>>>>> a proxy in the exchange, for message 0, the proxy will act as >>>>>> forward, and as reverse for the rest. >>>>>> >>>>>> Suggested (first sentence): >>>>>> In the remaining exchanges, the roles are reversed (i.e., the EAP >>>>>> peer acts as the CoAP server, and the EAP authenticator acts as the >>>>>> CoAP client). --> >>>>>> >>>>>> >>>>> [Authors] The text would be the following, hopefully it is clearer: >>>>> In the remaining exchanges, the roles are reversed (i.e., the EAP >>>>> peer acts as the CoAP server, and the EAP authenticator acts as the >>>>> CoAP client). When using a proxy in the exchange, for message 0 it will >>>>> act as a forward proxy, and as a reverse proxy for the rest. >>>>> >>>>>> 20) <!-- [rfced] Section 5: We found this sentence confusing, because >>>>>> the plural "Examples" is used but the text that follows shows an >>>>>> "either-or" relationship ("cipher suites that need to be negotiated >>>>>> or ..."). If the suggested text is not correct, please provide >>>>>> clarifying text. >>>>>> >>>>>> Original (the previous sentence is included for context): >>>>>> In the CoAP-EAP exchange, there is information that needs to be >>>>>> exchanged between the two entities. Examples of this information are >>>>>> the cipher suites that need to be negotiated or authorization >>>>>> information (Session-lifetime). >>>>>> >>>>>> Suggested: >>>>>> In the CoAP-EAP exchange, information needs to be exchanged between >>>>>> the two entities - for example, the cipher suites that need to be >>>>>> negotiated, or authorization information (Session-lifetime). --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 21) <!-- [rfced] Section 5: Per Figure 6, Table 4, and >>>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4SyTyIVA$ >>>>>> >, we moved the RID-I item >>>>>> so that it is the third item (Label 3, per Figure 6, Table 4, and >>>>>> IANA) instead of the second; RID-C is now the second item. >>>>>> Please let us know any objections. >>>>>> >>>>>> Original: >>>>>> 2. RID-I: Is the Recipient ID of the EAP peer. The EAP >>>>>> authenticator uses this value as a Sender ID for its OSCORE >>>>>> Sender Context. The EAP peer uses this value as Recipient ID for >>>>>> its Recipient Context. >>>>>> >>>>>> 3. RID-C: Is the Recipient ID of the EAP authenticator. The EAP >>>>>> peer uses this value as a Sender ID for its OSCORE Sender >>>>>> Context. The EAP authenticator uses this value as Recipient ID >>>>>> for its Recipient Context. >>>>>> >>>>>> Currently: >>>>>> 2. RID-C: The Recipient ID of the EAP authenticator. The EAP peer >>>>>> uses this value as the Sender ID for its OSCORE Sender Context. >>>>>> The EAP authenticator uses this value as the Recipient ID for its >>>>>> Recipient Context. >>>>>> >>>>>> 3. RID-I: The Recipient ID of the EAP peer. The EAP authenticator >>>>>> uses this value as the Sender ID for its OSCORE Sender Context. >>>>>> The EAP peer uses this value as the Recipient ID for its >>>>>> Recipient Context. --> >>>>>> >>>>>> >>>>> [Authors] No objection. >>>>> >>>>> >>>>> >>>>>> 22) <!-- [rfced] Section 6.1: Does "Steps 1 and 2" here refer to >>>>>> Steps 1 and 2 in Figure 3 or Steps 1 and 2 in Figure 8? >>>>>> For ease of the reader, we suggest adding a citation for the >>>>>> appropriate figure. >>>>>> >>>>>> Original: >>>>>> OSCORE runs after the EAP authentication, using the cipher suite >>>>>> selected in the cipher suite negotiation (Steps 1 and 2). --> >>>>>> >>>>>> >>>>> [Authors] We refer to Figure 3 in the first instance. To Figure 8 in the >>>>> other instances in that section. Corrected text below: >>>>> OSCORE runs after the EAP authentication, using the cipher suite selected >>>>> in the cipher suite negotiation (Steps 1 and 2 in Figure 3). To negotiate >>>>> the cipher suite, CoAP-EAP follows a simple approach: The EAP >>>>> authenticator sends a list, in decreasing order of preference, with the >>>>> identifiers of the supported cipher suites (Step 1 in Figure 8). In the >>>>> response to that message (Step 2 in Figure 8), the EAP peer sends its >>>>> choice. >>>>> >>>>> >>>>> >>>>>> 23) <!-- [rfced] Section 6.1: We had trouble following this sentence. >>>>>> If the suggested text is not correct, please clarify "where it can be >>>>>> appreciated the disposition". >>>>>> >>>>>> Original: >>>>>> An example of the exchange with the >>>>>> cipher suite negotiation is shown in Figure 8, where it can be >>>>>> appreciated the disposition of both EAP-Request/Identity and EAP- >>>>>> Response/Identity, followed by the CBOR object defined in Section 5, >>>>>> containing the cipher suite field for the cipher suite negotiation. >>>>>> >>>>>> Suggested: >>>>>> An example exchange for the >>>>>> cipher suite negotiation is shown in Figure 8. The >>>>>> EAP request (EAP-Request/Identity) and EAP response >>>>>> (EAP-Response/Identity) are sent; both messages include the CBOR >>>>>> object (Section 5) containing the cipher suite field for the cipher >>>>>> suite negotiation. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok >>>>> >>>>> >>>>> >>>>> >>>>>> 24) <!-- [rfced] Figure 7: We note that the ASCII art has two pipes >>>>>> (with "+" >>>>>> above each) between the "Data" and "cipher suites" fields, while the SVG >>>>>> has vertical lines along with curved lines that intersect each >>>>>> other. Please review and correct the edited copy of the XML if needed. >>>>>> --> >>>>>> >>>>>> >>>>> [Authors] We provided a new Figure in the xml attached file that >>>>> hopefully is much more clearer. >>>>> >>>>> >>>>>> 25) <!-- [rfced] Sections 6.1 and Appendix A: Do these algorithms need >>>>>> to be numbered? If yes, will this numbering scheme be clear to >>>>>> readers? >>>>>> >>>>>> Original: >>>>>> * 0) AES-CCM-16-64-128, SHA-256 (default) >>>>>> >>>>>> * 1) A128GCM, SHA-256 >>>>>> >>>>>> * 2) A256GCM, SHA-384 >>>>>> >>>>>> * 3) ChaCha20/Poly1305, SHA-256 >>>>>> >>>>>> * 4) ChaCha20/Poly1305, SHAKE256 >>>>>> ... >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 >>>>>> >>>>>> Perhaps: >>>>>> * AES-CCM-16-64-128, SHA-256 (default) >>>>>> >>>>>> * A128GCM, SHA-256 >>>>>> >>>>>> * A256GCM, SHA-384 >>>>>> >>>>>> * ChaCha20/Poly1305, SHA-256 >>>>>> >>>>>> * ChaCha20/Poly1305, SHAKE256 >>>>>> ... >>>>>> * TLS_SHA256 >>>>>> >>>>>> * TLS_SHA384 >>>>>> >>>>>> * TLS_SHA512 >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>> [Authors] The numbers on Sections 6.1 match the values in “9.1. CoAP-EAP >>>>> Cipher Suites”. >>>>> The numbers in Appendix A are the expected continuation of these, but are >>>>> not in the specification, and not in the IANA section. This text should >>>>> also solve issue 42 as well. >>>>> Suggested update text: >>>>> The following hash algorithms are considered in case the specification >>>>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>>>> >>>>> >>>>>> 26) <!-- [rfced] Section 6.2: Does "Steps 7 and 8" here refer to >>>>>> Steps 7 and 8 in Figure 3? If yes, for ease of the reader we suggest >>>>>> adding a citation for Figure 3. >>>>>> >>>>>> Original: >>>>>> The derivation of the security context for OSCORE allows securing the >>>>>> communication between the EAP peer and the EAP authenticator once the >>>>>> MSK has been exported, providing confidentiality, integrity, key >>>>>> confirmation (Steps 7 and 8), and downgrading attack detection. --> >>>>>> >>>>>> >>>>> [Authors] Yes, we refer to Figure 3. >>>>> >>>>> >>>>>> 27) <!-- [rfced] Section 6.2: We clarified these sentences as noted >>>>>> below. If these updates are incorrect, please clarify "the cipher >>>>>> suite 0". >>>>>> >>>>>> Original: >>>>>> If CS-C or CS-I were not sent, (i.e., default algorithms are used) >>>>>> the value used to generate CS will be the same as if the default >>>>>> algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR >>>>>> array with the cipher suite 0). >>>>>> ... >>>>>> If CS-C or CS-I were not sent, (i.e., default algorithms are used) >>>>>> the value used to generate CS will be the same as if the default >>>>>> algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR >>>>>> array with the cipher suite 0). >>>>>> >>>>>> Currently: >>>>>> If neither CS-C nor CS-I was sent (i.e., default algorithms are >>>>>> used), the value used to generate CS will be the same as if the >>>>>> default algorithms were explicitly sent in CS-C or CS-I (i.e., a >>>>>> CBOR array with the cipher suite value of 0). >>>>>> ... >>>>>> If neither CS-C nor CS-I was sent (i.e., default algorithms are >>>>>> used), the value used to generate CS will be the same as if the >>>>>> default algorithms were explicitly sent in CS-C or CS-I (i.e., a >>>>>> CBOR array with the cipher suite value of 0). --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 28) <!-- [rfced] Please review instances of the term "NULL" as used in >>>>>> this >>>>>> document and let us know if any updates are needed. We believe that >>>>>> "NULL" should be updated to either "NUL" (that is, referring to the >>>>>> specific ASCII control code) or "null". --> >>>>>> >>>>>> >>>>> [Authors] We mean the same as the instance you can find in rfc5191 of >>>>> PANA page 16 >>>>> - "IETF PANA" is the ASCII code representation of the non-NULL terminated >>>>> string (excluding the double quotes around it). >>>>> >>>>> >>>>> >>>>>> 29) <!-- [rfced] Section 7.1: We changed this text as noted below. >>>>>> Please review carefully (including our expansion of "AVP" for ease of >>>>>> the reader), and let us know if anything is incorrect. >>>>>> >>>>>> Original: >>>>>> Note: When EAP >>>>>> is proxied over an AAA framework, the Access-Request packets in >>>>>> RADIUS MUST contain a Framed-MTU attribute with the value 1024, and >>>>>> the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA >>>>>> server that it should limit its responses to 1024 octets. >>>>>> >>>>>> Currently: >>>>>> Note: When EAP is proxied over a AAA framework, the >>>>>> Access-Request packets in RADIUS MUST contain a Framed-MTU >>>>>> attribute with a value of 1024 and, in Diameter, the Framed-MTU >>>>>> Attribute-Value Pair (AVP) with a value of 1024. This information >>>>>> signals the AAA server that it should limit its responses to 1024 >>>>>> octets. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 30) <!-- [rfced] Section 7.2: This sentence is difficult to parse. If >>>>>> the suggested text is not correct, please rephrase "constrained >>>>>> devices and network scenarios" and "older versions with the goal of >>>>>> economization". >>>>>> >>>>>> Also, please review and let us know whether this "Note:" item that is >>>>>> set off in a separate paragraph should be in the <aside> element. >>>>>> <aside> is defined as "a container for content that is semantically >>>>>> less important or tangential to the content that surrounds it" >>>>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5DOBldVg$ >>>>>> ). >>>>>> >>>>>> Original: >>>>>> Note: For constrained devices and network scenarios, the use of the >>>>>> latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 >>>>>> [RFC9190]) is recommended in favor of older versions with the goal of >>>>>> economization, or EAP methods more adapted for IoT (e.g., EAP-NOOB >>>>>> [RFC9140], EAP-EDHOC [I-D.ietf-emu-eap-edhoc], etc.). >>>>>> >>>>>> Suggested: >>>>>> Note: To improve efficiency in environments with >>>>>> constrained devices and networks, the latest versions of EAP methods >>>>>> (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over >>>>>> older versions. EAP methods more adapted for IoT networks (e.g., >>>>>> EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also >>>>>> recommended. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 31) <!-- [rfced] Section 8.2: This sentence did not parse. We updated >>>>>> it as noted below. If this update is incorrect, please clarify >>>>>> "can be with the transport of SAML". >>>>>> >>>>>> Original: >>>>>> Providing more fine-grained >>>>>> authorization data can be with the transport of SAML in RADIUS >>>>>> [RFC7833]. >>>>>> >>>>>> Currently: >>>>>> Providing more fine-grained >>>>>> authorization data can be done by transporting the data using the >>>>>> Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. --> >>>>>> >>>>>> >>>>> [Authors] Currently suggested text is ok. >>>>> >>>>>> 32) <!-- [rfced] Section 8.3: >>>>>> >>>>>> a) To what does "exclusively" refer in this sentence? If the >>>>>> suggested text is not correct, please clarify. >>>>>> >>>>>> Original (the previous sentence is included for context): >>>>>> Since CoAP is an application protocol, CoAP-EAP assumes certain IP >>>>>> connectivity in the link between the EAP peer and the EAP >>>>>> authenticator to run. This link MUST authorize exclusively >>>>>> unprotected IP traffic to be sent between the EAP peer and the EAP >>>>>> authenticator during the authentication with CoAP-EAP. >>>>>> >>>>>> Suggested: >>>>>> This link MUST only authorize >>>>>> unprotected IP traffic to be sent between the EAP peer and the EAP >>>>>> authenticator during the authentication with CoAP-EAP. >>>>>> >>>>>> >>>>> [Authors] We mean that this link will only allow unprotected traffic >>>>> between the EAP peer and the EAP for the purpose of running CoAP-EAP. Any >>>>> other traffic should not be allowed. >>>>> >>>>> The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> b) This sentence did not parse. We updated it to make a complete >>>>>> sentence. Please review this update carefully; if it is incorrect, >>>>>> please clarify. >>>>>> >>>>>> Original: >>>>>> It is worth noting that if the EAP authenticator is not >>>>>> in the same link as the EAP peer and an intermediate entity helps >>>>>> with this process (i.e., CoAP proxy) and the same comment applies to >>>>>> the communication between the EAP peer and the intermediary. >>>>>> >>>>>> Currently: >>>>>> It is worth noting that if the EAP authenticator is not >>>>>> in the same link as the EAP peer and an intermediate entity (i.e., a >>>>>> CoAP proxy) helps with this process, this concept also applies to the >>>>>> communication between the EAP peer and the intermediary. --> >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>>> 33) <!-- [rfced] Section 8.5: Does "the document" refer to RFC 6677 or >>>>>> this document? Also, how may we update "(To be assigned by IANA)"? >>>>>> >>>>>> Original (the previous paragraph is included for context): >>>>>> According to the [RFC6677], channel binding, related to EAP, is sent >>>>>> through the EAP method supporting it. >>>>>> >>>>>> To satisfy the requirements of the document, the EAP lower layer >>>>>> identifier (To be assigned by IANA) needs to be sent, in the EAP >>>>>> Lower-Layer Attribute if RADIUS is used. >>>>>> >>>>>> Perhaps: >>>>>> To satisfy the requirements of this document, the EAP lower-layer >>>>>> identifier for CoAP-EAP (10) needs to be sent, in the EAP >>>>>> Lower-Layer Attribute if RADIUS is used. >>>>>> >>>>>> Or: >>>>>> To satisfy the requirements of this document, the EAP lower-layer >>>>>> identifier assigned by IANA (see Section 9.4) needs to be sent, in the >>>>>> EAP >>>>>> Lower-Layer Attribute if RADIUS is used. >>>>>> --> >>>>>> >>>>>> >>>>> [Authors] We believe the first proposal is ok >>>>> To satisfy the requirements of this document, the EAP lower-layer >>>>> identifier for CoAP-EAP (10) needs to be sent, in the EAP >>>>> Lower-Layer Attribute if RADIUS is used. >>>>> >>>>> >>>>> >>>>> >>>>>> 34) <!-- [rfced] Section 8.6: Does "Step 0" here refer to Step 0 in >>>>>> Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest >>>>>> adding a citation for the appropriate figure. >>>>>> >>>>>> Original: >>>>>> For instance, an attacker can forge >>>>>> multiple initial messages to start an authentication (Step 0) with >>>>>> the EAP authenticator as if they were sent by different EAP peers. --> >>>>>> >>>>>> >>>>> [Authors] we refer to Figure 3. >>>>> >>>>> >>>>> >>>>>> 35) <!-- [rfced] Sections 9.1 and 9.2: The name "CoAP-EAP protocol" for >>>>>> the new >>>>>> registry group reads oddly, as it means "Constrained Application >>>>>> Protocol-Extensible Authentication Protocol protocol". May we change the >>>>>> name of the new registry group to "CoAP-EAP"? >>>>>> >>>>>> If yes, we will ask IANA to update the registry group name on >>>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/coap-eap.xhtml__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6tPX02Xg$ >>>>>> >. >>>>>> (We could not find an existing IANA registry with the name "CoAP-EAP", >>>>>> so this name would be unique (but we would confirm this with IANA).) >>>>>> >>>>>> Original: >>>>>> IANA has created a new registry titled "CoAP-EAP Cipher Suites" under >>>>>> the new group name "CoAP-EAP protocol". >>>>>> ... >>>>>> IANA has created a new registry titled "CoAP-EAP Information element" >>>>>> under the new group name "CoAP-EAP protocol". --> >>>>>> >>>>>> >>>>> [Authors] The suggested changes are ok for us. >>>>> >>>>> >>>>> >>>>>> 36) <!-- [rfced] Section 9.2: Because there is no "Value" entity in the >>>>>> "CoAP-EAP Information Elements" registry, we changed "Value" to >>>>>> "Label" per >>>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4SyTyIVA$ >>>>>> >. If this is >>>>>> incorrect, please clarify the list of columns in the "CoAP-EAP >>>>>> Information Elements" registry. >>>>>> >>>>>> Original: >>>>>> The columns of the registry are Name, Label, CBOR Type, Description >>>>>> and Reference, where Value is an integer, and the other columns are >>>>>> text strings. >>>>>> >>>>>> Currently: >>>>>> The columns of the registry are Name, Label, CBOR Type, Description, >>>>>> and Reference, where Label is an integer and the other columns are >>>>>> text strings. --> >>>>>> >>>>>> >>>>> [Authors] The proposed text is correct. >>>>> >>>>> >>>>> >>>>>> 37) <!-- [rfced] [TS133.501]: We found a more recent version of this >>>>>> specification. Because it appears that EAP will continue to be >>>>>> mentioned in subsequent versions of this paper, may we update this >>>>>> listing as follows? >>>>>> >>>>>> Original: >>>>>> [TS133.501] >>>>>> ETSI, "5G; Security architecture and procedures for 5G >>>>>> System - TS 133 501 V15.2.0 (2018-10)", 2018. >>>>>> >>>>>> Suggested: >>>>>> [TS133.501] >>>>>> ETSI, "5G; Security architecture and procedures for 5G >>>>>> System - TS 133 501 V18.9.0", April 2025, >>>>>> https://urldefense.com/v3/__https://www.etsi.org/deliver/etsi_ts/133500_133599/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH47PGG_Jw$ >>>>>> 133501/18.09.00_60/ts_133501v180900p.pdf --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] The suggestion is ok and very welcome. Thank you. >>>>> >>>>> >>>>> >>>>>> 38) <!-- [rfced] [ZigbeeIP]: We could not find this document number. >>>>>> We also found that >>>>>> <https://urldefense.com/v3/__https://www.zigbee.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4xoZxesQ$ >>>>>> > steers to >>>>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>>>> >. When we searched >>>>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>>>> > for >>>>>> the number 095023r34, the result was "Nothing found, please try >>>>>> adjusting your search." >>>>>> >>>>>> Should a different paper be listed here and cited in Appendices B and >>>>>> C.5.1? >>>>>> >>>>>> Original: >>>>>> [ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document >>>>>> 095023r34)", 2014. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] Certainly, this seems to be an old reference. We have other >>>>> examples, the best course of action would be to remove this reference and >>>>> the associated text. >>>>> Forced removal can be done by sending new specific key material to the >>>>> devices that still belong to the network, excluding the removed device, >>>>> following a model similar to CoJP for 6TiSCH [RFC9031] or Zigbee IP >>>>> [ZigbeeIP]. >>>>> – >>>>> Another example would be when a shared Network Key is required by the >>>>> devices that join a network. An example of this Network Key can be found >>>>> in Zigbee IP [ZigbeeIP] or the THREAD protocol [THREAD]. >>>>> >>>>> >>>>> >>>>> >>>>>> 39) <!-- [rfced] We found a newer version (1.4.0) of the Thread >>>>>> specification. As the citation in Appendix B is general in nature, >>>>>> may we update this listing as suggested below? >>>>>> >>>>>> Original: >>>>>> [THREAD] Thread Group, "Thread specification 1.3", 2023. >>>>>> >>>>>> Suggested: >>>>>> [THREAD] Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper", >>>>>> September 2024, >>>>>> <https://urldefense.com/v3/__https://www.threadgroup.org/Portals/0/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7aZUQuhA$ >>>>>> Documents/ >>>>>> Thread_1.4_Features_White_Paper_September_2024.pdf>. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] The suggestion is ok and welcome. Thank you. >>>>> >>>>> >>>>> >>>>>> 40) <!-- [rfced] Figure 9: >>>>>> >>>>>> a) Please note that we changed "hanshake" to "handshake". However, >>>>>> in the HTML and PDF output files, the space after the "e" in >>>>>> "hanshake" was removed in the process. We cannot determine where in >>>>>> the SVG a coordinate should be modified to correct the spacing. >>>>>> Please correct the SVG in the edited copy of the XML. >>>>>> >>>>>> b) We see "down" arrows between MSK and DTLS_PSK in the ASCII art >>>>>> for this figure, but they do not appear in the SVG. If you would >>>>>> like to add the arrows in the SVG, please correct the SVG in the >>>>>> edited copy of the XML. >>>>>> >>>>>> c) We see "(Protected with (D)TLS)" in the ASCII art but >>>>>> "Protected with (D)TLS" in the SVG. If you prefer the parentheses, >>>>>> please correct the SVG in the edited copy of the XML. If you prefer >>>>>> that the parentheses be removed, let us know, and we will update the >>>>>> ASCII art accordingly. --> >>>>>> >>>>>> >>>>> [Authors] New figure in rfc9820_modified.xml solves these issues. >>>>> Also, for consistency, in Figure 3 there were no arrows indicating key >>>>> derivation, we also updated that Figure in the xml file. >>>>> >>>>> >>>>> >>>>>> 41) <!-- [rfced] Appendix A: >>>>>> >>>>>> a) As it appears that "Steps 1 and 2" here refer to Steps 1 and 2 in >>>>>> Figure 8 (as opposed to Steps 1 and 2 in Figure 3), may we add a >>>>>> citation for Figure 8 for ease of the reader? >>>>>> >>>>>> If the suggested text is not correct, please also clarify "if DTLS >>>>>> wants to be used". >>>>>> >>>>>> Original: >>>>>> To simplify the design in CoAP-EAP, the KDF hash algorithm >>>>>> can be included in the list of cipher suites exchanged in Step 1 and >>>>>> Step 2 if DTLS wants to be used instead of OSCORE. >>>>>> >>>>>> Suggested: >>>>>> To simplify the design in CoAP-EAP, the KDF hash algorithm >>>>>> can be included in the list of cipher suites exchanged in Steps 1 and >>>>>> 2 (Figure 8) if one wants to use DTLS instead of OSCORE. >>>>>> >>>>>> >>>>> [Authors] The suggested text is ok. >>>>> >>>>> >>>>> >>>>>> b) Should "(RID-C) (RID-I)" be "RID-C || RID-I" per Appendix A.1? >>>>>> >>>>>> Original: >>>>>> For the same >>>>>> reason, the PSK identity is derived from (RID-C) (RID-I) as defined >>>>>> in Appendix A.1. --> >>>>>> >>>>>> >>>>> [Authors] Yes, this is correct. "(RID-C) (RID-I)" should be "RID-C || >>>>> RID-I" >>>>> >>>>> >>>>> >>>>>> 42) <!-- [rfced] Appendix A: Should "considered" be "supported" in this >>>>>> sentence, along the lines of "The other supported and negotiated >>>>>> cipher suites are the following" as seen in Section 6.1? >>>>>> >>>>>> Original: >>>>>> The hash algorithms considered are the following: >>>>>> >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 >>>>>> >>>>>> Possibly: >>>>>> The following hash algorithms are supported: >>>>>> >>>>>> * 5) TLS_SHA256 >>>>>> >>>>>> * 6) TLS_SHA384 >>>>>> >>>>>> * 7) TLS_SHA512 --> >>>>>> >>>>>> >>>>> [Authors] Following the previous issue (point 25) >>>>> Proposed text. >>>>> The following hash algorithms are considered in case the specification >>>>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>>>> >>>>> >>>>> >>>>>> 43) <!-- [rfced] Appendix A.1: Because the other equations in this >>>>>> document don't end in periods, we removed the period from the end of >>>>>> this equation. Please let us know any concerns. >>>>>> >>>>>> Original: >>>>>> DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). >>>>>> >>>>>> Currently: >>>>>> DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length) --> >>>>>> >>>>>> >>>>> [Authors] The current proposed correction is ok. >>>>> >>>>> >>>>> >>>>>> 44) <!-- [rfced] Appendix B: Because "PSK" stands for "Pre-Shared Key", >>>>>> should "a shared key PSK" be "a PSK"? >>>>>> >>>>>> Original: >>>>>> Similarly, to the example of Appendix A.1, where a shared key PSK for >>>>>> DTLS is derived, it is possible to provide key material to different >>>>>> link-layers after the CoAP-EAP authentication is complete. --> >>>>>> >>>>>> >>>>> [Authors] You are correct. "a shared key PSK" should be "a PSK" >>>>> >>>>> >>>>> >>>>>> 45) <!-- [rfced] Appendix B: This sentence was difficult to follow. >>>>>> We updated it as noted below. If this is incorrect, please clarify >>>>>> the text. >>>>>> >>>>>> Original: >>>>>> How a particular link-layer technology uses the MSK to derive further >>>>>> key material for protecting the link-layer or use the OSCORE >>>>>> protection to distribute key material is out of the scope of this >>>>>> document. >>>>>> >>>>>> Currently (changed "uses the MSK ... or use the OSCORE protection" to >>>>>> "uses the MSK ... or uses OSCORE protection"): >>>>>> How a particular link-layer technology uses the MSK to derive further >>>>>> key material for protecting the link layer or uses OSCORE protection >>>>>> to distribute key material is outside the scope of this document. --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 46) <!-- [rfced] Appendix C: "EAP peers (A and B), which are EAP peers. >>>>>> They are the EAP peers." appeared to be some unintentionally repeated >>>>>> text. We removed the extra text as noted below. If some additional >>>>>> information for this bullet item was intended (for example, as was >>>>>> done for the "EAP authenticator (C)" and "AAA server (AAA)" bullet >>>>>> items), please provide the information. >>>>>> >>>>>> Original: >>>>>> * 2 EAP peers (A and B), which are EAP peers. They are the EAP >>>>>> peers. >>>>>> >>>>>> Currently: >>>>>> * Two EAP peers (A and B). --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 47) <!-- [rfced] Appendix C: "the EAP authenticator acts as an EAP >>>>>> authenticator" read oddly and was difficult to follow. We updated >>>>>> this sentence as noted below. If this update is incorrect, please >>>>>> clarify the text. >>>>>> >>>>>> Original: >>>>>> Here, the EAP authenticator acts as an EAP authenticator in pass- >>>>>> through mode. >>>>>> >>>>>> Currently: >>>>>> Here, the EAP authenticator is operating in pass- >>>>>> through mode. --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 48) <!-- [rfced] Appendix C: This sentence did not parse. We updated it >>>>>> as noted below. If this is incorrect, please clarify "... methods >>>>>> might need to be used (...) being able to ...". >>>>>> >>>>>> Original: >>>>>> With varied EAP peers and >>>>>> networks, more lightweight authentication methods might need to be >>>>>> used (e.g., EAP-NOOB[RFC9140], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], >>>>>> EAP-EDHOC[I-D.ietf-emu-eap-edhoc], etc.) being able to adapt to >>>>>> different types of devices according to organization policies or >>>>>> devices capabilities. >>>>>> >>>>>> Currently: >>>>>> With varied EAP peers and >>>>>> networks, authentication methods that are more lightweight (e.g., >>>>>> EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC >>>>>> [EAP-EDHOC], etc.) and are able to adapt to different types of >>>>>> devices according to organization policies or device capabilities >>>>>> might need to be used. --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>> >>>>>> 49) <!-- [rfced] Appendix C.1: Does "while" in this sentence mean "at >>>>>> the same time as" or "as long as" (per the "as long as the key >>>>>> material is still valid" phrase in the "It is worth noting that the >>>>>> first phase ..." paragraph)? >>>>>> >>>>>> Original: >>>>>> This access can be repeated without contacting the EAP >>>>>> authenticator, while the credentials given to A are still valid. --> >>>>>> >>>>>> >>>>> [Authors] It means "as long as". >>>>> >>>>> >>>>> >>>>>> 50) <!-- [rfced] Appendix C.1: We had trouble following the meaning of >>>>>> "the first phase with CoAP-EAP". If the suggested text is not >>>>>> correct, please provide clarifying text. >>>>>> >>>>>> Original: >>>>>> It is worth noting that the first phase with CoAP-EAP is required to >>>>>> join the EAP authenticator C's domain. >>>>>> >>>>>> Suggested: >>>>>> It is worth noting that to join EAP authenticator C's domain, the >>>>>> first phase (authentication via CoAP-EAP) is required. --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>>> 51) <!-- [rfced] Appendix C.2: >>>>>> >>>>>> a) Should "AKA" be "AKA'", as used elsewhere in this document? >>>>>> >>>>>> Original: >>>>>> A device (A) of the domain acme.org, which uses a specific kind of >>>>>> credential (e.g., AKA) and intends to join the um.es domain. >>>>>> >>>>>> >>>>> [Authors] This clarification adds more confusion than without it. Please >>>>> leave it as follows >>>>> >>>>> A device (A) of the domain acme.org, which uses a specific kind of >>>>> credential (e.g., AKA) and intends to join the um.es domain. >>>>> >>>>> >>>>>> b) This sentence does not parse. It appears that some words are >>>>>> missing. Please clarify "Through the local AAA server communicate >>>>>> with the home AAA server ...". >>>>>> >>>>>> Original: >>>>>> Through the local AAA server >>>>>> communicate with the home AAA server to complete the authentication >>>>>> and integrate the device as a trustworthy entity into the domain of >>>>>> EAP authenticator C. --> >>>>>> >>>>>> >>>>> [Authors]The text hopefully is clearer as follows: >>>>> Then, the local AAA server communicates with the home AAA server to >>>>> complete the authentication. This way, the device can be considered as a >>>>> trustworthy entity within the domain of the EAP authenticator C >>>>> >>>>> >>>>> >>>>>> 52) <!-- [rfced] Appendix C.5.1: We corrected the incomplete >>>>>> "Where can ..." sentence as follows. If this change is not correct, >>>>>> please provide clarifying text. >>>>>> >>>>>> Original (the previous sentence is included for context): >>>>>> For >>>>>> example, in IEEE 802.15.4 networks, a new KMP ID can be defined to >>>>>> add such support in the case of IEEE 802.15.9 [ieee802159]. Where >>>>>> can be assumed that the device has at least a link-layer IPv6 >>>>>> address. >>>>>> >>>>>> Currently (now one sentence that includes the expansion for "KMP"): >>>>>> For >>>>>> example, in IEEE 802.15.4 networks, a new Key Management Protocol >>>>>> (KMP) ID can be defined to add such support in the case of IEEE >>>>>> 802.15.9 [IEEE802159], where it can be assumed that the device has at >>>>>> least a link-layer IPv6 address. --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 53) <!-- [rfced] Appendix C.5.1: Per the phrase "entity (proxy) that is >>>>>> already part of the network (already shares key material and >>>>>> communicates through a secure channel with the authenticator)" in the >>>>>> next paragraph of this section and per Figure 10, we updated this >>>>>> sentence accordingly. If this is incorrect, please clarify what >>>>>> communicates through a secure channel. >>>>>> >>>>>> Original: >>>>>> In the case a proxy participates in CoAP- >>>>>> EAP, it will be because it is already a trustworthy entity within the >>>>>> domain, which communicates through a secure channel with the EAP >>>>>> authenticator, as illustrated by Figure 10. >>>>>> >>>>>> Currently: >>>>>> In the case that a proxy participates in >>>>>> CoAP-EAP, it will be because it is already a trustworthy entity >>>>>> within the domain and communicates through a secure channel with the >>>>>> EAP authenticator, as illustrated by Figure 10. --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. >>>>> >>>>> >>>>> >>>>>> 54) <!-- [rfced] Appendix C.5.1: This paragraph had several issues: >>>>>> This section (Appendix C.5.1) cited itself, and in the second >>>>>> sentence, "As mentioned, either ..." was unclear. Also, the >>>>>> second sentence was incomplete. Please review all of our updates >>>>>> carefully, and let us know if anything is incorrect. >>>>>> >>>>>> (Side note: We cited Section 3.6 here because although Section 3.1 >>>>>> mentions both direct links and linking via a proxy, it doesn't >>>>>> provide any descriptive text.) >>>>>> >>>>>> Original: >>>>>> Thus, the EAP peer follows the same process described in >>>>>> Appendix C.5.1 to perform the authentication. As mentioned, either >>>>>> with a direct link to the EAP authenticator, or through an >>>>>> intermediary entity (proxy) that is already part of the network >>>>>> (already shares key material and communicates through a secure >>>>>> channel with the authenticator) and can aid in running CoAP-EAP. >>>>>> >>>>>> Currently (the direct connection is mentioned in the previous >>>>>> paragraph, so we did not mention it again here): >>>>>> If the EAP peer cannot connect to the EAP authenticator directly, >>>>>> the EAP peer can follow the same process as that described in >>>>>> Section 3.6 to perform the authentication (i.e., can connect via >>>>>> an intermediary entity (proxy) that is already part of the network >>>>>> (already shares key material and communicates through a secure >>>>>> channel with the authenticator) and can aid in running CoAP-EAP). --> >>>>>> >>>>>> >>>>> [Authors] The currently suggested text is ok. The only change would be to >>>>> set proxy as example. >>>>> … an intermediary entity (e.g., proxy) that is already part of the network >>>>> >>>>> >>>>> >>>>>> 55) <!-- [rfced] Figure 10: We see "(security association)" in the ASCII >>>>>> art but "security association" in the SVG. If you prefer the >>>>>> parentheses, please correct the SVG in the edited copy of the XML. >>>>>> If you prefer that the parentheses be removed, let us know, and we >>>>>> will update the ASCII art accordingly. --> >>>>>> >>>>>> >>>>> [Authors] it is ok without parenthesis. >>>>> >>>>> >>>>> >>>>>> 56) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>> the online Style Guide at >>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7Wcxz1GQ$ >>>>>> >, >>>>>> and let us know if any changes are needed. Updates of this nature >>>>>> typically result in more precise language, which is helpful for >>>>>> readers. >>>>>> >>>>>> For example, please consider whether the following should be updated: >>>>>> Master Session Key, Master Secret, Master Salt, Master Key --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] These are the same terms used in the EAP [RFC] standard and >>>>> OSCORE standard [RFC] from which this work depends. It is needed to >>>>> understand the terminology to which we refer. >>>>> >>>>> >>>>>> 57) <!-- [rfced] Please let us know if any changes are needed for the >>>>>> following: >>>>>> >>>>>> a) The following terms were used inconsistently in this document. >>>>>> We chose to use the latter forms. Please let us know any objections. >>>>>> >>>>>> AAA Server / AAA server (per post-6000 published RFCs) >>>>>> >>>>>> >>>>> [AUTHORS] AAA server >>>>> >>>>>> Client registration (in running text) / >>>>>> client registration (per RFC 9200) >>>>>> >>>>>> >>>>> [AUTHORS] client registration >>>>> >>>>>> b) The following terms appear to be used inconsistently in this >>>>>> document. Please let us know which form is preferred. >>>>>> >>>>>> "a/eap/1" (the URI for the first resource would be "a/eap/1") / >>>>>> '/a/eap/1' >>>>>> >>>>>> >>>>> [AUTHORS] "a/eap/1" >>>>> >>>>>> CBOR Object / CBOR object >>>>>> >>>>> [AUTHORS] CBOR Object >>>>> >>>>>> DTLS PSK / DTLS_PSK >>>>>> >>>>> [AUTHORS] DTLS_PSK >>>>> >>>>>> EAP Failure / EAP failure >>>>>> (will send an EAP Failure, sends an EAP failure) >>>>>> >>>>>> >>>>> [AUTHORS] EAP Failure >>>>> >>>>>> EAP-Request/Identity / EAP Req/Id / EAP-Req/Id >>>>>> >>>>>> >>>>> [AUTHORS] EAP-Request/Identity >>>>> >>>>> >>>>>> EAP response / EAP Response (used generally in text, e.g., >>>>>> "an EAP response", "an EAP Response") >>>>>> (We also see "EAP Response header" in Section 7.1.) >>>>>> >>>>>> >>>>> [AUTHORS] EAP Response >>>>> >>>>> >>>>> >>>>>> EAP-Response/Identity / EAP Resp/Id / EAP Response/Id >>>>>> >>>>>> >>>>> [AUTHORS] EAP-Response/Identity >>>>> >>>>> >>>>> >>>>>> EAP-X-Req (text) / EAP-X Req (Figure 3) >>>>>> >>>>>> >>>>> [AUTHORS] EAP-X-Req >>>>> We updated the figures so they are consistent >>>>> >>>>>> EAP-X-Resp (text) / EAP-X Resp (Figures 3 and 9) >>>>>> >>>>>> >>>>> [AUTHORS] EAP-X-Resp >>>>> >>>>> >>>>> >>>>>> Network Key / network key >>>>>> >>>>>> >>>>> [AUTHORS] Network Key >>>>> >>>>> >>>>> >>>>>> Option(s) / option(s) (e.g., "Location-Path Option", >>>>>> "Location-Path and/or Location-Query Options", >>>>>> "Location-Path or Location-Query options", >>>>>> "Location-Path (and/or Location-Query) Options", >>>>>> "Location-Path (and/or Location-Query) options") >>>>>> >>>>>> >>>>> [AUTHORS] Option(s) >>>>> >>>>>> OSCORE Security Context / OSCORE security context >>>>>> >>>>>> >>>>> [AUTHORS] OSCORE Security Context >>>>> >>>>> >>>>>> Session-Lifetime / Session-lifetime / Session Lifetime / >>>>>> session lifetime (in running text) >>>>>> (Figure 3 and Table 4 use "Session-Lifetime".) >>>>>> >>>>>> >>>>> [AUTHORS] Session-Lifetime >>>>> >>>>> >>>>> >>>>>> c) Should quoting and spacing be made consistent? For example: >>>>>> >>>>>> Quoting: '2.01 Created' / "2.01 Created" >>>>>> >>>>> [Authors] ‘2.01 Created’ >>>>> >>>>>> Spacing: Payload(EAP-X Resp) / Payload (EAP-X Resp) >>>>>> >>>>> [Authors] without spacing between be parenthesis >>>>> >>>>>> d) Should spacing after step numbers in figures be made >>>>>> consistent? For example: >>>>>> >>>>>> ... >>>>>> 0)| No-Response | >>>>>> ... (Figure 3) >>>>>> >>>>>> ... >>>>>> 0) | No-Response | >>>>>> ... (Figure 5) --> >>>>>> >>>>>> >>>>>> >>>>> [Authors] Without spacing is ok. >>>>> >>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/lb/rv >>>>>> >>>>>> >>>>> Thank you very much. >>>>> >>>>> >>>>>> On Jul 18, 2025, at 10:46 AM, rfc-edi...@rfc-editor.org wrote: >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2025/07/18 >>>>>> >>>>>> RFC Author(s): >>>>>> -------------- >>>>>> >>>>>> Instructions for Completing AUTH48 >>>>>> >>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>> If an author is no longer available, there are several remedies >>>>>> available as listed in the FAQ >>>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4mckAP4A$ >>>>>> ). >>>>>> >>>>>> You and you coauthors are responsible for engaging other parties >>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>> your approval. >>>>>> >>>>>> Planning your review >>>>>> --------------------- >>>>>> >>>>>> Please review the following aspects of your document: >>>>>> >>>>>> * RFC Editor questions >>>>>> >>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>> that have been included in the XML file as comments marked as >>>>>> follows: >>>>>> >>>>>> <!-- [rfced] ... --> >>>>>> >>>>>> These questions will also be sent in a subsequent email. >>>>>> >>>>>> * Changes submitted by coauthors >>>>>> >>>>>> Please ensure that you review any changes submitted by your >>>>>> coauthors. We assume that if you do not speak up that you >>>>>> agree to changes submitted by your coauthors. >>>>>> >>>>>> * Content >>>>>> >>>>>> Please review the full content of the document, as this cannot >>>>>> change once the RFC is published. Please pay particular attention to: >>>>>> - IANA considerations updates (if applicable) >>>>>> - contact information >>>>>> - references >>>>>> >>>>>> * Copyright notices and legends >>>>>> >>>>>> Please review the copyright notice and legends as defined in >>>>>> RFC 5378 and the Trust Legal Provisions >>>>>> (TLP – >>>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5D1hB7LA$ >>>>>> ). >>>>>> >>>>>> * Semantic markup >>>>>> >>>>>> Please review the markup in the XML file to ensure that elements of >>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>> and <artwork> are set correctly. See details at >>>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4qmIsbLQ$ >>>>>> >. >>>>>> >>>>>> * Formatted output >>>>>> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>> formatted output, as generated from the markup in the XML file, is >>>>>> reasonable. Please note that the TXT will have formatting >>>>>> limitations compared to the PDF and HTML. >>>>>> >>>>>> >>>>>> Submitting changes >>>>>> ------------------ >>>>>> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>> the parties CCed on this message need to see your changes. The parties >>>>>> include: >>>>>> >>>>>> * your coauthors >>>>>> >>>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>>> >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>> list: >>>>>> >>>>>> * More info: >>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH73FBctPw$ >>>>>> >>>>>> * The archive itself: >>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5RDfiTDg$ >>>>>> >>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>> If needed, please add a note at the top of the message that you >>>>>> have dropped the address. When the discussion is concluded, >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>> list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>> and technical changes. Information about stream managers can be found in >>>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email stating >>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>> as all the parties CCed on this message need to see your approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.xml__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH61uj9KFA$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH46vzPMGQ$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.pdf__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4VnhbREw$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.txt__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7CGA_kaw$ >>>>>> >>>>>> Diff file of the text: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-diff.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6IAS29qA$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6sl8fsTg$ >>>>>> (side by side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6VqyXnzw$ >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9820__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH41wCjt6w$ >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9820 (draft-ietf-ace-wg-coap-eap-15) >>>>>> >>>>>> Title : EAP-based Authentication Service for CoAP >>>>>> Author(s) : R. Marin-Lopez, D. Garcia-Carrillo >>>>>> WG Chair(s) : Loganaden Velvindron, Tim Hollebeek >>>>>> >>>>>> Area Director(s) : Deb Cooley, Paul Wouters >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Dan García Carrillo >>>>> --------------------- >>>>> Associate Professor >>>>> Dpto. de Informática, Área de Telemática, Universidad de Oviedo >>>>> Escuela Politécnica de Ingeniería, C.P. 33204, Campus de Viesques, Gijón >>>>> Dpcho. 2.7.8 - Edificio Polivalente >>>>> Tel.: +34 985182654 (Ext. 2654) | email: garcia...@uniovi.es >>>>> <rfc9820_modified.xml> >>>>> >>> -- >>> Dan García Carrillo >>> --------------------- >>> Associate Professor >>> Dpto. de Informática, Área de Telemática, Universidad de Oviedo >>> Escuela Politécnica de Ingeniería, C.P. 33204, Campus de Viesques, Gijón >>> Dpcho. 2.7.8 - Edificio Polivalente >>> Tel.: +34 985182654 (Ext. 2654) | email: garcia...@uniovi.es -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
