Hi! 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 with the intent of improving the operational aspects of the IETF drafts. Comments that are 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. This document is on the Standards Track, and clarifies the formatting to the BGP Flowspec Redirect Extended Community. Thank you for a nice short document. Relevant operational considerations are specified in RFC 5575. Summary: Ready with minor issues Major: None. Minor: 3. Security Considerations This document introduces no additional security considerations than those already covered in [RFC5575]. This seems correct — however, this document fixes what potentially is a security consideration. A small explanation of the implications of an incorrect matching decision to the wrong VRF would help here. Nits: -- The draft header indicates that this document updates RFC5575, but the abstract doesn't seem to directly say this. This "value wildcard" matching behavior, that does not take into account the format of the route target defined for a local VRF and may result in the wrong matching decision, does not match deployed implementations of BGP flowspec. s/that/which/ It should be noted that the low-order nybble of the Redirect's Type field corresponds to the Route Target Extended Community format field (Type). s/nybble/nibble/ The IANA Registries for BGP Extended Communities [RFC7153] document was written to update the previously-mentioned IANA registries to better document BGP Extended Community formats. Registries … were, or Registry … was. Use consistent case for “BGP Flowspec” (vs. “BGP flowspec”). Hope these help, — Carlos. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail