Summary

  • draft-ietf-ivy-entitlement-inventory-05 separates an organisational entitlement, its attachment to an asset, an installed reference, supporting licences, allowed, in-use and restriction values. None of those fields alone proves the next one.
  • The proposed YANG module is wholly read-only. Synchronisation, expiry alerts and the systems that actually change or enforce licence state remain outside it, so a green inventory row is a report rather than an executable right.
  • Safe automation needs a receipt chain from commercial grant through device-local validation, user authority, configuration, operational use and independently observed service.

A maintenance window with two truths

Consider an illustrative maintenance window. The central inventory says an advanced-routing entitlement is active. It is attached to the target chassis. The chassis view contains the entitlement under installed-entitlements. The capability points back to it, and allowed is true. Every field needed for a reassuring dashboard is green.

The operator enables the feature. The device refuses. Its local licence cache has not received the assignment, or the external licence service cannot validate it, or another entitlement in the dependency set has expired. Nothing about that example says the inventory lied. It says that each system reported the truth available at its own boundary.

The reverse is possible. The feature may still be forwarding traffic while the central catalogue says a licence expired. A grace period, stale poll, disconnected licence server or device-local state can preserve operation after the organisational record has changed. A dashboard and a device can disagree without either Boolean explaining which right is enforceable now.

This is the problem addressed by A YANG Module for Entitlement Inventory. Revision 05 is dated 29 September 2026, carries intended status Standards Track and expires on 2 April 2027. It is an active IETF Network Inventory YANG working-group Internet-Draft. It is not an RFC, a completed IANA registration, evidence of product support or a deployed licence policy.

Its value is not that it abolishes disagreement. It gives disagreement a structure.

Nine records, not one licence fact

The draft augments the base IVY network inventory with a top-level catalogue and asset-level views. Read as an evidence chain, it contains at least nine distinct propositions.

First, the organisation records an entitlement: an identifier, vendor or product metadata, state, activation date, start date, expiration date and possible restrictions. Second, the entitlement may be attached to an organisation, user, network element or component. Third, the asset can expose a reference under installed-entitlements. Fourth, it can report a technical capability. Fifth, that capability can name one or more supporting entitlements. Sixth, it can report whether entitlement state makes the capability allowed. Seventh, it can report whether the capability or entitlement is in-use. Eighth, it can expose global or capability-specific maxima and current consumption. Ninth, a separate observation can show whether the intended network service actually occurred.

Collapsing those stages destroys useful information. An organisation may own an unassigned licence. An assigned licence may not be active on the device. An active licence may support only one member of a dependency set. A capability may be allowed but unused. It may be in use yet exceed a shared commercial limit because another asset consumed the pool. It may operate within the limit while the service fails for a routing, optical, security or application reason.

The fields are powerful because they let an operator ask more precise questions. They are dangerous only when a consumer treats a precise field name as universal proof.

“Installed” depends on who is speaking

Revision 05 exposes an important work-in-progress tension. Its scope section says “installed entitlements” are assigned to an asset and that installation may mean direct provisioning on the device or only a logical assignment in a central system. The definitions section describes an Installed Entitlement as locally activated and available for use. Later text calls installed entries active and entitling the asset.

Those formulations may converge in a later revision. Today an implementation cannot safely resolve them by assumption. It must say which producer supplied the value and what that producer can see.

An asset-management platform can know that procurement assigned a licence to serial number X. A device can know that it loaded a local token. A cloud licence server can know that it granted a lease at 10:04. A controller can know that its last poll returned an installed reference. These are four receipts. They may share an entitlement ID without sharing an observation time or meaning.

The correct operational question is therefore not “is it installed?” It is “which system asserts which installation state, as of what time, under which validation path?” A common YANG path helps systems exchange the answer. It does not make their vantage points identical.

Presence, emptiness and ignorance

The model uses presence containers to signal reporting capability. If an information system exposes installed-entitlements, it claims knowledge of that class of information; a present but empty list can mean no entitlement is installed. If the container is absent, the system may simply be unable to report it.

That difference matters to automation. An absent capability list is not evidence that the asset has no capabilities. A missing in-use leaf can mean the producer cannot express use, not that use is false. An empty supporting-entitlements list can mean the capability needs no special entitlement, but an absent supporting-entitlements container means the producer cannot report the dependency relationship.

Data pipelines often erase those distinctions by coercing missing values to false or empty arrays. The result looks consistent and is wrong in the most consequential way: uncertainty becomes denial, or ignorance becomes unrestricted permission. A consumer should preserve at least four states—reported true, reported false, reported empty and not reported—plus producer and observation time.

The five implementation levels

The draft deliberately allows incremental adoption. Level 1 is a central catalogue. Level 2 adds installed entitlements on assets. Level 3 adds capability reporting. Level 4 links capabilities to supporting entitlements and adds allowed and in-use. Level 5 adds global and capability-specific restrictions.

