Reviewer: Keyur Patel Review result: Has Nits Document: draft-item-ccamp-dwdm-if-mng-ctrl-fwk Reviewer: Keyur Patel Review Date: August 7, 2017 Intended Status: Informational Track Here are my comments. Overall, the document is well organized and clear about the problem statement and requirements for the framework for Management and Control of DWDM optical interface. This document could simplify early draft sections text and fix few typos + grammatical errors. Attached are my comments: 1 - Section 1, Consider replacing: "Carriers deploy their networks today based on transport und packet" with "Carriers deploy their networks today based on transport and packet". 2 - Section 1, Last Paragraph, consider replacing: "Optical routing and wavelength assignment based on WSON is out of scope although can benefit of the way the optical parameters are exchanged between the Client and the DWDM Network." with: "Although Optical routing and wavelength assignment based on WSON is out of scope, they can benefit from the optical parameters that are exchanged between the Client and the DWDM Network." 3 - Section 2, first Paragraph, consider replacing: "The DWDM interfaces migration…" with "The DWDM interface migration..." 4 - Section 2, fifth Paragraph: "Administrative domain [G.805]: For the purposes of this Recommendation" Perhaps the authors meant "this document" as oppose to "this Recommendation"? 5 - Section 3.1.2 last Paragraph: "The following documents[DWDM-interface-MIB], [YANG], [LMP] define such a protocol- FIX-THE-REFERENCE specific information using SNMP SMI, Yang models and LMP TLV to support the direct exchange of information between the client and the network management and control plane." Does this also apply to Section 3.1.1 or it is specific to Section 3.1.2? If so, it should be moved out of Section 3.1.2. 6 - Section 4.1.2, third Paragraph and 5.1: LMP uses reliable UDP. For any Indirect and Direct connections, how does the optical network node recover from partial network configurations upon LMP based adjacency failures? Does that need to be a requirement for LMP extensions? 7 - Section 5.2.1: The alarms that can be generated for use cases mentioned in 5.2.1 can be chatty particularly when sending over LMP (or protocol of choice). Is there a requirement to pace/damp the rate of Alarms (that would be carried within LMP)?