Re: Éric Vyncke's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Jen and Lorenzo,

First, thank you for your quick reply.

For the scaled lifetime, my comment is indeed about the overspecification for what router implementations should do  (I do not mind the << 3 operation to have a 16-bit lifetime in seconds as other ND options).

Let’s keep the text about multiple interfaces if you and the WG prefer even if I noted that Mirja had a similar comment. Really up to you.

-éric

From: Lorenzo Colitti <[e-mail]>
Date: Tuesday, 17 December 2019 at 03:59
To: Jen Linkova <[e-mail]>
Cc: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>, 6man <[e-mail]>, 6man Chairs <[e-mail]>, Bob Hinden <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

On Tue, Dec 17, 2019 at 11:24 AM Jen Linkova <[e-mail]<mailto:[e-mail]>> wrote:
<[e-mail]<mailto:[e-mail]>> wrote:
> -- Section 5 --
> I find this "scaled lifetime" field overspecified with respect to the router
> vendor requirements (perhaps a bias of mine ;-)).

:)) I totally agree with you, my personal opinion is exactly the same.
However...not sure how much you've been following the discussion on
the list but this format is what the WG agreed on (vs 'only supporting
/96' or 'having a variable length option, adding a prefix length only
if it's not equal to 96').
So I do not think we can really address your comment here ;)

Eric: are you commenting about the meaning of the field itself, or are you saying that the text is too detailed in explaining what router implementations should do? I don't think we can change the meaning of the field itself. As for being overspecified... I would tend to agree, but I believe that the text we have now was suggested by a previous review comment that said that the text was not clear. There was another IESG comment about this too. So we might have to tweak that text anyway.

> -- Section 6 --
> The text "the host receives multiple RAs with different PREF64 prefixes on one
> or multiple interfaces" is not followed by any guidance on how to use PREF64
> received on different interfaces. Perhaps worth mentioning here also PvD and
> requiring to use a PREF64 received on an interface (or PvD) only with
> interface/next hop/DNS of this interface (or PvD).

Ah! We did had a whole section on multi-homed hosts in one of the
previous revisions:
https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-04#section-7

It was removed later as per a reviewer's suggestion.

Right. Personally I don't think we need to say this here. All ND options are basically strongly tied to the interface they are received on, and many RFCs don't really even specify that. For example, I don't think the SLAAC RFC says anything about whether the host can or can't use the IPv6 address it gets on another interface. That is left to other documents such as RFC 6724 (source address selection).