I-D list for Network Inventory YANG RSS Feed

A Base YANG Data Model for Network Inventory

2026-10-14T20:54:31.081934+00:00

Waiting on authors to respond to the comments provided by IESG and an updated draft.

A Base YANG Data Model for Network Inventory

2026-10-14T20:54:31.073985+00:00

Changed action holders to Chaode Yu, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Phil Bedard (IESG state changed)

A Base YANG Data Model for Network Inventory

2026-10-14T20:54:30.962646+00:00

IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup

A YANG Network Data Model for Inventory Topology Mapping

2026-10-14T12:16:36.063190+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard

A YANG Network Data Model for Inventory Topology Mapping

2026-10-13T17:13:59.061846+00:00

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I am offering some comments and suggestions that should be taken as coming
from someone that has not been following this work. Would appreciate if the
authors would correct me if have misunderstood or got something wrong.

The comments are inline in the idnits output of v11 of this document. The end
of the review is marked by the tag

353 Breakout channel is an atomic resource element obtained by
354 partitioning a breakout port. One physical interface may be
355 associated with one or more breakout channels, but one breakout
356 channel MUST NOT be associated with more than one physical interface.

Section 4.2 makes a normative requirement on an association this
module does not carry: the prohibition on associating a breakout channel with
more than one physical interface. The module lists the channels of a port but
has no reference from a channel to an interface, and the paragraph that
follows leaves that correlation to a future companion module, so nothing here
can conform to or violate the requirement. Suggest stating it as part of the
definition of a breakout channel, and leaving any normative rule to the module
that models the association (or saying here where, and by what, it is
enforced):

CURRENT
Breakout channel is an atomic resource element obtained by
partitioning a breakout port. One physical interface may be
associated with one or more breakout channels, but one breakout
channel MUST NOT be associated with more than one physical interface.
SUGGEST
Breakout channel is an atomic resource element obtained by
partitioning a breakout port. One physical interface may be
associated with one or more breakout channels; a breakout channel
is associated with at most one physical interface.

498 When a discovery system is unable to determine the media
499 type, it should use this identity rather than leaving the
500 leaf unset. An unset leaf indicates that the link type has
501 not been assessed, whereas unknown explicitly records that
502 the medium could not be classified.";

The "unknown" identity's description gives a rule for discovery
systems and gives the difference between "unknown" and an unset leaf a meaning
a consumer relies on, but states the rule in lowercase. As this is normative
module text, perhaps:

s/it should use this identity/it SHOULD use this identity/

555 This reference establishes a 1:1 mapping between the
556 logical node and its physical NE.";

The "ne-ref" and "port-ref" descriptions speak of "a 1:1 mapping" with
"the logical node" (or TP), while the presence statements call a node or TP
with the mapping "physical". "1:1" also reads as a constraint (no two nodes
referencing one NE, no two TPs one port) that the module neither states nor
enforces. Perhaps look at what is intended in both places and align the
wording?

620 "Reference to the physical port component in the
621 network inventory. This reference establishes a 1:1
622 mapping between the logical TP and its physical port
623 component.";

This carries the same "1:1 mapping" with "the logical TP" wording,
while the presence statement calls a TP with this reference "physical"; see my
previous comment.

687 Therefore, in typical deployments, "ne-ref", "port-ref", and "link-
688 type" SHOULD be populated through automatic discovery but MAY only be
689 overridden manually in exceptional cases (e.g., CPE, leased lines, or
690 planned resources). The "port-breakout" container MUST always
691 reflect hardware-determined state and therefore MUST NOT be manually
692 configured.

Section 6 specifies server behaviour with BCP 14 key words — how
"ne-ref", "port-ref" and "link-type" are populated, and when
"inventory-topology" may be configured — which sits oddly in Operational
Considerations. Suggest moving this paragraph and the MAY at lines 696-698
into Section 4 (or the module descriptions). Two further points in the same
text: "MAY only" uses MAY as a restriction, and the closing prohibition
restates that "port-breakout" is config false. Perhaps:

