Re: [Netconf] YangPush now

[Kent Watsen <[e-mail]>]

>>1. make the augmentation of a "notif" model mandatory (see the '+' lines
>>   below), to ensure that there is always something more than just a name
>>   being configured per receiver.
>>
>>      container receivers {
>>        list receiver {
>>          key "name";
>>          min-elements 1;
>>          leaf name {
>>            type string;
>>          }
>>   +      choice transport {
>>   +        mandatory true;
>>   +        description
>>   +          "Defines the transport-specific configuration data
>>   +           for the selected transport.";
>>   +      }
>
> The notion of an empty mandatory choice really stretches the definition
> of YANG Conformance.  This says you cannot possible implement the SN
> module without some other module augmenting it.

Correct.


> Yet there is no way in YANG (besides import) to say the module bar
> needs to be present if module foo is present.

Why is this a problem?  Servers will do the right thing, and the draft
is clearer for it.


>> 2. modify netconf-notif to augment-in the ietf-netconf-server grouping:
>>
>>  module ietf-netconf-notifications {
>>    prefix nn;
>>    import ietf-netconf-server { prefix ncs; }
>>    import ietf-subscribed-notifications { prefix sn; }
>>
>>    // define a *local* netconf-server instance
>>    container "netconf-server" {
>>      uses "ncs:netconf-server-grouping" {
>>        // prune out the "listen" subtree
>>        refine "listen" {
>>          if-feature "never-supported-feature";
>>        }
>>        // disable dependency on the "call-home" feature
>>        refine "call-home" {
>>          if-feature "true"; // needed? (see 7950, s7.20.2, P3)
>>                             // valid? (unsure)
>>        }
>>      }
>>    }
>
> The use of constant (true or false) values for if-feature are 
> not supported

Wasn't sure about that. Is there another way to achieve the same?


> and the use of dummy features that are always supposed to be a
> constant value seems to abuse the intent of YANG features.

This was discussed on the NETMOD list in the last few days.  See
the "removing a node from a grouping" thread.  I agree that it's
not ideal, but it appears to be legal.   Just filed yang-next#48
to track this for future improvement.


> Refactoring the groupings would be the cleanest solution.

Not always possible, such as in this case.

 
>>    // add leafref to above locally-configured call-home instances
>>    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>>      leaf netconf-endpoint {
>>        type leafref {
>>          path "/nn:netconf-server/nn:call-home/nn:netconf-client/nn:name";
>>        }
>>      }
>>    }
>>  }
>>
>>
>> 3. do the identical thing to the restconf-nofif draft:
>>
>>  module ietf-restconf-notifications {
>>    prefix rn;
>>    import ietf-restconf-server { prefix rcs; }
>>    import ietf-subscribed-notifications { prefix sn; }
>>
>>    // define a *local* restconf-server instance
>>    container "restconf-server" {
>>      uses "rcs:restconf-server-grouping" {
>>        // prune out the "listen" subtree
>>        refine "listen" {
>>          if-feature "never-supported-feature";
>>        }
>>        // disable dependency on the "call-home" feature
>>        refine "call-home" {
>>          if-feature "true"; // needed? (see 7950, s7.20.2, P3)
>>                             // valid? (unsure)
>>        }
>>      }
>>    }
>>
>>    // add leafref to above locally-configured call-home instances
>>    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>>      leaf restconf-endpoint {
>>        type leafref {
>>          path "/rn:restconf-server/rn:call-home/rn:netconf-client/rn:name";
>>        }
>>      }
>>    }
>>  }
>
>
> The problem with identityref leafs is that the client has no clue 
> what the server will support. The problem gets much worse for the
> client dealing with a mandatory empty choice.

How so?  If the server implements the notif module, the augment
shows up, right?


> Andy

Kent // contributor