There are some principles behind the design of NC and YANG and I think we should not mess around with them. Validation in NC and YANG is against the data model, not against the resource present and/or implementation constraints.
If you want entirely different behaviour, I suggest you submit a proposal for a new management protocol and language instead of eroding principles on which NC and YANG has been built. /js On Wed, Apr 26, 2023 at 09:13:25AM +0000, Fengchong (frank) wrote: > Hi Jurgen, > > If you replace a linecard, you have to create some new interfaces in system, > if you want to configure them. You don't need to replace the value of leaf. > > Modifying the value of if-type has no value for users(uses have to double > check the result, comparing between running/intended with operational > datastore, even if the configuration is valid), this behavior should not be > encouraged. > > > > -----邮件原件----- > 发件人: Jürgen Schönwälder [mailto:jschoenwaelder@constructor.university] > 发送时间: 2023年4月26日 14:45 > 收件人: Fengchong (frank) <frank.fengch...@huawei.com> > 抄送: Kent Watsen <kent+i...@watsen.net>; maqiufang (A) > <maqiufang1=40huawei....@dmarc.ietf.org>; netmod@ietf.org; Jan Lindblad > (jlindbla) <jlind...@cisco.com> > 主题: Re: 答复: [netmod] Comments on draft-ma-netmod-immutable-flag-06 > > I am not sure I follow. If I replace the line card, I may have to update the > type of the interface config. Why would this be disallowed? > > In the NC world, config is applied to resources. Validation is against the > data model, not against the resources currently present on a system. See for > example RFC 6241 section 8.6.1. with starts with: > > Validation consists of checking a complete configuration for > syntactical and semantic errors before applying the configuration to > the device. > > This is why we have the notion of <running> -> <intended> -> <applied>. > Initially, we did not expose <applied> but operationally the possible > difference between <running> and <applied> is important enough that we > started to expose it. But the point here is that the resources available do > not influence whether <running> is valid. A valid configuration satisfies the > data model constraints, it does not necessarily satisfy the resource > constraints. > > /js > > On Wed, Apr 26, 2023 at 01:36:37AM +0000, Fengchong (frank) wrote: > > Hi Kent, > > Some nodes that are originally read-only have to appear in running > > because they are referenced by other configurations. > > For example, the type of interface, many other configurations may > > reference it. > > Just as: > > container Ethernet-related { > > when ../type = 'ethernet' > > .... > > } > > So the leaf 'type' have to act as a configuration node to make the > > running datastore valid. But in fact, the value of leaf 'type' should not > > be changed. > > So it's marked with 'immutable' is reasonable. If someone try to modify > > it, reporting error from server should be acceptable. > > > > > > > > -----邮件原件----- > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen > > 发送时间: 2023年4月25日 19:53 > > 收件人: Jürgen Schönwälder <jschoenwaelder@constructor.university> > > 抄送: maqiufang (A) <maqiufang1=40huawei....@dmarc.ietf.org>; > > netmod@ietf.org; Jan Lindblad (jlindbla) <jlind...@cisco.com> > > 主题: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06 > > > > > > Hi Jürgen, > > > > > My assumption so far is that an interface configuration is matched > > > against hardware and it is applied if there is matching hardware. In > > > other words, if an edit makes the interface configuration not match > > > the hardware anymore, then the config is simply not applied anymore > > > and the interface is left unconfigured. (The same would happen if > > > you replace an interface with another that does not match the > > > current > > > config.) The idea that an interface configuration becomes partly > > > immutable once it is applied to a matching physical interface is not > > > really reflecting how I understand the design of N/Y. > > > > My understanding is the same, so I assume there's a nuance in the detail. > > Let's use this example: > > > > list interface { > > key name; > > immutable true; // the whole 'interface' object is immutable > > leaf name { > > ... > > } > > leaf description { > > Immutable false; // client may provide a description > > ... > > } > > leaf mac-addr { // H/W provided. Normally CF, but for some reason > > is > > mandatory true; // promoted to CT (for a 'must' or 'when' > > expression?) > > ... // Please don't nitpick the validity of > > the example, I could > > } // construct a similar example using > > built-in certs or keys. > > } > > > > Now say the client preconfigures: > > > > { > > "name": "sd3" > > "description": "uplink to closet-3", > > "mac-addr": "000000" // real address unknown, so a fake one used > > } > > > > Now the card is inserted and "sd3" appears as: > > > > { > > "name": "sd3" > > "mac-addr": "1234567" > > } > > > > The merge fails because the client's mac-addr doesn't match the real one? > > > > Ideally the immutable nodes (other than the keys) would NOT have to appear > > in <running>, but they do because "mandatory true"? > > > > > > > Also the notion > > > of immutable data in candidate, which is rather a scratchpad to > > > assemble bigger changes, seems odd to me. > > > > I had a similar reaction but, if <candidate> can be validated, doesn't it > > follow that the immutable nodes need to be copied into it as well? > > > > > > > /js > > > > K. > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://constructor.university/> -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
