Hi Quifang, Jason, I've not thought deeply about this, but I would have thought that if a client configured an interface (e.g., perhaps an L3 tunnel interface) without specifying the interface type, but where the type is inferable from the name, then it would seem reasonable for that interface type to be created by the system and then put into system.
The client cannot delete the interface's type leaf in system, but if they delete the interface resource, then I think that the device is allowed to remove the associate type leaf from system. But perhaps this goes against the current RFC text. Kindi regards, Rob From: maqiufang (A) <[email protected]> Date: Friday, 16 January 2026 at 09:48 To: Jason Sterne (Nokia) <[email protected]>, [email protected] <[email protected]> Subject: [netmod] Re: mandatory 'type' leaf in interface model, but not in running or intended in system-config-18 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]
