Is /GetSerial meant to list data for child groups recursively? Is /GetOwnershipVoucher expected to create an OV using a PDC in the parent group?

[pranav-jnpr]

As per the service usage example, /GetSerial is used to get ALL the component IDs which are part of the root-group "org-acme" - https://github.com/openconfig/ovgs/blob/main/docs/service-overview.md#getting-all-serial-numbers.

However at this stage in the sample workflow, no sub-groups have been defined. What is the intended usage of the /GetGroup RPC when the sub-groups have been defined, and the components have been moved under their respective groups? Consider a case where there are no orphaned components directly under the root group - all of them have been assigned to their respective sub-groups - should a /GetGroup call to 'org-acme' recursively list ALL components within the sub-groups?

On the similar note, if there is a PDC assigned to a parent group, is the service expected to allow creation of a corresponding OwnershipVoucher using the PDC in the parent group for a component which is placed in one of the child groups?

[haussli]

Hi. I do not believe that there are any recursive/tree-walking operations in ovgs. An operation taking a group argument only affects that group. Each child_group_ids must be resolved manually.

WRT the PDC; yes, I expect that any PDC in a parent group, reaching from a subgroup all the way to the root, which the calling role has permissions to create OVs, could be used. This would reflect the permissions resolution; a user inherits permissions for a subgroup from its parents, if it does not have a specific entry in the subgroups' "users" field.

@sulrich might confirm/comment on these.

[sulrich]

wrt, GetSerial operation i don't think we've been particularly crisp in defining the behavior here. the permissions model for the serial number collection lends itself to allowing the recursive collection of all the SNs for the components in all sub-groups. however, this may pose other challenges. having the client interrogate individual sub-groups that it has access to seems like reasonable behavior.

wrt, to PDC inheritance, if nothing's specified i would expect it to use the nearest inherited PDC.

cc: @harshitk-arista for additional color.

[harshitk-arista]

should a /GetGroup call to 'org-acme' recursively list ALL components within the sub-groups? No. GetGroup will return components and PDCs assigned only to that specific group.

Note that the permission model is hierarchical (who gets to invoke certain operations via the corresponding RPC), based on the role and group a user is assigned to for a particular group in the heirarchy, the usage of the certs and serials is not. When generating vouchers (via GetOwnershipVoucherRequest), the component and the cert has to be supplied. Based on the calling clients group membership and role, it is checked whether the client is authorized to invoke this operation. It is however necessary to set a PDC with the group and we do not use the nearest inherited PDC.

This is what the 3 predetermined roles correspond to. Typically - 1.) An account with ADMIN role (greatest level of privileges) will be responsible for creating the heirarchy and adding other users with the appropriate role. This is bootstrapping the hierarchy and who gets permission over whatever serials (that wil be assigned next) in each subtree (Relevant RPCs: CreateGroup, DeleteGroup, AddUserRole, RemoveUserRole) 2.) An account with ASSIGNER role will be responsible for adding and associating the certs and serials with the groups created in step 1 (Relevant RPCs -AddSerial, RemoveSerial , CreateDomainCert, DeleteDomainCert) 3.) An account with REQUESTOR. role (lowest privileges) will request vouchers via GetOwnershipVoucher. This can also invoke all the Get RPCs (GetGroup, GetSerial, GetUserRole, GetDomainCert)

[haussli]

@pranav-jnpr has this discussion resolved the question?