A few thoughts here: 1) Only <intended> is subject to validation. Related, the "template requirements" landed on a desire for templates in <running> (really, think <candidate>) are lightly validated. For instance, that a node, if supplied, is of the right type, but not requiring a node to be supplied, even if "mandatory true".
2) It follows that <system> MUST be "by itself" valid, as it is not required that <running> contain any data in order for <intended> to be valid. 3) It follows that <running> MAY be "by itself" valid, as it is assumed that <running> will become complete/valid, once merged with <system> to create <intended>. Kent > On Jan 16, 2026, at 4:48 AM, maqiufang (A) > <[email protected]> wrote: > > Hi, Jason, all, > > The subtle difference is that, the system-config B.2 example uses the > fictional interface data model defined in Appendix B > (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-18#appendix-B) > which doesn’t define “type” leaf as mandatory. So the absence of type node > will not render <running>/<intended> become invalid. > > To think further, if we follow the interface model defined in 8343, suppose > the interface does not physically exist, yet a client creates an interface > entry in <running>, will a sever generates a type value in <system>? > Perhaps the system will generate a value based on the description you > provided below, but I don't think it should appear in <system>. As <system> > only defines the non-deletable configuration, while when the interface entry > is cleared, it is weird to me if <intended> still holds the interface entry > with a type value. I'm less certain if it will be generated in <running> > (although this goes against the principle that the client has control over > <running>), but it seems that if it is not generated in <running>, then > client would need to explicitly provide it. > > But things might be different if the interface card is physically available, > the system detects the hardware and generates a type value (that value could > be immutable) for the interface, okay if client creates an interface entry > without the type value, as the merging of <system> and <running> which > results in the contents of <intended> will be subject to validation. > > Best Regards, > Qiufang > From: Jason Sterne (Nokia) [mailto:[email protected]] > Sent: Friday, January 16, 2026 7:37 AM > To: NETMOD WG <[email protected]> > Subject: [netmod] mandatory 'type' leaf in interface model, but not in > running or intended in system-config-18 > > Hi all, > > The ‘type’ leaf in the interfaces model is a funny beast: > https://datatracker.ietf.org/doc/html/rfc8343 > > It is marked as mandatory and the description says this: > > When an interface entry is created, a server MAY > initialize the type leaf with a valid value, e.g., if it > is possible to derive the type from the name of the > interface. > > That’s always been a behavior that seemed ‘iffy’ to me (the client would then > read back something different from what they sent, i.e. the client isn’t the > master/owner of the config in that case). > > In any case, in the latest system-config draft > (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-18), > section B.2 doesn’t have that leaf in the running or the intended. It makes > running invalid if it isn’t in there. We’ve talked about validity of running > in the context of template expansion before, but for something basic like > ‘mandatory’ don’t we expect that to be enforced in running? > If not – then it should at least be showing up in intended? (but strange to > have it show up there IMO and not running) > > Jason (he/him) > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
