Matthew: Thank you for your comments. Sorry about the delay in replying. We (authors) have uploaded a new version and have included changes reflecting your comments. Please see: https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-urpf-improvements-04.txt Please also see responses to your comments inline below.
>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? > Great catch. I am surprised we (authors) overlooked and no one else caught it for so long. Thank you! Fixed. > >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. > The sentence now reads: The Virtual Routing and Forwarding (VRF) technology [RFC4364] [Juniper] allows a router to maintain multiple routing table instances separate from the global Routing Information Base (RIB). Shuffled the order of references. Keeping [Juniper] because there is some tutorial material in it that may be helpful for some readers. Regards, Sriram _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
