A YANG Data Model for CMIS Access and Control

A YANG Data Model for CMIS Access and Control NTT

shunsuke.homma.ietf@gmail.com

NTT West

hitoshi.irino.ge@west.ntt.co.jp

NTT

toru.mano@ntt.com

1Finity

tochio@fujitsu.com

Ciena

rrokui@ciena.com

CCAMP Working Group This document provides YANG data models to access to and control CMIS for controlling pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside. CMIS has custom pages which enables to be defined by the module vendor for its own usage, and allows to extend the uses of the optics devices. These YANG modules also allow the utilization of CMIS custom pages as a generic control mechanism.

Pluggable Digital Coherent Optics (DCO) transceivers enable routers or switches to directly connect to 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, equipped by a platform device (e.g., a switch or a router), are generally controlled by the network OS running on the device using Content Management Interoperability Specifications (CMIS), which is an open standard protocol designed to facilitate interoperability between management systems. The specification is defined in . 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.

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 , 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 ; 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 . NETCONF (Network Configuration Protocol): Mechanisms to install, manipulate, and delete the configuration of network devices. The definitions and specification is described in ; 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 . The following terms of NETCONF defined in are also used in this specification: (NETCONF) client configuration data datastore message remote procedure call (RPC) (NETCONF) server state data (NETCONF) user This document makes use of the terms defined in .

The following acronyms are used in this document: Customer Edge Command Data Block Communication Service Provider Digital Coherent Optics Digital Signal Processor Dense Wavelength Division Multiplexing Generalized Signal-to-Noise Ratio Inter-Integrated Circuit Network Operating System Network Management System Optical Transport Network Quality of Transmission Third Party Application Wavelength Division Multiplexing

The tree diagrams used in this document follow the notation defined in .

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 are augments to the ietf-interface . The details of the modules are described in . Prefix YANG module Reference if ietf-interfaces 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 usecases of this YANG data model for accessing to and control CMIS.

This YANG data model disaggregates management features for pluggable DCO transceivers which a platform device equips with 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 .

| 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 serves as an effective means to realize this decoupling. 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 CEs delegate whole the DCO transceivers management to the controller, the controller needs to monitor the DCO transceivers for detecting their failure occurred. For this case, notification-based YANG would be used .

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. ), physical layer monitoring (Ref. ), and accurate estimation (e.g., GSNR) (Ref. ).

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. May 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 is an augment to the ietf-interface. It allows the user to set the operating mode of CMIS for control pluggable devices as well as other operational parameters.

The structure of ietf-cmis-control is shown below:

Note that the values related to CMIS pages are defined in .

The YANG module of "ietf-cmis-control" is defined as below.

