I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-idr-bgp-extended-messages-33 Reviewer: Paul Kyzivat Review Date: 2019-07-09 IETF LC End Date: 2019-07-18 IESG Telechat date: ? Summary: This draft is on the right track but has open issues, described in the review. Disclaimer: I have very little understanding of the subject matter of this document, so this review is limited to the form and structure of the document. General: The Abstract and Introduction are written in the abstract, implying (to me) that the requirements here are intended to be broadly applicable for the stated purposes, over an extended period of time. On the other hand, I get the impression that requirements in this document are actually more focused, intended for use in a one-time selection of an Internet video codec to be a successor to HEVC and VP9. If this document is intended only for one-time use then it isn't evident to me why it ever needs to become an RFC. Issues: Major: 0 Minor: 0 Nits: 2 1) NIT: Section 4 says: If a BGP message with a Length greater than 4,096 octets is received by a BGP listener who has not advertised the Extended Message Capability, the listener MUST treat this as a malformed message, and MUST generate a NOTIFICATION with the Error Subcode set to Bad Message Length (see [RFC4271] Sec 6.1). The "MUST" seems inappropriate because this is not new normative behavior. Rather it is the existing behavior, at it states. This is already covered by the 2nd paragraph of Section 5, so why does it need to be covered here as well? 2) NIT: Reading the last two security considerations in section 8 leaves me concerned. I was expecting to see some further discussion of how these issues can be mitigated, or why it is OK that they are not. Otherwise this short document seems to be in good shape.