Update authorization examples and use of bootz

[marcushines]

No description provided.

[LimeHat]

What is "rejection" in this case? Does this mean that an RPC should return an error?

I'd argue that returning an empty response for this case should be allowed (if not required). This allows for consistent behavior (and implementation) with other scenarios (for example scenario#4 gnmi.Subscribe(10.0.0.10:515253, core-contollers, /interfaces/interface/state/counters, ONCE)), as well as a graceful support for scenarios where multiple paths are queried at the same time (e.g. if the subscription list contains 1 allowed path, and 1 disallowed path in the same query).

[marcushines]

yes the subscribe should return unauthorized

how is it graceful to provide silently discard valid paths to a subscriber based on authorization rejection?

[marcushines]

the other option here would be to add a new response message type which can at least single to a client that there are paths that were in the subscription that are unable to be displayed

[morrowc]

In chatting with eben @ juniper (and marcus previous to that) I think the idea that the caller asks for X, Y, Z and only gets X and Z is confusing to the caller. There isn't (today) a way (except 'not-authorized') for the grpc server to say: "Sorry you get 2 of 3 paths"

Is it ok longer term for callers to keep asking for things that it'll not get?
Why not just error immediately as a signal to fix the caller's configuration?

[LimeHat]

let's consider the following example:

• a router has two interfaces, ethernet-1 and mgmt.
• a client has access to /interfaces/interface[name=ethernet-1], but doesn't have access to /interfaces/interface[name=mgmt] according to the policy.

if the client subscribes to /interfaces/ tree as a whole, it will receive data only for ethernet-1.
if the client chooses to subscribe to /interfaces/interface[name=ethernet-1], /interfaces/interface[name=mgmt0], according to the new description he should receive the error (while he could be getting the same data; in this example, both requests are equivalent).

this behavior discrepancy makes less sense to me. if you want to explicitly signal an error, shouldn't the first case also return an error?

Is it ok longer term for callers to keep asking for things that it'll not get?

i don't see much of a problem with it? do we have to disclose the specifics of a security policy to clients?

there's already Probe() RPC that can be used by security teams to validate policies for a specific user id, making it feasible to perform this validation out-of-band. or access to this RPC can even be given to telemetry clients.

if anything, in b/384081671 there was a similar request (not related to security policies) to allow clients to subscribe to nonexisting and non-supported paths..