I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10.txt Reviewer: Suresh Krishnan Review Date: 2013/02/04 IESG Telechat date: 2013/02/07 Summary: This document is almost ready for publication as an Informational RFC but I have some comments you may wish to address. Minor ===== * Section 5.4 It is not clear how the next-next-hop for a DR is calculated if the router P uses ECMP to reach the DR (i.e. there are potentially multiple next-next-hops). Can you please clarify? * MTU considerations There is no discussion of the MTU issues that come up due to encapsulation and some form of requirement for the repair endpoint to perform path MTU discovery. This is especially important for IPv6 endpoints. * Security Considerations - The first sentence talks about using this mechanism disguising delivery of a packet without talking about further details. Are you talking about one of the issues discussed in Section 2 of RFC6169? If so, a pointer could be useful. - What does the term private address mean in the context of this section? Does it mean a RFC1918 or RFC4193 address (the properties requested seem to imply these)? If so, it might be good to make this explicit. Editorial ========= * Section 1 s/based on the concept tunnelling/based on the concept of tunnelling/ Thanks Suresh