The configRev attribute in LPL has presence condition AC_LN0_M which indicates mandatory for LLN0, else optional.
But in semantic definition of configRev, it is used to identify configuration of a logical device, and so expected only in LLN0. So following this definition, it is not possible in other LN.
Proposal
There are two possibilities to fix this problem:
- The configRev could have the presence condition AC_LN0_EX to not allow it outside LLN0
- the semantic could be changed to allow it in other LN.
The second possibility should be more inline with the other revision trackers valRev and paramRev which could be used anywhere.
A rule could be added to allow management only at LD level which centralize configuration revision when it is not defined in lower LN
Discussion
Created
Status
05 Jan 17
In Force (green)
Final proposal is as below suggested by Thierry
12 Oct 16
Ballot Period
Note that Part 6, Clause 9.3.2, must then be updated as well, as it may be misleading (it explicitly mentions LLN0.NamPlt.configRev, not for any LN).
15 Mar 16
Discussion (red)
The semantic table also states:
"Also the semantics of configRev concerning other LNs is left to the user."
So, the usage of configRev shall not be limited to LLN0.
The sentence has disapeared in the current CDV Ed2.1 draft but obviously needs to be re-added.
Proposal:
'LLN0.NamPlt.configRev' respectively 'LN.NamPlt.configRev' uniquely identifies the configuration of a logical device instance respectively logical node instance. 'LLN0.NamPlt.configRev' respectevely 'LN.NamPlt.configRev' has to be changed at least on any semantic change of the data model of the logical device respectively logical node that may affect interpretation of the data by the client. How this is detected and performed is left to the user.
For further details, see Annex C.