Hi Frank,
> On Apr 25, 2023, at 9:36 PM, Fengchong (frank) <frank.fengch...@huawei.com> > 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. I take this as an agreement to the below discussion. Thanks, Kent > > > > -----邮件原件----- > 发件人: 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod