[Ace] AD review of draft-ietf-ace-oscore-gm-admin-13

[Paul Wouters <[e-mail]>]

AD review of draft-ietf-ace-oscore-gm-admin-13

Thanks for this document. All in all it is very clear.
I do have some questions and comments/nits:

TLS version

        this can rely on DTLS [RFC9147] as per [RFC9202]

Does this mean it requires DTLS 1.3, or is DTLS 1.2 allowed? Should this
be made more explicit?

Default values and their use

    While the defaults use RECOMMENDED, things like Section 6.6 state the
    value from defaults MUST be used. It is a little unclear to me what
    this means when the RECOMMENDED value was not used. Should it use the
    different value or the RECOMMENDED to comply to the MUST ?


Fix reference on draft-amsuess-core-cachable-oscore

det_hash_alg refers to draft-amsuess-core-cachable-oscore but this should
be draft-ietf-core-cacheable-oscore.

default values

        This section defines the default values that the Group Manager
        uses for the configuration and status parameters.

But the next sentence says these are the RECOMMENDED values. So perhaps it
should say that here too?

Section 6.6.1

Why is this listed here? Isn't this regular operation unrelated to this
document?


Section 6.6.2

6.6.2 also repeats this text:

        If the value of the status parameter 'active' is changed from true
        (0xf5) to false (0xf4):

        The Group Manager MUST stop accepting requests for new individual
        keying material from current group members

Should this not read that the group members MUST stop sending requests ?
If not, why is this text repeated from 6.6.1? Note that it does say so
in the second bullet point:

        * Every group member, upon learning that the OSCORE group has
        been deactivated (i.e., 'active' has value false (0xf4)), SHOULD
        stop communicating in the group.

then:

         Every group member, upon learning that the OSCORE group has
         been reactivated (i.e., 'active' has value true (0xf5) again),
         can resume communicating in the group.

Am I correct in that group members "learn" this via the pairwise connection
with the GNM by requesting a LIST command filtered by Active state?


Section 6.8

        Otherwise, the Group Manager continues processing the request,

I am not sure where this "Otherwise" comes from. Eg if "otherwise" is the
"else" part, what was the "if" part? What part of the processing was done
before this statement was reached?


I wonder if [I-D.amsuess-core-cachable-oscore] should be normative?

[I-D.tiloca-core-oscore-discovery] is definitly normative.

RFC9176 is probably normative too



NITS:

        The Constrained Application Protocol (CoAP) [RFC7252] can also
        be used for group communication [I-D.ietf-core-groupcomm-bis],
        where messages are exchanged between members of a group

I would remove "also" and the comma before "where.

        as well as how it should be configured and later on updated
        or deleted, e.g., based on the current application state or
        pre-installed policies

I had to read this a few times.. how abour "and later on how it should
be updated or deleted"

        and is poorly flexible

and is not very flexible.