Clarification on Subscription Setup Admission/Rejection - XPath and Resource Based Validation

[abhinava]

Based on the gNMI specification section 3.5.2.4 SubscribeResponse Behavior Table, there are these following scenarios:

ID	Subscription Scenario	ONCE/POLL	STREAM
A	Subscribed paths exist or a YANG default value is in use.	Value(s) are returned	Value(s) are returned
B	Subscribed paths are syntactically correct but one or more paths neither exist (yet) nor has a YANG default value in use.	No value returned for non-existent paths	nothing is sent for non-existent paths (yet), RPC is not closed
C	Subscribed paths are syntactically correct but one or more paths is not implemented by the server.	Return UNIMPLEMENTED	Return UNIMPLEMENTED
D	One or more subscribed paths is syntactically incorrect.	Return INVALID_ARGUMENT	Return INVALID_ARGUMENT

Also in the section 3.5.1.3:

There is no requirement that the path specified in the message must exist within the current data tree on the server. While the path within the subscription SHOULD be a valid path within the set of schema modules that the target supports, subscribing to any syntactically valid path within such modules MUST be allowed. In the case that a particular path does not (yet) exist, the target MUST NOT close the RPC, and instead should continue to monitor for the existence of the path, and transmit telemetry updates should it exist in the future.

I have a few questions for which some clarifications would be really helpful:

1. What does "syntactically correct (or incorrect)" mean here? For instance, if the incoming request breaks the gNMI path conventions, we can safely say it is syntactically incorrect (scenario D) in the table above.
2. On the other hand, if an XPath follows gNMI path conventions but is not implemented by the target/node's YANG modules, this falls under scenario C i.e., UNIMPLEMENTED.
3. However, what happens in cases where a client subscribes to openconfig-interfaces: /interfaces/interface[name="eth2345"], and on that target, eth2345 can never come into existence?
   a) In these types of scenarios, should the node fallback to scenario B above, where it accepts the subscription, but no data is ever produced for this subscription (no sync_response etc.) - silent failure.
   b) Or, should this be treated as scenario D i.e., return an INVALID_ARGUMENT error code?
4. A follow-up question somewhat similar to the scenario above is, what if a requested path is syntactically valid, and also the underlying resource (e.g., eth2345) is acceptable to the target. However, the physical resource which supports eth2345 like a line-card or a chassis has suffered a critical hardware failure, and it will not be able to produce telemetry updates until there is a physical intervention (replacing the card, re-cabling the interface etc.)
   a) What is the expectation here? Should this also fallback to scenario B above, where subscription request is accepted, and the node waits until the underlying physical issue is resolved?
   b) If subscription already existed that maps to this physical resource, given that the interface eth2345 continues to exist from a "configuration" perspective, we can't send a SubscribeResponse / Notification / delete (Path). It's likely that the gNMI target emits SubscribeResponse / Notification / update (Update) messages due to change in things like operational state.
   c) But if a new subscription is attempted to be created while the physical issue persists, would this be grounds for the gNMI target to reject the subscription and return INTERNAL (13) or DATA_LOSS (15) (or one such gRPC status codes)?
5. Another (potentially) related question is, what if the request is syntactically valid (including potentially target/platform-specific checks etc.), but the system doesn't have resources to accept this subscription.
   a) In such a case, should the behavior be consistent with B where since the subscription is valid, we accept the request and wait for the system state to go back to steady state where the telemetry updates can be processed/published?
   b) Or, should the node reject the subscription request with RESOURCE_EXHAUSTED (or one such gRPC status codes).
6. Finally (and again, a related, follow-up to the above points), the table scenario B, and also the section 3.5.1.3 implies that subscription admission (or rejection) SHOULD NOT rely on the underlying physical/logical resource from being explicitly user configured (via gNMI Set, or some other nodal configuration interface - NETCONF, CLI etc.).
   a) Could you confirm that this is what the specification means? That is, explicit configuration through the management plane is not a pre-requisite to reject a Subscribe RPC request to setup the subscription.
   b) However, a slightly different interpretation could be made here where a gNMI implementation rejects Subscribe RPC requests by looking at discovered system state (not configuration state - for e.g., deciding to reject a Subscribe RPC request based on the presence (or absence) of a physical transceiver or line-card) --> This could be in theory clubbed in to the same category as point 3(a) or 4(a) above.

Any feedback or comments on this will be very helpful.

Thanks!

[abhinava]

I see another related open query: #112