Group Communication for the Constrained Application Protocol (CoAP)
draft-ietf-core-groupcomm-bis-18

[Ballot comment]
Thank you for preparing this document on multicast transport. This is a topic I have worked with over many years, and I know this touches on a wide range of issues and trade-offs. Thank you also for the changes in -17 that address my other topics.

Please consider the following comments for draft-ietf-core-groupcomm-bis:

Thank you for the TSV-ART review by Magnus, it raised many issues that were important to me as a WIT AD. I see the document was revised following this (rev -14), some of my comments below relate also to these topics as seen in rev -14.

Section 2.2.2
/  For unsecure group communication using the NoSec mode (see
  Section 4), there is no security material to be provided, hence there
  is no security group for CoAP endpoints to participate in./
- For me, this text is not well constructed, because I earlier understood that NoSec mode was only permitted under very specific uses and I'd expected this to be clear here also and for the avoidance of any doubt I'd expect this also to be clear in the introduction to section 4.
---
/This task MAY be entrusted to a
  dedicated administrator, that interacts with a Group Manager as
  defined in Section 5./
- Is this really an interoperability requirement, could the /MAY/ be a /may/?
---

These commenst mostly relate to editorial NiTs, I've suggested some proposed text, but you my find other text, if you wish to clarify please do:

/Then, Group configuration/
- Why capital "G" here, could this be "group"?
---
/In fact, being a member of a security group actually grants/
- I didn't understand why this is written this way, would it be the same as something like:
/Being a member of a security group grants/
---
Section 2.2.1.1.
I see the text refers to the IPv6 prefix: ff15
- I think this is intended to be a a temporary site-local multicast address, if so please state this also in the text, rather than allowing any possibly for a reader to think this is a special reserved prefix.
---
Section 2.2.1.2.
This text mentions ff35:30:2001:db8:f1:0:8000:1 which seems like it may be an example of a site-local scope multicast address, please state this also in the text.
---
I see this text:
/For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16./
- This does not clearly point to the address allocation and its specified use. Please explain the scope and refer to the IANA registry entry.
----
At various places, the word "effective" is used to describe the impact of an attack. Whilst it is true an attack would have an "effect", I don't think this word is the best, and I could suggest:
/more effective/ is replaced by /makes this more vulnerable/ or something equivalent that indicates this is a problem not a goal.
---
/the attack may/the attack could/
- only to avoid potential mis-reading.
---
Section 3.1.3 makes a general statement I think is wrong:
/Group requests sent over IP multicast generally have much higher loss rates than messages sent over unicast, particularly in constrained networks./
- I can see that loss ratios can be higher for multicast when sent over a different link with a different property, but in the general Internet this is not so. I suggest:
/Group requests sent over IP multicast can have much higher loss rates than messages sent over unicast, particularly when using a constrained network./
---
/This document updates [RFC7252] by allowing a group request to contain ETag Options as specified below./
- please refer to section number where the update is to be applied in RFC 7252.
---
/the CoAP default UDP port number 5683/
- OK, but please insert a reference to the IANA allocation registry.
---
/One way to create multiple CoAP groups is using different UDP ports  with the same IP multicast address, .../
- True, but it seems like this should probably be prefaced by something like:
/When COAP groups are created with unique IP multicast addresses
the receivers of these messages can utilise multicast filters
to extract the messages of interest./
- and then make the directly above sentence in the text start as: /Another way..."
---
/The port number 5684/
- OK, but please insert a reference to the IANA allocation registry.
---
/For a CoAP server node that supports resource discovery as defined in
  Section 2.4 of [RFC7252], the default port number 5683 MUST be
  supported /
- I don't know what "supported" means in this context - must the receiver process packets received on this port; or only if configure, or what? (please change supported to some explanation).
---
/If this happens, the reverse-proxy MUST /
- appears in a separate paragraph to the description. I think it would be better for the sentence to state what /this/ is, i.e. if a client re-uses a Token value, or something similar.
- Consider also making this one paragraph to clearly link the description with the requirement.
---
/  For the operation of HTTP-to-CoAP reverse proxies, see the last two
  paragraphs of Section 3.5.1, which apply also to the case of reverse-
  proxies./
- Would this be clearer rewritten, e.g.:
/  The last two  paragraphs of Section 3.5.1, also apply for the operation of HTTP-to-CoAP reverse proxies./
---
/CoAP group requests may result in a multitude of responses from/
- To avoid doubt, can this be rewritten as something like:
/CoAP group requests could result in a multitude of responses from/
---
/Multicast usage of
  Block1 is non-trivial due to potential message loss (leading to
  missing blocks or missing confirmations), and potential diverging
  block size preferences of different members of the CoAP group./
- I agree, but would also strongly encourage that you add another consideration: that retransmission needs to conform to the congestion control requirements stated in section XX of this document.
---
/the default port number 5683 MUST be supported as per Sections 7.1 and 12.8 of [RFC7252] /
- as before, please expand upon the word /supported/, does this mean messages received and processed? (Also the same comment to explain the meaning of support in 3.9.3)
---
/A suitable cross-proxy can be set up, such that it receives a
      unicast CoAP group request over TCP/TLS/WebSockets, and then
      forwards the request to the servers in the group over UDP/IP
      multicast /
- OK, but please explicitly state that any multicast transmission MUST respect the requirements stated in this document.
---
Section 4: Please consider moving the text within the first few paras. I'd hoped the requirement: /It is NOT RECOMMENDED to use CoAP group communication in NoSec mode./ at the start of section 4 followed by the next para an explanation why, so that this is made this very clear.
---
Plase consider whether you can creat a separate section title: "Operational Considerations" to alert the operator community to relevant content (no need for extra content, just restructuring to make this more obvious).
- If you do this, I'd encourage you to move the subsections 6.6, 6.7 and 6.8 to this new section.
---
I assume all appendices are Informative - but this is not stated, please add a sentence to state this.
---