Implementations are asked to document which levels they support and where they deviate. That disclosure is not administrative decoration. A Level 1 product cannot answer whether a capability is allowed on a particular device. A Level 3 product can list a function without showing the licence dependency. A Level 4 system can report permission without the pool or throughput limits needed to decide whether one more use is valid.

Procurement comparisons should therefore avoid a single checkbox called “supports entitlement inventory.” The meaningful question is which level, which producers, which fields, what freshness and what consistency behavior.

allowed is a decision, not an effect

At Level 4 a capability may require several supporting entitlements. The model says allowed must reflect their combined effect; if a required entitlement is missing, expired or revoked, it should be false. This makes the Boolean an output of a policy calculation, not a raw property of hardware.

To trust it, a consumer needs the complete dependency set, current state for every dependency, the combination rule and the identity of the decision maker. A stale catalogue can keep allowed true after revocation. An incomplete dependency map can keep it true while an add-on is missing. Two systems can calculate different answers if one understands a grace period and the other does not.

Even a correct allowed=true proves only that entitlement policy permits use at that point. It does not prove that a particular administrator has Network Configuration Access Control Model permission to configure the feature. RFC 8341 addresses user access to management operations and data. Entitlement addresses the organisation's right to activate a capability. A valid licence does not promote a user. A privileged NETCONF account does not manufacture a licence.

Nor does entitlement permission prove readiness. Configuration dependencies, memory, line-card support, software version, topology and service policy can still block the feature. Permission is a necessary input in some deployments, not the whole activation transaction.

in-use still needs an observer

The model can report in-use for an installed entitlement and for a capability. Where both exist, they are expected to agree: if any supported capability is used, the entitlement should be marked in use. That relationship helps detect obvious contradictions.

It does not tell an operator how use was observed. A device might derive it from configuration presence, process state, allocated resources or traffic counters. A licence server might count checked-out seats. A controller might repeat the last device report. Those methods answer different questions.

For a routing feature, “configured,” “process running,” “adjacency established,” “route selected,” “forwarding entry installed” and “customer traffic delivered” are not synonyms. The inventory should link to those receipts rather than absorb them into one licence field.

Pools and counters can race

Restrictions can be global—such as the number of installations across an organisation—or local to a capability, such as maximum throughput, tunnels or connections. The model provides resource name, units, maximum and current value.

A value of 80 against a maximum of 100 does not automatically authorize another request for 20. The current value may be ten minutes old. Two controllers may reserve the same headroom. The unit may describe configured capacity while enforcement counts active use. A parent licence and child add-on may draw from different pools.

The draft also permits hierarchical entitlements. YANG can prevent a direct self-reference, but it cannot by itself reject every deeper cycle. A management system must detect A→B→A before committing the graph. Schema validity is therefore not graph validity, and graph validity is not atomic reservation.

Every restriction receipt needs scope, source, time, aggregation window, reset rule and reservation state. Without them, a current-value leaf is descriptive telemetry, not a concurrency control.

The model reports state; another system changes it

Every node in the proposed module is config false. The model is read-only. Underlying entitlement state is changed by external systems such as licence servers or asset-management platforms, and their channels to assets are outside the document's scope.

That boundary should shape architecture. A NETCONF or RESTCONF read can be mutually authenticated and protected in transit while still returning stale or false entitlement state. The draft's security section warns that compromise of external channels can inject state that makes capabilities appear allowed or restricted contrary to actual organisational rights.

Central and local records therefore need reconciliation. Revision 05 says implementations should detect inconsistencies among the central catalogue, locally installed entitlements and actual capability usage. It does not define one precedence rule, freshness deadline or conflict winner. Those remain deployment decisions that should be visible in evidence.

Expiry is similar. The model exposes dates but does not define approaching-expiry notifications. A management application must own the alert, escalation and renewal receipt. Caching may be necessary at scale, so the cache identity and last successful refresh belong next to every green status.

A receipt chain for executable rights

A defensible entitlement decision can be represented as a chain:

  1. Grant receipt: what right was issued, by whom, for which holder, dates and restrictions.
  2. Assignment receipt: which asset or component was selected and by which organisational authority.
  3. Activation receipt: which device or licence service accepted the entitlement, under which identifier and at what time.
  4. Dependency receipt: the complete supporting-entitlement set and hierarchy, with cycle validation.
  5. Permission receipt: the producer and rule behind allowed, including freshness and exceptions.
  6. Access receipt: the human or automation principal and the separate NACM decision.
  7. Use receipt: what “in use” means for this implementation and the observation that supports it.
  8. Restriction receipt: pool, units, current reservation, enforcement result and remaining headroom.
  9. Outcome receipt: configuration acceptance, operational state, traffic evidence and the intended service result.

No universal database has to own all nine. The point is to preserve the hand-offs. A common inventory becomes more trustworthy when it admits where its authority ends.

Sources