Clarification: Prefix handling for Get|SubscribeResponse

[gsindigi]

How the response for a gNMI Get or Subscribe request with prefix set to a valid path in the YANG tree should be formed?

1. Should the response be always relative to the incoming prefix? If so,
   i. how the target should handle Get calls when it knows response could be large and may not fit in existing default gRPC limit e.g., 4MB?
   ii. In case of Subscribe calls, it is possible to send stream of responses, but how the target to decide the criteria to split response so as is fits in such allowed limit?
2. If target can choose to send response by re-adjusting prefix + responses' paths, is the client expected to inspect prefix + each of the updates' path and act on it? Many a times, it would be required on the client side to group updates as a single group/object and then process e.g., processing /interfaces/interface objects one-by-one.
   i. If the same object is split, for size considerations, how the client should determine, the current updates's in hand are complete or to expect more?
   ii. If there is no order of elements ensured, it becomes still more complicated to decide the border between the objects

With increase in size, it becomes both CPU and memory intensive operation on both target and client. As the size of the data increases, it becomes essential to handle scenarios gracefully; like indicating by an error to use Subscribe instead of Get. As in the case of Subscribe, since it is possible to send stream of responses, what are the guidelines on both client and server (target), so that handling of data is consistent on both ends?