Authors and WG, I do not believe the changes required for the AD review are large. If we can get an updated draft before Monday max, I can still IETF LC it and maybe bring it to a telechat before IETF-125. If we don't reach the IETF LC stage, you will have to wait for the new SEC AD to get up to speed with ace/lake before this document can move forward. That would be a shame.
Paul On Tue, Sep 30, 2025 at 10:47 PM Paul Wouters <[email protected]> wrote: > > 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. > > >
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