CURRENT
Therefore, in typical deployments, "ne-ref", "port-ref", and "link-
type" SHOULD be populated through automatic discovery but MAY only be
overridden manually in exceptional cases (e.g., CPE, leased lines, or
planned resources). The "port-breakout" container MUST always
reflect hardware-determined state and therefore MUST NOT be manually
configured.
SUGGEST
Therefore, in typical deployments, "ne-ref", "port-ref", and "link-
type" SHOULD be populated through automatic discovery and SHOULD NOT be
configured manually except where discovery is not possible (e.g., CPE,
leased lines, or planned resources). The "port-breakout" container
reflects hardware-determined state and is read-only.

707 protocols, such as Network Configuration (NETCONF) [RFC6241] and
708 RESTCONF [RFC8040]. These YANG-based management (1) have to use a
709 secure transport layer and (2) have to use mutual authentication
710 (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC9846], and QUIC
711 [RFC9000]).

The second sentence departs from the RFC 9907 template: "protocols" is
missing, and the examples have moved from the secure transport to mutual
authentication, so SSH, TLS and QUIC read as authentication methods. Perhaps:

CURRENT
RESTCONF [RFC8040]. These YANG-based management (1) have to use a
secure transport layer and (2) have to use mutual authentication
(e.g., Secure Shell (SSH) [RFC4252], TLS [RFC9846], and QUIC
[RFC9000]).
SUGGEST
RESTCONF [RFC8040]. These YANG-based management protocols (1) have
to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252],
TLS [RFC9846], and QUIC [RFC9000]) and (2) have to use mutual
authentication.

references:
Replace draft-ygb-ivy-passive-network-inventory with
draft-ietf-ivy-passive-network-inventory, which replaced it.

A YANG Network Data Model for Inventory Topology Mapping

2026-10-13T17:13:59.061756+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Ketan Talaulikar

A YANG Network Data Model for Inventory Topology Mapping

2026-10-09T05:29:55.810392+00:00

[Ballot comment]
I'm an author of the spec.

A YANG Network Data Model for Inventory Topology Mapping

2026-10-09T05:29:55.810323+00:00

[Ballot Position Update] New position, Recuse, has been recorded for Mohamed Boucadair

A Base YANG Data Model for Network Inventory

2026-10-08T14:11:49.239811+00:00

IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation

A Base YANG Data Model for Network Inventory

2026-10-08T13:36:25.814312+00:00

[Ballot comment]
Thanks for the work done in this document (and using nice SVG graphics).

Other thanks to Haoyu Song, the INT-directorate reviewer (at my request), please consider and reply to the review posted at:
https://datatracker.ietf.org/doc/review-ietf-ivy-network-inventory-yang-19-intdir-telechat-song-2026-09-30/

The document seems to be only about "physical" components, not about virtual or "cloud instance" and the latter are also important, IMHO, to network operations (e.g., licensing cost, power up/down, ...). If the model is limited to physical elements, then let's be clear in the title and in the abstract.

Some other comments:

### Section 2.2

Is a Wi-Fi interface to be considered as a port ? The description seems to talk mainly about physical ports.

A Base YANG Data Model for Network Inventory

2026-10-08T13:36:25.814240+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke

A Base YANG Data Model for Network Inventory

2026-10-08T05:17:55.065640+00:00

[Ballot comment]
Thanks to Valery S. for the SECDIR review.

Thanks to the authors for the well written draft.

In section 3.1 the definition of UUID is given as follows:

> uuid:
> The Universally Unique Identifier (UUID) of the inventory object, assigned by the server. Such identifiers are widely implemented with systems and
> guaranteed to be globally unique.

What is "the server"? Various servers are mentioned prior to this, but no clear indication of "the server" is given.

A Base YANG Data Model for Network Inventory

2026-10-08T05:17:55.065550+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Christopher Inacio

A Base YANG Data Model for Network Inventory

