Summary: Needs 3 more YES or NO OBJECTION positions to pass.
Note to the IESG: This is a returning document. It went through IESG Evaluation and was approved at the Feb 8, 2018 Telechat. After approval (version -16 addressed any remaining Telechat comments), the authors proposed significant changes to the content of the document to remove support for the IPv6 SID due to lack of implementation and support . The document went again through WG and IETF LCs. Note that the IPv6-specific work is being addressed in a different document. For your convenience, here are the diffs: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-16&url2=draft-ietf-idr-bgp-prefix-sid-21  https://mailarchive.ietf.org/arch/msg/idr/FM31nSL78B5L5yCBZB17NfLwQy4/?qid=7f0a07c88788f56211e8702176812f8e
Please expand NLRI on first use. The "MUST be present" (in BGP Prefix-SID) in Section 3.1 seems to potentially be in conflict with the "are only used when SR is applied to the MPLS dataplane" in Section 3, but it's quite possible that I'm just missing the piece that ties things together. Section 7 It's a little weird to mark the value 2 as "deprecated" with reference "this document" but not have the previous usage described at all in the final version. Section 9 It might be nice to note the consequences of the BGP Prefix-SID attribute's non-protection by BGPsec signatures, though thank you for calling out the lack of coverage.
I'm balloting NoObjection, but I'm sad that nothing came of my previous request: "Major(ish) issue: Section 5. Advertising BGP Prefix-SID Attribute "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be deployed." Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated. "
Minor, no critical comment: I still don't really see why reserved bits and flags are needed given they are both defined the same way ("MUST be clear on transmission and MUST be ignored on reception."). Or more generally, I don't see at all why a flags field is needed given you can also just always create a new TLV...