Hi, Paul. So noted: https://www.rfc-editor.org/auth48/rfc9820
Thank you! RFC Editor/lb > On Aug 13, 2025, at 11:42 AM, Paul Wouters <paul.wout...@aiven.io> wrote: > > approved > > Paul > > On Wed, Aug 13, 2025 at 11:50 AM Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> wrote: > 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