2026-10-07T19:37:56.148113+00:00

[Ballot comment]
# IESG review of draft-ietf-ivy-network-inventory-yang-20

CC @MikeBishop

## Comments

### Section 3.2, paragraph 3
```
The ne-id should be assigned such that the same network element
```
SHOULD?

### Section 3.3.1, paragraph 4

This shows slots and boards as peers, but the examples differ. Which is
correct? If both are valid configurations, consider putting an example of each.

### Section 3.4.3, paragraph 0

Why is parent not also listed as a difference? The change from leaf to
leaf-list is potentially incompatible.

### Section 5, paragraph 21
```
"The name of the entity (e.g., component), as specified by a
network operator, that provides a non-volatile 'handle' for
the entity. The network operator can specify a different
```
The "non-volatile handle" description is used for the `alias` in RFC 8348. Is
the difference deliberate?

### Section 5, paragraph 28
```
type yang:date-and-time;
description
"The date of manufacturing of the component.";
```
Why `date-and-time` rather than `date`? The description only indicates the date,
not the time.

### Section 5, paragraph 33
```
leaf parent-rel-pos {
when 'count(../parent) < 2' {
```
The scenario RFC 8348 describes, where a component consumes multiple slots,
doesn't mean it no longer has a position relative to its siblings. Three
dual-slot components across six slots, for example. How is that expressed with
this restriction?

### "Appendix C.", paragraph 4
```
resources in large scale networks. This scalability limitation is
caused by the limited transmission capabilities of HTTP protocol.
This scalability limitation should be solved at protocol level rather
than data model level.
```
Really? What's the transmission capability limitation you're hitting?

### "Appendix F.", paragraph 2
```
system. A non-modular network element does not have any slots to
take cards so it cannot take any non-field replaceable modules other
```
This seems backwards. If it had slots, it *could* take field-replaceable
modules; if it lacks them, it can't take field-replaceable ones.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.2, paragraph 34
```
- Elsewhere, a card can be called board, module, circuit pack, etc..
- -
```

#### Section 2.4, paragraph 1
```
- Table 1 list the prefixes of the modules that are used in this
+ Table 1 lists the prefixes of the modules that are used in this
+ +
```

#### Section 3.1, paragraph 4
```
- by a network operator. It could also be present on a GUI instead
- ^
- as well as the name.
+ by a network operator. It could also be present in a GUI instead of
+ ^ +++
+ or in addition to the name.
```

#### Section 3.3.1, paragraph 1
```
- contains network-element, board and port. This model, likewise
- ----
```

#### Section 5, paragraph 13
```
- "Base identity for non hardware components (e.g., software
- ^
+ "Base identity for non-hardware components (e.g., software
+ ^
```

#### Section 7, paragraph 6
```
* "/nwi:network-elements"
```
Do you mean `/nwi:network-inventory/nwi:network-elements`?

#### "E.1.", paragraph 4
```
- first stack port of the first switch in the stack.",
- --- ^
+ first stack port of the second switch in the stack.",
+ ^^^^^
```
```
- second stack port of the first switch in the stack.",
- --- ^
+ second stack port of the second switch in the stack.",
+ ^^^^^
```

#### "Appendix F.", paragraph 2
```
- take cards so it cannot take any non-field replaceable modules other
- ^
+ take cards so it cannot take any non-field-replaceable modules other
+ ^
```

### Section 2.2, paragraph 21
```
* storage device
```
IANA_HW_YANG uses "storage drive".

### Section 3, paragraph 6

"physical-network-element" vs. "ne-physical"

### Section 3, paragraph 10

"non-hardware" vs. "non-hardware-component-class"

### Section 3.1, paragraph 2

"designed" rather than "guaranteed"?

### Section 5, paragraph 6
```
Editor: Sergio Belotti

Editor: Jean-Francois Bouquier

Editor: Fabio Peruzzini

```
Two authors have different contact info between here and the Authors' Addresses.
Is that intentional?

