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
