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 . Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08 Reviewer: Pete Resnick Review Date: 2019-06-04 IETF LC End Date: 2019-06-04 IESG Telechat date: Not scheduled for a telechat Summary: Almost Ready. I found this overall to be an excellent document with clear technical explanations that even an upper-layer knucklehead like me could understand. However, there a couple of issues could use more discussion. I put them as "Minor issues", in that they're not showstoppers, but I do think they're important and hope you'll be able to address them. Major issues: None. Minor issues: Throughout, but particularly in section 5, this document refers to "hosts" doing address selection. To be fair, so does RFC 6724, but 6724 is referring to *default* address selection. In reality, *applications* do address selection on a host; the host stack will only do address selection if the application requests a default address. That works well for the scenarios in 6724, but in this document, for example section 5.2.3, I'm not so sure. The idea that a host would receive an ICMP destination unreachable and re-arrange its address selection seems at least an incomplete picture: An application with a (normal, non-multi-path) TCP connection to a remote application is not able to "try another source address to reach the destination"; the source address is already set for that TCP connection, so the only choice is to close the connection entirely. If the application chooses to re-establish the connection with a default address, yes, the host stack could then give a new default address back to the application, but this is hardly the dynamic and quickly adjusting process that the document seems to be envisioning. I don't think the above invalidates the core of the document or requires some grand rewrite. But I do think some clarification is in order, saying that the mechanisms described help with the *default* address selection, and some short discussion of the limitations for what applications can (and more importantly cannot) do with these mechanisms would be useful. My suspicion is that section 7.3 underestimates the availability (current and future) of multipath transport. Apple is using it now in production, and Linux already has it in their implementation. I think this is actually a reasonable possible solution in the future, and I would be a little more optimistic than the WG in this section. Nits/editorial comments: Two editorial bits in section 1: This document defines routing requirements for enterprise multihoming using provider-assigned IPv6 addresses. We have made no attempt to write these requirements in a manner that is agnostic to potential solutions. Instead, this document focuses on the following general class of solutions. Is that second sentence right? If you are giving a general class of solutions, that seems agnostic to the particular solution. Just a bit confusing. A host SHOULD be able respond dynamically... Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.