[yang-doctors] Advise

[Mahesh Jethanandani <[e-mail]>]

Hi Fellow YANG experts,

I am reviewing the YANG model being published as part of draft-ietf-ccamp-flexigrid-yang <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang-09#section-6>  which is tightly tied to the YANG model in draft-ietf-ccamp-wson-yang draft, that Acee is reviewing.

I find the approach that this models and the approach other models have taken from the same WG as unusual, and I was wondering if there was any advise one could give on the design of the model. Maybe it is just me but when I see 80 augment statements in a model, something looks unusual.

The first thing that stood out for me was a presence container that was used to identify the type of topology the model supports, with nothing else in the container.

     augment "/nw:networks/nw:network/nw:network-types"
           + "/tet:te-topology" {
       description
         "Augment network types to define flexi-grid topology type.";
       container flexi-grid-topology {
         presence
           "Its presence identifies the flexi-grid topology type.";
         description
           "Introduce new network type for flexi-grid topology.";
       }
     }
That presence container is then used all over the model to support a ‘when’ statement:

       when "/nw:networks/nw:network/nw:network-types"
          + "/tet:te-topology/tet-flexig:flexi-grid-topology" {
         description
         "Augmentation parameters apply only for networks with
          flexi-grid topology type.";
       }
Could a simple ’type’ node have achieved the same purpose? Or maybe a ‘feature’ statement??

The rest of the model is a set of 80 augment statement, each augmenting a particular node in the topology defined by the ietf-te-topology model to add a few nodes to that branch of the topology, most of that being one node.

     augment /nw:networks/nw:network/nt:link/tet:te
               /tet:information-source-entry/tet:label-restrictions
               /tet:label-restriction/tet:label-end/tet:te-label
               /tet:technology:
       +--:(flexi-grid)
          +--ro flexi-n?   l0-types:flexi-n
Could this be better designed? As an operator, I would find configuration using this model to be very tedious. Not being an expert of Traffic Engineering (TE), I am not able to comment if this is how TE expects the configuration to happen, or if it this design that is flawed. Any advise?

Mahesh Jethanandani
[e-mail]