Subject: Alvaro Retana's No Objection on draft-ietf-6man-multi-homed-host-07: (with COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Tue, 02 Aug 2016 11:39:10 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-multi-homed-host-07: No Objection

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-6man-multi-homed-host/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 08:17:18 +1200

On 03/08/2016 06:39, Alvaro Retana wrote:
...
> RFC2119, for example may need to/is for future investigation/…

Agreed (see my response to Alia).

> to extend" or "will need to add support".  "SHOULD" seems appropriate.

I wouldn't object to s/will need to/SHOULD/ in both cases. I guess it seemed
a bit out of place in the Introduction section.

> extensions are how RFC4861 is Updated.

IMHO it isn't really helpful to an implementer to specify detailed textual
updates to 4861, since we are adding new behaviour. The way it affects
each implementation will be different, especially depending on whether
or not they already support Rule 5.5 and if so, how they chose to represent
and store the relevant state.

> include a reference to section 3.3.

OK for me.

> rfc6724 (if I'm reading the order of the rules correctly).  Please

But only if Bob already implements Rule 5.5, which many of today's Bob's
don't. Maybe we need to mention that.

Regards
    Brian