IETF Last Call Review of draft-ietf-core-groupcomm-bis-14
review-ietf-core-groupcomm-bis-14-secdir-lc-turner-2025-07-29-00

Hi! Started out comparing this I-D to RFC 7390; there are a LOT of changes, but
that is a good because RFC 7390 is experimental and this I-D is bound for
standards track.

I have one issue worth discussing and the rest are nits.

Issue) It is possible that I am missing the point of the document, but I am
left wondering if I follow the recommendations herein will I end up with an
interoperable solution. s2.2.2 is pretty explicit about there not being a
mandatory group creation protocol, but shouldn't there be a key management
protocol? s5.2 includes the following:

  The key management operations mentioned above are entrusted to the
  Group Manager responsible for the OSCORE group
  [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform
  them as defined in [I-D.ietf-ace-key-groupcomm-oscore].

Based on the following IESG statement
(https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/)
and with RECOMMENDED = SHOULD, isn't I-D.ietf-ace-key-groupcomm-oscore a
normative reference?

With 15 examples of the "x can be used to do y" (not normative requirements), I
left feeling like  ¯\_(ツ)_/¯ that I can get to an interoperable solution even
after skimming the references to: - RFC 9176 (normative) -
I-D.ietf-ace-key-groupcomm-oscor (informative) - I-D.ietf-ace-oscore-gm-admin
(informative) - I-D.ietf-core-oscore-groupcomm (normative) -
I-D.ietf-core-groupcomm-proxy (informative) - I-D.tiloca-core-oscore-discovery
(informative)

Nits:

n0) s2.2.3.2: This sentence was a little awkward for me:

  The following discusses a number of methods to discover application
  groups and CoAP groups, building on the following assumptions.

would this work:

  The following discusses a number of methods to discover application
  groups and CoAP groups.

n1) s4 includes:

  Consistent with such
  security implications, the use of the NoSec mode should still be
  avoided whenever possible.

should that should be a SHOULD?

n2) s4 & s6.1 consistency:

s4 includes (right before this is refers to s6.1):

  It is NOT RECOMMENDED to use CoAP group communication in
  NoSec mode.

s6.1 includes:

  Except for the class of applications discussed above, and all the
  more so in applications that obviously have hard security
  requirements (e.g., health monitoring systems and alarm monitoring
  systems), CoAP group communication MUST NOT be used in NoSec mode.

Are these consistent?

n3) s5.3 includes:

  For a client performing a group communication request via a forward-
  proxy, end-to-end security should be implemented.

should that should be SHOULD?

n4) s6.7 includes:

  In a home automation scenario using Wi-Fi, Wi-Fi security should be
  enabled to prevent rogue nodes from joining.

should this should be a SHOULD?

Cheers,
spt