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
