Re: [netmod] Using augment to overwrite an existing definition?

[Jiangyuanlong <[e-mail]>]

Jan,

Thank a lot for your prompt feedback. Please see my comments inline.

Cheers,
Yuanlong

From: Jan Lindblad [mailto:[e-mail]]
Sent: Tuesday, April 10, 2018 4:58 PM
To: Jiangyuanlong
Cc: [e-mail]
Subject: Re: [netmod] Using augment to overwrite an existing definition?

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.
[Yuanlong] Agreed. My first guess was also to use namespaces.

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?
[Yuanlong] we are not targeting to use these codes in our standards, but trying to simulate some possible derived implementations. In the past, there was no unified MIB standards for IEEE 1588, this resulted in very diversified  practices in its management.

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.
[Yuanlong] we will consider this option together with the necessary alignment with IEEE 1588 information model.

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.
[Yuanlong] My understanding is 1588 implementation will initialize this value itself, not resort to configuration (from IEEE 1588-2008). But that’s exactly why the existing 1588 implementations may not internetwork with each other. We will consider this too.

/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.
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod