Yuanlong, Both approaches you describe are technically valid, but I don't like either of them much.
When you augment another "leaf two-step-flag" (from a different module) into the same parent you will end up with *both* leafs. They will have the same local-name, but different namespaces. For the average user, this will likely be highly confusing. I also don't like when standards bodies are playing with deviations. They are meant to be a last resort for implementors that are unable to follow a standard. If a standard requires the use of deviations, the value of the standard is diluted. And if an implementor would want to deviate from the standard, how would he deviate from the deviation? Instead, I'd propose that you model this as two leafs with different names, one config false and one config true. The config true leaf may depend on a feature. Btw, the current definition of the leaf two-step-flag defines no default value and does not declare the leaf mandatory. This opens up for an undefined case. If the two-step-flag is true, it's a two-step clock. If false, one-step. But what if an implementation doesn't return the two-step-leaf at all? There is no requirement per the YANG to return this leaf, and no language as to what that would mean. /jan > 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 > <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 > <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 > <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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
