IETF Last Call Review of draft-ietf-idr-flowspec-redirect-ip-10
review-ietf-idr-flowspec-redirect-ip-10-genart-lc-davies-2026-05-03-00

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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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