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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
