Hi! I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines host multihoming extensions to HIP. NB: I am reviewing draft-ietf-hip-multihoming-10 instead of draft-ietf-hip-multihoming-09 Summary: Ready (with a couple questions) I see no additional operational considerations, but I have two questions below. Major Issues: None. Minor Issues: No issues, two questions: 1. When more than one locator is provided to the peer host, the host MAY indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the addresses used in the base exchange are preferred until indicated otherwise. It may be the case that the host does not express any preferred locators. The “by default” and the “it may be the case that" threw me off a bit. Does this basically say that if a host does not indicate a preferred locator, the addresses used in the base exchange are preferred locators? Given the plural, how can multiple addresses be “a preferred”? How is the non-default case? 2. In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator, although rules for source address selection should ultimately govern the selection of the source locator based on the destination locator. Why is a configuration allowed but potentially not effective? Can this yield to operational confusion? Nits: None. HTH, — Carlos.