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 document is ready with issues. The document defines an extension mechanism for the "flags" field in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry information in BGP about multicast routing inside VPN. RFC 6514 describes an 8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one of the 7 bits as an extension mark, and proposes to create an IANA registry for the remaining 6 values, and for the values of the newly defined extension field. The draft is pretty simple, but it poses the generic issue of extensions. What happens if some routers in a domain are aware of the newly assigned extension and some are not? The authors argue that this behavior is properly defined in the documents describing the future extensions. This is plausible, but the draft does define a generic mechanism, and does switch the meaning of one of bits marked as "reserved" in RFC 6514. We have thus two possible issues: 1) A router supports RFC 6514 but does not implement the extension mechanism. 2) A router supports the extension mechanism, but does not support the specific extension. I am able to guess a plausible behavior based on the text in the draft and the reference to " Treat-as-withdraw" option of RFC 7606, but I would much prefer if there was a recommended behavior in the draft. -- Christian Huitema