IETF Last Call Review of draft-ietf-ace-oscore-gm-admin-15
review-ietf-ace-oscore-gm-admin-15-artart-lc-gondwana-2026-02-24-00

Request Review of draft-ietf-ace-oscore-gm-admin
Requested revision No specific revision (document currently at 17)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2026-02-16
Requested 2026-02-02
Authors Marco Tiloca , Rikard Höglund , Peter Van der Stok , Francesca Palombini
I-D last updated 2026-03-31 (Latest revision 2026-03-26)
Completed reviews Artart IETF Last Call review of -15 by Bron Gondwana (diff)
Secdir IETF Last Call review of -14 by Wes Hardaker (diff)
Secdir Telechat review of -15 by Wes Hardaker (diff)
Assignment Reviewer Bron Gondwana
State Completed
Request IETF Last Call review on draft-ietf-ace-oscore-gm-admin by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/nT1hwGgFLvjKwK_NhVA9jtRzvHw
Reviewed revision 15 (document currently at 17)
Result Ready w/nits
Completed 2026-02-24
review-ietf-ace-oscore-gm-admin-15-artart-lc-gondwana-2026-02-24-00
I am the assigned ARTART reviewer for this document.  Sorry for my late reply,
I have tried and failed multiple times to give this a thorough review, my eyes
kept glazing over.  I have skimmed through and not seen anything objectionable,
the one thing I had questions about I figured out and it made sense.

HOWEVER, I do have a general concern that what seems to be a fairly standard
CRUD protocol - for updating things which are defined in other documents - is
over 80 pages long.  This suggests that either it's a very complex thing to
implement, or that the spec and operational considerations are intermixed in a
way which means there's a lot of normative text for any implementation to read
and fully understand before implementing.

Anyway, that's my feedback.  The document seems to be very verbose for what it
achieves.