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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. draft summary: This document is using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. The Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. The document to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB, an LFB that specifies the configuration parameters of an FE. The SM LFB describes the configuration parameters of an FE, namely the LFB classes it should load, the CEs it should be associated with as well the respective CE IP addresses. Additionally the SM LFB provides a general purpose attribute definition to describe config information, as well as the ability to manipulate debug logging mechanism. SecDir status summary: Ready. This document states that it does not alter the ForCES Model [RFC5812] or the ForCES Protocol [RFC5810], so it has no impact on their security. I am not an expert in ForCES, but I tend to agree with this. This document defines the operational parameters and capabilities of an LFB that manages subsidiary mechanism for loading LFBs and create new connections between FEs and CEs. This document does not attempt to analyze the security issues that may arise from misuse of the SM LFB and defers analysis and design of mitigation strategies (if any needed) to designers of SM implementations. I am wondering if it is worth pointing directly to RFC 3746, Section 8 (In particular Section 8.1.6 on Data Confidentiality)? This would avoid the need to go through a level of indirection provided by RFC 5810.