Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen <[e-mail]>]

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.