Going beyond message validation in Layer 2 Config

[vbabuEM]

Current status on layer 2 config

To my knowledge, the following is the current requirement specified in Beckn-ONIX and status on field w.r.t. Layer 2 Config

1. Network participants(NPs) should install layer 2 config provided by the Network Facilitator(NF)
2. It extends existing core spec with new rules specified by NF. The format (OpenAPI) is same as the core specification.
3. The NPs(BAP and BPP) will use this file for message validation for all incoming messages and ensures that all outgoing messages also are compliant with it.
4. The exact file to use is decided based on the tuple of (domain,core_version[version]) from the context field of the message.
5. In case any message is received for which the Layer 2 config file is not available to the NP, the core specification relevant to the core_version[version] of the protocol is used for validation.

Given the current state mentioned above, there have been some things discussed in past, but not part of current Beckn-ONIX requirements nor of reference implementation. I am listing them for sake of recording.
a. Granularity at which the layer 2 config should be specified (currently it is domain,core_version - as specified above)
b. Composition, Management and Distribution mechanisms ( How do network faciliators write these rules easily. How do they manage rules over time including versioning etc and how do they distribute it - one file vs multiple files vs zip file etc)

New requirement

While the name "Layer 2 Config" has Config within it, in the current state, it is primarily message format spec used for validation. The OpenAPI format is custom built for that and it does a good job (with some restrictions that I wont go into in this discussion) at it.

However there are many cases where Network Facilitators need to instruct/guide Network Participants on configurations. One example that has currently come up is where a Network Facilitator wants to specify telemetry data to be collected by all Network Participants. At a high level, they want to specify the list of attributes for each Transaction API and additional collection related configuration such as sampling rate etc.

Similarly, as more and more services are added to the Beckn-ONIX extended requirements, we will have additional information on these that the NFs might wish to prescribe (e.g. details about reconciliation flows, grievance flows etc). Trying to put this information into the current OpenAPI format layer 2 config will look like a force fit. OpenAPI is an API specification mechanism and a lot of these configurations do not fall into the API description category.

Hence we need the following:
a. A mechanism to specify configuration data that NFs want to recommend to NPs (yaml/json or other format)
b. A recommended way to create, manage and distribute these (Should we have one yaml file along with the OpenAPI layer 2 config file or should it be a set of yaml files split at the level of functionality [one for telemetry, one for reconcilliation ] etc.

Please contribute your views on the above and help guide this forward.

@ravi-prakash-v @sjthnrk @pramodkvarma @venkatramanm @binrange @faizmagic