> 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. +1 I support adoption. Göran On 2020-07-03, 08:56, "Ace on behalf of Christian Amsüss" <[email protected] on behalf of [email protected]> wrote: 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