[Ballot comment]
Thanks for the work done in this document and for addressing the blocking DISCUSS points of my previous ballot [1] and the issues raised by Brian Haberman in his int-dir review [2].

The I-D is now much cleaner wrt to multicast.

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/core/N0x5gyVLzepZA_aTdsXZcYJyGyY/
[2] https://datatracker.ietf.org/doc/review-ietf-core-groupcomm-bis-15-intdir-telechat-haberman-2025-10-14/

[Ballot comment]
Thanks to the authors and WG for their work on this document.

Also thanks to the authors for the updated version to address my comments and clear the previous DISCUSS position.

Changed document external resources from:

github_repo https://github.com/core-wg/groupcomm-bis (Working Group Repo)

to:

github_repo https://github.com/core-wg/groupcomm-bis (Working Group Repo)
related_implementations https://github.com/eclipse-californium/californium (Implementation in Eclipse Californium)
related_implementations https://github.com/obgm/libcoap (Implementation in libcoap)
related_implementations https://github.com/plgd-dev/go-coap (Implementation in Go-CoAP)

[Ballot comment]
Thank you for providing context and considerations about this DISCUSS. I'll clear the DISCUSS and will let you decide how to best document the relevant aspects in the document.
https://mailarchive.ietf.org/arch/msg/core/KG1PXIc9bqW6lJ7HWkDj9tBEBmc/

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-core-groupcomm-bis-15
CC @evyncke

Thank you for the work put into this document. A generic comment (and I am also partly 'guilty' as I did not make the connection between group and multicast at first sight), as it has a multicast component, it should have gained a deep multicast review by requesting an Internet Directorate review. At this point, I am balloting a DISCUSS mainly to defer to request an Internet directorate review to double check the multicast points as this I-D does not appear to have a mboned/pim review.

Please find below two blocking DISCUSS points (one easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Carsten Bormann for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Other thanks to Petr Špaček, the DNS directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-core-groupcomm-bis-15-dnsdir-telechat-spacek-2025-09-29/ (all is good as the comments were addressed)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 1.1

The use of "we" in `we expect many of the considerations` is ambiguous... Is it the authors ? The CORE WG ? The IETF ? Suggest using the passive voice or paraphrasing.

### Multicast addressing

This is the part where my multicast knowledge is not bullet-proof (hence the defer for a review by multicast expert). Happy to stand corrected.

#### Section 2.2.1.2

Previous text (`Only the Any Source Multicast (ASM) mode` in section 1.1) specifies that only ASM mcast is used but the example `ff35:30:2001:db8:f1:0:8000:1` is SSM and not ASM...

#### Section 2.2.2

`For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16.` but ff3x::/16 is for SSM and not ASM.

[Ballot comment]

## COMMENTS (non-blocking)

Is there any reason why the filename is not rfc7390-bis ? even if only for clarity ;-)

### UDP ports may become useless for mcast

As noted by Erik and Gunter, draft-ietf-intarea-multicast-application-port tends to remove the use of UDP port for mcast traffic. In a constrained environment, this could be useful (even with 6LO compression) to remove the 8-octet UDP header. This draft should at least be mentioned.

### Section 1

Humm I wonder whether `Both unsecured and secured CoAP group communication are specified in this document` is correct as most of the security aspects are in the companion draft-ietf-core-oscore-groupcomm.

### Section 2.1.4

Thanks for using SVG artwork, the HTML rendering is much nicer and more readable.

### Section 2.2.1.1

Thanks for using ff15::1234 for a transient site-local multicast example, but I think that section 3 of RFC 6676 (Multicast Addresses for Documentation) would rather prefer ff05:db8::1234 even if this RFC is informational.

Also, making the UDP port 5683 by default will be incompatible with draft-ietf-intarea-multicast-application-port. Can this part of the I-D be removed to avoid future issues ?

### Section 2.2.3.2

Please add the addresses rather than `to the "All CoAP Nodes" multicast address (see Section 12.8 of [RFC7252])` and forcing readers to jump to another RFC ;-) (but keep the reference of course)

### Section 3.4

Does the IETF really want to have a PS with `One way to create multiple CoAP groups is using different UDP ports with the same IP multicast address` ? At least over Wi-Fi, this could easily kill the devices batteries (even those of non-members).

### Section 3.9.2

Should a reference be added for IEEE 802.15.4 ?

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-core-groupcomm-bis-15
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-groupcomm-bis-15.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Many thanks to Claudio Allocchia for the ARTART review.

I have no objections on this document.

[Ballot discuss]
(For the IESG to process at the formal telechat)

Idnits points out:
  ** Downref: Normative reference to an Informational RFC: RFC 5110
  ** Downref: Normative reference to an Informational RFC: RFC 7967
  ** Downref: Normative reference to an Informational RFC: RFC 9053

