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

[Shunsuke Homma <[e-mail]>]

Hi Roberto,

Sorry for the delay in replying, and thanks again for your detailed review.
Please find our responses to each of your comments below.
------------------------------
*Section 2.2*

Thank you for your comment.
Pattern 2 in this draft is not intended to represent a configuration that
does not require the proposed YANG model.
Rather, it assumes the same model as the basis and illustrates a
possible *deployment
architecture* where a container running on the NOS interacts with the
controller, using the proposed model, to control DCO modules.
The purpose of including Pattern 2 is to show that the proposed model can
also be applied to distributed or layered implementations, not limited to a
centralized controller model.

We understand, however, that the detailed analysis of Pattern 2 may not be
essential to the main contribution of this draft.
Therefore, we plan to simplify this section — for example, by moving it to
the *Use Case* section or *Appendix*, or removing it — since it mainly
discusses *implementation aspects* rather than normative elements of the
model itself.
------------------------------
*Section 3.1 (ietf-cmis-control)*

We agree with your point regarding the page-num range and the need to
restrict access to CMIS-defined pages.
If the WG reaches consensus that this draft should be *limited to custom
pages*, we will define the valid range as 176–255according to Table 8-1 in
CMIS 5.3.

We also agree with your observation that both “page-num” and “bank” should
be keys of the cmis-page list.
We will modify the model accordingly.
Regarding your question about how an implementation should behave when the
full tree is requested, our original assumption was that the system would
return a binary dump of all pages and banks.
However, we agree that this behavior is not desirable in practice.

Therefore, we will revise the draft to either require explicit
specification of both the page and bank or, as you suggested, clarify that
interaction with CMIS pages should be performed only via actions or RPCs.
------------------------------
*Section 3.2 (ietf-cmis-control-primitive)*

Thank you for pointing this out.
It seems that the action statements accidentally overwrote the correct
model during editing.
The *tree diagram* reflects the correct structure.
We will fix this issue in the next update.
------------------------------
*Sections 3.3 and 3.4*

We agree that restricting the page range (176–255) is appropriate *if* the
WG agrees to limit the model to custom pages.
We also agree that page manipulation should be performed only via *actions
or RPCs*, and we will consider making one of these modules (preferably the
action-based one) mandatory.
------------------------------
*Section 3.5 (ietf-cmis-monitor)*

We agree with your suggestion to limit the page range (176–255) under the
same condition as above.
Your proposal to include scalability considerations is also valid.
We will consider adding read-only leaves that advertise the
implementation’s capability, such as the maximum number of monitor
instances and the minimum interval supported.
------------------------------
*Section 4 (Security Considerations)*

We agree that the model itself should ideally restrict access to the custom
page range (176–255).
If the WG prefers to keep the range open for potential future CMIS updates,
we also support your suggestion to make the *server-side
responsibility* explicit
— ensuring that the server blocks access to any page that may affect NOS
manageability or data-path consistency.
------------------------------
*Section 6 (Normative References)*

Thank you for pointing this out.
We will update the reference to the latest revision, *OIF-CMIS-05.3
(September 2024)*.
------------------------------

Best regards,
Shunsuke

On Fri, Oct 24, 2025 at 6:36 PM Roberto Manzotti <[e-mail]>
wrote:

> 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]>
> *Sent:* Friday, October 17, 2025 3:23 PM
> *To:* [e-mail]
> *Cc:* [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]>
> 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]>, Kazuya Anazawa <
> [e-mail]>, Shunsuke Homma <[e-mail]>,
> Toru Mano <[e-mail]>, Yuji Tochio <[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
> Status:
> https://datatracker.ietf.org/doc/draft-hi-ccamp-cmis-control-yang/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-hi-ccamp-cmis-control-yang
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-hi-ccamp-cmis-control-yang-01
>
> 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
>
>