Dear Kristian, Brad and Siva, I believe we need both. A name and an ID for a network node and its components. The name should be in terms of network node assignable by the operator while the component names (such as interface or line card names) should be assigned by the network operating system. The id of the network node and the components should be something which a manufacturer assigns. Similar to a serial number.
This is reflected in this work https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08#section-3.1 at IVY. Looking at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-18, I see that the typedef host is now a fully qualified domain name and there is a new host-name typedef. typedef host-name { type domain-name { length "2..max"; pattern '[a-zA-Z0-9\-\.]+'; } description "The host-name type represents (fully qualified) host names. Host names must be at least two characters long (see RFC 952) and they are restricted to labels consisting of letters, digits and hyphens separated by dots (see RFC1123 and RFC 952)."; reference "RFC 952: DoD Internet Host Table Specification RFC 1123: Requirements for Internet Hosts -- Application and Support"; } typedef host { type union { type ip-address; type host-name; } description "The host type represents either an IP address or a (fully qualified) host name."; } Best wishes Thomas From: Kristian Larsson <[email protected]> Sent: Saturday, September 20, 2025 2:03 PM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [NMOP] Unique device identifiers Be aware: This is an external email. If hostname is underspecified, then that is solved by tightening the spec not be entirely shifting to an artificial ID like UUID. hostname is a natural and assignable ID (we, as the network operators decide what it should be and assign it, not the equipment / device vendor / something else / generated). Overall in the network space, the vast majority of keys and identifiers are user assigned, which gives a certain way of working. I know that when I set hostname=foo on a device and later receive telemetry for device=foo, then I can connect the dots. I think this is a very good property. It enables stateless declarative automation systems that can compute the entire configuration based on abstract intent. Contrast it with many cloud APIs where you create something and you receive the UUID as a return value. Now you must keep track of this ID, if not, you loose track of the instance. UUID is no panacea. If you replace or reset equipment, it tends to be reset and then you have to deal with the problem of connecting data with UUID=1 to UUID=2 because the same logical node in the network had multiple UUID throughout its lifetime. Kind regards, Kristian. On 20 Sep 2025, at 11:49, [email protected]<mailto:[email protected]> wrote: Dear Siva, Welcome to the NMOP mailing list. Its great that YANG Message Broker Consumer (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-08#section-4.6) implementors are joining the NMOP mailing list. Indeed you are raising a very valid point on network node and network node component identification. The IVY (Network Inventory YANG) working group has a key document https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08#section-3.1 which defines unique identifiers for network nodes and network node components generically. With https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#section-3.4.1 at the NETCONF (Network Configuration) working group we have an Extensible YANG Model for YANG-Push Notifications which includes the hostname. As you are well aware, the hostname in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#section-5.1.2 leaf hostname { type inet:host; description "The hostname of the network node according to [RFC1213]. This value is usually configured on the node by the administrator to identify the node in the network uniquely."; } Using the typdef host from ietf-inet-types.yang defined in RFC 6991 (see below). This in turn has typdefs ip-address and domain-name. Where ip-address has typedefs in ipv4-address and ipv6-address. Considering all these combinations and the ambiguous semantics of domain-name, fully qualified vs not, shows the Internet old problem that the hostname is not a real unique identifier for a network node. With https://datatracker.ietf.org/doc/html/draft-ietf-nmop-rfc3535-20years-later-00#section-4.10 at NMOP we are raising the point that the Network Telemetry RFC 9232 protocols developed at IETF don't have a common level of entities. I believe what you are saying is that one of the items should be the UUID (https://datatracker.ietf.org/doc/html/rfc9562) of the network node as defined in https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08#section-3.1 and for YANG-Push, as one of the Network Telemetry applications, a YANG-Push header extensionhttps://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#appendix-B should be proposed. Correct? I cross posted to the IVY and NETCONF mailing lists to see wherever this makes sense and wherever others have interest. To the draft-ietf-ivy-network-inventory-yang authors. I see that implementation status section being empty. Are there already any implementations? I published today a new document where the hostname among others is used to generate a unique YANG indexhttps://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-message-broker-message-key-00#section-3.1. Here the uniqueness of the hostname in the YANG-Push notifications are coming into play as well. Therefore, your are raising a very valid, Internet old problem. As you see, the IETF community is moving at several fronts forward to resolve that problem. Looking forward for comments and feedback. With best wishes Thomas As a side note: Another related approach are COSE Signatures https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance which proposing extensions to the data manifest and the "ietf-yp-notification" https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance-01#section-4.2.2. typedef host { type union { type inet:ip-address; type inet:domain-name; } description "The host type represents either an IP address or a DNS domain name."; } typedef ip-address { type union { type inet:ipv4-address; type inet:ipv6-address; } description "The ip-address type represents an IP address and is IP version neutral. The format of the textual representation implies the IP version. This type supports scoped addresses by allowing zone identifiers in the address format."; reference "RFC 4007<https://datatracker.ietf.org/doc/html/rfc4007>: IPv6 Scoped Address Architecture"; } typedef ipv4-address { type string { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' + '(%[\p{N}\p{L}]+)?'; } description "The ipv4-address type represents an IPv4 address in dotted-quad notation. The IPv4 address may include a zone index, separated by a % sign. The zone index is used to disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index number or the name of an interface. If the zone index is not present, the default zone of the device will be used. The canonical format for the zone index is the numerical format"; } typedef ipv6-address { type string { pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + '(%[\p{N}\p{L}]+)?'; pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + '(%.+)?'; } description "The ipv6-address type represents an IPv6 address in full, mixed, shortened, and shortened-mixed notation. The IPv6 address may include a zone index, separated by a % sign. The zone index is used to disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index number or the name of an interface. If the zone index is not present, the default zone of the device will be used. The canonical format of IPv6 addresses uses the textual representation defined in Section 4 of RFC 5952<https://datatracker.ietf.org/doc/html/rfc5952#section-4>. The canonical format for the zone index is the numerical format as described in Section 11.2 of RFC 4007<https://datatracker.ietf.org/doc/html/rfc4007#section-11.2>."; reference "RFC 4291<https://datatracker.ietf.org/doc/html/rfc4291>: IP Version 6 Addressing Architecture RFC 4007<https://datatracker.ietf.org/doc/html/rfc4007>: IPv6 Scoped Address Architecture RFC 5952<https://datatracker.ietf.org/doc/html/rfc5952>: A Recommendation for IPv6 Address Text Representation"; } typedef domain-name { type string { pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '|\.'; length "1..253"; } description "The domain-name type represents a DNS domain name. The name SHOULD be fully qualified whenever possible. Internet domain names are only loosely specified. Section<https://datatracker.ietf.org/doc/html/rfc1034#section-3.5> 3.5 of RFC 1034<https://datatracker.ietf.org/doc/html/rfc1034#section-3.5> recommends a syntax (modified in Section<https://datatracker.ietf.org/doc/html/rfc1123#section-2.1> 2.1 of RFC 1123<https://datatracker.ietf.org/doc/html/rfc1123#section-2.1>). The pattern above is intended to allow for current practice in domain name use, and some possible future expansion. It is designed to hold various types of domain names, including names used for A or AAAA records (host names) and other records, such as SRV records. Note that Internet host names have a stricter syntax (described in RFC 952<https://datatracker.ietf.org/doc/html/rfc952>) than the DNS recommendations in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. The description clause of schema nodes using the domain-name type MUST describe when and how these names are resolved to IP addresses. Note that the resolution of a domain-name value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence can either be defined explicitly or may depend on the configuration of the resolver. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase US-ASCII characters. Internationalized domain names MUST be A-labels as per RFC 5890<https://datatracker.ietf.org/doc/html/rfc5890>."; reference "RFC 952: DoD Internet Host Table Specification RFC 1034<https://datatracker.ietf.org/doc/html/rfc1034>: Domain Names - Concepts and Facilities RFC 1123<https://datatracker.ietf.org/doc/html/rfc1123>: Requirements for Internet Hosts -- Application and Support RFC 2782<https://datatracker.ietf.org/doc/html/rfc2782>: A DNS RR for specifying the location of services (DNS SRV) RFC 5890<https://datatracker.ietf.org/doc/html/rfc5890>: Internationalized Domain Names in Applications (IDNA): Definitions and Document Framework"; } From: Sundaravadivel, Sivakumar <[email protected]<mailto:[email protected]>> Sent: Monday, September 15, 2025 5:22 PM To: [email protected]<mailto:[email protected]> Subject: [NMOP] Unique device identifiers Be aware: This is an external email. Dear Team, My name is Sivakumar, and I am an Architect of BPUAA, an NMS solution. While reviewing recent documents on "Netconf notif envelope," I came across the following information that Devices are uniquely identified based on Sysname. I wanted to bring the following to your notice. Based on my experience, I would like to highlight a specific scenario, one of our customer equipment's Sysname retrieved over snmp by our system did not match with the name retrieved by Netconf used by another system, with which we had to integrate for certain information. Basically, one of the two had an FQDN while the other had just the name. And also, my understanding is that sysnames can be modified from the device. In order to ensure that data continuity is not lost when the sysname changes, or for effective integration across different solutions, it appears the envelope should have more than Sysname information to handle various lookups. Please let me know if this is a valid concern. Regards, Sivakumar Sundaravadivel -- Nmop mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
