In a scenario where a client skips session parameters negotiation, and starts with a ModifyRequest with an AFToperation only, should the successful operation be acknowledged with a deprecated OK status as suggested by these lines in .proto
|
// If the client does not send session_parameters, then the network element |
|
// assumes the following defaults: |
|
// - ALL_PRIMARY for client redundancy |
|
// - A client disconnect is treated as if the client issued DELETE |
|
// AFTOperation for all the AFT entries that client ADDed. |
|
// - Each AFTOperation is acknowledged with OK or FAILED in |
|
// in the AFTResult of the ModifyResponse. |
Or, as could be implied from the specification.md, we should use RIB_PROGRAMMED instead (since this is the default ack mode)
|
It is possible that the client skips the negotiation step. In this case, the |
|
first `ModifyRequest` message from the client contains `operation` but not |
|
`params`. The device will assume the default parameters are requested by the |
|
client. If any of the default parameters is not supported by the device, the |
|
device should close the `Modify` RPC upon receiving the first `ModifyRequest` |
|
message, and the device should set the generic gRPC |
|
[`Status.code`][gRPC status code] to `UNIMPLEMENTED`. The `Status.details` |
|
should contain `ModifyRPCErrorDetails` message with `reason` set to |
|
`UNSUPPORTED_PARAMS`. The following are the default parameters: |
|
|
|
* `redundancy` = `ALL_PRIMARY`. |
|
* `persistence` = `DELETE` |
|
* `ack_type` = `RIB_ACK` |
?
