Network Access Management as a CRR Use Case: Wireline Perspectives on Capability Discovery and Runtime Restrictions

[clundie-CL]

Network Access Management as a CRR Use Case: Wireline Perspectives on Capability Discovery and Runtime Restrictions

Background

The Capabilities & Runtime Restrictions (CRR) API was designed to solve a problem that is well understood in mobile network contexts: the set of features an API provider can deliver to a given consumer is not static. It varies by operator implementation, by subscriber service context, by the physical equipment provisioned at a location, and by the runtime state of that equipment at any given moment.

This discussion brings a wireline perspective to that problem, grounding it in concrete use cases from the Network Access Management (NAM) API. NAM manages operator-supplied network access devices — gateways, mesh systems, and similar CPE — and enables API consumers to create and manage Trust Domains (logically separated LANs) and register subscriber and IoT devices for Zero Touch Onboarding (ZTO) using protocols such as DPP, Matter, and WKSO.

Wireline deployments introduce a capability discovery problem that CRR is well positioned to solve: a third-party platform (e.g., a property management system, a smart home integrator, or an IoT fleet manager) may be operating across multiple operators and multiple subscriber accounts, each with different service tier entitlements and different gateway hardware. Knowing what is actually valid to request — before making the request — is not a simple static lookup.

---

The Layered Nature of Capability

The CRR working group has described capability as a set of nested layers, each narrowing the previous:

• What the network can do — global operator infrastructure capability
• What the deployed service is configured to do — operator configuration and footprint
• What is exposed via Network APIs — the subset surfaced through standardized interfaces
• What is valid for this subscriber's service context — service tier policy and entitlements
• What is valid right now — runtime state of the subscriber's physical equipment

A CRR query resolves through all of these layers simultaneously, returning a set of restrictions on the target API's OpenAPI schema that describe exactly what a valid request looks like for the given resource context at this moment.

For NAM specifically, the subscriber's service context introduces two distinct narrowing steps worth calling out explicitly:

1. Service-level policy — Does this subscriber's service plan include Trust Domain management or ZTO features at all? An operator may support Thread globally but restrict it to certain service tiers.
2. Hardware/firmware reality — Even if the service tier permits a configuration, does the specific gateway provisioned at this subscriber's location support it? WPA3-Personal, Thread, Matter commissioning, and DPP bootstrapping are all hardware and firmware dependent.

Both can change independently over time — a subscriber upgrades their service tier, or an operator pushes a firmware update to field equipment — which is precisely where CRR's subscription and notification model adds value that a static bespoke endpoint cannot.

---

Where CRR Fills the Gap in NAM

CRR is appropriate when the question is about what the API provider's implementation supports for a specific subscriber context, dynamically. This includes service policy entitlements, hardware-derived constraints, and runtime network state — anything that varies by subscriber and can change.

NAM's existing GET /trust-domains/capabilities endpoint can resolve to a subscriber and service context via the access token, but it remains a point-in-time query with no ability to express schema-level restrictions on the API itself or notify consumers when capabilities change. CRR fills that gap — offering a generalized, cross-operator mechanism for capability discovery with the added benefit of a subscription model for dynamic adaptation.

---

Use Cases

Use Case 1: Trust Domain Creation — Sunny Day

An API consumer would like to create a WPA3-Personal Wi-Fi Trust Domain for a new tenant's service account, and wants to confirm the configuration is valid before making the creation request.

For this request to be valid, the following must be true:

Dependency	Layer
This operator supports WPA3-Personal	Global operator capability
Trust Domain management is included in this subscriber's service plan	Service policy entitlement
The gateway provisioned at this subscriber's location supports WPA3	Hardware/firmware reality
The gateway is currently online and able to accept configuration	Runtime state

CRR resolution: The consumer POSTs a CRR query referencing network-access-management.yaml with a resource scope identifying the subscriber's service context. All layers resolve favorably — no restrictive overlays are applied to Wi-Fi:WPA_PERSONAL or WPA3-Personal. The consumer proceeds to POST /trust-domains with confidence that the request is valid.

---

Use Case 2: Trust Domain Creation — WPA3 Not Supported by Subscriber Hardware

An API consumer would like to create a WPA3-Personal Wi-Fi Trust Domain for a subscriber whose provisioned gateway is an older model supporting WPA2 only.

CRR resolution — restriction overlay: The hardware/firmware layer narrows the assessment. The CRR response includes a restriction overlay on the securityModeType enum within WpaPersonalDetail, reducing the permitted values to ["WPA2-Personal", "WPA2-WPA3-Personal"]. The consumer's application evaluates the overlay, removes WPA3-Personal from its available options, and creates the Trust Domain with WPA2-Personal — a valid request the first time, without trial-and-error against the NAM API.

CRR resolution — blocked with context: If the consumer attempts POST /trust-domains with securityModeType: WPA3-Personal without first consulting CRR, the NAM API returns a 400 INVALID_ARGUMENT or 422 response. With CRR integration, the consumer's application never reaches this state — the overlay prevents the invalid configuration from being submitted.

---

Use Case 3: Trust Domain Creation — Feature Not Included in Service Tier

An API consumer would like to create a Thread:STRUCTURED Trust Domain for a subscriber's IoT devices.

For this request to be valid, the following must be true:

Dependency	Layer
This operator supports Thread	Global operator capability
Thread networking is included in this subscriber's service plan	Service policy entitlement
The subscriber's gateway supports Thread:STRUCTURED (vs. Thread:TLV only)	Hardware/firmware reality

CRR resolution — restriction overlay: The service policy layer narrows the assessment. The CRR response includes a SchemaRestrictionOperation with notAvailable: true applied to Thread-related access type configurations for this subscriber. The consumer learns before attempting the creation request that Thread is not available for this subscriber's service tier, and can surface an appropriate message or offer a Wi-Fi-only alternative.

CRR resolution — blocked with context: If Thread:STRUCTURED is technically supported by the hardware but the subscriber's plan does not include it, a POST /trust-domains attempt would return a 403 PERMISSION_DENIED or 422 SERVICE_NOT_APPLICABLE. CRR surfaces this constraint pre-flight, allowing the consumer to either inform the subscriber or trigger a service upgrade flow before attempting provisioning.

---

Use Case 4: Zero Touch Onboarding — Protocol Selection (Sunny Day)

An API consumer would like to register a new smart thermostat to a subscriber's Trust Domain using DPP bootstrapping and wants to confirm DPP onboarding is supported before submitting the registration.

For this request to be valid, the following must be true:

Dependency	Layer
This operator supports DPP bootstrapping	Global operator capability
ZTO/device onboarding is included in this subscriber's service plan	Service policy entitlement
The subscriber's gateway supports DPP	Hardware/firmware reality
The gateway is currently reachable and capable of initiating a DPP exchange	Runtime state

CRR resolution: The CRR query resolves favorably across all layers. The response overlay confirms DPP is a valid value in BootstrappingProtocol for this subscriber context. The consumer proceeds to POST /trust-domains/{trustDomainId}/devices with bootstrappingInfo.DPP populated.

---

Use Case 5: Zero Touch Onboarding — Protocol Fallback

An API consumer would like to register a device that supports both DPP and Matter to a subscriber's Trust Domain, but the subscriber's gateway does not support DPP.

CRR resolution — restriction overlay: The hardware/firmware layer narrows the assessment. The CRR response includes a restriction narrowing the valid values of protocolPreference items — DPP is excluded from the permitted enum, but MATTER remains valid. The consumer's application evaluates the overlay, selects Matter as the bootstrapping protocol, and submits the registration with bootstrappingInfo.MATTER populated. No failed request is made; the protocol fallback is handled proactively.

CRR resolution — blocked with context: If the consumer submits a registration with protocolPreference: [DPP] without first consulting CRR, the NAM API returns a 422 SERVICE_NOT_APPLICABLE or 400 INVALID_ARGUMENT indicating DPP is not supported for this device/subscriber context. CRR integration allows the consumer to avoid this failure entirely by selecting a compatible protocol before submitting.

---

Use Case 6: Dynamic Adaptation — Gateway Replacement

An API consumer would like to maintain valid pre-staged Trust Domain and ZTO configurations for multiple subscriber accounts, and be notified automatically when a subscriber's gateway is replaced so it can re-evaluate those configurations.

How the subscription model serves this need: At onboarding time, the consumer includes a subscriptionRequest in its CRR query, registering a webhook sink for capability-bitmap-changed and capability-info-changed events scoped to the subscriber's service context.

When the operator provisions a replacement gateway — for example, a new model that adds Thread support where the previous one had none, or vice versa — the CRR service emits a capability-info-changed event to the consumer's webhook. The consumer receives the updated restriction overlay and re-evaluates its pre-staged configurations:

• Configurations that were previously blocked by hardware constraints may now become valid and can be applied proactively
• Configurations that relied on capabilities the new hardware lacks are flagged for review before they result in failed provisioning attempts

This pattern enables API consumers to build applications that are dynamically responsive to evolving subscriber circumstances without polling.

---

Use Case 7: Dynamic Adaptation — Service Tier Upgrade

An API consumer would like to be notified when a subscriber upgrades their service plan to include Thread networking, so it can proactively offer Thread Trust Domain configurations that were previously unavailable.

How the subscription model serves this need: The existing CRR subscription emits a capability-bitmap-changed event when the service tier change takes effect. The consumer's application receives the updated bitmap, evaluates that Thread restrictions have been lifted, and surfaces Thread configuration options to the subscriber — without requiring the subscriber to re-initiate any discovery flow, and without the consumer having to poll for plan changes.

---

Summary

NAM presents a compelling wireline use case for CRR that complements the mobile-network scenarios the working group has primarily considered to date. The core value proposition across these use cases is:

• Pre-flight validation of Trust Domain and ZTO configurations against the full capability stack, from global operator support down to subscriber hardware reality, preventing invalid requests before they are submitted
• Actionable constraint surfacing when capabilities are unavailable, enabling consumers to adapt configurations or surface meaningful feedback rather than handling opaque API errors
• Cross-operator portability of the capability discovery mechanism for third-party platforms operating across multiple operators
• Dynamic responsiveness via subscription callbacks when subscriber service circumstances change — gateway replacement, firmware updates, service tier changes — without polling

We believe these use cases strengthen the case for CRR as a general-purpose mechanism applicable beyond mobile network APIs and welcome feedback from the working group.

[clundie-CL]

Note on the edit: I didn't paste the content in correctly and noticed there were some rendering issues with what I pasted vs the source markdown I was trying to copy from. Fixed by copying the actual markdown source.