Alissa Cooper has entered the following ballot position for draft-ietf-rtgwg-enterprise-pa-multihoming-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to discuss the following comments from the Gen-ART reviewer: "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." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the remainder of the Gen-ART review. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
