Reviewer: Gyan Mishra Review result: Ready with Nits 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-idr-bgp-open-policy-?? Reviewer: Gyan Mishra Review Date: 2021-12-21 IETF LC End Date: 2021-12-17 IESG Telechat date: Not scheduled for a telechat Summary: This draft provides a new BGP open role capability and OTC path attribute to detect and mitigate route leaks automatically. I have been following this draft on IDR and supported through Adoption and WGLC. This document has matured and is ready for publication. The new BGP role capabilities mismatch code 2 subcode 8 discussed on ML seems to have multiple implementations deployed and one confined by Cisco. I agree that the authors should request a new subcode for the role mismatch notification. Major issues: None Minor issues: None Nits/editorial comments: Comment related to Gao-Rexford model. The Gao-Rexford Model only has 3 peer types North bound upstream Provider, Southbound Customer and lateral same tier level peer. With the role capabilities, RS and RS-Client is added which makes it slightly different but almost identical. In describing the role types would it make sense to have a graphical depiction of Gao-Redford model with the role capabilities on adjacent peers to help explain the role relationship for local and remote-as. Just an idea to help explain the role capabilities. In the role correctness section scenario where the peer receives multiple role capabilities to send role mismatch notification. What if there is a timing issue and the multiple are received after the BGP open and peer is established possible sequence of events issue. Is it possible the peer may not get a mismatch notification if the peer establishes prior to getting a different capabilities where a mismatch or problem exists that is missed that could result in a route leak. I am thinking of possibly false positive or negative or negative during BGP open capabilities exchange -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
