[netmod] Alarm Threshold type modelling for DWDM-IF

[Roberto Manzotti <[e-mail]>]

Netmod and CCAMP WGs,

I'm writing on behalf of all co-authors and contributors of 
draft-ietf-ccamp-dwdm-if-param-yang document looking for advice on how 
to handle the configuration of alarm related threshold crossing value on 
dwdm interfaces in future extension of the model.

In our current revision of the draft we are managing the definition of 
the tca-type attribute using an identityref that defines all the 
possible DWDM monitoring parameters that can create threshold crossing 
alarms. This is a snip with an example of the current identity

>   identity wdm-if-tca-type {
>     description
>       "The different types of Threshold Crossing Alert (TCA's)
>        for DWDM Interfaces. Any augmentation of the list of
>        tca-type MUST use this identity as base";
>   }
>
>   identity tx-power-tca {
>     base wdm-if-tca-type;
>     description
>       "The Interface Transmit power TCA";
>   }
>
>   identity rx-power-tca {
>     base wdm-if-tca-type;
>     description
>       "The Interface Receive power TCA";
>   }
> ....

As part of the input received from the dwdm pluggable transceivers gap 
analysis, we are adding a large set of monitoring attributes.
By adding these additional monitoring points, we also need to align the 
list of identities for the threshold crossing alarms, to support alarm 
configuration also for new set of attributes. This actually highlighted 
a maintenance issue in the model. For future extension or augmentation 
that adds monitoring points in the interface, also the wdm-if-tca-type 
identity will need to be extended accordingly.

To avoid this double edit maintenance we tried to model the tca-type as 
an instance-identifier pointing to the interface monitoring attribute 
for which the threshold is defined:

>   grouping wdm-if-tca-thresholds {
>     description
>       "Thresholds for TCA's";
>     leaf tca-type {
>       type instance-identifier {
>         require-instance false;
>       }
>       must 'count(deref(.)/..
>                   | current()/../../..) = 1' {
>         error-message
>           "The TCA type must reference an attribute of the
>            current wdm-interface";
>       }
>       mandatory true;
>       description
>         "XPath identifying the performance-measurement attribute
>          monitored by the TCA. The referenced attribute MUST be a
>          leaf directly contained in the current wdm-interface.
>          Please note that the must statement cannot verify the
>          existence of the node in the operational datastore, since
>          it is not accessible from the config datastore where this
>          leaf is defined. Validation of the existence of the
>          attribute in the operational datastore SHALL be done by
>          the server implementation";
>     }
> .....

While this allows a simpler future maintenance of the model, it has the 
drawback that the instance-identifier Xpath must be defined as absolute 
path. The following snippets provide a json examples for an identityref 
implementation and for an instance-identifier based implementation.

Json with identityref:
>           "wdm-if-tcas": {
>             "number-of-tcas-supported": 10,
>             "tca-list": [
>               {
>                 "tca-id": "rx-channel-power-low",
>                 "tca-type": "rx-power-tca",
>                 "tca-name": "Low-RX-Power",
>                 "raise-threshold": "-13.0",
>                 "clear-threshold": "-12.0"
>               }
>             ]
>           }, 


Json with Xpath:
>           "wdm-if-tcas": {
>             "number-of-tcas-supported": 10,
>             "tca-list": [
>               {
>                 "tca-id": "rx-channel-power-low",
>                 "tca-type": 
> "/ietf-interfaces:interfaces/interface[name='Trunk-0/1']/ietf-wdm-interface:wdm-interface/rx-channel-power",
>                 "tca-name": "Low-RX-Power",
>                 "raise-threshold": "-13.0",
>                 "clear-threshold": "-12.0"
>               }
>             ]
>           },

What would be the preferred option for defining this tca-type leaf that 
identify the monitoring measure subject of the threshold?:
- Option 1: keep the identityref with its double edit maintenance issue 
but a more simple and readable info in the output data
- Option 2: move to the instance-identifier Xpath with its long full 
path in the data output thereby removing the identity maintenance in the 
model
- Option 3: any other possible suggested solution is also welcome.

Thanks for your comments/suggestion.
Best Regards
Roberto and all the co-authors of the draft