RFC9053 is already in the DownRef Registry (https://datatracker.ietf.org/doc/downref/).  RFC7967 was called in the IETF Last Call Message.

==[ from IETF Last Call Message ]==
… snip …
The document contains these normative downward references.

See RFC 3967 for additional information:
    rfc7967: Constrained Application Protocol (CoAP) Option for No Server Response (Informational - Independent Submission stream
==[ end IETF Last Call Message ]==

However, RFC5110 was neither announced in IETF Last Call or found the DownRef registry.  It was used as a normative reference in RFC7390. The IESG needs to approve this use.

[Ballot discuss]
Thanks to the authors and WG for their work on this document.

There are some aspects I would like to discuss to understand better:

discuss#1:
In section 2.2.1.1, there is the use of this multicast address ff15::1234 as an example. There are a few other similar use in other sections.
Per https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#variable the FF0X:0:0:0:0:DB8::/96 is the range provided for documentation [RFC6676].

Further, section 2.2.1.2 and Appendix B also uses ff35:30:2001:db8:f1:0:8000:1 which is also outside this range?

My concerns are that such usage should not infringe about valid multicast addresses that may be used in the wild. An easy way to fix this would be to switch to using the correct documentation prefix.

discuss#2:
In section 2.2.2 there are the following text blobs:
The IETF does not define a mandatory protocol to accomplish CoAP group creation.
For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16.

I seem to be missing where such an assignment has been made. I can't find it in https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml and this document is not making any such allocations.

An easy solution would be to remove the sentence about the the "common multicast address ranges" and let operators pick something from the appropriate scope from the "free" multicast address space?

discuss#3:
This document obsoletes RFC7390. It does not have any IANA considerations. What happens to the IANA registrations done by RFC7390? https://www.rfc-editor.org/rfc/rfc7390#section-6 ... perhaps are they to be marked as deprecated or unassigned or something else?

discuss#4:
The normative reference to an IANA registry [Resource.Type.Link.Target.Attribute.Values] should be perhaps be informative?

[Ballot discuss]
Thanks to the authors and WG for their work on this document.

There are some aspects I would like to discuss to understand better:

discuss#1:
In section 2.2.1.1, there is the use of this multicast address ff15::1234 as an example. There are a few other similar use in other sections.
Per https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#variable the FF0X:0:0:0:0:DB8::/96 is the range provided for documentation [RFC6676].

Further, section 2.2.1.2 and Appendix B also uses ff35:30:2001:db8:f1:0:8000:1 which is also outside this range?

My concerns are that such usage should not infringe about valid multicast addresses that may be used in the wild. An easy way to fix this would be to switch to using the correct documentation prefix.

discuss#2:
In section 2.2.2 there are the following text blobs:
The IETF does not define a mandatory protocol to accomplish CoAP group creation.
For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16.

I seem to be missing where such an assignment has been made. I can't find it in https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml and this document is not making any such allocations.

An easy solution would be to remove the sentence about the the "common multicast address ranges" and let operators pick something from the appropriate scope from the "free" multicast address space?

discuss#3:
This document obsoletes RFC7390. It does not have any IANA considerations. What happens to the IANA registrations done by RFC7390? https://www.rfc-editor.org/rfc/rfc7390#section-6 ... perhaps are they to be marked as deprecated or unassigned or something else?

[Ballot comment]
I have only one comment (rather a question) related to the IPv4 usage in this document. Are the authors or WG aware of any use or requirements for IPv4 in the deployments of this specification? I observe that while there are several helping/supporting protocols for IPv6 deployments, there is sparse coverage for IPv4. Is IPv4 support/coverage desired and mature for inclusion in this Proposed Standard document? Are there any operational recommendations necessary in favor of IPv6 over IPv4?

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-core-groupcomm-bis-15

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-groupcomm-bis-15.txt

# I am not that very skilled in this specific application and technology. I looked at the draft from multicast technology perspective. I do have one DISCUSS for consideration and understanding. I think my observation will be easy to resolve by improving my understanding of CoAP dependencies on Multicast.

# DISCUSS
# =======

608   A CoAP group is always defined by the two properties of IP multicast
609   address and UDP port number (see Section 2.1.1).

GV> Draft draft-karstens-pim-multicast-application-ports-01 (expired) explores the logic that its not always required to have a port number and that multicast streams are usually simply defined by a multicast address, while the port number is a more opaque property. Is for this purpose the CoAP truly needed to have both port and multicast address? Would the use of a unique multicast address alone not be sufficient? When using only the multicast address to represent the application and the group may be simpler. Hence i am not convinced that using port numbers AND a unique multicast group address is needed. Not having to bother about port numbers makes life easier. Any thoughts around this?

Kind Regards,
Gunter Van de Velde
RTG Area Director

[Ballot comment]
# Internet AD comments for draft-ietf-core-groupcomm-bis-15
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* I tried to use this URL to jumpstart reviewing the deltas:

  https://author-tools.ietf.org/iddiff?url1=rfc7390&url2=draft-ietf-core-groupcomm-bis-15&difftype=--html

  It's not the easiest to read.  It might be nice to bear in mind this
  kind of a review when preparing future -bis documents.

### S2.2.1.1, S3.1.1, S3.4, etc

* It might be worth noting that draft-ietf-intarea-multicast-application-port
  may support/impact some of these statements about UDP port use.

[Ballot discuss]
Thank you for preparing this document on multicast transport. This is a topic I have worked with over many years, and I know this touches on a wide range of issues and trade-offs. The following topics are blocking DISCUSS points (some may be trivial to address, but I do wish to understand first if I am correctly understanding what is proposed and to discuss each point).

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

1. DISCUSS - Status as PS

RFC 7390 was EXPERIMENTAL. The text describing the changes to the document that this obsoletes and replaces [RFC7390] does not describe any implementation or reason why this document is to be published as PS.

Alas, I did not see a stated reason why this was published as experimental. I do not see any reason in the current document that explains why the level of interoperability and experience would support publication on the standards track.
- If the intent is to publish as PS, is the review sufficient?
- What is the level of review and implementation experience for the final specification set out in rev -14?
----
2. DISCUSS - updates to RFC 7252

This document specifies updates to RFC 7252, and although section 1.3 refers to relevant sections in the new document, I found it hard to relate these changes to the sections that appear in RFC 7252. Please can you explain which specific sections (or text) in that existing RFC will be changed as a result of publication of this document as an RFC?

- I also could not find a mention of "CoAP group creation"?

---
4. DISCUSS
Section 2.2.2
/The part of the process that involves secure distribution of group security material MAY use standardized communication with a Group Manager as  defined in Section 5./
- Why is this a MAY? ought this to be a SHOULD? - It seems to lack context to make the decision and isn't it best pactice to recommend use of secure methods?
---
5. DISCUSS
Section 3 (Please explain the multicast addressing model).

I think (from my reading) refers to the ASM model. I see text in  RFC 7390 that clearly states: "  CoAP group communication will run in the Any Source Multicast (ASM) mode [RFC5110] of IP multicast operation.  This means that there is no restriction on the source node that sends (originates) the CoAP messages to the IP multicast group.  For example, the source node may or may not be part of the IP multicast group.  Also, there is no restriction on the number of source nodes."
- I do not see equivalent text in this document. I'd like to understand if this still applies and can be included, or if not, what model ought to be described?
---
6. DISCUSS
Section 3.1.3 - is recovery totally optional?
/To this end, CoAP clients can rely on the following two
  approaches./ ... MAY... MAY...
- I am unsure what is intended! ... and how will this be interoperable?
- I wonder if the intent was to specify a recommended default (SHOULD) and then suggest an alternative?
- Please propose text or explain more.
---
7. DISCUSS
3.1.5.  Token Reuse
/ A preferred solution to meet this requirement is to generate a new unique Token for every new group request, such that a Token value is never reused.  /
- I do not understand the sentence highlighted above, when stated as a part of a PS. Is this intended to be the WG recommendation or not?
- I wonder if the intent was to specify a recommended default (SHOULD)?
Later it states:
/Thus, a client may reuse a
  Token value after it has been freed up, as discussed above and
  considering a reuse time greater than MIN_TOKEN_REUSE_TIME. /
- ought this to be a MAY or SHOULD?
This is followed by:
/Another method to more easily meet the above constraint is to instantiate multiple CoAP clients at multiple UDP ports on the same host.  The Token values only have to be unique within the context of a single CoAP client, so using multiple clients can make it easier to meet the constraint./
- Please clarify what the intent is. If this document is to be published as a PS, it ought to provide clear guidance in RFC2119 language about what is required for an interoperable implementation.
---
8. DISCUSS
Section 3.2.2.1. ETag Option in a Group Request/Response
/Finally, the recommended strategy is for the servers to generate unique ETags as specified below./
- So it describes options and concludes you can do other things, this seems weirdly indecisive at the start and suddenly makes normative requirements.
- Please clarify what the intent is. If this document is to be published as a PS, it ought to provide clear guidance in RFC2119 language about what is required for an interoperable implementation.
---
9. DISCUSS
Section  3.6.  Congestion Control
/Therefore, both the
  sending of CoAP group requests and the sending of the unicast CoAP
  responses to these group requests should be conservatively
  controlled./
- Why is this not a SHOULD, as per RFC 8085?
- Why are the following statements not all normative requirements using  RFC 2119 language?
- including:
/The transmission parameter DEFAULT_LEISURE may be
      used to define a Leisure period when it cannot be computed
      otherwise./
- Why is this not the recommendation, is there another mitigation that can satisfy this need?
- and:
/  Independently of the transport used, additional guidelines to reduce congestion risks defined in this document are as follows:/
- If these are normative requirements, which I agree they ought to be based on RFC98085 etc, then these are not "guidelines", but requirements, please could you change this word?
---
10. DISCUSS
Section 3.6.1.  Default Leisure Updates
/If the Leisure is not computed or configured, the default value
  DEFAULT_LEISURE MAY be used./
- I'd like to understand how this can be used to improve scaling of the method. If this document is to be published as a PS, it ought to provide clear guidance in RFC2119 language about what is required for safe operation, why is this not MUST or at least SHOULD (stating why this is important).
---
11. DISCUSS
Section 3.7.  Observing Resources
/When responding, a server SHOULD apply the Leisure period defined in Section 8.2 of [RFC7252]./
- Please explain why this is not MUST in this case? (if it were SHOULD how will the equivalent response scaling be achieved to satisfy the congestion control requirements?)
---
12. DISCUSS
Section 3.7. 
/A server SHOULD have a mechanism to verify the aliveness of its
  observing clients and the continued interest of these clients in
  receiving the Observe notifications. /
- what does SHOULD have mean?
- Is this: /A server SHOULD verify.../?
---
13. DISCUSS
/Furthermore, a server (member of a targeted CoAP group) that needs to respond to a group request with a particularly large resource can use lock-wise transfer (Block2 Option) at its own initiative, to limit the size of the initial response./
- This seems a very plausible method to use. Why is this not recommended (SHOULD), since it seems to align with other congestion control requirements defined in this document?
---
14. DISCUSS
Section 3.9.1.
/IPv6 multicast MAY be supported in a network only for a limited scope. /
- I'm unsure what the MAY permits and what is also allowed. is this really normative (constraining something) or simply explanation, so it might be /may/?
---
15. DISCUSS
Section 5.1.  Group OSCORE
/As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint.../
What does lower case recommended here? I see this is put forward as "PS", does this not define requirements for this case?
The section later says:
/If security is required, / is this intended to be /The security method described in this section requires.../ ?
and
/  For secured group communication (see Section 5), the maintenance
  operations of the protocol Group OSCORE
  [I-D.ietf-core-oscore-groupcomm] MUST be implemented as well.
/
- Why is this a requirement only to implement? Is this also a requirement to process?
---

[Ballot comment]

Please consider the following comments for draft-ietf-core-groupcomm-bis:

Thank you for the TSV-ART review by Magnus, it raised many issues that were important to me as a WIT AD. I see the document was revised following this (rev -14), some of my comments below relate also to these topics as seen in rev -14.

Section 2.2.2
/  For unsecure group communication using the NoSec mode (see
  Section 4), there is no security material to be provided, hence there
  is no security group for CoAP endpoints to participate in./
- For me, this text is not well constructed, because I earlier understood that NoSec mode was only permitted under very specific uses and I'd expected this to be clear here also and for the avoidance of any doubt I'd expect this also to be clear in the introduction to section 4.
---
/This task MAY be entrusted to a
  dedicated administrator, that interacts with a Group Manager as
  defined in Section 5./
- Is this really an interoperability requirement, could the /MAY/ be a /may/?
---

These commenst mostly relate to editorial NiTs, I've suggested some proposed text, but you my find other text, if you wish to clarify please do:

/Then, Group configuration/
- Why capital "G" here, could this be "group"?
---
/In fact, being a member of a security group actually grants/
- I didn't understand why this is written this way, would it be the same as something like:
/Being a member of a security group grants/
---
Section 2.2.1.1.
I see the text refers to the IPv6 prefix: ff15
- I think this is intended to be a a temporary site-local multicast address, if so please state this also in the text, rather than allowing any possibly for a reader to think this is a special reserved prefix.
---
Section 2.2.1.2.
This text mentions ff35:30:2001:db8:f1:0:8000:1 which seems like it may be an example of a site-local scope multicast address, please state this also in the text.
---
I see this text:
/For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16./
- This does not clearly point to the address allocation and its specified use. Please explain the scope and refer to the IANA registry entry.
----
At various places, the word "effective" is used to describe the impact of an attack. Whilst it is true an attack would have an "effect", I don't think this word is the best, and I could suggest:
/more effective/ is replaced by /makes this more vulnerable/ or something equivalent that indicates this is a problem not a goal.
---
/the attack may/the attack could/
- only to avoid potential mis-reading.
---
Section 3.1.3 makes a general statement I think is wrong:
/Group requests sent over IP multicast generally have much higher loss rates than messages sent over unicast, particularly in constrained networks./
- I can see that loss ratios can be higher for multicast when sent over a different link with a different property, but in the general Internet this is not so. I suggest:
/Group requests sent over IP multicast can have much higher loss rates than messages sent over unicast, particularly when using a constrained network./
---
/This document updates [RFC7252] by allowing a group request to contain ETag Options as specified below./
- please refer to section number where the update is to be applied in RFC 7252.
---
/the CoAP default UDP port number 5683/
- OK, but please insert a reference to the IANA allocation registry.
---
/One way to create multiple CoAP groups is using different UDP ports  with the same IP multicast address, .../
- True, but it seems like this should probably be prefaced by something like:
/When COAP groups are created with unique IP multicast addresses
the receivers of these messages can utilise multicast filters
to extract the messages of interest./
- and then make the directly above sentence in the text start as: /Another way..."
---
/The port number 5684/
- OK, but please insert a reference to the IANA allocation registry.
---
/For a CoAP server node that supports resource discovery as defined in
  Section 2.4 of [RFC7252], the default port number 5683 MUST be
  supported /
- I don't know what "supported" means in this context - must the receiver process packets received on this port; or only if configure, or what? (please change supported to some explanation).
---
/If this happens, the reverse-proxy MUST /
- appears in a separate paragraph to the description. I think it would be better for the sentence to state what /this/ is, i.e. if a client re-uses a Token value, or something similar.
- Consider also making this one paragraph to clearly link the description with the requirement.
---
/  For the operation of HTTP-to-CoAP reverse proxies, see the last two
  paragraphs of Section 3.5.1, which apply also to the case of reverse-
  proxies./
- Would this be clearer rewritten, e.g.:
/  The last two  paragraphs of Section 3.5.1, also apply for the operation of HTTP-to-CoAP reverse proxies./
---
/CoAP group requests may result in a multitude of responses from/
- To avoid doubt, can this be rewritten as something like:
/CoAP group requests could result in a multitude of responses from/
---
/Multicast usage of
  Block1 is non-trivial due to potential message loss (leading to
  missing blocks or missing confirmations), and potential diverging
  block size preferences of different members of the CoAP group./
- I agree, but would also strongly encourage that you add another consideration: that retransmission needs to conform to the congestion control requirements stated in section XX of this document.
---
/the default port number 5683 MUST be supported as per Sections 7.1 and 12.8 of [RFC7252] /
- as before, please expand upon the word /supported/, does this mean messages received and processed? (Also the same comment to explain the meaning of support in 3.9.3)
---
/A suitable cross-proxy can be set up, such that it receives a
      unicast CoAP group request over TCP/TLS/WebSockets, and then
      forwards the request to the servers in the group over UDP/IP
      multicast /
- OK, but please explicitly state that any multicast transmission MUST respect the requirements stated in this document.
---
Section 4: Please consider moving the text within the first few paras. I'd hoped the requirement: /It is NOT RECOMMENDED to use CoAP group communication in NoSec mode./ at the start of section 4 followed by the next para an explanation why, so that this is made this very clear.
---
Plase consider whether you can creat a separate section title: "Operational Considerations" to alert the operator community to relevant content (no need for extra content, just restructuring to make this more obvious).
- If you do this, I'd encourage you to move the subsections 6.6, 6.7 and 6.8 to this new section.
---
I assume all appendices are Informative - but this is not stated, please add a sentence to state this.
---

[Ballot comment]
Hi Esko & Marco,

Many thanks for the effort put into this specification.

The document is well-written. I enjoyed reading it. I appreciate the thoughts and effort to identify and articulate the configuration model and deployment considerations.

Please find some comments (ordered following the spec flow), fwiw. Feel free to grab whatever useful.

# Implementation frozen in an RFC

CURRENT:
  Notable
  CoAP implementations that support group communication include
  "Eclipse Californium" [Californium], "Go-CoAP" [Go-CoAP] as well as
  "libcoap" [libcoap].

This might be too late but following the guidance in rfc7942 would be appropriate. Another option is to consider adding related_implementation tag rather than having those frozen in an RFC?

# Alternate solutions

CURRENT:
  One example is
  Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central
  broker server that CoAP clients access via unicast communication.
  These alternative methods may be usable for the same or similar use
  cases as the ones targeted in this document.

Are there any guidance where the use of group communication is more appropriate than these alternative mechanisms?

# ASM-only

CURRENT:
  Only the Any
  Source Multicast (ASM) mode [RFC5110] of IP multicast operation is in
  scope. 

I naively thought that having an SSM-like mode would be more appropriate if we want to better control who issue the requests. For example, a controller will behave as a CoAP client in such case.

# Demux for Multiple groups

CURRENT:
  A node may be a member of
  multiple CoAP groups, by hosting multiple CoAP server endpoints on
  different UDP ports. 

Why not considering distinct addresses (typically, IPv4 and IPv6) as another way to support that? what is that restricted to port numbers only?

# Deployment assumptions

CURRENT:
  There can be a many-to-many relationship between security groups and
  CoAP groups, but often it is one-to-one.  Also, there can be a many-
                ^^^^^^^^^
  to-many relationship between security groups and application groups,
  but often it is one-to-one.  Such relationships are discussed in more
  ^^^^^^^^^
  detail in Section 2.1.4.

The “often” part may not be stand (in the future, all cases) as this is deployment-specific. Maybe better to focus on protocol implications to support such schemes.

I wonder whether we can translate this into an operational consideration such as a controllers/managers should be able to associate multiple groups and avoid restriction by design. Also, endpoints should be able to support such configuration.

# Preference

CURRENT:
  In this case, a CoAP client can join
  just one of the security groups, based on what it supports and
  prefers, while a CoAP server in the application group would rather
  have to join all of them.

Is this a local decision or inferred from a local policy? Can we translate this into an operational consideration for this matter?

# Access Policies

CURRENT:
  In particular, it is NOT RECOMMENDED to use different security groups
  to reflect different access policies for resources in the same
  application group.

IMO, there is nothing broken if that recommendation is not followed for other reasons (e.g., isolation, ease troubleshooting). That is up to a local deployment. The key message here should be that security groups are not meant to enforce access policies; these are enforced using other means.

# UML

CURRENT:
  Figure 1 summarizes the relationships between the different types of
  groups described above in Unified Modeling Language (UML) class
  diagram notation. 

Consider adding a reference for UML.

# Figure 1

From a deployment perspective, which entity has to maintain this view depicted in Figure 1?

# Conflicting actions

CURRENT:
  These
  clients may be temperature/humidity sensors that report measurements
  periodically to all HVAC devices (Srv5, Srv6) in the Application
  Group 3, using for example /resC to report temperature and /resD to
  report humidity.

When an endpoint belongs to multiple application groups, but conflict actions are being requested for each appl, how is that handled but an endpoint?

# dual-stack

CURRENT:
  The host
  subcomponent indirectly defines the IP multicast address of the CoAP
  group, in case the host consists of a hostname: resolving the
  hostname to an IP address in this case produces the IP multicast
  address.

How this is supposed to work for dual stack hosts?
I guess two groups should be defined in such case? but..

CURRENT:
  For example, if the
  two hostnames group1.example and group1.alias.example both resolve to
  the IP multicast address [ff15::1234], then the following authority
  components are all names for the same CoAP group.

This may resolved to an IPv4/IPv6 multicast address. From IP multicast perspective, these are distinct groups, but this text seems to says that these should be handled as single one.

# Non-default port numbers

CURRENT:
  Also note that, when using the "coap" scheme, the two authority
  components  and :5683 both identify the same CoAP group,
  whose members listen to the CoAP default port number 5683.

Do we allow to configure a distinct port number other than the default one?

# Dependency on DNS

CURRENT:
  When configuring a CoAP group membership, it is recommended to
  configure an endpoint with an IP multicast address literal, instead
  of a group hostname.  This is because an infrastructure providing a
  name resolution service, such as DNS, may not be deployed in many
  constrained networks. 

The first point is reasonable, as a generic statement. However, for the second sentence, wouldn’t this be known to the entity that will deploy the service?

# Multiple channels

CURRENT:
  An application group name can be explicitly encoded in a group URI.
  Specifically, it can be encoded within one of the following URI
  components:

Should this discuss the case where the info is provided in several channels (may be a side effect of various configuring entities), which one takes priority? At least the text can say this is not recommended?

# Not encoded or encoded?

CURRENT:
  Finally, it is also possible to not encode the application group name
  in the CoAP request, yielding the most compact representation on the
  wire. 

I guess you ment “encode”?

# authorization request

CURRENT:
  *  A CoAP endpoint may have to request an authorization to join a
      specific security group through the respective Group Manager,

Can we provide examples how to do that?

# Infer nosec mode from the name

CURRENT:
  Indications that endpoints
  can use the NoSec mode MUST NOT rely on setting up and advertising a
  pseudo security group with name "NoSec" or any of its lowercase/
  uppercase combinations.

I would generalize and say that the (no)security mode MUST NOT be inferred from the name (and then provide nosec and its variation as an example).

# Configuration scope

CURRENT:
  The configuring entity can be, for example, a local application with
  pre-configuration, a user, a software developer, a cloud service, or
  a local commissioning tool.

This seems to assume that the configuration origin may be any. There are deployment implications of such model.

If the configuration is done by an entity distinct from the one that deploys, then there might be configuration conflicts and even potential of stale configuration.

# Remind IPv4 address as well

CURRENT:
  For IPv6 CoAP groups, common multicast address ranges from which
  group addresses can be taken are ff1x::/16 and ff3x::/16.

I would also remind the IPv4 multicast address.

# Various configuring entities

CURRENT:
  To create a security group, a configuring entity defines an initial
  subset of the related security material. 

Do we assume that it is the same entity that configures/control all the various app/sec/etc. groups?

# Lack of mechanism to retrieve actual configuration

CURRENT:
  The configuration of groups and membership may be performed at
  different moments in the life-cycle of a device.  For example, it can
  occur during product (software) creation, in the factory, at a
  reseller, on-site during first deployment, or on-site during a system
  reconfiguration operation.

Given that configuration may done by various entities (including even a software dev as mentioned previously), there are some implication on upgrading/maintaining the functionality in a given network. Support of means to control/retrieve embedded configuration, flushing it out, and also help with troubleshooting. This feature is important for operations.

# GET access control

CURRENT:
  As discussed below, such a GET request may be sent to the IP
  multicast address of an already known CoAP group associated with one
  or more application groups; or to the "All CoAP Nodes" multicast
  address (see Section 12.8 of [RFC7252]), thus targeting all reachable
  CoAP servers in any CoAP group.  Also, the GET request may specify a
  query component, in order to filter the application groups of
  interest.

Does this means that every node can discover what is available in a network? Shouldn’t some filtering be in place?

Doesn’t this help to detect which applications to target by a misbehaving node?

# This is not a new behavior

OLD:
  All CoAP requests that are sent via IP multicast MUST be Non-
  confirmable (NON), see Section 8.1 of [RFC7252]. 


NEW:
  All CoAP requests that are sent via IP multicast must be Non-
  confirmable (NON), see Section 8.1 of [RFC7252]. 

This is redundant with RFC7252.

# Application context

CURRENT:
  This document adds the requirement that a
  server SHOULD suppress the response in case of error or in case there
  is nothing useful to respond, unless the application related to a
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  particular resource requires such a response to be made for that^
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  resource.

How is this technically characterized? Is this managed by a policy?

# Urgent?

CURRENT:
  Therefore, it is more urgent to have a strategy in place
  for handling the loss of group requests than the loss of unicast
  responses. 

What is the purpose of this text?

# Tokens

CURRENT:
  The CoAP client then sends this group
  request using a different Message ID (and the same or a different
  Token value), in which case all servers that received the initial

To what extent the use of same token is conflicting with RFC7252:

  The client SHOULD generate tokens in such a way that tokens currently
  in use for a given source/destination endpoint pair are unique.

# Delivery of responses

CURRENT:
  Due to UDP level multiplexing, the UDP destination port
  number of the response MUST match to the client endpoint's UDP port
  number, i.e., to the UDP source port number of the client's request.

In doing so, this response will traverse on-path devices with EIM/EIF (rfc4787). The response may be filtered if more restrictive filtering is in place (EDF).

# Implementable?

CURRENT:
  How the client in the case above determines the CoAP servers that are
  currently members of the CoAP group is out of scope for this
  document. 

How can the feature discussed in this section be implemented if we don’t have a way to implement it? I expected some more explicit behavior to be specified here as this is targeting STD tracks.

# dst port number

CURRENT:
  the same port number is used as the destination port number
  for requests across all CoAP servers that are members of a CoAP group
  and across all CoAP clients sending group requests to that group.

I guess we meant the dst port nb of multicast request (not dst of responses from servers). I would make this clearer.

# Tracking requests

CURRENT:
      As a result, each server accepts only the first copy of the group
      request received from one of the proxies, while discarding as
      replay any later copies received from any other proxy.

This requires some tracking, which is needed anyway to store the required info to forward a response back.

I guess that tracking should be maintained for a minimum period that would accommodate any reordering/delay in the network.

# TCP, TLS, and WebSockets

This is more describing approaches to support this, but does not specify an exact behavior. This can be better fit in an appendix, IMO.

# Other Transports

I’m not sure whether all will be applicable. Better to declare those out of scope.

# No NoSec again

CURRENT:
Indications that endpoints can use the NoSec mode MUST NOT
  rely on setting up and advertising a pseudo security group with name
  "NoSec" or any of its lowercase/uppercase combinations.

This reco is already stated in 2.2.1.3

Cheers,
Med

Request for IETF Last Call review by SECDIR Completed: Has Issues. Reviewer: Sean Turner. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-core-groupcomm-bis-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-29):

From: The IESG
To: IETF-Announce
CC: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-groupcomm-bis@ietf.org, mbishop@evequefou.be
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Group Communication for the Constrained Application Protocol (CoAP)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Group Communication for the
Constrained Application Protocol (CoAP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-07-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Constrained Application Protocol (CoAP) is a web transfer
  protocol for constrained devices and constrained networks.  In a
  number of use cases, constrained devices often naturally operate in
  groups (e.g., in a building automation scenario, all lights in a
  given room may need to be switched on/off as a group).  This document
  specifies the use of CoAP for group communication, including the use
  of UDP/IP multicast as the default underlying data transport.  Both
  unsecured and secured CoAP group communication are specified.
  Security is achieved by use of the Group Object Security for
  Constrained RESTful Environments (Group OSCORE) protocol.  The target
  application area of this specification is any group communication use
  cases that involve resource-constrained devices or networks that
  support CoAP.  This document replaces and obsoletes RFC 7390, while
  it updates RFC 7252 and RFC 7641.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7967: Constrained Application Protocol (CoAP) Option for No Server Response (Informational - Independent Submission stream)

# Document Shepherd Write-Up for Group Documents

*The revision of the template used here is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This is a substantial document addressing a somewhat specialized topic
(multicast), so there is no surprise that there were only about four
responses (all positive) to the second WGLC, albeit with several
detailed reviews coming in earlier.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes.  Multicast CoAP is sufficiently entrenched that we didn't do a
survey of existing implementations.  For these, the document provides
information that will aid in their further development; several
implementers have contributed reviews.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The main technology outside of the CoRE WG this document interacts is
IP multicast.  As the document is based on extensive implementation
experience, we expect the usual directorate review to be sufficient.
(The document also interacts with LAKE via OSCORE; several main LAKE
contributors have reviewed, one is co-author.)

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document interacts with such common issues mainly in the
applications (ART), Internet (INT) and transport/transfer (WIT) areas.
These issues have been a good part of the discussion in the WG and are
believed to be properly addressed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, replacing RFC 7390 which was Experimental.
(Not all proposals in RFC 7390 are part of this draft.)

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; authors (including a previous co-author) have replied to the IPR
query that was issued with the WGLC.  No disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.  (We reduced the number of co-authors to two in the step from -12
to -13.)

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The idnits tool has several warnings about artwork being wide enough
to be outdented, which we believe do not need action.

There are two normative references to an Informational RFC: RFC 7967
and RFC 9053.  (see 15, 17.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC 9053 is listed as a normative reference although only becomes
normative through its use in normative references of this document.
We believe listing it in the normative references could prevent
surprises by readers that do not follow through on all normative
references.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

(No such normative references.)

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
Yes.
There are downreferences to:

* RFC 7967, which is an Independent Stream document that exercises an
  extension point of RFC 7252; the new option 258 (No-Response) has
  since turned out to be useful in controlling a potential avalanche
  of responses to a multicast request.  Its use is therefore suggested
  in the passages dealing with amplification attacks.

* draft-ietf-core-oscore-groupcomm, which should be processed in a
  cluster with this document.

* RFC 9053 (COSE algorithms), which is mostly used by
  draft-ietf-core-oscore-groupcomm but is listed as a normative
  reference here as well.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

(draft-ietf-core-oscore-groupcomm is expected to be submitted in close
temporal proximity to this document.)

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 7390 (experimental RFC); it also updates RFC 7252 and RFC 7641.
This is listed on the title page and further explained in abstract and intro; Section 1.3 then goes into more details.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no actions for IANA.
(It suggests making use of a registry established by RFC 6690 in the
"Constrained RESTful Environments (CoRE) Parameters" registry group,
but these would be separate actions.)

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document has no actions for IANA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*The revision of the template used here is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This is a substantial document addressing a somewhat specialized topic
(multicast), so there is no surprise that there were only about four
responses (all positive) to the second WGLC, albeit with several
detailed reviews coming in earlier.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes.  Multicast CoAP is sufficiently entrenched that we didn't do a
survey of existing implementations.  For these, the document provides
information that will aid in their further development; several
implementers have contributed reviews.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The main technology outside of the CoRE WG this document interacts is
IP multicast.  As the document is based on extensive implementation
experience, we expect the usual directorate review to be sufficient.
(The document also interacts with LAKE via OSCORE; several main LAKE
contributors have reviewed, one is co-author.)

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document interacts with such common issues mainly in the
applications (ART), Internet (INT) and transport/transfer (WIT) areas.
These issues have been a good part of the discussion in the WG and are
believed to be properly addressed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, replacing RFC 7390 which was Experimental.
(Not all proposals in RFC 7390 are part of this draft.)

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; authors (including a previous co-author) have replied to the IPR
query that was issued with the WGLC.  No disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.  (We reduced the number of co-authors to two in the step from -12
to -13.)

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The idnits tool has several warnings about artwork being wide enough
to be outdented, which we believe do not need action.

There are two normative references to an Informational RFC: RFC 7967
and RFC 9053.  (see 15, 17.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC 9053 is listed as a normative reference although only becomes
normative through its use in normative references of this document.
We believe listing it in the normative references could prevent
surprises by readers that do not follow through on all normative
references.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

(No such normative references.)

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
Yes.
There are downreferences to:

* RFC 7967, which is an Independent Stream document that exercises an
  extension point of RFC 7252; the new option 258 (No-Response) has
  since turned out to be useful in controlling a potential avalanche
  of responses to a multicast request.  Its use is therefore suggested
  in the passages dealing with amplification attacks.

* draft-ietf-core-oscore-groupcomm, which should be processed in a
  cluster with this document.

* RFC 9053 (COSE algorithms), which is mostly used by
  draft-ietf-core-oscore-groupcomm but is listed as a normative
  reference here as well.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

(draft-ietf-core-oscore-groupcomm is expected to be submitted in close
temporal proximity to this document.)

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 7390 (experimental RFC); it also updates RFC 7252 and RFC 7641.
This is listed on the title page and further explained in abstract and intro; Section 1.3 then goes into more details.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no actions for IANA.
(It suggests making use of a registry established by RFC 6690 in the
"Constrained RESTful Environments (CoRE) Parameters" registry group,
but these would be separate actions.)

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document has no actions for IANA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/