Hi Jeff/Elwyn, Please see one comment inline.
Cheers, Med De : Jeffrey Haas <[email protected]> Envoyé : mardi 19 mai 2026 17:53 À : Elwyn Davies <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : [Last-Call] Re: draft-ietf-idr-flowspec-redirect-ip-10 ietf last call Genart review Elwyn, Thanks for the review. I had mis-filed this review originally. Sorry for my late response to it. On May 3, 2026, at 19:10, Elwyn Davies via Datatracker <[email protected]<mailto:[email protected]>> wrote: 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. The majority of the SHOULD discussion will be concluded in the DISCUSS from Éric. Abstract and s1, para 2: Expand VRF on first use (Virtual Routing and Forwarding). Done. I may take some time at the upcoming IETF to petition this get added to the well known abbreviations list. It's silly that it isn't at this point. Abstract, last sentence and s1, para 2: Would be worth referencing RFC 4360 in connection with BGP extended communities. Done. s1, para 2, last sentence: expand L3. Done. It'll be interesting to see if the RFC Editor simply reverts it since L3VPN is a common term of art at this point. s2.1, para 1: expand EBGP. Let's not. It's a core term of art (covered in RFC 4271) and expansion of it simply makes the text awkward. If the RFC Editor finds it inappropriate, they'll likely offer a fully reworked sentence. s2.1, last para: s/Compare similarly to/This is a similar constraint to that in I've gone with "This procedure is similar 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. I disagree. It simply squishes the text due to the numerical indenting without adding clarity. s2.1.1, rule 2, 3rd, 4th and 5th conditions: Would this benefit from a reference to RFC 5065 which introduces confederations? Good catch. RFC 9774 covers the confederation set, but other confederation procedures would benefit from the citation. I've added a single instance of it. s2.2, para 2: Expand NLRI. (Note AFI and ECMP are deemed well-known.) This was already done in the introduction. 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? Please see DISCUSS with Éric and feel free to contribute there toward that thread's conclusion. s2.2.2, end of para 1: s/carried/carried out/ Done. s2.2.2, para 4: s/T==1/T = 1/ (This isn't C programming language) Done. s4, para 1: s/based interactions/based on interactions/ Done. 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. I suspect the ops reviewers might quibble with your assessment here. Thus, I'm leaving these alone for the moment. [Med] These uses are compliant with the IESG statement on keywords (https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/). Specifically, this part: “Operational requirements, especially around mandatory logging and configuration needed to produce successful deployments”. I suggest to leave the current wording. Thanks. Unlike some of the protocol impacts in Éric's DISCUSS, I'm otherwise ambivalent about changing these. 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 Done. Note that bibxml for this is diferent. You'll find the agreed-upon changes in version -14. -- Jeff ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
