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-flowspec-redirect-ip-10 Reviewer: Elwyn Davies Review Date: 2026-05-03 IETF LC End Date: 2026-05-12 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. There are several abbrevations that need to be expanded and I would suggest revisiting some of the SHOULDs which may not always be appropriate. Major issues: None Minor issues: None Nits/editorial comments: Nits: Abstract and s1, para 2: Expand VRF on first use (Virtual Routing and Forwarding). Abstract, last sentence and s1, para 2: Would be worth referencing RFC 4360 in connection with BGP extended communities. s1, para 2, last sentence: expand L3. s2.1, para 1: expand EBGP. s2.1, last para: s/Compare similarly to/This is a similar constraint to that in / s2.1.1: It would make clear the extent of the three rules by converting them from top level paragraphs to numbered bullet points. s2.1.1, rule 2, 3rd, 4th and 5th conditions: Would this benefit from a reference to RFC 5065 which introduces confederations? s2.2, para 2: Expand NLRI. (Note AFI and ECMP are deemed well-known.) s2.2, instances of SHOULD: I am not clear that the various instances of SHOULD in this section are appropriate: Para 1: I suspect this ought to be MUST. Para 3, SHOULD be load shared: Maybe a 'should' - This could be a configuration decision for the router implementation. Para 3, appropriate encapsulations SHOULD: I am not sure what else would be appropriate -maybe MUST. Para 3, SHOULD be ignored: What else could one do? Maybe MUST - is there any sort of error message that could be sent? Para 4, SHOULD loas-share, and Para 5 SHOULD ignore and Para 6: I guess the wiggle room represented by this SHOULD gives implementers some options. Para5, SHOULD deterministically: Is this supposed to mean that the same target address is to be used for all relevant packets? s2.2.2, end of para 1: s/carried/carried out/ s2.2.2, para 4: s/T==1/T = 1/ (This isn't C programming language) s4, para 1: s/based interactions/based on interactions/ s4, para 1: s/SHOULD be made visible/should be made visible/ - this is not a protocol requirement. s4, paras 2, 3 and 4: s/SHOULD/should/ - similarly, these are management considerations not protocol requirements. s5: The two items should note that the items come from the Border Gateway Protocol (BGP) Extended Communities registry. It is becoming conventional to provide links to the relevant registries as references. https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-ipv4 https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-ipv6