file "ietf-cmis-control@2026-05-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: WG List: Editor: Shunsuke Homma Editor: Hitoshi Irino "; 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-05-12" { description "Revised control model to use whitelist approach. Added remote-read-allowed-pages for granular access control."; reference "RFC XXXX: A YANG Data Model for CMIS Access and Control"; } 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 write-only element with celan-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 clean-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"; 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 whitelists."; } 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 "A whitelist 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: Lower Memory (Address 0-127) SHOULD NOT be included in this list if it contains Clear-on-Read (CoR) registers that are managed by the Host NOS."; leaf page-num { type uint8; description "The CMIS page number allowed for remote read."; } } list remote-write-allowed-pages { key "page-num"; description "A whitelist 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: Lower Memory (Address 0-127) MUST NOT be included in this list as it contains critical Host management flags. When a page is removed from this list, or when the default-policy changes to 'disabled' (and the page is not in the read-whitelist), the Host NOS MUST strictly enforce its local configuration (running-config) to the target CMIS pages. Values modified by a remote controller MUST be overwritten by the Host's local configuration or reset to default values to maintain configuration consistency."; 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; } } }

]]>






  
  
  This document provides a more primitive YANG data model for CMIS access and control. 
  This is called as "ietf-cmis-control-primitive" or "primitive mode" and it doesn't 
  manage supplemental information, such as access-types or description, of the fields in 
  a CMIS page, and treat accessed memories as flat data structure.
  
  
  
  This model enables implementation of server (i.e., network node) side to be simple, but on the other hand, 
  client (i.e., controller) side is needed strict management of data of CMIS pages. 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.
  

  
  The tree diagram of "ietf-cmis-control-primitive" is shown below:
  



  
  The "ietf-cmis-control-primitive" module is defined as below.
  

 file "ietf-cmis-control-primitive@2025-04-21.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:   
    WG List:  

    Editor:   Shunsuke Homma
      
    
    Editor:   Hitoshi Irino
      ";

  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) 2025 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 "2025-04-21" {
      description
        "Initial revision.";
      reference
        "RFC XXXX: A YANG Data Model for CMIS Access and Control";
    }

    augment "/if:interfaces/if:interface" {
      description "Add primitive CMIS read/write actions under interface.";

      action cmis-read {
        description "Read CMIS register under this interface.";
        input {
          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 "The memory size of the value.";
          }
        }
        output {
          leaf data {
            type binary;
            description "Raw register data.";
          }
        }
      }

      action cmis-write {
        description "Write CMIS register under this interface.";
        input {
          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 data {
            type binary;
            mandatory true;
            description "Data to write.";
          }
        }
      }
    }
}

]]>




  
  The "ietf-cmis-control-action" module defines actions-based controls of CMIS pages with NETCONF RPC.
  



  
  The YANG module of "ietf-cmis-control-action" is defined as below.
  

 file "ietf-cmis-control-action@2026-05-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:   
    WG List:  

    Editor:   Shunsuke Homma
      
    
    Editor:   Hitoshi Irino
      ";

  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-05-12" {
    description
      "Updated action definitions to respect governance policy 
       defined in ietf-cmis-control.";
    reference
      "RFC XXXX: A YANG Data Model for CMIS Access and Control";
  }

  revision "2025-10-11" {
    description "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for CMIS Access and Control";
  }

  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 
         whitelists), the server MUST return an error.
         Note: Care should be taken when accessing Lower Memory 
         (Address 0-127, typically Page 00h) 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 whitelist).";
            }
            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.";
        }
      }
    }
  }
}

]]>

  






  
  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.
  

 /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.
  

 file "ietf-cmis-control-rpc@2026-05-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:   
    WG List:  

    Editor:   Shunsuke Homma
      

    Editor:   Hitoshi Irino
      ";

  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-05-12" {
    description
      "Updated RPC definitions to respect governance policy 
       defined in ietf-cmis-control.";
    reference
      "RFC XXXX: A YANG Data Model for CMIS Access and Control";
  }

  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, typically Page 00h) 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 whitelist).";
          }
          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.";
      }
    }
  }
}

]]>

  



  
  The "ietf-cmis-monitor" module provides monitoring capabilities for CMIS-based optical modules.
  

  
  The tree diagram of "ietf-cmis-monitor" is shown below.
  

 /if:interfaces/interface/name
        +--rw monitor-target
        |  +--rw page      uint8
        |  +--rw bank      uint8
        |  +--rw offset    uint8
        |  +--rw size?     uint8
        +--rw condition
        |  +--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.
    
  
 file "ietf-cmis-monitor@2025-10-11.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:   
     WG List:  

    Editor:   Shunsuke Homma
      

    Editor:   Hitoshi Irino
      ";

  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 "2025-10-11" {
    description "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for CMIS Access and Control";
  }

  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.";
        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.";
    }
  }
}

]]>




  
  
  This YANG allows remote systems to control the equipped pluggable devices directly. 
  It might cause conflict of management of the pluggable devices among the platform node 
  and remote systems.
  

  
  To avoid such conflicts, a whitelist-based control mechanism is introduced.
  

  
  
    
    **default-policy**: Determines the access level for pages NOT explicitly listed in the whitelist. The default is 'read-only'. Setting this to 'disabled' blocks all remote access unless whitelisted.
    
    
    **remote-read-allowed-pages**: A whitelist that explicitly permits remote read access to specific CMIS pages, even when default-policy is disabled.
    
    
    **remote-write-allowed-pages**: A whitelist 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.
    
  
  

  
  The operator must ensure that the pages delegated to the Remote system (via the whitelist) do not overlap with pages required for the Host NOS's basic link establishment operations.
  

  
  Regarding to use of the primitive mode, the control rights of the accessible pages 
  are delegated to a controller. Therefore, it is recommended that the mode is used 
  in case that the controller can be trusted, for example, the controlled device and 
  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 
  

  

  
  
  IANA Considerations

  
  This document requests IANA to register the following YANG modules in
  the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group.
  
  
  


    RFC Editor Note: Please replace XXXX with the RFC number assigned to this document and remove this note.



  
    
      
        
          Common Management Interface Specification (CMIS) Revision 5.3
          
            OIF
          
          
        
      

      &RFC2119;
      &RFC7223;
      &RFC7950;
      &RFC8340;
    

    
      &RFC6241;
      &RFC8040;
      &RFC8341;
      
        
          Sub-Hertz Spectral Analysis of Polarization of Light in a Transcontinental Submarine Cable
          
            Google
          
          
            Google
          
          
            Google
          
          
            Google
          
          
            Caltech
          
          
        
        
        
      

      
        
          Digital Longitudinal Monitoring of Optical Fiber Communication Link
          
            NTT
          
          
            NTT
          
          
            NTT
          
          
            NTT
          
          
            NTT
          
          
            NTT
          
          
        
        
        
      

      
        
          Fast WDM provisioning with minimal probing: the first field experiments for DC exchanges
          
            NTT
          
          
            NTT
          
          
            NEC Labs America
          
          
            NEC Labs America
          
          
            Duke Univ.
          
          
            NTT
          
          
            NTT
          
          
            NEC Labs America
          
          
            Politecnico di Torino
          
          
            NTT
          
          
            NTT
          
          
            NTT
          
          
            Politecnico di Torino
          
          
            Columbia Univ.
          
          
            CONNECT Centre
          
          
            Duke Univ.
          
          
            NEC Labs America
          
          
            NEC Corp.
          
          
            NTT
          
          
        
        
        
      
    
    
    
      
      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 on Remote Host
       
      In this pattern, a controller or an NMS implements a client using this YANG data model, and controls pluggable modules 
      installed to a platform device. The overview is shown in .
      
      Application Running on the Platform Device
      
      In this pattern, a 3rd party's application running on a platform device implements a client using this YANG data model, 
      and controls pluggable modules installed to the device. That application can behave as a server using this YANG data model, 
      or provide more generic interfaces, such as REST APIs to remote systems. The overview is shown in .
      
    
    



 | APL | |
|       |        `---'  | 
|   ,---V-----------.   |
|  |       NOS       |  |
|   `---------------'   |
|           A           |
|           | CMIS via  |
|           V i2c bus   |
|       +-------+       |
+-------|  DCO  |-------+
        +-------+

]]>