### Section 7, paragraph 6

Do you mean `/nwi:network-inventory/nwi:network-elements`?

### Grammar/style

#### Section 1, paragraph 1
```
d to expose that information in a consistent way. Network inventory manageme
^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "consistently" to avoid
wordiness.

#### Section 3.3.1, paragraph 1
```
t or component as explained in section Section 6. The way used by the contro
^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 3.3.1, paragraph 4
```
ement, and, in the same way, one boot-loader, one firmware and one or more Fi
^^^^^^^^^^^
```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

A Base YANG Data Model for Network Inventory

2026-10-07T19:37:56.148019+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Mike Bishop

A YANG Network Data Model for Inventory Topology Mapping

2026-10-06T22:55:50.741640+00:00

IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK

A YANG Network Data Model for Inventory Topology Mapping

2026-10-06T22:55:42.435912+00:00

IANA Experts State changed to Expert Reviews OK from Reviews assigned

A YANG Network Data Model for Inventory Topology Mapping

2026-10-06T22:55:37.715828+00:00

The XML registration has been approved.

A Base YANG Data Model for Network Inventory

2026-10-06T18:06:01.551426+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Andy Newton

A Base YANG Data Model for Network Inventory

2026-10-06T09:41:56.917120+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Charles Eckel

A Base YANG Data Model for Network Inventory

2026-10-05T22:00:23.182235+00:00

[Ballot comment]
Thank you to Elwyn Davies for the GENART review.

** software-rev

Given the diverse choices in SBOM formats and the focus on software supply chain security, consider if richer format than name, revision and patch would be helpful.

A Base YANG Data Model for Network Inventory

2026-10-05T22:00:23.182163+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw

A Base YANG Data Model for Network Inventory

2026-10-04T13:59:10.172559+00:00

[Ballot comment]

Thanks to Valery Smyslov for their secdir review.

Section 3.2, para 2, sentence 2: It is unusual to use the term being defined 'running' in the definition. Perhaps the word 'executing' might be an option? Or is the intent to define the difference between software images and software modules?

Section 3.4: Is this an update to RFC 8348? If so, that should be stated up front. It would not be shocking for an RFC published 8 years ago to benefit from an update.

Section 3.4.2, last para: Does 'name' really mean 'component name'? Or is there another form of 'name'? The fact that there are components and component-id as two distinct entities is confusing (to me, anyway).

Section 7, bullet 1: The example that comes to my mind with respect to sensitive information is version/patch level for hw/sw running on a network. This isn't stated directly, but I assume that is what is reported in that subtree.

A Base YANG Data Model for Network Inventory

2026-10-04T13:59:10.172488+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley

A Base YANG Data Model for Network Inventory

2026-10-03T00:10:21+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:53:00.177433+00:00

Placed on agenda for telechat - 2026-10-22

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:23:29.754369+00:00

Ballot has been issued

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:23:29.470369+00:00

[Ballot Position Update] New position, Yes, has been recorded for Mahesh Jethanandani

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:23:29.446099+00:00

Created "Approve" ballot

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:23:28.725736+00:00

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead

A YANG Network Data Model for Inventory Topology Mapping

2026-10-02T22:23:28.682090+00:00

Ballot writeup was changed

A Base YANG Data Model for Network Inventory

2026-10-02T13:01:36.147046+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard

A Base YANG Data Model for Network Inventory

2026-10-02T10:21:54.492040+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde

A Base YANG Data Model for Network Inventory

2026-10-01T20:00:22.458426+00:00

Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list.

A Base YANG Data Model for Network Inventory

2026-10-01T18:14:52.473465+00:00

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Please find below some comments, questions and suggestions on this document
inline in the idnits output of v20 of this document. The end of the review is
marked by the tag .

I've not been following or familiar with this work, so please correct me if
I am wrong.

251 The following terms are defined in the description statements of the
252 corresponding YANG identities, defined in [IANA_HW_YANG], and are not
253 redefined here:

