Skip to main content

Last Call Review of draft-ietf-ace-key-groupcomm-17

Request Review of draft-ietf-ace-key-groupcomm
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-10-20
Requested 2023-10-06
Authors Francesca Palombini , Marco Tiloca
I-D last updated 2023-10-13
Completed reviews Artart Last Call review of -17 by Henry S. Thompson (diff)
Tsvart Last Call review of -17 by Vidhi Goel (diff)
Genart Last Call review of -17 by Thomas Fossati (diff)
Iotdir Telechat review of -17 by Dave Thaler (diff)
Assignment Reviewer Thomas Fossati
State Completed
Request Last Call review on draft-ietf-ace-key-groupcomm by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 17 (document currently at 19)
Result Ready w/issues
Completed 2023-10-13
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-ace-key-groupcomm-??
Reviewer: Thomas Fossati
Review Date: 2023-10-13
IETF LC End Date: 2023-10-20
IESG Telechat date: Not scheduled for a telechat


This document describes how to do secure group communication management
using ACE.

The document does not directly define a protocol.
Rather, it provides a framework - in terms of message formats and a
comprehensive REST API (plus the associated IANA machinery) - that
individual secure group communication protocols are supposed to
instantiate for their purposes, and according to their specific needs.

The document is very clearly written.  Kudos to the editors.

From a Gen-ART perspective this work is basically ready, except a couple
of minor CDDL-related issues described below.

IANA-wise, all registrations to existing registries as well as the
creation of new registries look good.  DE instructions are also
excellent, thanks for that.

One question I have related to error handling:
Have you considered reusing the RFC9290 framework instead of putting
`error` and `error_description` in application/ace-groupcomm+cbor?
* it is (quite) common practice to use a separate "problem details"
  format (e.g., see ACME, JMAP, SCITT, and CT) because of the advantage
  of using a single interface for *all* 4/5.xx responses, not just those
  that are protocol-specific
* it is similarly compact (but allows extra information to be added, if
* it is not limited to English/ASCII text

Major issues:


Minor issues:

Two small things related to the CDDL:

* RFC 9237 has `AIF-Generic` rather than `AIF_Generic`
  * also maybe add `;# include rfc9237` to each CDDL fragment to make it
    self-consistent - or add the definition of AIF-Generic at the top

* `scope = << [ + scope_entry ] >>` is not valid CDDL (`<< >>` is for
  embedding CBOR items AFAIK, not CDDL.)  Do you mean instead:
scope_entries = [ + scope_entry ]
scope = bstr .cbor scope_entries

Editorial comments:

* terms and concept that readers are expected to be familiar with should
  also include RFC8610

* there are a few occurrences of this pattern: "the invariant once
  established identifier [...]", which may be easier to parse if
  rewritten as: "the identifier [...]. Once established, it never
  changes / it is invariant." (unless I have completely missed the


A bunch of typos fixed in [1] - which also has (in a separate
commit) a SVG-ised version of the architectural diagram for
fancier rendering in HTML and PDF :-)