%% You should probably cite rfc9117 instead of this I-D.
@techreport{ietf-idr-bgp-flowspec-oid-13,
    number =    {draft-ietf-idr-bgp-flowspec-oid-13},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/13/},
    author =    {Jim Uttaro and Juan Alcaide and Clarence Filsfils and David Smith and Prodosh Mohapatra},
    title =     {{Revised Validation Procedure for BGP Flow Specifications}},
    pagetotal = 12,
    year =      2021,
    month =     apr,
    day =       12,
    abstract =  {This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an iBGP received route, the originator is typically a border router within the same autonomous system. The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises AS\_PATH validation rules so Flow Specifications received from an eBGP peer can be validated when such peer is a BGP route server. This document updates the validation procedure in RFC8955.},
}