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 draft is standards track and describes a few extensions to ease programmability and to improve wire efficiency of some transactions. It adds extensions to the ForCES Protocol RFC5810 and RFC7121. The document appears mostly ready for publication. The security considerations section (section 6) only refers to RFC 5810. 1 Nits and 3 Questions regarding the security section below: Nits: - section 3.2.3.1. last paragraph: s/writting/writing Questions: 1. section 3.2.3.1. last paragraph:  "On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a    master CE can turn on support for extended results by setting the    value to 2 in which case the FE MUST switch over to sending only    EXTENDEDRESULT-TLVs." Not sure about the full network topology, but could that enable a master CE to effectively make the replies of a FE unreadable to other old-version CEs (which can only understand RESULT-TLVs) by switching on the "only" new EXTENDEDRESULT-TLVs? 2. with the New Codes in section 3.2.1. : do any of the new more detailed error codes (e.g. "E_EMPTY |  Table is empty") pose a risk of data leakage of information detail that was not intended to be disclosed in that detail in the original RFC 5810? 3. section 3.1.: Could the new "TABLERANGE-TLV", which requires significantly more computing on the receiver per request from the sender, enable an attacker for a type of Denial of Service attack scenario? NOTE: though I reviewed the ID, I did not validate the XML structure in appendix A. Thank you and best regards. Tobias