Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09 Reviewer: Dhruv Dhody Review Date: 12-03-2018 IETF LC End Date: unknown Intended Status: Informational *Summary:* * I have some minor concerns about this document that I think should be resolved before publication. *Comments:* * The draft provides useful information related to management and control of single channel DWDM interface. I have highlighted some issues which could improve the readability and clarity of the document. *Major Issues:* * No major issues found *Minor Issues:* * Section 1.1, please use the latest template for requirement language as you do use lower case RFC 2119 keywords and the reference to RFC 8174 would make that clear. * I find the use of 'SNMP' as problematic, when used together with Yang. One is a protocol, another is a data modeling language! Suggest to either use MIB & Yang or to use SNMP & NETCONF/RESTCONF. * It was not clear that the SNMP/MIB would be used only for retrieving data (read-only MIB) or it would include writable MIB objects. To me this includes write capability and thus consider adding some text and making the intention clearer in lieu of IESG statement - https://www.ietf.org/iesg/statement/writable-mib-module.html; if there are no plans to define MIB extensions (i did not find any extension) then consider removing. * I understand that MIB, Yang models and LMP extensionsare not defined in this documents, but since the work has started,consider putting some details in the appendix for the reader making it clear that these details are based on the status at the time of publication and subject to change. * Section 4.1.1, are there any security implications because of a client device being controlled by the transport management system? * Query: Can the PCE play any role here? if yes (i hope) consider adding some text as well. * Section 6, IMHO the requirements listed reads as requirements for the deployments/implementation but there is one or two instance of requirements in terms of what needs to be standardized/defined in a future RFC (requirement 1, 6). I would suggest to rephrase. Also the guidance in section 1.1 could be updated to make it clearer on who is the target of these requirements in the 2nd paragraph. * Section 6, is it wise to only mention NETCONF? Maybe change that to YANG based network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]? * Suggestion: The current document highlights the protocols and data model aspects but does not list or discuss what are theseparameters. In usecases, P(in) and P(out) or modulation scheme, FEC is mentioned, but it is light on details. Consider if providing this information would be useful? *Nits:* * Expand these on first use - DWDM, EMS, NMS, ROADM, WSON, SMI, LMP, WDM, OLS, Rs, Ss etc. I would recommend checking out - https://www.rfc-editor.org/materials/abbrev.expansion.txt * s/wither/either/ (Section 1) * Missing closing bracket in "(defined in [ITU-T.G.694.1];" (Section 2) * s/including Add Drop Multiplexers (ROADM)/including Reconfigurable Optical Add/Drop Multiplexers (ROADMs)/ (Section 2) * Consider rephrasing, difficult to parse -  (Section 3.1.1)    This document elaborates only the IaDI Interface as shown in Figure 1    as transversely compatible and multi-vendor interface within one    administrative domain controlled by the network operator. * s/OADMs/ROADMs/ (Section 3.1.2) * s/through tho optical/through the optical/(section 5.1) * Section 5.2.1 "..depicted as yellow triangles..", remove yellow for obvious reasons :) * P(in) and Pin as well as P(out) and Pout are used interchangeably. * Please change the title for figure 6 Thanks! Dhruv