Folks,

We are developing a YANG module for IEEE 1588, which is already a WG draft, 
please see https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07.
The base module defines a leaf node ‘two-step-flag’ and tags it as read-write, 
but some applications may want to remodel it as read-only.
The following is the codes I tried:
module ptp-augment {
    namespace "urn:example:ptp-augment";
    prefix ptp-ag;

    import ietf-ptp {
        prefix ptp;
    }

    augment /ptp:ptp/ptp:instance-list/ptp:default-ds {
           leaf two-step-flag {
             config false;
             type boolean;
             description
               "When set, the clock is a two-step clock; otherwise,
                the clock is a one-step clock.";
           }

}
}
The codes are validated to be right by http://www.yangvalidator.com/validator.
My question is: By using ‘augment’, two leaf nodes are defined successfully 
with the same YANG identifier but with different behaviors (also applicable to 
different types), does the new definition take the precedence and overwrite its 
old definition?
If the answer is yes, I will be glad to use this YANG feature, but perhaps it 
makes sense that a YANG compiler emits a warning that a new definition 
overrides an existing one.
Or, are two leaf nodes defined exactly? How do we distinguish them?

I also tried to use ‘deviation’ instead, the following is the codes:

     module ptp-deviations {
       namespace "urn:example:ptp-deviations";
       prefix ptpd;

       import ietf-ptp {
         prefix ptp;
       }

       deviation /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-flag {
           deviate replace {
             config false;
           }
       }

     }
The codes are also validated to be right by 
http://www.yangvalidator.com/validator.
My concern is, it cannot add new leaf nodes, so inevitably, another augment 
will always be used.

Any thoughts?

Thanks,
Yuanlong
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to