Summary

  • draft-ietf-ivy-entitlement-inventory-05 proposes a read-only YANG model for entitlements, capabilities and restrictions; it is an active Internet-Draft, not an RFC or deployment report.
  • Its installed entitlement may be a device-local activation or a logical assignment in a centralized system. The reporting source therefore belongs to the fact.
  • allowed, in-use and observed service execution are different claims. A useful inventory becomes dangerous only when software silently promotes one into another.

Imagine two records with the same shape. Both say that entitlement ent-47 is installed on router r9. In the first environment, the device received a licence, validated it and exposed the result from local state. In the second, an asset database assigned the entitlement to r9, while the device relied on an external agreement and never held the entitlement itself. The strings match. The operational receipts do not.

That is not an edge case invented around the draft. Revision 05 deliberately spans both realities. Its scope says that an installed entitlement is assigned to a network asset and that “installation” may mean direct provisioning on a device or a logical assignment in a centralized system. Its terminology also describes an Installed Entitlement as locally activated and available to the element’s capabilities. The point is not to declare the model inconsistent. The point is to recognise that one portable label covers more than one evidence path.

The deployment models make the distinction explicit. A licence may be installed and enforced locally. It may live on an external licence server that the asset queries. Or it may exist as a commercial agreement whose compliance is tracked outside the asset, with the network element unaware of the entitlement. A network element, a licence service and a monitoring system can all expose useful parts of the same tree. None is automatically the sole witness.

The model is designed for that uneven world. It is entirely read-only and supports five levels of implementation. Level 1 records the organization’s entitlement catalogue. Level 2 maps entitlements to assets. Level 3 adds the capabilities an asset reports. Level 4 connects capabilities to supporting entitlements and adds allowed and in-use. Level 5 adds global and capability-specific restrictions such as installation counts, throughput or connection limits.

Those levels are not cosmetic maturity badges. They define which question a system can answer. A Level 1 catalogue can say what the organization manages, not what a particular box received. A Level 2 assignment can say which right is associated with an asset, not what the asset can perform. A Level 3 capability list does not identify the licence enabling the function. Level 4 joins the relationship, while Level 5 exposes constraints. Reading a partial tree as though it were complete manufactures evidence that the producer never supplied.

Presence containers are the model’s mechanism for saying “I can report this.” Their absence means the implementation cannot report the information. It does not necessarily mean that the capability, entitlement or restriction is absent in reality. This is a small but decisive rule for automation. Converting missing into false may shut down usable capacity; converting missing into true may authorize work that the evidence does not support. The honest state is often unknown.

Even at Level 4, the booleans need boundaries. When a capability depends on several entitlements, allowed is meant to reflect their combined effect; a missing, expired or revoked requirement should make the field false. in-use reports whether the capability is currently operational. Yet both remain values in a read-only inventory. They are not a configuration transaction, an activation command, an independent telemetry trace or an immutable receipt that a customer-visible service worked.

Revision 05 itself anticipates divergence. Its operational considerations call for mechanisms to detect inconsistencies among centralized entitlement records, locally installed entitlements and actual capability usage. If those layers were interchangeable, reconciliation would be unnecessary. The model is most useful precisely because it can place them in one graph without pretending that they are one event.

Capability identity introduces a second source of ambiguity. Vendors choose the granularity. One may report a coarse class such as Advanced Services; another may expose MPLS, BGP and QoS separately. An allowed: true value is therefore meaningful only with the capability definition, vendor vocabulary and asset scope that produced it. The common schema standardizes the relationship. It does not standardize every commercial feature boundary.

Automatic discovery is outside the current draft. Associations may be provisioned in a licence server, reported through a device management interface or entered manually during inventory work. Expiry notification is also outside scope: the model exposes dates, while another system must detect the approach of expiry and deliver an alert. A date is not an alert receipt, just as an assignment is not proof of local activation.

The security boundary reinforces the same lesson. NETCONF or RESTCONF can carry the data over protected sessions, and NACM can limit who reads sensitive catalogue, contract and capability information. Those controls protect access to a report. They cannot prove that the upstream licence server or asset platform wrote the correct state. The draft warns that an attacker able to inject false external state could make a capability appear allowed or restricted contrary to the organization’s real entitlements.

Standards status must remain equally precise. Revision 05 is dated 29 September 2026 and targets Standards Track, but it remains an Internet-Draft. Its YANG structure, validation and possible future registry entries would establish vocabulary and interoperability material. They would not prove IETF approval, vendor implementation, complete support, fresh data or the condition of a named network.

The draft’s value is therefore not that it eliminates uncertainty. It gives uncertainty an address. Catalogue, assignment, local activation, permission, reported use, restriction and actual operation can be recorded as separate claims. The operational error begins when a dashboard flattens them into a green tick labelled “licensed”.

Sources