Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

1) Section 2.1 describes GMPLS control plane as a distributed control system. "Controller" is used in this section as distributed on each node, while "controller" in most of the other places in this draft indicates a centralized controller. This may cause confusion. A GMPLS control plane instance is also used in this section to support the NE level control. It is suggested to align the terminologies and eliminate confusion. 

2) Section 2.3,  the logic of the two paragraphs under Figure 1 is not too clear. What does "Alternatively" in the second paragraph intend to substitute? The first paragraph already describes domain 1 uses NETCONF/YANG and/or PCEP. The second paragraph (starting with "Alternatively")  describes NETCONF again. It is not an alternative but an enhanced descripion, is it? Besides, is the description of MDSC also the same in these two paragraphs?

3) Section 5.1, is "Yang Path Computation requests [PAT-COMP]" the only way for controller interaction in case of path computation?


Nits:

1) Section 4.3, s/notification that permits to notify the client about topology changes/notification of topology changes to the client
2) Section 5.1, s/service e2e path setup/e2e service path setup
3) Section 5.2, TED lacks of an expanded explanation, although the explanation appears later in Section 5.3.  s/TED/ Traffic Engineering Database (TED) in Section 5.2
4) Section 7.1, s/The topology on network element/The topology on a network element
5) Section 7.3.3, the first paragraph, s/the detail extensions/the detailed extensions
6) Section 7.4.3, the last paragraph, s/could be taken place/could take place
7) Section 7.4.4, the fourth paragraph, s/failure occurs.../failure that occurs...
8) Section 9, s/The security requirements in both system still applies/The security requirements in both systems still apply