[CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt

[Italo Busi <[e-mail]>]

Hi Shunsuke, all,

Thanks for the useful discussion on this draft.

IMHO, this draft is addressing different items and it would be worthwhile analyzing them independently.

The first item is the use case described in section 2.1.1 of draft-hi-ccamp-cmis-control-yang-01.

IMHO, it would be worthwhile adding the description of this use case to draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps, without assuming any specific solution.

Shunsuke can contribute to this draft participating to the bi-weekly calls or by providing some comments or text proposals to the authors (e.g., via e-mail or through github) or directly to the CCAMP WG list. In any case, I would propose the authors of draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps to take the text in draft-hi-ccamp-cmis-control-yang-01 as an input

The second item seems related to the difference in interpretation of CMIS definitions or in the existing IETF YANG models, for standardized definitions.

IMHO, the CMIS issues should be addressed by OIF (out of scope of CCAMP WG), while the IETF YANG models issues should be addressed by the CCAMP WG.

It would be good if Shunsuke or other vendors/operators share on the list the issues identified by a different interpretation of the IETF YANG models developed or under development in CCAMP WG.

The third item is related to gaps in existing IETF YAG models.

Identifying this gap is already an on-going work in the context of draft-rokui-ccamp-actn-wdm-pluggable-modelling.

It would be good if Shunsuke or other vendors/operators could contribute to the gap analysis in draft-rokui-ccamp-actn-wdm-pluggable-modelling, participating to the weekly calls or by providing some comments or text proposals to the authors (e.g., via e-mail or through github) or directly to the CCAMP WG list

The forth item is related to the requirement to support vendor-specific extensions.

Since WDM is a cutting-edge technology, vendor-specific extensions to the standards are unavoidable. Therefore, I agree that it is worthwhile defining standard solutions that are open to support vendor-specific extensions which can co-exist with standardized features.

YANG language (through vendor-specific augmentations) and CMIS (through custom pages) seems to be able to support this approach.

The issue we are facing in the use case described in section 2.1.1 of draft-hi-ccamp-cmis-control-yang-01 is that the vendor of the DCO module is not the same as the vendor of the host.

My feeling is that this issue is not only applicable to that use case but may be applicable also in other scenarios. My understanding is that a generalization of this issue is under discussion in Appendix B of draft-rokui-ccamp-actn-wdm-pluggable-modelling.

IMHO, it would be worthwhile improving the text description in Appendix B of draft-rokui-ccamp-actn-wdm-pluggable-modelling considering also the use case described in draft-hi-ccamp-cmis-control-yang.

Shunsuke can contribute to this draft participating to the bi-weekly calls or by providing some comments or text proposals to the authors (e.g., via e-mail or through github) or directly to the CCAMP WG list. In any case, I would propose the authors of draft-rokui-ccamp-actn-wdm-pluggable-modelling to take the text in draft-hi-ccamp-cmis-control-yang-01 as an input to complete Appendix B

The last item is related to the solution to support vendor-specific extensions.

I share some of the concerns expressed on the list on exposing CMIS pages on YANG.

Exposing standard CMIS pages on YANG would cause a potential conflict between the configuration done through YANG-based CMIS pages and other standardized YANG data models (that the host translates into standard CMIS page configuration in internal interface).

Exposing only custom CMIS pages would mitigate this issue and doing so through the Host OS would also mitigate some other issues expressed on the list.

However there could be still some issues when, for example, a SW/FW upgrade of the pluggable module changes the structure of the custom pages.

The CMIS: Path to Plug and Play [oiforum.com]<https://urldefense.com/v3/__https:/www.oiforum.com/wp-content/uploads/OIF-CMIS-Plug-and-Play-01.0.pdf__;!!OSsGDw!K1nBX9rO3A5CduR8G6rnz9RH-9n8OZLaVhIaL9je2zZ2i8YVgcVmiyBCakM8SEkUxasXi7d7dtfuYrdFUj8JS9v83gY$> White Paper mentioned by Gert is partially addressing the requirement to support vendor-specific extensions.

My 2 cents

Italo

From: Shunsuke Homma <[e-mail]>
Sent: mercoledì 5 novembre 2025 10:29
To: Gabriele Galimberti <[e-mail]>
Cc: Davis, Nigel <ndavis=[e-mail]>; Rokui, Reza <rrokui=[e-mail]>; Gert Grammel <ggrammel=[e-mail]>; [e-mail]; [e-mail]; Gabriele Galimberti <[e-mail]>
Subject: [CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt

Hi Nigel, Gabriele, and Sergio,


Thank you very much for your review and valuable feedback.
I fully understand the concerns about operating CMIS from an external controller. As you mentioned, for functions requiring strict real-time management, a YANG-based approach would not meet the requirements.

On the other hand, the proposed approach does not necessarily intend to delegate full DSP control to an external controller. For example, fundamental hardware management such as module insertion/removal or temperature monitoring can continue to be handled by the NOS, while only configuration aspects—where vendor-specific differences are significant—can be controlled externally. I believe this separation can effectively address the real-time concern.

As stated in the Security section, functions that should not be accessed externally can be restricted using mechanisms such as NACM. I plan to further clarify which functions should remain under NOS control and which can be safely exposed to external systems.

One important point to emphasize is that it is still the NOS that controls the DSP registers via CMIS. The proposed YANG model only allows external systems to interpret or handle certain data through the NOS, not to directly manipulate the registers. Therefore, this approach does not violate the definition of CMIS as a protocol for host–module interaction, I think.

You made a valid point that mapping CMIS registers directly into YANG models would not promote interoperability.
We agree that defining a common and standardized YANG model consistent with the device–controller architecture is the ultimate goal.
Our current intent is not to replace that effort, but rather to explore an interim, complementary solution that can help bridge the management gaps—especially for vendor-specific implementations—until such a standard model becomes available.

As discussed in the Smart Optics community, host-independent management remains an important challenge.
The current situation—where operators must wait for each vendor to support new DCO modules—restricts the flexibility of module selection and can increase costs due to vendor lock-in. As I mentioned in my previous email, this also limits the adoption of white-box platforms and open-source NOS solutions such as SONiC or Goldstone.

I sincerely appreciate your constructive comments, and I would like to continue the discussion to determine how we can best align this proposal with ongoing standardization efforts, including [I-D.rokui-ccamp-actn-wdm-pluggable-modelling].



Best regards,

Shunsuke

On Sat, Nov 1, 2025 at 12:15 AM Gabriele Galimberti <[e-mail]<mailto:[e-mail]>> wrote:
Hi Shunsike-san,

Please see below some comments on the draft-hi-ccamp-cmis-control-yang.

-              CMIS is an internal (to device) interface supporting a fast communication between two HW components.
-              The protocol is mainly implemented by SW but is supported by HW, the communication is then in real time and includes (but not limited to):
o             Polling procedure
o             Interrupt management
o             Fast counter reading / reset
o             Actions like laser shutdown, etc.
-              This requires a strict timing control that cannot be achieved via a high level protocol (like Netconf) crossing many devices.
-              In addition, requirements like streaming telemetry should be addressed shortly.

Having said that and considering your proposal addressing only proprietary information and registers I’d discourage to map the CMIS registers on Yang models.
Moreover, you correctly pointed out the different vendor implementation of CMIS IA and above all the lack of a standard model that can fully address the requirement for DCO management.
But the solution proposed to overcome these gaps is not the right path: permitting a proliferation of binary programming to configure the DCO for sure does not promote a good interoperability .
Instead, as said by Roberto,  pushing vendor for interoperable implementation of CMIS IA and for the lack of exhaustive management the good path is to work on a standard YANG solution
Consistent with the models between device and controller without any explicit exposure of CMIS registers.

Best Regards,

Gabriele and Sergio


Da: "Davis, Nigel" <ndavis=[e-mail]<mailto:[e-mail]>>
Data: mercoledì 29 ottobre 2025 alle ore 12:35
A: "Rokui, Reza" <rrokui=[e-mail]<mailto:[e-mail]>>, Gert Grammel <ggrammel=[e-mail]<mailto:[e-mail]>>, Roberto Manzotti <[e-mail]<mailto:[e-mail]>>, 'Shunsuke Homma' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Rokui, Reza" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Oggetto: [CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt

Hi Shunsuke,

I have reviewed your document and the comments below.

I agree strongly with the comments by Roberto. I recognise the challenge highlighted by the draft (which has been discussed on several occasions) but do not agree with the approach propose in your draft. Exposing raw CMIS is not the right way to approach the challenge for the various reasons highlighted by Roberto. It is important for interoperability that there is exposure of information in a normalised form consistent with the other interfaces between the device and the controller

Aligning with the views expressed by Gert, I am also concerned by the specific nature of the CMIS interface itself, for example:

  *   The mechanism for highlighting change requires polling of registers. This does not extend well over an interface to an external controller. It would be expected that the device would provide fully detailed notification of change so as to remove the need for polling.
  *   The counters need to be collected with a tight timing. The external controller needs interpreted values and thresholding, not just raw values and certainly should not need to poll counter registers. It would be expected that the device would provide the required abstraction.
It is normal to delegate functions that deal with normalisation and first stages of processing to the device.

I fully align with the comments made by Reza and agree with Reza that the authors of the draft should join us in the activity led by Reza. On the specific challenge highlighted in the draft, I suggest that we do explore how to expose the proprietary properties starting, as Gert proposed, with a framework defining the problem and scope. After that we can develop the solution. I suspect that the solution will be to provide those proprietary properties in a normalised form consistent with the remainder of the interfaces exposed by the device to the controller. We should define and scope the problem and develop the solution as part of the activity led by Reza.

I look forward to working with you.

Kind regards,

Nigel


From: Rokui, Reza <rrokui=[e-mail]<mailto:[e-mail]>>
Sent: 25 October 2025 01:39
To: Gert Grammel <ggrammel=[e-mail]<mailto:[e-mail]>>; Roberto Manzotti <[e-mail]<mailto:[e-mail]>>; 'Shunsuke Homma' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rokui, Reza <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] [CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt

Hi Shunsuke,

I also would like to provide my thoughts on your draft.
The CMIS (Common Management Interface Specification) protocol is an internal communication protocol used within a host device (such as a router). Its purpose is to allow the host to discover pluggable modules and to manage or control them.

Because CMIS operates internally within the host, it contains many technical details that do not need to be exposed to network operators. These details are essential for communication between the host and the pluggable modules, but they are generally not meaningful or relevant to operators managing the network.

As a result, CMIS defines numerous registers—spanning many pages—that primarily serve internal management functions. Most of these registers have little or no direct significance to network operators when they are managing pluggable modules or the optical services connecting them.

For this reason, the idea behind the following draft was initiated to address the objectives outlined in your draft.
In summary, the ultimate goal of this draft is to enable interoperability—allowing a pluggable module from Vendor X to be inserted into a host from Vendor Y, where the host can automatically recognize the pluggable and fully support its control and management functions, including configuration and telemetry collection.

https://datatracker.ietf.org/doc/draft-rokui-ccamp-actn-wdm-pluggable-modelling/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-rokui-ccamp-actn-wdm-pluggable-modelling/__;!!OSsGDw!P4pIyT7ZIshAxkjuNO0T6Q2PYcz43noYSgbRKBN-x8nYuO5uSNZlLnbMHmssEW771EY40Px_LiCnY1YTAkELAgCkzQ8$>

Therefore, in my opinion, it would like to ask you and the co-authors of your draft to join the efforts on [I-D.rokui-ccamp-actn-wdm-pluggable-modelling] and contribute your valuable insights to make the draft more comprehensive and robust. Please also note that our work complementing the following operator’s daft:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps/01/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps/01/__;!!OSsGDw!P4pIyT7ZIshAxkjuNO0T6Q2PYcz43noYSgbRKBN-x8nYuO5uSNZlLnbMHmssEW771EY40Px_LiCnY1YTAkEL-VOsgRI$>

Cheers,
Reza

From: Gert Grammel <ggrammel=[e-mail]<mailto:ggrammel=[e-mail]>>
Date: Friday, October 24, 2025 at 7:07 AM
To: Roberto Manzotti <[e-mail]<mailto:[e-mail]>>, 'Shunsuke Homma' <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [**EXTERNAL**] [CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt
Roberto, Shunsuke,

I downloaded OIF-CMIS-05.3 [oiforum.com]<https://urldefense.com/v3/__https:/www.oiforum.com/wp-content/uploads/OIF-CMIS-05.3.pdf__;!!OSsGDw!K1nBX9rO3A5CduR8G6rnz9RH-9n8OZLaVhIaL9je2zZ2i8YVgcVmiyBCakM8SEkUxasXi7d7dtfuYrdFUj8JGVFNVLY$> from OIF and found that the in the Introduction, the “Purpose and Scope” is defined as:


This Common Management Interface Specification (CMIS) defines a generic management communication

interface together with a generic management interaction protocol between hosts and managed modules.

And in section 1.1.1 “CMIS Specification (BASE)”
This specification, CMIS, has been developed to allow host and module software implementers to utilize a
common code base across a variety of form factors and across a variety of transmission module1 capabilities,
and to foster the possibility of vendor agnostic management for standardized module functions.

Furthermore, OIF is working on CMIS: Path to Plug and Play [oiforum.com]<https://urldefense.com/v3/__https:/www.oiforum.com/wp-content/uploads/OIF-CMIS-Plug-and-Play-01.0.pdf__;!!OSsGDw!K1nBX9rO3A5CduR8G6rnz9RH-9n8OZLaVhIaL9je2zZ2i8YVgcVmiyBCakM8SEkUxasXi7d7dtfuYrdFUj8JS9v83gY$>.

Comparing OIF with draft-hi-ccamp-cmis-control-yang-01.txt:

  *   OIF is working on an interoperable management specification that is plug&play between host and pluggable modules.
  *   https://www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt__;!!OSsGDw!K1nBX9rO3A5CduR8G6rnz9RH-9n8OZLaVhIaL9je2zZ2i8YVgcVmiyBCakM8SEkUxasXi7d7dtfuYrdFUj8J1zoBYKk$> talks about vendor-proprietary (non-agnostic) communication which is not plug&play and appears between a network controller and the pluggable module.

Irrespective of its possible merits, it doesn’t look straight to start working on https://www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt__;!!OSsGDw!K1nBX9rO3A5CduR8G6rnz9RH-9n8OZLaVhIaL9je2zZ2i8YVgcVmiyBCakM8SEkUxasXi7d7dtfuYrdFUj8J1zoBYKk$>. We’d be better off, starting with a framework defining the problem and scope.


My2c

Gert







Juniper Business Use Only
From: Roberto Manzotti <[e-mail]<mailto:[e-mail]>>
Date: Friday, 24 October 2025 at 11:36
To: 'Shunsuke Homma' <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP]Re: Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt
[External Email. Be cautious of content]

Hi Shunsuke, co-authors and WG,

I have read and reviewed the draft and providing my comments here for your consideration, but before moving to the detailed comments on the text I would like to share some general consideration about the DCO management approach proposed.

The problem that this draft is trying resolve, exposed in the introduction, is to provide a management model to support proprietary customization (custom pages) allowed by CMIS implementation agreement. Since CMIS define and allow the usage of such custom pages, this is clearly a valid use case from an operator/user perspective, but I wonder if it is correct for an SDO like IETF to define a standard model which main purpose is to enable and potentially proliferate proprietary customization; I’m worried that this short term solution may cause even worse interoperability problem in the long term. This is the main doubt that I want to share with you and the workgroup and would like to hear some other opinion on it.

In the same way the document introduction mentions the different vendor implementation of CMIS agreement, and the fact that current standard models do not fully address the needs for DCO management, as an additional problem that may require direct access to CMIS memory page. I think that the right solution for this is pushing vendor for proper interoperable implementation and filling the network management gap by proper standardization and abstraction of the DCO functions (like in the ongoing work on the cited [I-D.rokui-ccamp-actn-wdm-pluggable-modelling], where you and co-authors may for sure participate with your expertise). By-passing any kind of modelling by allowing each vendor to configure DCO trough binary programming of their pluggable does not seems to me a standardization path, but actually provide a facility that allow proliferation of proprietary implementations.
Moreover, the direct configuration (and even only the read operation in the case of “Clear On Read” pages) of CMIS register may result in host NOS misaligned with the current configuration and state of the pluggable, with the risk to disrupt the normal monitoring ,management and datapath consistence of the same.

I want to iterate again that I fully recognize the needs and use cases highlighted by this document, but I also think that this may not be right path. From my side I think that the direct access to pages that are fully defined and described by CMIS should never be allowed (neither RO), should be only accessible by the host NOS and abstracted by proper modelling as stated above. On the other side (while I still think is not a great approach for an SDO) It could be reasonable to move on with the proposal of this document only for custom pages, that are in fact defined for proprietary customization.

The rest of my comments on the various section of the document are provided below with this hardcoded limitation in mind. i.e. only custom pages manipulation is allowed.

Thanks
Best Regards
Roberto

----
#Section 2.2:
While Pattern1 clearly require the model defined in this draft to achieve the goal, I think Pattern2 do not really need it. If a “Generic/Abstracted Data Model over NETCONF/RESTCONF or REST API” (as indicated in Figure 3) is available, or under definition, I do not see any reason for pushing the NOS for the implementation of this draft and use an intermediate Third Party Application, instead of implementing directly the “Generic/abstracted DATA MODEL…” in the NOS, that in fact is what I think should be the right path for standardization.

#Section 3.1. ietf-cmis-control:
##page 11:
Leaf page-num for me SHALL allow only custom pages, range should be “176 .. 255” (BO – FF are the custom page as per CMIS 5.3 Table 8-1). I think that is not enough to limit access to the CMIS defined pages using the access control feature as described in the security consideration. The model itself should restrict the access to custom pages.

##page  13:
since both “page-num” and “bank” are required to address the memory, I think they should be both keys of the “cmis-page” list, otherwise only one entry will be allowed for every page-num, resulting in access support of only one bank for that page.

## Section 3.1 in general:
it is not clear how an implementation that support this module should provide cmis-control data when the full tree is requested  (e.g. /interfaces/interface[‘if-name’]/cmis-control , or even larger scope /interfaces/interface ), is it expected to return the binary dump of all custom pages/banks? Since I think this is the default behavior in Netconf it should be better to interact with CMIS pages only trough action/rpc making one of the other two module mandatory and leave only the control information (eg list of available/supported pages but w/o data) in this control module.

#Section 3.2. ietf-cmis-control-primitive
I have the impression that the Model definition does not match with the tree at the beginning of section. The model has just a simplified version of the cmis-read and cmis-write action also defined in the next section, while the tree does not have actions at all.

#Section 3.3. and 3.4.
Same comment of section 3.1 for limiting the model to custom page, adding a range “176 .. 255” to the page selection leaf.
I also think as, written above, that the page manipulation should only happens trough action or rpc, so one of this two modules (I would prefer action) should become mandatory

#Section 3.5. ietf-cmis-monitor
Same comment on the page range (176 .. 255)

Considering that a host can be equipped with a large number of DCO and that on each one multiple monitoring instances with different granularity can be enabled with this model, I think that could be beneficial for this section a scalability assessment on the expected number of monitor instances that an implementation should support.
I think it could also be helpful to have a pair of RO leaves in the model where the server implementation can advertise its capabilities in terms of maximum monitor instances and maximum granularity (minimum interval-ms)

# Section 4. Security Consideration
As mentioned before I think that the model itself shall limit the access to page range 176 .. 255  (custom pages).
If there would be consensus in the WG to leave the page range free in the model (could make sense if we think that the page definition is not strict and CMIS can change it in a future revision), I would suggest to change the security management ownership for protected pages in this section and move it from the client controller configuration trough ACM under the server responsibility that should block access to any page that may impact the NOS manageability and datapath consistency.

#Section 6. Normative References
There is a new rev. of OIF-CMIS , you may consider to update the reference to latest revision 5.3 of September 2024.
----


From: Shunsuke Homma <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 17, 2025 3:23 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP]Fwd: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt


Hi CCAMP,

We updated "draft-hi-ccamp-cmis-control-yang". The main updates are as follows:

- a new coauthor joined
- added supplemental information into introduction and usecases
- added new YANG modules (action, rpc, monitor)
- modified editorial issues

Your feedback would be appreciated.

Best regards,

Shunsuke

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Fri, Oct 17, 2025 at 9:52 PM
Subject: New Version Notification for draft-hi-ccamp-cmis-control-yang-01.txt
To: Hitoshi Irino <[e-mail]<mailto:[e-mail]>>, Kazuya Anazawa <[e-mail]<mailto:[e-mail]>>, Shunsuke Homma <[e-mail]<mailto:[e-mail]>>, Toru Mano <[e-mail]<mailto:[e-mail]>>, Yuji Tochio <[e-mail]<mailto:[e-mail]>>


A new version of Internet-Draft draft-hi-ccamp-cmis-control-yang-01.txt has
been successfully submitted by Shunsuke Homma and posted to the
IETF repository.

Name:     draft-hi-ccamp-cmis-control-yang
Revision: 01
Title:    A YANG Data Model for CMIS Access and Control
Date:     2025-10-17
Group:    Individual Submission
Pages:    32
URL:      https://www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hi-ccamp-cmis-control-yang-01.txt__;!!NEt6yMaO-gk!GzXm1mTYLaXIhR54pC7B3V7s1coWBrpQJLaGbatbNeKttRAxnrKoeq8M3PC8GisvNi6pn1wKQLQTL-tE5MBrzMU$>
Status:   https://datatracker.ietf.org/doc/draft-hi-ccamp-cmis-control-yang/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hi-ccamp-cmis-control-yang/__;!!NEt6yMaO-gk!GzXm1mTYLaXIhR54pC7B3V7s1coWBrpQJLaGbatbNeKttRAxnrKoeq8M3PC8GisvNi6pn1wKQLQTL-tELRMe-as$>
HTMLized: https://datatracker.ietf.org/doc/html/draft-hi-ccamp-cmis-control-yang<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hi-ccamp-cmis-control-yang__;!!NEt6yMaO-gk!GzXm1mTYLaXIhR54pC7B3V7s1coWBrpQJLaGbatbNeKttRAxnrKoeq8M3PC8GisvNi6pn1wKQLQTL-tE2wBOm-Q$>
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-hi-ccamp-cmis-control-yang-01<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-hi-ccamp-cmis-control-yang-01__;!!NEt6yMaO-gk!GzXm1mTYLaXIhR54pC7B3V7s1coWBrpQJLaGbatbNeKttRAxnrKoeq8M3PC8GisvNi6pn1wKQLQTL-tEnKEjXUM$>

Abstract:

   This document provides a YANG data model to access to and control
   CMIS for managing 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.



The IETF Secretariat