Pete, thank you for your review. I entered a DISCUSS ballot on the basis of your first point. Alissa > On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Pete Resnick > Review result: Almost Ready > > 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-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. > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
