I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Nits. This draft describes a framework for abstraction and control of traffic engineered networks (ACTN). According to the abstract, a traffic engineered network is a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to-end connectivity. Abstraction in this context is a technique can be applied across a single or multiply domains to create a single virtualized network under the control of a network operator or owner. This is thus a very broad topic, and the ID is informational only. The most important part is probably the description of the ACTN base architecture. It describes three components: the Customer Network Controller (CNC) responsible for communicating the customer’s requirements to the network provider , the Multi-Domain Servicing Coordinator (MDSC), responsible for implementing ACTN functions, and the Provisioning Network Controller (PNC), responsible for configuration and topology management. It also describes as the interfaces between them. The document also gives a description of some more advanced ACTN architectures, a description of several topology abstraction methods, and an example of an advanced ACTN application: a multi-destination servers. The security considerations section, while it lists some general considerations that would hold for any kind of network, mainly concentrates on the two interfaces between the components: the CNC-MDSC (CMI) and the MDSC-PNC (MPI) interfaces. It gives a good overview of the types of security risks that might arise with respect to the two interfaces, and the means for mitigating them. For the rest, it defers security considerations to the specific applications, which I assume would be handled by other working groups. I believe that this is reasonable for an informational document that is providing a general framework. A nit: I couldn’t parse the last sentence of Section 9.3: Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted) should also be authenticated and specific access restrictions and topology views, should be configurable and/or policy-based. I think it may be the commas are misplaced, and what you really want to say is this: Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted), should also be authenticated, and specific access restrictions and topology views should be configurable and/or policy-based. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil