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

[Göran Selander <[e-mail]>]

>    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" <[e-mail] on behalf of [e-mail]> 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