Jan,

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

Cheers,
Yuanlong

From: Jan Lindblad [mailto:j...@tail-f.com]
Sent: Tuesday, April 10, 2018 4:58 PM
To: Jiangyuanlong
Cc: netmod@ietf.org
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
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

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

Reply via email to