On Tue, Apr 25, 2023 at 11:52:32AM +0000, Kent Watsen wrote:
>
> 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?
Which merge fails? If the mac-addr in running does not match the
hardware (and it has to match according to the model), then the
interface config simply will not be applied.
> 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?
>
One of the nice properties of the original NC design was that it
exposes an API that hides certain complexities from the clients. We
now see proposals to expose data nodes controlled by "the system" and
data nodes that can only modified if certain conditions are true etc.
We are heading back to the SNMP world where you had to send sequences
of set-requests in the order expected by the agent in order to get a
job done.
/js
--
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
