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

From: Christian Amsüss <[email-masked]>
Date: Fri, 3 Jul 2020 08:55:58 +0200

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 3 Jul 2020 07:11:24 +0000

>    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-masked] on behalf of [email-masked]> wrote:

    Hello ACE,

    Best regards
    Christian

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 20 Jul 2020 09:59:08 +0200

Hi Christian,

Thanks for your support and comments!

We have processed some of your comments in the latest version -02, while
some are still open to cover in the next version.

Please, see our replies in line.

Best,
/Marco

> leverage OSCORE group communication in full.

==>MT
Right, we have added some text in the introduction, based also on a
related input received from Carsten during the ACE interim in June.
<==

> names have to do with URI components?

==>MT
This slipped through in the latest update. We'll remove the statement in
the next version, i.e. the sentence can end with "... that are valid for
a URI path segment".
<==

> it even sounds like the path is prescribed.

==>MT
That's actually intended for the uri-path . We have updated the text,
avoiding to talk about fixed resources and default names.

OLD: The URI of the group-collection resource is fixed and has /manage
as last path segment. The url-path /manage is a default name:
implementations are not required to use this name, and can define their
own instead.

NEW: As an example, this document uses /manage as the url-path of the
group-collection resource; implementations are not required to use this
name, and can define their own instead.
<==

> scopes (not sure), but as of now it isn't.

==>MT
Yes, we can explore more about different administrators managing common
groups.

More generally, this management process is supposed to work side by side
with the joining process, for which the Group Manager uses ACE. So, it
just felt natural to think of the Administrator as also another ACE
Client at the Group Manager.
<==

> replace the resource, it just modifies it.

==>MT
Everything that is not specified in the request is completed considering
default values.

We will extend this to support PATCH and selectively update only some
parameters.

Thanks a lot again!
<==

>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Jul 2020 15:12:09 -0400

This email closes the call for adoption. The document has been adopted.
Please upload the document as an IETf WG document.
Yours,
Daniel

On Tue, Jun 23, 2020 at 9:45 AM Francesca Palombini <
[email-masked]> wrote:

> Hi,
>
>
>
> I have reviewed the document and I believe this will be helpful for the
> work we are doing in Ace. +1 for adoption.
>
>
>
> Thanks,
> Francesca
>
>
>
> *From: *Ace <[email-masked]> on behalf of Daniel Migault <
> [email-masked]>
> *Date: *Monday, 22 June 2020 at 22:31
> *To: *Ace Wg <[email-masked]>
> *Subject: *[Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin
>
>
>
> Hi,
>
>
>
> Following the interim meeting this morning, this email starts a call for
> adoption of "Admin Interface for the OSCORE Group Manager"[1]. Please
> state your opinion by July 6 2020 whether the WG should adopt or not this
> document.
>
>
>
> Yours,
>
> Jim and Daniel
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>

-- 
Daniel Migault
Ericsson