Authors,
While reviewing this document during Final Review, please resolve (as
necessary)
the following questions, which are also in GitHub issues
(see https://github.com/rfc-editor-drafts/FinalReview-rfc10020/issues).
1) <!-- [rfced] FYI - We will do the following when we convert the file to
RFCXML:
a) update the formatting of the ordered list in Appendix A.2.1
b) remove "PRE-" in "PRE-RFC10021" and "PRE-10021"
-->
2) <!--[rfced] I-D.bormann-core-responses has been replaced by
I-D.ietf-core-responses; may we point to the new version shown below?
Original:
[I-D.bormann-core-responses]
Bormann, C. and C. Amsüss, "CoAP: Non-traditional response
forms", Work in Progress, Internet-Draft, draft-bormann-
core-responses-06, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-bormann-core-
responses-06>.
New version:
[I-D.ietf-core-responses]
Bormann, C. and C. Amsüss, "CoAP: Non-traditional response
forms", Work in Progress, Internet-Draft, draft-ietf-core-
responses-00, 12 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
responses-00>.
-->
3) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
4) <!--[rfced] In Sections 1.2 and 2.2.1.2, may we update "-" to ":"
following the terms being defined? One example below:
Original:
* Group URI - This is defined as a CoAP URI that has the "coap"
scheme and includes ...
Perhaps:
* Group URI: This is defined as a CoAP URI that has the "coap"
scheme and includes ...
-->
5) <!--[rfced] In the following, "as to" reads oddly. Would "in terms
of"
or "specifically regarding" be clearer?
Original:
* With reference to Section 8.2 of [RFC7252], it updates the
request/response layer for group communication, as to response
suppression (see Section 3.1.2 of the present document).
* With reference to Section 5.3.1 of [RFC7252], it updates the token
requirements on request/response matching, as to token reuse time
(see Section 3.1.5 of the present document).
Perhaps:
* With reference to Section 8.2 of [RFC7252], it updates the
request/response layer for group communication in terms of
response suppression (see Section 3.1.2 of the present document).
* With reference to Section 5.3.1 of [RFC7252], it updates the token
requirements on request/response matching in terms of Token reuse
time (see Section 3.1.5 of the present document).
-->
6) <!--[rfced] May we rephrase this introductory sentence as follows?
Original:
A special note is appropriate about the possible relationship between
security groups and application groups.
Perhaps:
Note that the following paragraphs describe the possible relationships
between security groups and application groups.
-->
7) <!--[rfced] May we remove the numbering from this sentence?
Original:
A best practice is to use a URI path component such that: i) it
includes a path segment as delimiter with a designated value,
e.g., "gp", followed by ii) a path segment containing the name of
the application group, followed by iii) the path segment(s) that
identify the targeted resource within the application group.
Perhaps:
A best practice is to use a URI path component such that it
includes a path segment as the delimiter with a designated value,
e.g., "gp", followed by a path segment containing the name of
the application group, followed by the path segment(s) that
identifies the targeted resource within the application group.
-->
8) <!--[rfced] May we include the section numbers where the examples
can be found? If yes, please review and confirm that Appendices
C.1 and C.4 are the correct sections.
Original:
In examples presented in the following, this document considers
such values for the attribute "rt" to have the semantics
"g.<GROUPTYPE>", where GROUPTYPE denotes the type of the
application group in question.
Perhaps:
Examples presented in Appendices C.1 and C.4 consider
such values for the attribute "rt" to have the semantics
"g.<GROUPTYPE>", where GROUPTYPE denotes the type of the
application group in question.
-->
9) <!--[rfced] May we remove the numbering from this sentence?
Note there are other similar instances throughout the document.
If agreeable, these other instances will also be updated accordingly.
Original:
That is, the client gains knowledge of: i) the set of
servers that are members of the specified CoAP group and member
of any of the associated application groups; ii) for each of those
servers, the name of the application groups where the server is a
member and that are associated with the CoAP group.
Perhaps:
That is, the client gains knowledge of the set of
servers that are members of the specified CoAP group and members
of any of the associated application groups and, for each of those
servers, the name of the application groups where the server is a
member and that are associated with the CoAP group.
-->
10) <!--[rfced] We are having trouble parsing "for each application
group the associated CoAP group(s)" in the sentence below. How
may it be updated for clarity?
Original:
Through the corresponding responses, the query result is a list of
resources at CoAP servers that are members of the specified
application group and for each application group the associated
CoAP group(s).
Perhaps:
Through the corresponding responses, the query result is a list of
resources at CoAP servers that are members of the specified
application group and of each application group associated with the
CoAP group(s).
-->
11) <!--[rfced] FYI - We have updated the definition of
MAX_SERVER_RESPONSE_DELAY
to reflect the definition in RFC 7390 (i.e., updated "CoAP group" to
"multicast". Please review and let us know of any objections.
Original:
This specification defines MAX_SERVER_RESPONSE_DELAY as
was done in [RFC7390], that is: the expected maximum response delay
over all servers that the client can send a CoAP group request to.
Current:
This specification defines MAX_SERVER_RESPONSE_DELAY consistently
with [RFC7390], that is, as "the expected maximum response delay
over all servers that the client can send a multicast request to".
-->
12) <!--[rfced] This sentence is difficult to parse. May we update it
as
follows?
Original:
In particular, if the client wishes to validate, using a group request,
a response from server 1 with an ETag value N, while it wants a fresh
response from server 2, there is no way to achieve this using a
single group request.
Perhaps:
In particular, if the client wishes to validate a response from server 1
(with ETag value N) using a group request while also receiving a fresh
response from server 2, there is no way to achieve this using a
single group request.
-->
13) <!--[rfced] Please review whether the following note in this
document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
Current:
Note: A CoAP server implementation that is unaware of the updates to
[RFC7252] made by this document will expect group requests to never
contain an ETag Option (see Section 8.2.1 of [RFC7252]). Such a
server treats an ETag Option in a group request as an unrecognized
option per Sections 5.4 and 8.2.1 of [RFC7252], causing it to ignore
this (elective) ETag Option regardless of its value, and processes
the request normally as if that ETag Option was not included.
-->
14) <!--[rfced] For clarity, may we update "which both should be
chosen
conservatively"?
Original:
... for a group size estimate G, a target data transfer rate R (which
both should be chosen conservatively), and an estimated response size
S.
Perhaps:
... for a group size estimate G (which should be chosen conservatively),
a target data transfer rate R (which should also be chosen conservatively),
and an estimated response size S.
-->
15) <!--[rfced] We are having some difficulty understanding "and sent
over
UDP". Please review and let us know how this sentence may be updated
for clarity.
Original:
That is, after the first group request including the Block2 Option
and sent over UDP, the following unicast CoAP requests targeting
individual servers to retrieve further blocks may be sent over TCP
or WebSockets, possibly protected with TLS.
Perhaps:
That is, after the first group request containing the Block2 Option
is sent over UDP, the following unicast CoAP requests targeting
individual servers to retrieve further blocks may be sent over TCP
or WebSockets, potentially protected by TLS.
-->
16) <!--[rfced] To match the abbreviation of "ACE" in RFC 9200, we have
updated
the text as follows. Please review and let us know of any objections.
Original:
As mentioned in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint can
join an OSCORE group through the realization of a Group Manager
specified in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE
framework for Authentication and Authorization in constrained
environments [RFC9200].
Current:
As mentioned in [PRE-RFC10021], a CoAP endpoint can join an OSCORE group
through the realization of a Group Manager as specified in [CoAP-ACE]
and based on the Authentication and Authorization for Constrained
Environments (ACE) framework [RFC9200].
-->
17) <!--[rfced] Please clarify "and based on". Would it be clearer to
update to "using" as shown below?
Original:
A CoAP endpoint can discover OSCORE groups and retrieve information
to join them through their respective Group Managers by using the
method described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE
Resource Directory [RFC9176].
Perhaps:
A CoAP endpoint can discover OSCORE groups and retrieve information
to join them through their respective Group Managers by using the
method described in [CoAP-GROUP-OSCORE] and the CoRE Resource
Directory [RFC9176].
-->
18) <!--[rfced] The text "as verifiable to be originated by the
alleged,
identifiable sender" reads oddly. Please review and let us know how
it may be updated for clarity.
Original:
In fact, source authentication is always ensured for exchanged CoAP
messages, as verifiable to be originated by the alleged,
identifiable sender in the OSCORE group.
Perhaps:
In fact, source authentication is always ensured for exchanged CoAP
messages, as they can be verified as originating from a specific,
identifiable sender within the OSCORE group.
-->
19) <!--[rfced] May we update "that does not yet have configured" to
"that has not yet configured" for clarity?
Original:
This early, unprotected step is relevant for a CoAP
client that does not know the address of such hosts in advance and
that does not yet have configured a mutual security relationship with
them.
Perhaps:
This early, unprotected step is relevant for a CoAP
client that does not know the address of such hosts in advance and
that has not yet configured a mutual security relationship with
them.
-->
20) <!--[rfced] We are having some difficulty understanding "with value
the name of the application group" in this sentence. May we update
it as follows for clarity?
Original:
In particular, the URI
query component includes a query parameter "gp" as designated
indicator, with value the name of the application group.
Perhaps:
In particular, the URI
query component includes a query parameter "gp" as the designated
indicator, with the value as the name of the application group.
-->
21) <!--[rfced] May we update the latter part of this sentence to
improve
readability?
Original:
An alternative, shorter
encoding (not shown in the figure) is to use only the value "1" for
each "gpt" attribute, in order to denote that the resource is of type
application group.
Perhaps:
An alternative, shorter
encoding (not shown in the figure) is to use only the value "1" for
each "gpt" attribute, in order to denote that the resource is the type
of application group.
-->
22) <!--[rfced] Figure 22
a) We note that Figure 22 is hard to read in the PDF output file (it
looks good in the html file); the display is small because it is
scaled to fit on one page. Please review and let us know if you would
like to split this into separate figures to improve readability.
b) May we move the second sentence from the title of Figure 22
and add it to the text before the figure?
Original:
In Figure 22, the client sends a Non-confirmable GET request to the
CoAP group, targeting the resource "log" in the application group
"gp1", and requesting a block-wise transfer.
...
Figure 22: Example of Non-confirmable group request starting a
block-wise transfer, followed by Non-confirmable Responses with
the first block. The transfer continues over confirmable unicast
exchanges
Perhaps:
In Figure 22, the client sends a Non-confirmable GET request to the
CoAP group, targeting the resource "log" in the application group
"gp1", and requesting a block-wise transfer. The transfer continues
over confirmable unicast exchanges.
...
Figure 22: Example of Non-Confirmable Group Request Starting a
Block-Wise Transfer, Followed by Non-Confirmable Responses with
the First Block
-->
23) <!--[rfced] Please review each artwork element and let us know if any
should be marked as sourcecode instead; specifically, please review
Figures 8-19 and let us know if any should be marked as sourcecode
type="coap".
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
24) <!--[rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
medium access control (MAC)
b) Both the expansion and the acronym for the following terms are used
throughout the document. As recommended in the Web Portion of the
Style Guide <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>,
once an abbreviation is introduced, the abbreviated form should be
used thereafter. Please consider if you would like to apply this style
for the following terms:
6LoWPAN Border Router (6LBR)
Denial of Service (DoS)
Extended Address Registration Option (EARO)
Multicast Listener Discovery Version 2 (MLDv2)
Neighbor Discovery (ND)
NoSec (No Security)
Object Security for Constrained RESTful Environments (OSCORE)
Resource Directory (RD)
-->
25) <!-- [rfced] Terminology
a) Throughout the text, "group URI" and "Group URI" appear to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
b) We note that the following terms are phrased differently throughout
the text. Please review and let us know if/how they may be made
consistent.
IP address literal vs. IPv6 literal address vs. literal IPv6 multicast address
-->
26) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "Master" should be updated.
-->
Thank you.
Alanna Paloma and Karen Moore
RFC Production Center
On Jul 16, 2026, at 5:55 PM, RFC Editor via auth48archive
<[email protected]> wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Your document has now entered Final Review (previously AUTH48).
The document was edited in kramdown-rfc as part of the RPC pilot test (see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
Final Review is being handled in GitHub as part of the GitHub pilot test
(see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test).
Your document is available for review at:
https://github.com/rfc-editor-drafts/FinalReview-rfc10020
Please do the following:
a) accept your invitations to join the repo as collaborators.
b) see the README for details on the Final Review process:
https://github.com/rfc-editor-drafts/FinalReview-rfc10020/blob/Approved/README.md
c) review the edits in the RPC-edits pull request:
https://github.com/rfc-editor-drafts/FinalReview-rfc10020/pulls
d) address the issues:
https://github.com/rfc-editor-drafts/FinalReview-rfc10020/issues
Once the content of the .md file is stable, we will convert it to .xml
and provide the .html, .pdf, .txt, and .xml files for review.
You and your coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Once the document has been reviewed and approved by all of the authors,
it will be published as an RFC. If an author is no longer available,
there are several remedies; see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10020/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
