Dear all,   I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.   Technical Comments:   This document provides a complete overview for both the existing networking and future networking and proposes architecture that compatible to both. It is quite generic and can be applied in various scenarios; however it is not easy to generate networks directly from this draft. There can be some future architectural drafts based on the ABNO architecture, talking about the detailed applications, for example, multi-layer architectures. Similar issue applies to most of the use case mentioned in section 3.   From the architecture figure 1, it seems that the ABNO controller is the critical functional block in the architecture and a lot of interactions between this controller and other blocks are required. It is a necessary to consider the complexity of such controllers, which may bring difficulties for implementation. On the other hand, this figure only shows the one-to-one relationship between ABNO controller and PCE, however, there may be N-to-one or one-to-N cases for different applications. Some description should be included in section 2 for better specification. The functionalities between PCE and ABNO controller is also not very clear, there may be following understanding: the PCE is responsible for Path computation and ABNO controller for configuration, or, the PCE is responsible for Path computation and configuration while the ABNO controller is responsible for negotiation with APP layer. It is fine to be open on this question. For section 2.3.1.8.2, it is necessary to describe the relationship between LSP database and stateful PCE, i.e., stateless PCE may not be able to use this database.   For section 3.2 multi-layer use case, there are 7 steps for service provisioning. RFC 5623 provide more than one solutions and there are still other alternatives for cross-layer service provisioning. Future work need to be added to make the solution more complete, maybe in separate draft with more specific descriptions.     Editorial Comments:   In section 3.1, The Hierarchical PCE section, the second paragraph has the following correction:   As shown in Figure 4, the ABNO Controller sends a request to the parent PCE for an end-to-end path.  As described in [RFC6805], the parent PCE consults its TED that shows the connectivity between ASes.  This helps it understand that the end-to-end path must cross each of ASa, ASb, and ASc, so it is sends a few individual path computation requests to each of PCE a, b, and c to determine the best options for crossing the ASes.     In section 3.7.2, the 2nd paragraph, “Figure 29 shows … ”, some editorial changes should be applied  as follow: Figure 29 shows a diagram of an example data center based application.  A carrier network provides access for an and-user end-user through PE4. Three data centers (DC1, DC2, and DC3) are accessed through different parts of the network via PE1, PE2, and PE3.   The Application Service Coordinator receives information from the end-user about the services it wants, and converts this to service requests that it passes to the the ABNO Controller. The end-user may already know which data center it wishes to use, the Application Service Controller Coordinator may be able to can either make this determination, or the task of selecting the data center may be left leave it to the ABNO Controller, and this may utilize a further database (see Section 2.3.1.8) to contain information about server loads and other data center parameters.     Thank you, Tina