Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items)

[Christian Amsüss <[e-mail]>]

Hello ACE,

I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that
it fixes a gap in the set of current drafts on the topic:

Without (something like) this, group deployment applications need
application specific group managers, and as the GM is not trivial to
implement, I'd expect that they would bundle the GM with their
on-at-deployment-time tools rather than ship a constrained and
well-specified always-on GM that's just managed by their deployment
tools -- leading to much more error prone deployments that can't
leverage OSCORE group communication in full.

I don't quite see myself in a position to advocate adoption in this WG I
haven't actively contributed to before, but I do support this document
being processed somewhere in the IETF.

Best regards
Christian


PS: Small by-catch issues for the authors:

The pct-encoded names in the group name sound odd to me. What do those
names have to do with URI components?

The "is fixed" and "is a default name" terminology around resources is
probably confusing to people who don't know ahead of time what it's
supposed to mean; moreover, demanding that the URI be fixed is a pretty
harsh requirement for something that may move around in the network;
furthermore, while an I-D should avoid creating URI aliasing, it
shouldn't rule out that the server may do that either. (And if it
supports different transports, right now it needs to). Later in 2.5.3,
it even sounds like the path is prescribed.

Other than this being an ACE document, is there a particular reason
"Getting Access to the Group Manager" is prescribed to use ACE? The
whole 2.1 section sounds quite repetitive when read in the context of
ACE, and unnecessary when different methods are employed. Maybe if there
were talk about different admins and whether they may change each
other's groups that'd be conveniently be expressed in terms of ACE
scopes (not sure), but as of now it isn't.

Why is "Update a Group Configuration" a PUT and not a PATCH? It does not
replace the resource, it just modifies it.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom