| Internet-Draft | YANG-CMIS-Access-Control | September 2026 |
| Homma, et al. | Expires 13 March 2027 | [Page] |
This document provides YANG data models for accessing and controlling CMIS in order to manage pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside the platform device. CMIS provides custom pages that can be defined by the module vendor for its own usage, allowing the capabilities of the optics devices to be extended. These YANG modules also allow the utilization of CMIS custom pages as a generic control mechanism. The models complement abstracted data models for coherent pluggables: they provide governed access to opaque, vendor-specific attributes (e.g., those exposed via CMIS custom pages) and a transitional path for standardized features that the host NOS does not yet support.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Pluggable Digital Coherent Optics (DCO) transceivers enable routers or switches to directly connect to an optical network (e.g., DWDM or OTN). Pluggable DCO transceivers, such as CFP2-DCO and QSFP-DD DCO, implement optical connectors (i.e., Tx and Rx) and a Digital Signal Processor (DSP), and provide higher data rates (100 Gbps, 400 Gbps, and beyond) and flexible data transport.¶
Pluggable DCO transceivers, installed in a platform device (e.g., a switch or a router), are generally controlled by the network OS running on the device using the Common Management Interface Specification (CMIS), which is an open, standardized management interface between the host and its managed modules. The specification is defined in [OIF-CMIS]. CMIS also allows vendor-specific extensions of its transceiver features by using custom pages. For example, CMIS custom pages can be used for non-standardized functions.¶
However, the continuous emergence of new transceiver standards makes it highly challenging for Network OS (NOS) vendors to support the full feature set of every transceiver immediately. As a result, a NOS might support only a basic subset of a DCO transceiver's capabilities. This document defines a YANG data model for accessing and controlling CMIS from outside the platform device, allowing an external management system to configure and monitor advanced features directly without waiting for NOS upgrades.¶
Absent a standard mechanism, using such capabilities requires per-vendor, per-NOS integration: each new module capability must be separately implemented in every NOS before operators can benefit from it. A standard, governed host-side access mechanism replaces this per-feature, per-NOS effort with a single generic implementation per NOS, while the semantics of the accessed attributes remain with the parties that own them: the module vendor and the operator's controller. The need to describe vendor-specific capabilities in a generic way is also recognized in OIF's advertising-based management direction [OIF-PNP]. In addition, the access governance itself (which pages may be delegated, and under which controls) benefits from being interoperable across NOS implementations rather than being reinvented per platform.¶
The data models defined in this document provide register-level access to CMIS pages and are intended to complement, not replace, abstracted YANG data models for coherent optical interfaces (e.g., [I-D.rokui-ccamp-actn-wdm-pluggable-modelling]). Where a standardized, semantically abstracted data model is available for a given function, its use is preferable. The models in this document address two cases that abstracted models cannot cover, with different time horizons. The first case is opaque, vendor-specific attributes: capabilities, configuration, or statistics whose semantics are defined by a single vendor, such as those exposed via CMIS custom pages. These cannot be abstracted a priori, and this document provides a permanent, governed access path for them. The second case is standardized features that are not yet reflected in abstracted models or in the host NOS; for these, this document provides a transitional path until abstraction catches up.¶
The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The terms and their definitions used in this specification are described below:¶
CMIS (Common Management Interface Specifications): A generic management communication interface together with a generic management interaction protocol between host and managed modules. The specification is defined in [OIF-CMIS];¶
NACM (Network Configuration Access Control Model): A standard access control model to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The specification is defined in [RFC8341].¶
NETCONF (Network Configuration Protocol): Mechanisms to install, manipulate, and delete the configuration of network devices. The definitions and specifications are described in [RFC6241];¶
RESTCONF: An HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. The specification is defined in [RFC8040].¶
The following terms of NETCONF defined in [RFC6241] are also used in this specification:¶
The following acronyms are used in this document:¶
The tree diagrams used in this document follow the notation defined in [RFC8340].¶
In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules. The proposed modules augment the ietf-interfaces module [RFC8343]. The details of the modules are described in Section 4.¶
| Prefix | YANG module | Reference |
|---|---|---|
| if | ietf-interfaces | [RFC8343] |
| cmis-ctrl | ietf-cmis-control | RFC XXXX |
| cmis-ctrl-pm | ietf-cmis-control-primitive | RFC XXXX |
| cmis-ctrl-act | ietf-cmis-control-action | RFC XXXX |
| cmis-ctrl-rpc | ietf-cmis-control-rpc | RFC XXXX |
| cmis-mon | ietf-cmis-monitor | RFC XXXX |
Note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.¶
This section describes use cases of the YANG data models for accessing and controlling CMIS.¶
This YANG data model disaggregates management features for pluggable DCO transceivers installed in a platform device from its Network OS (NOS), enabling centralized control of such transceivers. For example, when a pluggable DCO transceiver is installed in a Customer Edge (CE) router connected to a DWDM/OTN network provided by a Communication Service Provider (CSP), the transceiver configurations (e.g., assigned wavelength, output power) strongly depend on the CSP's optical network design, such as the distance to the next node and the status of adjacent channels. Therefore, the CSP often needs to control the CE-equipped DCO transceiver as part of a managed service. If the customer alters these settings freely, it may cause severe interference with other active wavelengths in the CSP network. From a security and operational stability perspective, it is highly desirable to place the transceiver strictly under the CSP's management, as shown in Figure 1.¶
+-------------+
. . .>| Controller |< . .
. +-----A-------+ .
. . .
,---------. . . . ,---------.
( ) . ,---V----. . ( )
( Customer +------V+ ( ) +V------+ Customer )
( Network | CE [DCO]---( DWDM/OTN )---[DCO] CE | Network )
( +-------+ ( ) +-------+ )
`-----------' `--------' `-----------'
`-------v-------' `------------v------------' `--------v------'
Customer Domain Service Provider Domain Customer Domain
Legend
<. . . > : C-plane Signals
Furthermore, to increase the flexibility in combining various NOSs and pluggable DCO transceivers, an architecture that allows a centralized controller to manage the transceivers independently of the NOS's support status is an effective approach. Due to differences in DSP implementations among vendors and the continuous release of new specifications (e.g., 800G, 1.6T, and beyond), a NOS might only support a basic subset of a new transceiver's capabilities. This data model allows an external controller to configure and utilize advanced DSP features without waiting for NOS software upgrades.¶
Additionally, this decoupled management architecture is highly applicable to emerging advanced optical technologies such as OpenXR (XR Optics). OpenXR adopts an architecture where DSP management is decoupled from the host NOS, and this YANG model can serve as a standardized, governed means to realize such decoupling for standard CMIS modules. A key feature of OpenXR is point-to-multipoint (P2MP) coherent connectivity, where digital subcarriers within a single wavelength are divided and assigned to multiple remote transceivers. In a P2MP deployment where a single hub serves multiple customers, the optical signal is broadcast via passive splitters. Each leaf transceiver physically receives the entire optical spectrum but uses its DSP to selectively extract and demodulate only its assigned subcarriers. If a customer at the CE is allowed to freely reconfigure the transceiver's subcarrier assignments via CMIS, they could potentially tune into subcarriers allocated to other customers, leading to severe security risks such as eavesdropping. Thus, it is crucial that the CSP tightly controls the subcarrier allocations and DSP settings, explicitly restricting the host's access to prevent such vulnerabilities.¶
If the management of the DCO transceivers on the CEs is entirely delegated to the controller, the controller needs to monitor the DCO transceivers to detect failures. For this case, the notification-based YANG module described in Section 4.5 can be used.¶
Note that this use case describes an operational scenario, not a mechanism. Within this scenario, functions covered by abstracted data models are expected to be managed through those models; the mechanisms in this document apply only to the opaque, vendor-specific residual and to features not yet supported by the NOS, as described in the Introduction and in Section 2.2. The applicability of this document within this use case is therefore intentionally limited, and the abstracted models and this document are expected to cooperate under a single transport-domain controller.¶
The rapid evolution of optical technologies makes it difficult for NOS implementations, especially Open Source Software (OSS) NOSs like SONiC, to immediately support all features of a new transceiver. Often, a NOS utilizes only a basic subset (e.g., 30%) of a transceiver's capabilities required for standard link bring-up. By using this YANG data model, operators can complement the missing capabilities of the NOS in two ways:¶
Standard Pages: Operators can access advanced features, detailed alarms, and performance monitors defined in standard CMIS pages that the NOS has not yet implemented.¶
Custom Pages: Operators can obtain detailed DSP information and configure vendor-specific extensions contained in CMIS custom pages even if the modeling of the data is not standardized. Example uses of such detailed DSP information include fiber sensing (Ref. [ECOC48923.2020.9333176]), physical layer monitoring (Ref. [JLT.2021.3139167]), and accurate estimation (e.g., GSNR) (Ref. [JOCN.505729]).¶
To safely control CMIS modules from remote systems, it is essential to classify CMIS pages based on their management responsibility. Managing pages that are already under the control of the Host Network OS (NOS) can lead to conflicts and service disruption. Therefore, CMIS pages are categorized as follows based on the OIF CMIS and C-CMIS specifications:¶
| Category | Page Number | Description | Remote Control |
|---|---|---|---|
| Lower Memory | N/A | Interrupt Flags and Module Status. Reading may cause Clear-on-Read (CoR) side effects. | No |
| Base EEPROM & Advertising | 00h, 01h | Module ID, Vendor Information, and Supported Applications Advertising. | Read-Only |
| Thresholds & Monitors | 02h | Alarm/Warning thresholds and generic monitors. | Read-Only |
| Datapath Control & Status | 10h, 11h | Datapath initialization, Application selection, and Lane Status/Alarms. | May |
| Timing & Tx/Rx Characteristics | 12h | Timing characteristics and tunable laser controls. | May |
| Active Diagnostics | 13h, 14h | PRBS generation/checking, Loopbacks, and Diagnostic counters. | May |
| Advanced Diagnostics (VDM) | 20h - 2Fh | Versatile Diagnostics Monitor (VDM) configuration and real-time values. | May |
| Coherent Media Settings | 30h - 3Fh | C-CMIS media configuration (Grid, Frequency) and DSP monitors (OSNR, CD, DGD). | May |
| Advanced Coherent Features | 40h - 4Fh | C-CMIS extended features such as FlexO and Out-of-Band (OOB) messaging. | May |
| Firmware & Messaging (CDB) | 9Fh - AFh | Command Data Block (CDB) used for Firmware updates and complex messaging. Remote write MUST NOT be permitted (see Security Considerations). | Read-Only |
| Vendor Specific Extensions | B0h - FFh | Proprietary extension pages. Remote control MUST be coordinated with Host NOS. | May |
| Reserved & Minor Optional | 03h-0Fh, 15h-1Fh, 50h-9Eh | CMIS reserved pages and minor optional features. Remote access depends on Host NOS support. | May |
The 'remote-write-allowed-pages' and 'remote-read-allowed-pages' lists defined in the YANG model are used to clarify which pages are delegated to the remote system based on this classification.¶
This document defines the following YANG modules for the management of CMIS-capable pluggable DCO transceivers.¶
ietf-cmis-control (base model, mandatory)¶
ietf-cmis-control-primitive (optional)¶
ietf-cmis-control-rpc (optional)¶
ietf-cmis-control-action (optional)¶
ietf-cmis-monitor (optional)¶
Each module augments the ietf-interfaces module and allows the user to set the operating mode of CMIS for controlling pluggable devices as well as other operational parameters.¶
The "ietf-cmis-control-action" and "ietf-cmis-control-rpc" modules provide equivalent read/write operations as YANG 1.1 actions and as top-level RPCs, respectively. The action-based module is RECOMMENDED for servers that support YANG 1.1 actions because the operations are naturally scoped to the target interface; the RPC-based module is provided for clients and servers that cannot use actions.¶
The structure of ietf-cmis-control is shown below:¶
module: ietf-cmis-control
augment /if:interfaces/if:interface:
+--rw cmis-control
+--ro cmis-enabled? boolean
+--ro cmis-version? string
+--rw default-policy? enumeration
+--rw remote-read-allowed-pages* [page-num]
| +--rw page-num uint8
+--rw remote-write-allowed-pages* [page-num]
| +--rw page-num uint8
+--rw cmis-page* [page-num bank]
+--rw page-num uint8
+--rw bank uint8
+--ro page-access-type? access-type
+--rw description? string
+--rw value* [offset]
+--rw offset uint8
+--rw size uint8
+--ro value-access-type? access-type
+--rw value-data binary
+--rw description? string
¶
The allowlists ('remote-read-allowed-pages' and 'remote-write-allowed-pages') are defined per page number. A page granted in an allowlist applies to all banks of that page: banks are per-lane instances of the same page structure and share the same sensitivity. Bank-granular access control is a candidate extension for a future revision if finer delegation proves necessary.¶
The YANG module of "ietf-cmis-control" is defined as below.¶
<CODE BEGINS> file "ietf-cmis-control@2026-07-12.yang"
module ietf-cmis-control {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cmis-control";
prefix cmis-ctrl;
import ietf-interfaces {
prefix if;
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Shunsuke Homma
<mailto:shunsuke.homma.ietf@gmail.com>
Editor: Hitoshi Irino
<mailto:hitoshi.irino.ntt@gmail.com>";
description
"This YANG module defines a data model for the management
of CMIS (Common Management Interface Specification) pages
as specified by OIF. It enables configuration and retrieval
of CMIS page data, including access types and value fields,
to support the management of pluggable optical modules via
NETCONF or RESTCONF.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
revision "2026-07-12" {
description
"Changed the key of the cmis-page list to 'page-num bank' to
support banked pages. Renamed access-type enums to avoid
'/' in enum names. Adopted inclusive terminology
(allowlist).";
reference
"I-D.hi-ccamp-cmis-control-yang-04";
}
revision "2026-05-12" {
description
"Revised control model to use an allowlist approach.
Added remote-read-allowed-pages for granular access control.";
reference
"I-D.hi-ccamp-cmis-control-yang-02";
}
revision "2025-04-21" {
description
"Initial revision.";
reference
"I-D.hi-ccamp-cmis-control-yang-00";
}
/*
* CMIS control data nodes
*/
typedef access-type {
type enumeration {
enum rw {
description "A readable and writable element.";
}
enum rww {
description "A readable and writable element that can be
modified by the module.";
}
enum ro {
description "A read-only element.";
}
enum wo {
description "A write-only element.";
}
enum wo-sc {
description "A write-only element with self-clearing side
effect.";
}
enum ro-cor {
description "A read-only element with clear-on-read side
effect.";
}
}
description
"Defines access types for CMIS elements as defined in
OIF-CMIS.";
}
grouping cmis-page {
description
"Parameters stored in the CMIS page";
leaf page-num{
type uint8 {
range "0 .. 255";
}
mandatory true;
description
"The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description
"The banks corresponding to the CMIS page.";
}
leaf page-access-type {
type access-type;
config false;
description "Access type of the CMIS page.";
}
leaf description {
type string;
description
"The description of the CMIS page.";
}
list value {
key "offset";
description
"The value contained in the CMIS page.";
leaf offset {
type uint8;
mandatory true;
description
"The memory address of the value.";
}
leaf size {
type uint8 {
range "1 .. 128";
}
mandatory true;
description
"The memory size of the value.";
}
leaf value-access-type {
type access-type;
config false;
description "Access type of the target value.";
}
leaf value-data {
type binary;
mandatory true;
description
"The data contained in the value. It is writable only
when the access-type is not Read-Only or Read-Only with
clear-on-read side effect.";
}
leaf description {
type string;
description
"The description of the value.";
}
}
}
grouping cmis-pages {
description
"The list of the accessible CMIS pages supported by the
pluggable device accommodated into the interface.";
list cmis-page {
key "page-num bank";
description "A CMIS page supported by the device.";
uses cmis-page;
}
}
grouping cmis-control {
description
"Parameters for CMIS control and governance.";
leaf cmis-enabled {
type boolean;
default "false";
config false;
description
"The availability of the CMIS for control the pluggable
device equipped in the interface. If the device does not
support CMIS, this value is false.";
}
leaf cmis-version {
type string;
config false;
description
"The version of the CMIS by the pluggable device.";
}
leaf default-policy {
type enumeration {
enum disabled {
description
"Remote access is completely disabled for pages not
listed in the allowlists.";
}
enum read-only {
description
"Remote access is restricted to monitoring only for pages
not listed in 'remote-write-allowed-pages'.";
}
}
default "read-only";
description
"Defines the default access policy for CMIS pages.";
}
list remote-read-allowed-pages {
key "page-num";
description
"An allowlist of pages that are allowed to be READ
by a remote controller, even if the default-policy
is 'disabled'. This list is useful when
'default-policy' is set to 'disabled' but specific
pages need to be monitored.
Note: this list authorizes access to pages only; it does not
extend to Lower Memory (Address 0-127), which is independent
of page selection. Care should be taken with remote reads of
Lower Memory, as it may contain Clear-on-Read (CoR)
registers managed by the Host NOS; see the Security
Considerations of
this document.";
leaf page-num {
type uint8;
description "The CMIS page number allowed for remote read.";
}
}
list remote-write-allowed-pages {
key "page-num";
description
"An allowlist of pages that are allowed to be modified by
a remote controller (Read/Write).
If a page is listed in both this list and
'remote-read-allowed-pages', this list takes precedence,
granting Read/Write access.
Note: inclusion of a page in this list does not authorize
writes to Lower Memory (Address 0-127), which is independent
of page selection and contains critical Host management
flags. Remote writes to Lower Memory MUST NOT be permitted;
see the Security Considerations of this document.
When a page is removed from this list, the write
delegation for that page is revoked and the Host NOS
MUST strictly enforce its local configuration
(running-config) on that page. Values modified by a
remote controller MUST be overwritten by the Host's
local configuration or reset to default values to
maintain configuration consistency. Note that
'default-policy' does not affect pages listed here;
it governs only pages that are not present in either
allowlist.";
leaf page-num {
type uint8;
description "The CMIS page number allowed for remote write.";
}
}
uses cmis-pages;
}
/*
* Augment Interface
*/
augment "/if:interfaces/if:interface" {
description "Augments interface with CMIS control parameters.";
container cmis-control {
description "Container for CMIS control.";
uses cmis-control;
}
}
}
<CODE ENDS>¶
This document provides a more primitive YANG data model for CMIS access and control. This is called "ietf-cmis-control-primitive" or "primitive mode"; it doesn't manage supplemental information, such as access-types or descriptions, of the fields in a CMIS page, and treats accessed memory as a flat data structure.¶
This model enables the implementation of the server (i.e., network node) side to be simple, but on the other hand, the client (i.e., controller) side needs strict management of the data of CMIS pages. Note that the simplification concerns the handling of metadata (access types and descriptions), not the access governance: enforcing the governance is a lightweight per-page lookup and is required in both modes. For example, when a client sends a request to change any value, it needs to comprehend the page number, the offset, and the data size in which the data is contained.¶
Access via the primitive mode is subject to the same access governance as the base module: the 'default-policy' and the allowlists of "ietf-cmis-control" apply equally to primitive-mode access, and the prohibited regions (writes to Lower Memory, and the CDB/firmware pages) remain non-delegable regardless of which module is used. The primitive mode simplifies the data representation; it does not provide a way to bypass the governance.¶
The tree diagram of "ietf-cmis-control-primitive" is shown below:¶
module: ietf-cmis-control-primitive
augment /if:interfaces/if:interface:
+--rw cmis-control-primitive
+--ro cmis-enabled? boolean
+--ro cmis-version? string
+--rw primitive-cmis-page* [page-num bank offset]
+--rw page-num uint8
+--rw bank uint8
+--rw offset uint8
+--rw size uint8
+--rw value binary
¶
The "ietf-cmis-control-primitive" module is defined as below.¶
<CODE BEGINS> file "ietf-cmis-control-primitive@2026-07-12.yang"
module ietf-cmis-control-primitive {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-cmis-control-primitive";
prefix cmis-ctrl-pm;
import ietf-interfaces {
prefix if;
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Shunsuke Homma
<mailto:shunsuke.homma.ietf@gmail.com>
Editor: Hitoshi Irino
<mailto:hitoshi.irino.ntt@gmail.com>";
description
"This YANG module defines a primitive data model for the
management of CMIS (Common Management Interface Specification)
pages as specified by OIF. It treats CMIS page memory as a
flat data structure without supplemental information such as
access types or descriptions, to support the management of
pluggable optical modules via NETCONF or RESTCONF.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
revision "2026-07-12" {
description
"Changed the key of the primitive-cmis-page list to
'page-num bank offset' so that multiple memory regions
can be held simultaneously.";
reference
"I-D.hi-ccamp-cmis-control-yang-04";
}
revision "2026-06-10" {
description
"Restored the datastore-based module definition; the module
body in the previous revisions of this document had been
erroneously replaced with action definitions.";
reference
"I-D.hi-ccamp-cmis-control-yang-03";
}
revision "2025-04-21" {
description
"Initial revision.";
reference
"I-D.hi-ccamp-cmis-control-yang-00";
}
/*
* Primitive Mode of CMIS control data nodes
*/
grouping primitive-cmis-page {
description
"Parameters stored in the CMIS page as flat data structure";
leaf page-num {
type uint8 {
range "0 .. 255";
}
description
"The number of the CMIS page.";
}
leaf bank {
type uint8;
description
"The bank corresponding to the CMIS page.";
}
leaf offset {
type uint8;
description
"The memory address of the value.";
}
leaf size {
type uint8 {
range "1 .. 128";
}
mandatory true;
description
"The memory size of the value.";
}
leaf value {
type binary;
mandatory true;
description
"The actual data to write to the CMIS memory.";
}
}
grouping cmis-control-primitive {
description
"Parameters for primitive CMIS control of the pluggable
device equipped in the interface.";
leaf cmis-enabled {
type boolean;
default "false";
config false;
description
"The availability of the CMIS for control the pluggable
device equipped in the interface. If the device does not
support CMIS, this value is false.";
}
leaf cmis-version {
type string;
config false;
description
"The version of the CMIS by the pluggable device.";
}
list primitive-cmis-page {
key "page-num bank offset";
description
"A flat representation of CMIS page memory.";
uses primitive-cmis-page;
}
}
/*
* Augment Interface
*/
augment "/if:interfaces/if:interface" {
description
"Augments interface with primitive CMIS control parameters.";
container cmis-control-primitive {
description
"Container for primitive CMIS control.";
uses cmis-control-primitive;
}
}
}
<CODE ENDS>¶
The "ietf-cmis-control-action" module defines action-based control of CMIS pages using YANG 1.1 actions [RFC7950].¶
module: ietf-cmis-control-action
augment /if:interfaces/if:interface:
+---x cmis-read
| +---w input
| | +---w page uint8
| | +---w bank uint8
| | +---w offset uint8
| | +---w size uint8
| +--rw output
| +--rw data? binary
+---x cmis-write
+---w input
| +---w page uint8
| +---w bank uint8
| +---w offset uint8
| +---w data binary
+--rw output
+--rw status? enumeration
+--rw post-write-value? binary
¶
The YANG module of "ietf-cmis-control-action" is defined as below.¶
<CODE BEGINS> file "ietf-cmis-control-action@2026-07-12.yang"
module ietf-cmis-control-action {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cmis-control-action";
prefix cmis-ctrl-act;
import ietf-interfaces {
prefix if;
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Shunsuke Homma
<mailto:shunsuke.homma.ietf@gmail.com>
Editor: Hitoshi Irino
<mailto:hitoshi.irino.ntt@gmail.com>";
description
"This YANG module defines a data model for action-based
management of CMIS (Common Management Interface Specification)
pages as specified by OIF. It enables configuration and
retrieval of CMIS page data, including access types and value
fields, to support the management of pluggable optical modules
via NETCONF or RESTCONF.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
revision "2026-07-12" {
description
"Adopted inclusive terminology (allowlist).";
reference
"I-D.hi-ccamp-cmis-control-yang-04";
}
revision "2026-05-12" {
description
"Updated action definitions to respect governance policy
defined in ietf-cmis-control.";
reference
"I-D.hi-ccamp-cmis-control-yang-02";
}
revision "2025-10-11" {
description "Initial revision.";
reference
"I-D.hi-ccamp-cmis-control-yang-01";
}
augment "/if:interfaces/if:interface" {
description
"Add CMIS read/write actions under interface.";
action cmis-read {
description
"Read CMIS register via action context.
The operation MUST respect the governance policy defined
in the 'cmis-control' container of the target interface.
If the target page is not accessible (e.g., default-policy
is 'disabled' and the page is not in the read/write
allowlists), the server MUST return an error.
Note: Care should be taken when accessing Lower Memory
(Address 0-127) as it may contain
Clear-on-Read registers.";
input {
leaf page {
type uint8;
mandatory true;
description "The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description "The banks corresponding to the CMIS page.";
}
leaf offset {
type uint8;
mandatory true;
description "The memory address of the value.";
}
leaf size {
type uint8{
range "1 .. 128";
}
mandatory true;
description "The memory size of the value.";
}
}
output {
leaf data {
type binary;
description "Raw register data.";
}
}
}
action cmis-write {
description
"Write CMIS register data via action context.
The operation MUST respect the governance policy defined
in the 'cmis-control' container of the target interface.
If the target page is not in the
'remote-write-allowed-pages' list, the server MUST
reject the request. Writing to Lower Memory
(Address 0-127) MUST NOT be performed to prevent
interference with Host management.";
input {
leaf page {
type uint8;
mandatory true;
description "The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description "The banks corresponding to the CMIS page.";
}
leaf offset {
type uint8;
mandatory true;
description "The memory address of the value.";
}
leaf data {
type binary;
mandatory true;
description "Data to write.";
}
}
output {
leaf status {
type enumeration {
enum success {
description "Write operation succeeded.";
}
enum not-permitted {
description
"Write request was rejected due to access-type or
governance policy (e.g., page not in allowlist).";
}
enum io-error {
description "I/O error during write.";
}
enum invalid-params {
description "Bad parameters";
}
}
description "Result of the write operation.";
}
leaf post-write-value {
type binary;
description
"Optional read-back of the target value after write.
Present only if the implementation performed a read-back
(e.g., for 'rw' registers). Not present for 'wo'
registers or when no-readback was
requested/possible.";
}
}
}
}
}
<CODE ENDS>¶
The "ietf-cmis-control-rpc" module provides a schema to control CMIS pages with NETCONF RPC.¶
The tree diagram of "ietf-cmis-control-rpc" is shown below.¶
module: ietf-cmis-control-rpc
rpcs:
+---x cmis-read
| +---w input
| | +---w interface-name -> /if:interfaces/interface/name
| | +---w page uint8
| | +---w bank uint8
| | +---w offset uint8
| | +---w size? uint8
| +--ro output
| +--ro data? binary
+---x cmis-write
+---w input
| +---w interface-name -> /if:interfaces/interface/name
| +---w page uint8
| +---w bank uint8
| +---w offset uint8
| +---w data binary
+--ro output
+--ro status? enumeration
+--ro post-write-value? binary
¶
The YANG module of "ietf-cmis-control-rpc" is defined as below.¶
<CODE BEGINS> file "ietf-cmis-control-rpc@2026-07-12.yang"
module ietf-cmis-control-rpc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cmis-control-rpc";
prefix cmis-ctrl-rpc;
import ietf-interfaces {
prefix if;
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Shunsuke Homma
<mailto:shunsuke.homma.ietf@gmail.com>
Editor: Hitoshi Irino
<mailto:hitoshi.irino.ntt@gmail.com>";
description
"This YANG module defines a data model for the management
of CMIS (Common Management Interface Specification) pages
as specified by OIF with RPC. It enables configuration and
retrieval of CMIS page data, including access types and
value fields, to support the management of pluggable
optical modules via NETCONF or RESTCONF.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
revision "2026-07-12" {
description
"Adopted inclusive terminology (allowlist).";
reference
"I-D.hi-ccamp-cmis-control-yang-04";
}
revision "2026-05-12" {
description
"Updated RPC definitions to respect governance policy
defined in ietf-cmis-control.";
reference
"I-D.hi-ccamp-cmis-control-yang-02";
}
revision "2025-10-11" {
description
"Initial revision.";
reference
"I-D.hi-ccamp-cmis-control-yang-01";
}
rpc cmis-read {
description
"Read a CMIS register from a pluggable DCO transceiver.
The operation MUST respect the governance policy defined
in the 'cmis-control' container of the target interface.
Note: Care should be taken when accessing Lower Memory
(Address 0-127) as it may contain
Clear-on-Read registers.";
input {
leaf interface-name {
type leafref{
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description "Target interface name.";
}
leaf page {
type uint8;
mandatory true;
description "The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description "The bank of the CMIS page.";
}
leaf offset {
type uint8;
mandatory true;
description "The memory address of the value.";
}
leaf size {
type uint8;
default 1;
description "Number of bytes to read.";
}
}
output {
leaf data {
type binary;
description "Raw register data.";
}
}
}
rpc cmis-write {
description
"Write CMIS register data to a pluggable module.
The operation MUST respect the governance policy defined
in the 'cmis-control' container of the target interface.
If the target page is not in the
'remote-write-allowed-pages' list, the server MUST
reject the request. Writing to Lower Memory
(Address 0-127) MUST NOT be performed to prevent
interference with Host management.";
input {
leaf interface-name {
type leafref{
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description "Target interface name.";
}
leaf page {
type uint8;
mandatory true;
description "The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description "The banks corresponding to the CMIS page.";
}
leaf offset {
type uint8;
mandatory true;
description "The memory address of the value.";
}
leaf data {
type binary;
mandatory true;
description "Data to write.";
}
}
output {
leaf status {
type enumeration {
enum success {
description "Write operation succeeded.";
}
enum not-permitted {
description
"Write request was rejected due to access-type or
governance policy (e.g., page not in allowlist).";
}
enum io-error {
description "I/O error during write.";
}
enum invalid-params {
description "Bad parameters provided.";
}
}
description "Result of the write operation.";
}
leaf post-write-value {
type binary;
description
"Optional read-back of the target value after write.
Present only if the implementation performed a read-back
(e.g., for 'rw' registers). Not present for 'wo' registers
or when no-readback was requested/possible.";
}
}
}
}
<CODE ENDS>¶
The "ietf-cmis-monitor" module provides monitoring capabilities for CMIS-based optical modules.¶
The tree diagram of "ietf-cmis-monitor" is shown below.¶
module: ietf-cmis-monitor
+--rw monitors
+--rw monitor-rule* [id]
+--rw id string
+--rw interface-name -> /if:interfaces/interface/name
+--rw monitor-target
| +--rw page uint8
| +--rw bank uint8
| +--rw offset uint8
| +--rw size? uint8
+--rw condition
| +--rw value-encoding? enumeration
| +--rw scale-factor? decimal64
| +--rw condition-type enumeration
| +--rw threshold? decimal64
| +--rw delta-rate? decimal64
+--rw interval-ms? uint32
+--rw enabled? boolean
notifications:
+---n cmis-monitor-event
+--ro interface-name? string
+--ro rule-id? string
+--ro monitor-target
| +--ro page uint8
| +--ro bank uint8
| +--ro offset uint8
| +--ro size? uint8
+--ro condition-type? enumeration
+--ro current-value? binary
+--ro threshold? decimal64
+--ro delta-rate? decimal64
+--ro timestamp? yang:date-and-time
¶
The YANG module of "ietf-cmis-monitor" is defined as below.¶
<CODE BEGINS> file "ietf-cmis-monitor@2026-07-12.yang"
module ietf-cmis-monitor {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cmis-monitor";
prefix cmis-mon;
import ietf-interfaces {
prefix if;
}
import ietf-yang-types {
prefix yang;
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
Editor: Shunsuke Homma
<mailto:shunsuke.homma.ietf@gmail.com>
Editor: Hitoshi Irino
<mailto:hitoshi.irino.ntt@gmail.com>";
description
"This module provides monitoring capabilities for CMIS-based
optical modules. Users can define monitor rules for CMIS
registers identified by page/bank/offset/size. Notifications
are generated when threshold or delta-rate conditions are met.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision "2026-07-12" {
description
"Added value-encoding and scale-factor to define how raw
register data is interpreted for threshold and delta-rate
comparison.";
reference
"I-D.hi-ccamp-cmis-control-yang-04";
}
revision "2025-10-11" {
description "Initial revision.";
reference
"I-D.hi-ccamp-cmis-control-yang-01";
}
grouping monitor-target {
description
"Target CMIS register to monitor.";
leaf page {
type uint8;
mandatory true;
description "The number of the CMIS page.";
}
leaf bank {
type uint8;
mandatory true;
description "The bank of the CMIS page.";
}
leaf offset {
type uint8;
mandatory true;
description "The memory address of the value.";
}
leaf size {
type uint8 {
range "1 .. 128";
}
description "The memory size of the monitored value.";
}
}
container monitors {
description "Container for all monitor rules.";
list monitor-rule {
key "id";
description "Monitoring rule.";
leaf id {
type string;
description "Unique identifier of the rule.";
}
leaf interface-name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description "Target interface of the monitored CMIS module.";
}
container monitor-target {
description "Target CMIS register details.";
uses monitor-target;
}
container condition {
description
"Condition to trigger notification. For 'threshold' and
'delta-rate' conditions, the monitored register data is
interpreted as a number according to 'value-encoding'
and 'scale-factor', and the result is compared against
'threshold' or 'delta-rate'. For numeric interpretation,
the size of the monitored value MUST be 8 bytes or
less.";
leaf value-encoding {
type enumeration {
enum unsigned-int {
description
"The register data is interpreted as a big-endian
unsigned integer.";
}
enum signed-int {
description
"The register data is interpreted as a big-endian
two's-complement signed integer.";
}
}
default "unsigned-int";
description
"How the raw register data is interpreted as a number
before comparison.";
}
leaf scale-factor {
type decimal64 {
fraction-digits 6;
}
default "1.0";
description
"Multiplier applied to the interpreted integer value
before comparison (e.g., to apply CMIS-defined scaling
of monitored values).";
}
leaf condition-type {
type enumeration {
enum threshold {
description "Condition based on crossing a threshold.";
}
enum delta-rate {
description "Condition based on a rate of change.";
}
}
mandatory true;
description "Type of condition.";
}
leaf threshold {
type decimal64 {
fraction-digits 2;
}
description
"Threshold value for triggering notification
(only used for threshold type).";
}
leaf delta-rate {
type decimal64 {
fraction-digits 2;
}
description
"Maximum allowed change per interval (only used for
delta-rate type).";
}
}
leaf interval-ms {
type uint32;
default 1000;
description "Monitoring interval in milliseconds.";
}
leaf enabled {
type boolean;
default true;
description "Enable or disable this monitor rule.";
}
}
}
notification cmis-monitor-event {
description
"Notification raised when monitor rule condition is met.";
leaf interface-name {
type string;
description "Interface name of the monitored module.";
}
leaf rule-id {
type string;
description "ID of the rule that triggered this notification.";
}
container monitor-target {
description "Target CMIS register that triggered the event.";
uses monitor-target;
}
leaf condition-type {
type enumeration {
enum threshold {
description "Triggered by crossing a threshold.";
}
enum delta-rate {
description "Triggered by a rate of change.";
}
}
description "The type of condition that was met.";
}
leaf current-value {
type binary;
description "Current value of the monitored register.";
}
leaf threshold {
type decimal64 {
fraction-digits 2;
}
description "Threshold value (present if threshold type).";
}
leaf delta-rate {
type decimal64 {
fraction-digits 2;
}
description "Delta-rate value (present if delta-rate type).";
}
leaf timestamp {
type yang:date-and-time;
description "Time when the notification was generated.";
}
}
}
<CODE ENDS>¶
Adding a page to 'remote-write-allowed-pages' delegates write control of that page to the remote system. While a page is delegated, the host NOS MUST NOT autonomously modify registers on that page, except for safety-related intervention (e.g., shutting down a transmitter); after such intervention, the host SHOULD notify the remote system (e.g., via the ietf-cmis-monitor module).¶
Removing a page from 'remote-write-allowed-pages' revokes the write delegation for that page. Setting 'default-policy' to 'disabled' revokes the implicit read access to pages that are not present in either allowlist; it does not revoke the write delegation for pages that remain in 'remote-write-allowed-pages'. Upon revocation of a write delegation, the host NOS MUST enforce its local configuration on the affected page, overwriting values modified by the remote controller or resetting them to default values, as specified in the ietf-cmis-control module. Revocation takes effect for operations initiated after the governance change; implementations SHOULD reject in-flight remote writes that have not yet been applied.¶
The mechanisms in this document provide low-level access to module registers and are intended for controlled environments: a single administrative domain in which the remote controller is operated by, or trusted by, the operator of the host device.¶
A staged deployment is RECOMMENDED. Initial use is expected in lab validation, bring-up, and troubleshooting. In production networks, deployments SHOULD start with read-only and monitoring-centric use, and SHOULD enable write access only for specific pages and procedures that have been validated in advance (e.g., delegated vendor custom pages). This document is not intended to provide a general-purpose provisioning path that replaces abstracted data models where they exist. Settings that change the host's interface inventory (e.g., breakout configuration) remain the responsibility of the host's interface and platform management; the use of this model assumes that the interface structure is consistent with the module configuration.¶
Concrete examples of custom-page usage, together with an analysis of why their exposure does not harm host operation, are provided in Appendix D. A summary of deployment models for pluggable management, and how the governance settings of this document map to them, is provided in Appendix C.¶
The 'ietf-cmis-control' module represents page memory as YANG data nodes. Retrieving the operational state of the cmis-page/value subtree implies reading the corresponding module memory over the host-internal management bus (e.g., i2c), which is slow and shared with host-critical module management. An unfiltered retrieval, or frequent polling of this subtree, can therefore transfer large amounts of data and saturate the management bus.¶
For on-demand register access, clients SHOULD use the targeted operations defined in 'ietf-cmis-control-action' or 'ietf-cmis-control-rpc', which read or write only the requested offset and size. The datastore model is intended primarily for configuring the access governance (default-policy and the allowlists), discovering supported pages, and holding a bounded set of values of interest. For change-driven data collection, the 'ietf-cmis-monitor' module SHOULD be used instead of polling the datastore.¶
Servers SHOULD support subtree or XPath filtering for these nodes, MAY populate value data on demand, and SHOULD bound the amount of module memory readable in a single retrieval. Implementations SHOULD rate-limit remote read and write operations and MUST enforce a lower bound on the monitoring interval ('interval-ms'); the specific limits are implementation and deployment specific. Note that the allowlists also bound the set of pages exposed to a remote system.¶
[Note to the RFC Editor: Please remove this entire section, as well as the reference to [RFC7942], before publication.]¶
This section records the status of known implementations of the data models defined by this specification at the time of posting of this Internet-Draft, following the process described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.¶
Organization: [TBD]¶
Implementation: [TBD - brief description, e.g., an implementation of the ietf-cmis-control-primitive module on the platform device side]¶
Maturity level: [TBD - e.g., prototype / research / production]¶
Coverage: [TBD - which modules and which parts are implemented]¶
Contact: [TBD]¶
This section analyzes the attack surface introduced by the data models in this document, distinguishes it from access paths that exist independently of this document, and maps each identified risk to a corresponding control.¶
Register-level access to a pluggable module is not, by itself, a capability introduced by this document. The register map of a module, including vendor-specific custom pages, is readable by anyone with physical access to the module, and host platforms commonly provide local diagnostic mechanisms that expose it. What this document introduces is a remote access path to those registers. The security objective is therefore not to prevent register access as such, but to ensure that remote access is explicitly delegated, bounded in scope, auditable, and revocable. The page-level governance mechanism of the 'ietf-cmis-control' module exists to meet this objective: no page is remotely writable unless the operator has explicitly delegated it, and the delegation itself is recorded in the configuration and is therefore auditable.¶
Delegating a page transfers operational responsibility for that page, including the side effects of read operations. In particular, registers with clear-on-read (CoR) semantics can be read meaningfully by only one party: if a remote system reads such a register, the host NOS may miss the corresponding event, and vice versa. Consequently, a page that the host NOS needs to consult for its own operations SHOULD NOT be delegated; conversely, once a page is delegated, the responsibility for reading it, including any CoR semantics, rests with the remote system. Conflicts arising from concurrent use of a delegated page by both parties are a delegation design error rather than a protocol defect; the handover behavior when delegation is granted or revoked is specified in Section 5.¶
Certain regions of the CMIS address space MUST NOT be delegated under any governance configuration. Writes to Lower Memory MUST NOT be permitted, as it contains host management flags and page-selection registers whose modification would corrupt the host NOS's own module management. In addition, the firmware management pages (the Command Data Block (CDB) pages, 9Fh - AFh) MUST NOT be included in 'remote-write-allowed-pages': write access to these pages could be used to initiate a firmware update and inject malicious firmware into the module, which, unlike a misconfigured register value, constitutes a persistent compromise. These prohibitions apply independently of, and take precedence over, any operator configuration. Furthermore, an implementation MAY impose additional system-level restrictions that limit the set of pages exposed to remote systems below what the operator has configured; such restrictions take precedence over the operator's configuration, and pages so restricted are treated as if they were not present in the allowlists. A mechanism for advertising such system-level restrictions is under consideration for a future revision of this document.¶
Threats that stem from misconfigured delegation, such as allowlisting standard pages that affect transmission characteristics, are addressed by the deployment guidance in Section 6. The residual risk that is genuinely new in this document is resource exhaustion of the module management bus; this risk and the corresponding controls are specified in Section 7.¶
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
Unlike typical YANG data models, the models in this document provide raw register-level access to the pluggable device. NACM controls access at the granularity of data nodes and operations, and it cannot restrict access based on the values of RPC or action input parameters (e.g., the target page number). Therefore, this document additionally defines a page-level governance mechanism in the 'ietf-cmis-control' module that complements NACM:¶
default-policy: Determines the access level for pages NOT explicitly listed in the allowlists. The default is 'read-only'. Setting this to 'disabled' blocks all remote access to pages that are not explicitly allowed.¶
remote-read-allowed-pages: An allowlist that explicitly permits remote read access to specific CMIS pages, even when default-policy is 'disabled'.¶
remote-write-allowed-pages: An allowlist that explicitly permits remote write access to specific CMIS pages. Pages listed here are under remote control. If a page appears in both lists, write access takes precedence.¶
There are a number of data nodes and operations defined in these YANG modules that are writable/creatable/deletable or invocable and that are particularly sensitive or vulnerable in some network environments. Write operations to these data nodes and invocation of these operations without proper protection can have a negative effect on network operations:¶
/if:interfaces/if:interface/cmis-control/default-policy, remote-read-allowed-pages, and remote-write-allowed-pages: Misconfiguration of these nodes can expose sensitive pages to an untrusted remote system or break the page-level governance described above. Write access to these nodes SHOULD be restricted to the operator of the platform device via NACM.¶
/if:interfaces/if:interface/cmis-control/cmis-page/value/value-data, the 'cmis-write' action and RPC, and the 'primitive-cmis-page' list: Arbitrary register writes can modify transmitter characteristics such as output power and frequency, which may cause severe interference with other active wavelengths in the optical network. Writes to Command Data Block (CDB) pages (9Fh - AFh) can initiate firmware updates; an attacker with write access to these pages could attempt to inject malicious firmware into the module. Writes to Lower Memory MUST NOT be permitted, as it contains critical host management flags.¶
/monitors/monitor-rule (ietf-cmis-monitor): A monitor rule with a very small 'interval-ms' can saturate the management bus (e.g., i2c) shared with the host NOS, resulting in a denial of service against local module management. Implementations SHOULD enforce a lower bound on the polling interval.¶
Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. In particular, vendor identification and detailed diagnostic data can reveal information about the network design. In addition, reading registers with clear-on-read (CoR) semantics has side effects; the delegation principle for such registers is discussed in Section 9.1.¶
The operator MUST ensure that the pages delegated to the remote system (via the allowlists) do not overlap with pages required for the host NOS's basic link establishment operations.¶
Regarding the use of the primitive mode, the control rights of the accessible pages are delegated to a controller. Therefore, it is recommended that this mode be used only when the controller can be trusted, for example, when the controlled device and the controller are managed by the same operator. Otherwise, specific pages which may affect data plane signaling SHOULD NOT be exposed, by using access control features such as NACM [RFC8341].¶
This document does not define mechanisms for the atomicity or mutual exclusion of multi-step CMIS operations (e.g., CDB command sequences) between the host NOS and a remote system; coordination of such operations is the responsibility of the operator and is out of scope for this document.¶
This document requests IANA to register the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
URI: urn:ietf:params:xml:ns:yang:ietf-cmis-control Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-cmis-control-primitive Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-cmis-control-action Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-cmis-control-rpc Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-cmis-monitor Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.¶
This document also requests IANA to register the following YANG modules in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group.¶
Name: ietf-cmis-control Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-cmis-control Prefix: cmis-ctrl Reference: RFC XXXX Name: ietf-cmis-control-primitive Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-cmis-control-primitive Prefix: cmis-ctrl-pm Reference: RFC XXXX Name: ietf-cmis-control-action Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-cmis-control-action Prefix: cmis-ctrl-act Reference: RFC XXXX Name: ietf-cmis-control-rpc Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-cmis-control-rpc Prefix: cmis-ctrl-rpc Reference: RFC XXXX Name: ietf-cmis-monitor Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-cmis-monitor Prefix: cmis-mon Reference: RFC XXXX¶
RFC Editor Note: Please replace XXXX with the RFC number assigned to this document and remove this note.¶
The following individuals contributed to the development and review of this document:¶
Kazuya Anazawa (NTT)¶
Email: kazuya.anazawa@ntt.com¶
This document introduces two patterns to implement a client using an interface in which this YANG data model is available:¶
+-----------------------+
| Controller/NMS |
+-----------------------+
A
| This YANG over NETCONF,
| RESTCONF or RPC.
|
V
+-----------------------+
| Platform Device |
| ,---------------. |
| | NOS | |
| `---------------' |
| A |
| | CMIS via |
| V i2c bus |
| +-------+ |
+-------| DCO |-------+
+-------+
+-----------------------+
| Controller/NMS |
+-----------------------+
A
| Generic/abstracted Data Model
| over NETCONF/RESTCONF or REST API
+------+
+------------------|----+
| Platform Device | |
| V |
| This YANG over ,---. |
| NETCONF etc. | TPA | |
| +-----> | APL | |
| | `---' |
| ,---V-----------. |
| | NOS | |
| `---------------' |
| A |
| | CMIS via |
| V i2c bus |
| +-------+ |
+-------| DCO |-------+
+-------+
Several deployment models for the management of pluggable DCO transceivers in packet devices have been discussed in the industry, notably in [I-D.poidt-ccamp-actn-poi-pluggable] and [I-D.davis-ccamp-photonic-plug-control-arch]; a vendor summary of these models is given in [CIENA-MGMT]. In brief:¶
This document does not mandate any of these models. The governance settings of the 'ietf-cmis-control' module allow an operator to select, and mix at page granularity, the effective model: setting 'default-policy' to 'disabled' with empty allowlists corresponds to Option 2; the default 'read-only' policy corresponds to Option 1; and listing selected pages in 'remote-write-allowed-pages' realizes a page-scoped variant of Option 3, bounded by the safeguards described in Section 9.1.¶
This appendix gives illustrative, vendor-neutral examples of custom-page usage together with an analysis of why exposing them under the governance of this document does not harm host operation. The examples follow the threat model in Section 9.1: they involve only vendor-designated custom pages, never Lower Memory or the firmware management pages, and write access exists only where the operator has explicitly delegated the page.¶
These examples are illustrative. Concrete register layouts are vendor specific; a future revision may extend this appendix with additional examples based on implementation experience.¶