Last Call Review of draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09
review-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09-rtgdir-lc-dhody-2018-03-12-00

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