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 On 2020-07-03 08:55, Christian Amsüss 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. ==>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. <== > > 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? ==>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". <== > > 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. ==>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. <== > > 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. ==>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. <== > > Why is "Update a Group Configuration" a PUT and not a PATCH? It does not > 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 > Ace@ietf.org > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
