Thank Per for the clear analysis. Since the current YANG RFC7950 does not have a formal way to specify the overriding rule, I agree that the best way is to remove the default statements from "level-1" and "level-2", as Per, Martin, and Rob suggested.
Regards, - Xufeng [Forwarding Per's reply to LSR mailing list] On Sun, Jun 9, 2019 at 1:08 PM Per Hedeland <[email protected]> wrote: > On 2019-06-09 17:28, Juergen Schoenwaelder wrote: > > > > YANG does not have 'levels'. This seems to be an ISIS specific > > question you should ask on the ISIS list. > > AFAIK, this list is not restricted to discussions of what YANG "is" or > "has", but also covers (at least) how YANG can be used, and what the > semantics of various YANG usage patterns are. I think there is a > generic YANG question in the problem described, and possibly even an > indication that the wording in the spec is overly restrictive. > > > On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote: > >> In Section 2.3. and many other locations, the current IS-IS model > applies > >> the parameter overriding rule as below: > >> > >> [Quote]: > >> > >> 2.3 < > https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2..3 > >. > >> Per-Level Parameters > >> > >> > >> Some parameters allow a per level configuration. In this case, the > >> parameter is modeled as a container with three configuration > >> locations: > >> > >> o a top-level container: corresponds to level-1-2, so the > >> configuration applies to both levels. > >> > >> o a level-1 container: corresponds to level-1 specific parameters. > >> > >> o a level-2 container: corresponds to level-2 specific parameters. > >> > >> +--rw priority > >> | +--rw value? uint8 > >> | +--rw level-1 > >> | | +--rw value? uint8 > >> | +--rw level-2 > >> | +--rw value? uint8 > >> > >> Example: > >> > >> <priority> > >> <value>250</value> > >> <level-1> > >> <value>100</value> > >> </level-1> > >> <level-2> > >> <value>200</value> > >> </level-2> > >> </priority> > >> > >> An implementation SHOULD prefer a level specific parameter over a > >> level-all parameter. As example, if the priority is 100 for the > >> level-1, 200 for the level-2 and 250 for the top-level > configuration, > >> the implementation should use 100 for the level-1 and 200 for the > >> level-2. > >> > >> [End of Quote] > >> > >> > >> In the model, all three value leaves above have a default statement > >> default 64 , which brings up my question for the following example: > > So, to give an actual YANG snippet for this example, it would be > > container priority { > leaf value { > type uint8; > default 64; > } > container level-1 { > leaf value { > type uint8; > default 64; > } > } > container level-2 { > leaf value { > type uint8; > default 64; > } > } > } > > >> <priority> > >> <value>250</value> > >> <level-1> > >> <value>100</value> > >> </level-1> > >> </priority> > >> > >> > >> The user does not provide a configured value for level-2. According to > >> Section 7.6.1. of RFC7950, because the default value is in use, "the > server > >> MUST operationally behave as if the leaf was present in the data tree > with > >> the default value as its value". This means the priority value for > level-2 > >> will be 64 (the default value), so the value 250 can never take effect > as > >> intended in the above quoted Section 2.3. > > Obviously there is at least a deficiency in the description, since it > makes no sense with your (justifiable) interpretation. I think it is > clear that the *intent* is that the value 250 should take effect for > level-2 in this case (and I think that this is a very valid design). > That intent could have been made clear by saying "if the priority is > *configured* as 100" instead of just "if the priority is 100", since > the "is" applies equally well to a "default value in effect" and a > configured value. > > But this would seem to violate the statement in RFC 7950, since it > actually does say that the value 64 MUST be used for level-2 in this > case. Maybe it should have some conditional like "unless otherwise > specified" or something - but IMHO it's entirely reasonable that the > "overall system" behaves differently depending on whether the value > for a specific leaf is actually configured or is just a > "default-in-effect". > > Then again, in this case one could question what the point of the > default values for the level-1 and level-2 leafs is. Removing them > would mean that without values configured, they would use the > "toplevel" value, whether default or configured - and since the > defaults *in this case* are all the same, it would amount to the > exactly the intent I assume above, but without any violation of the > 7950 statement. > > However with different defaults, it is not as straightforward - say > e.g. > > container priority { > leaf value { > type uint8; > } > container level-1 { > leaf value { > type uint8; > default 32; > } > } > container level-2 { > leaf value { > type uint8; > default 64; > } > } > } > > IMHO, it would make perfect sense (assuming of course that it is > documented) for the system to in this case behave like > > configured "toplevel" configured level-2 use for level-2 > > 1) nothing nothing 64 > 2) 250 nothing 250 > 3) irrelevant 128 128 > > And then the case 2) would again seem to violate the 7950 statement. > > --Per > > >> Is my understanding correct? > >> > >> > >> Since this is a generic question, I am CC ing NETMOD WG too. > >> > >> > >> Thanks, > >> > >> - Xufeng > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
