[RM] Define forward compatibility policy/strategy for CNTT

[kedmison]

In discussions on the exceptions framework and how it would be implemented in practice, the topic of forward compatibility came up. Assumptions were being made about its use, but it is not explicitly documented or addressed in the RM or at a Governance or Technical Steering level.

This issue is to create a proposal on what the forward compatibility strategy is for CNTT. Once agreed to in the RM level, the proposal will be presented to the Tech Steering (and governance) levels if necessary for ratification.

This issue is also related to issue #1008 about backward compatibility strategy.

[kedmison]

Can we expect the VNF validation process to be sufficient in covering the validation that VNFs compliant to CNTT release 'x' can be run on a NFVI compliant to CNTT release 'x+1', assuming the NFVI is implementing backwards compatibility as per #1008? What gaps may exist in this assumption?

[kedmison]

apparently if I do the assignments too fast it unassigns people...

[petorre]

What gaps may exist in this assumption?

Depends on how much are apps coupled with the infrastructure+platform underneath and difference from X to X+1 release.
As differences between releases could be in RM Profiles, RA APIs, Exceptions, Certification and level of HW+SW details defined (generic Metrics or specific HW+SW configs), VNF Validated for X would not work on X+1 if:

1. Profile or APIs: Changed enough.
2. Exceptions: VNF must use (typically to reach required latency) Infrastructure Exception X.A not available in X+1. But it would work if VNF would optionally use Exception X.B (typically to run more cost effective). Similar like for Infrastructure can be for Platform services.
3. Certification and level of HW+SW details: X+1 HW+SW changes enough to create impact on NFVI performance characteristics or non-resilient VNF.

In PR #789 I propose generic framework of it with terminology.