Photonic Model review - Githubissues

I have some doubts regarding the modelling criteria applied in the Photonic Model, I will try summarize first and the explain each of the discussion points:

Structure of the model. Some augmentations inside the model are duplicated, why we do not merge duplicated augmentations by include all the content inside a single augmentation? Example:

 augment "/tapi-common:context/tapi-connectivity:connectivity-service/tapi-connectivity:end-point" {
        uses otsi-connectivity-service-end-point-spec;
        uses media-channel-service-interface-point-spec;
        description "none";
}

instead:

   augment "/tapi-common:context/tapi-connectivity:connectivity-service/tapi-connectivity:end-point" {
        uses otsi-connectivity-service-end-point-spec;
        description "none";
}
    augment "/tapi-common:context/tapi-connectivity:connectivity-service/tapi-connectivity:end-point" {
        uses media-channel-service-interface-point-spec;
        description "none";
}

media-channel duplicated definitions. As it is defined now, the model augments some of the constructs of the TapiCommon, TapiTopology and TapiConnectivityService models (owned-node-edge-point (NEP), connection-end-point (CEP), connectivity-service-end-point (CSEP) or service-interface-point (SIP)) with MediaChannel or OTSI specific parameters. This somehow invalids the use of "layer-protocol-name" and "layer-protocol-qualifiers" as a differentiator between the constructs. IMHO the value of the "layer-protocol-name" and "layer-protocol-qualifiers" shall be used to refer the layer at which a target NEP, CEP, CSEP, or SIP is operating and avoid duplications on the definitions regarding the layer. Example:
```
    grouping media-channel-connection-end-point-spec {
        container media-channel {
            config false;
            uses media-channel-properties-pac;
            description "none";
        }
        description "none";
    }
    grouping ots-connection-end-point-spec {
        container ots-media-channel {
            config false;
            uses media-channel-properties-pac;
            description "none";
        }
        description "none";
}
```
,in this case the same attributes are named as "media-channel" and "ots-media-channel" when the real difference is the layer at which the target CEP are operating, i.e., OMS or OTS repectivelly.

OTSI and MC defined in the same model: In the same line of the previous point, the OTSI and MC definitions extends the agnostic TAPI constructs (CEP, NEP or SIP), however there are not constraints on the values the "layer-protocol-name" and "layer-protocol-qualifiers" attributes can take on those constructs. For instance, if we are extending a CSEP with a layer-protocol-name=PHOTONIC_MEDIA and layer-protocol-qualifier=SPECTRUM_TYPE_NMC, there is not a constraint on using only:

+--rw nmc-config
   +--rw spectrum
      +--rw upper-frequency?   uint64
      +--rw lower-frequency?   uint64
      +--rw frequency-slot
         +--rw central-frequency
         |  +--rw grid-type?                grid-type
         |  +--rw adjustment-granularity?   adjustment-granularity
         |  +--rw central-frequency?        uint64
         |  +--rw channel-number?           uint64
         +--rw spectral-width?      uint64
         +--rw slot-width-number? uint64

, and not:

+--rw otsi-config
|  +--rw central-frequency
|  |  +--rw grid-type?                grid-type
|  |  +--rw adjustment-granularity?   adjustment-granularity
|  |  +--rw central-frequency?        uint64
|  |  +--rw channel-number?           uint64
|  +--rw application-identifier
|  |  +--rw application-identifier-type?   application-identifier-type
|  |  +--rw application-code?              string
|  +--rw modulation?                         modulation-technique
|  +--rw laser-control?                      laser-control-type
|  +--rw transmit-power
|  |  +--rw total-power?              decimal64
|  |  +--ro power-spectral-density?   decimal64
|  +--rw total-power-warn-threshold-upper?   decimal64
|  +--rw total-power-warn-threshold-lower? decimal64

I am not sure if the aim of this specific case is to allow including the definition of the signal (OTSI) togheter with the Media-Channel, for a given CS between CSEPs at the NMC layer, if this is the case maybe the next example can ilustrate this better:

In the case of the CEP's augmentations included in the Photonic-Media model, there are defined at the same level:

  augment /tapi-common:context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:connection-end-point:
+--ro otsi-termination

  augment /tapi-common:context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:connection-end-point:
+--ro media-channel

  augment /tapi-common:context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:connection-end-point:
+--ro ots-media-channel

, without existing any constraint which limits the usability of these parameters according to the layer to which the augmented CEP belongs to.

I might missed part of the discussion during the definition but I don't really get the point on merging photonic-media and otsi models.

SPECTRUM_TYPE type-definitions. There are two things which I think that there should be revised in the model:

This group of identities are defined from the base: tapi-common:LAYER_PROTOCOL_QUALIFIER; which means that they can be used to define the layer at which several TAPI constructs operate (NEP,CSEP,CEP or SIP). I wonder which is the reason to include the word "SPECTRUM" instead simply left the name of the layer defined by the ITU-T, such OTSi, OTSiA...

Second comment is that right now this SPECTRUMTYPE* identities are used only in:

    typedef spectrum-type {
        type identityref {
            base SPECTRUM_TYPE;
        }
        description "none";
    }

, and the spectrum-type is not even used.

Open-Network-Models-and-Interfaces-ONMI / TAPI

Photonic Model review #352