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]> > 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. 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
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
