Hi Jim,
Thanks for this review! We have processed your comments in the latest
version -02, with one open point left for discussion.
Please, see our replies in line.
Best,
/Marco
On 2020-06-07 18:22, Jim Schaad wrote:
> * Does 'joining_path' contain the path or the full URI to the joining
> resource. Is it possible for the Group Manager Administration to be on a
> different server (or via a different address) from the Group Manager itself?
> Path tends to me to say only path.
==>MT
Right, it's intended as full URI. And yes, the Administrator and the
Group Manager can be in totally different machines. We have renamed the
parameter as 'joining_uri'.
<==
> * Section 2.3.2.1 - I think it makes more sense to make all of the defaults
> to the groupcomm draft from ACE for OSCORE. Since this is for managing
> those types of groups, it should be that document which gets to set the
> defaults. If it wants to refer back to the same documents that is fine, but
> it should be that the defaults can change based on changing that document.
==>MT
We have moved the default values of the configuration parameters to a
new section in ace-key-groupcomm-oscore , while we keep here the default
values of the status parameters in Section 2.3.2.2.
<==
>
> * Section 2.3.2.2 - I think there may be a difference between an empty
> string and an absent string for group_title. Just verifying that what you
> want is an empty string.
==>MT
We have updated the parameter definition to be the CBOR simple value
Null, if no description is provided for the group. The default value
defined in this section has also been update to be Null.
<==
>
> * Section 2.4.1 - I am not sure why this is a subsection of 2.4.
==>MT
It should in fact be a self-standing Section 2.5. Now fixed.
<==
>
> * Section 2.5.3 - What does "or is not fine to consider for tis OSCORE
> group" in bullet #4 list #2? Is this implying some type of judgement on the
> part of the AS based on parameters in the group definition or the expected
> usage of the group?
==>MT
No, we don't mean anything so specific. We wanted to capture that the
Group Manager may still trust the suggested AS, but already has a
different associated AS to use.
We have updated the text in current Section 2.6.3, limiting the error
cause to not trusting the suggested AS while at same time not having any
alternative AS to consider for this OSCORE group.
<==
>
> * Section 2.5.3 - I think it might make sense to return at least some of the
> information in the return value of the POST such as the "joining_path" and
> the "as_uri" because just the management path is not sufficient to be able
> to start populating the RD.
==>MT
We have updated current Section 2.6.3 accordingly, and further included
'group_name' to the list of parameters included in the response.
Along the same lines, we have also updated the response to a PUT request
updating the current configuration, in current Section 2.6.5. This
applies at least to the case where the Administrator specifies a new AS,
and the Group Manager rejects it but has a better one to use instead,
and indicates it in the response to the PUT request.
In both sections mentioned above, we have also added text describing how
a registration/update in the RD can follow, for the link to the
group-membership resource of the created/updated OSCORE group.
<==
>
> * Section 2.5.3 - An interesting question - Should it be allowable for the
> name to be different between the management and the group key nodes? I
> would like to see some type of discussion at least on the mailing list.
> Doing the search on the join path would result in the same answer and little
> additional penalty since I doubt that GM Admin clients are going to be
> constrained.
==>MT
It is possible to have two separate parameters here, i.e.
'group_name_admin' and 'group_name_members'. They would both point at
the same OSCORE group, but:
- The Administrator can use either of the two to retrieve the same group
configuration.
- The Administrator uses 'group_name_members' for
publication/advertisement or for registering a link to the
group-membership resource in the RD (where that group name will be the
value of the attribute 'sec-gp').
- The candidate group members end up using the group name
'group_name_members'.
So, it's true that there is no real penalty in doing this, but what's
the actual advantage in having this distinction? Is it about making it
allowable for future use cases?
<==
>
> * Section 2.5.5 - The second paragraph makes zero sense to me. The third
> paragraph should just be talking about the update message and not mixing the
> create and update messages together.
==>MT
In current Section 2.6.5, we have rephrased the second paragraph
explicitly mentioning the error handling on the request payload,
analogous to the one for the POST request for creating a new OSCORE group.
On the third paragraph, not sure where we referred to group creation. We
have anyway pointed more clearly