Section 2.2 says "power supply" and "storage device" but the
iana-hardware identities are "power-supply" and "storage-drive".

374 Physical network elements are usually devices such as hosts,
375 gateways, terminal servers, and the like, which have management
376 agents responsible for performing the network management functions
377 requested by the network management stations ([RFC1157]).

RFC 1157 is Historic; perhaps cite something current ?

379 The "ne-type" is defined as a YANG identity to describe the type of
380 the network element. This document defines only the "physical-
381 network-element" identity.

The module defines "ne-physical", not "physical-network-element".
Similarly, in the same section, it defines "non-hardware-component-class",
not "non-hardware". Also RFC 8348 carries no "rack", "sub-slot" or "board"
at all, and no "slot" identity — a slot there seems to be modelled as
"ianahw:container" and a board or card as "ianahw:module"?

785 description
786 "This module defines a base model for retrieving network
787 inventory.

789 Copyright (c) 2026 IETF Trust and the persons
790 identified as authors of the code. All rights reserved.

792 Redistribution and use in source and binary forms, with or
793 without modification, is permitted pursuant to, and subject
794 to the license terms contained in, the Revised BSD License
795 set forth in Section 4.c of the IETF Trust's Legal Provisions
796 Relating to IETF Documents
797 (https://trustee.ietf.org/license-info).

799 This version of this YANG module is part of RFC XXXX; see
800 the RFC itself for full legal notices.

802 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
803 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
804 'MAY', and 'OPTIONAL' in this document are to be interpreted as
805 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
806 they appear in all capitals, as shown here.";

RFC 9907 Section 4.8 asks every published module's description to
carry a pointer to the registry group where its revisions can be found, and
the module description does not have one. Suggest adding to the description:

All revisions of IETF and IANA published modules can be found at
the "YANG Parameters" registry group:
.

811 reference
812 "RFC XXXX: A YANG Data Model for Network Inventory.";

The revision and ne-type reference statements cite "A YANG Data Model
for Network Inventory"; the document's title has "Base" in it.

1061 leaf part-number {
1062 type string;
1063 description
1064 "The vendor-specific part number of the component
1065 type. It is expected that vendors assign unique part
1066 numbers to different component types within the
1067 scope of the vendor.";
1068 }
1069 leaf serial-number {
1070 type string;
1071 description
1072 "The vendor-specific serial number of the component instance.

1074 It is expected that vendors assign unique serial numbers to
1075 different component instances within the scope of the
1076 'part-number'.";
1077 }

"part-number" and "serial-number" carry no reference?

1136 leaf ne-id {
1137 type string;
1138 description
1139 "An identifier that uniquely identifies the NE in
1140 a network.";
1141 }

Section 3.2 says the ne-id is assigned by the server, and that it
should be assigned so that the same network element keeps the same identifier
even across disconnection; Section 3.1 says the uuid is assigned by the
server. The module descriptions for those two nodes carry neither point.

1271 are also allowed. In case some information is not provided by the
1272 device, the network controller SHALL omit this information unless
1273 this information is known by other sources of information (e.g.,
1274 through local configuration within the network controller).

This is a normative requirement on an implementation sits oddly in
Operational Considerations. Suggest moving the sentence into Section 3.

1361 IANA is requested to register the following URI in the "ns" registry
1362 within the "IETF XML Registry" group [RFC3688]:

1364 URI: urn:ietf:params:xml:ns:yang:ietf-network-inventory
1365 Registrant Contact: The IESG
1366 XML: N/A; the requested URI is an XML namespace.

1368 IANA is requested to register the following YANG module in the "YANG
1369 Module Names" registry [RFC6020] within the "YANG Parameters"
1370 registry group.

RFC 6020 is listed as normative and RFC 3688 as informative. Suggest
classifying the two the same way, whichever way is more accurate.

A Base YANG Data Model for Network Inventory

2026-10-01T18:14:52.473377+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Ketan Talaulikar