Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-urpf-improvements03.txt Reviewer: Matthew Bocci Review Date: 21 August 2019 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Generally, I found the draft quite readable, with a clear explanation of the problem statements and solutions as well as the trade-offs on the implementation. However, I have one minor comment and a nit. Major Issues: No major issues found. Minor Issues: Terminology: The document expands 'uRPF' as 'unicast reverse path filtering'. However, I believe that uRPF commonly means 'unicast reverse path forwarding' (see RFC3704 and most vendor documentation). "Ingress filtering" is the general concept and "reverse path forwarding" the specific algorithm. Did the authors intend to use a new term, and if so why? Nits: Section 2.5: "...separate from the global Routing Information Base (RIB) [Juniper][RFC4364]." VRFs are supported by most vendors so I think it is sufficient just to reference RFC4364.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
