note that E2APv2.0 has the related messages changed and mandates configurartion transfer in E2 Setup as well. We need to update the original design a bit. If we now start working on E2APv2.0, I think it makes sense not to bother the E2APv1.1 messages definitions.

originally discussed in RIC-174

E2AP 1.1 additional ASN.1 IEs (as compared to E2AP1.0) were all added as optional. So, from that point of view it’s backwards compatible. E.g., configuration transfer in E2 Setup has an optional “E2 Node Component Configuration Update List”. So, E2 nodes that only support E2APv1.0 would not send it. As would E2 nodes with E2APv1.1 that do not support configuration transfer. So basically – as always with optionality – things become more complex. E2APv.1.1 RIC must support E2 nodes that transfer configuration and those that do not. Similar for the RAN Function OID addition (RIC-640).

Furthermore, note that a proposal (approval - if coming - will take months) currently discussed in WG3 (“RSY-2020.10.23-WG3-CR-0001-E2AP Spec v1.01 Corrections-v11_TrackChanges.docx”) would remove the optionality and make things mandatory. Which is a backwards incompatible change. So on OSC side we might not want to invest too much time into the cases where this is not included, e.g., with some hardcoding that is later changed to error cases. Supporting two E2AP versions that are not backwards compatible (which would also be a possibility) add complexity that is not justified. In the stage we are in, it's easier to adapt all components (in RIC and outside of RIC) to the newer version.