AFTResult status code for a Modify session w/o param negotiation

[LimeHat]

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

gribi/v1/proto/service/gribi.proto

Lines 96 to 102 in 0f369fb

	// 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)

gribi/doc/specification.md

Lines 151 to 163 in 0f369fb

	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`

?

[robshakir]

@LimeHat Apologies, missed this issue -- with the deprecation of OK, then RIB_PROGRAMMED should be used IMHO. Any thoughts?

[robshakir]

Currently this is not tested in the compliance test suite, because we always assume that we specify some persistence mode, and SINGLE_PRIMARY. Tying adding the compliance test in openconfig/gribigo@689fdad to adding support for non-leader elected, non-persistent clients to gribigo.

[LimeHat]

Thanks Rob. I agree with the behavioral part and thank you for adding the test.

Perhaps the proto comment can also be updated to remove the ambiguity?

gribi/v1/proto/service/gribi.proto

Line 107 in 024356c

// - Each AFTOperation is acknowledged with OK or FAILED in