Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks for the feedback Mike, and great questions! We're currently
working off slightly different assumptions, but are working through these
to validate that they are the expected behaviour for the majority of users:

* Space developers in the 'owning' space (this is the way we've thought
about this too!) *would *be able to delete or unshare a shared service
instance with bindings, but they would get a warning in the CLI warning
them that this will automatically delete bindings in other spaces.

Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* Space developers can only bind and unbind to service instances that have

been shared into their space. In this first version they wouldn't be able
to remove the service instance from appearing in their space without asking
the sharer to unshare it.

If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* We've investigated a number of sharing permission models, including how

both CF admins and service broker authors want to control this. Initial
feedback has suggested that for most use cases, service brokers shouldn't
care where the binding is coming from (it looks the same to them). There
are edge cases here with things like ASGs though which we will need to
consider.

IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.
md#catalog-management) is too much to ask. Unless there is some
complexity I'm not seeing?


Thanks,
Mike