First-Hop Router Selection by Hosts in a Multi-Prefix Network
draft-ietf-6man-multi-homed-host-10

Besides my first comment (which matches Alia's DISCUSS, which I support, but offers a slightly different point of view), I don't think that my comments raise to the point of a DISCUSS, but I would really like them to be considered as a STRONG COMMENT (stronger ones are at the top).

1. First of all, there's the topic of the scope.  From Section 1. (Introduction and Applicability):  "…the mechanics of egress routing once the packet leaves the host are out of scope."  But then in Section 2.2. (Expectations of multi homed networks) you write that "The direct implication of Section 2.1 is that, if the network uses a routing protocol, the routing protocols used in multihomed networks SHOULD implement source-prefix based egress routing".  I think that the "SHOULD" goes against the fact that routing is out of scope.  While the general statement (of needing src-dst routing) may be true, for the networks shown in 2.1 all you really need is a default route as the topology and the host itself take care of selecting the correct exit point — so it is also not that direct of an implication.  Proposed solution: ideally get rid of 2.2, but I'm fine with changing the "SHOULD" for something not in RFC2119, for example may need to/is for future investigation/…

2. In Section 1. (Introduction and Applicability) there are 2 places that say that implementations "will need to extend/add support".  What does that mean?  This document is a specification of what has to be done, so it shouldn't read like a list of future actions.  Given that the next sentence warns that "Hosts that do not support these features may fail to communicate in the presence of filters as described above."…I would like to see the text be a little more prescriptive than just saying "will need to extend" or "will need to add support".  "SHOULD" seems appropriate.

2.1.  In the same piece of text…  "…this specification is consistent with [RFC4861].  Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 4861 will need to extend their implementations accordingly."   It would be very nice if the text included the sections where the appropriate extensions are mentioned/defined — presumably these extensions are how RFC4861 is Updated.

2.2. Same text…  "This specification is fully consistent with [RFC6724] and implementers will need to add support for its Rule 5.5."  It may not be apparent (at this point in the text) to everyone that 5.5 applies to the case where information related to which next-hop advertised which prefix (or that the document is going in that direction) -- please include a reference to section 3.3.

3. In Section 3.1. (Interpreting Router Advertisements), "…Bob-A and one had advertised itself as a default router or as having a route to Alice, that is the router Bob should choose.  If none of Bob-A have advertised that but Bob-B has, it is irrelevant; Bob is using the address allocated in PA and courts a BCP 38 discard if he doesn't send the packet to Bob-A."  I think this case is irrelevant too, but not because Bob knows/thinks about BCP 38 — it is irrelevant because of Rule 5.5 in rfc6724 (if I'm reading the order of the rules correctly).  Please clarify.

I have a  few minor comments:

-1.1,  indented paragraphs (A) and (B):
It's not entirely clear to me if these restate requirements from 1122, or if these are requirements from this document that might "confuse" the Strong Host model. If the former, please consider dropping the 2119 keywords.

-2.1, first paragraph: Please expand SLAAC on first mention.

- 2.1, 2nd paragraph: 
s/implementation/implementations
s/the two routers may not even know/each router may not even know

-3, title: Does this refer to expectations the host has, or that other things have of the host? If the latter, what expects them? (Previous section talked about expectations the host has on the network; is this section about expectations the network (operator) has on the host?

general: I think this is very verbose, an editing pass
to remove as many words as possible would be good, some
examples below where I think more words confused me more
than was needed...

- Abstract: is bcp38 really crucial here or advisory? If
the latter, then I'd suggest not making it sound like it
is necessary, no matter how much we'd like it deployed.

- intro: "the only consistent solution" may be an
overstatement (unless you can prove there is no other)

- text on p4 after figure 1: it's probably me but I
found reading this a slog, not sure if it's really
needed, but if (part of) it is, making the necessary
bits clearer would seem like a fine plan. If it's not
needed, maybe delete some or all of it.

- 2.1: When you say SLAAC here, are you encompassing use
of privacy addresses? Sometimes those are presented as
an alternative to SLAAC but I'm not sure which is the
more correct terminology. In any case, I assume this
document is intended to fully work with privacy
addresses.