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