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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 06:59:18 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-ra-pref64-08: 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-ra-pref64/

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

Jen, Lorenzo,

Thank you for the work put into this short and clear document and let's hope
for implementations.

Answers/actions to my COMMENTs below will be welcomed, even if those COMMENTs
are not blocking.

Regards,

-éric

== COMMENTS ==

-- Section 5 --
I find this "scaled lifetime" field overspecified with respect to the router
vendor requirements (perhaps a bias of mine ;-)).

Define MaxRtrAdvInterval as "MaxRtrAdvInterval" in RFC 4861 ?

-- 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).

---

From: Jen Linkova <[email-masked]>
Date: Tue, 17 Dec 2019 13:24:25 +1100

Hi Eric,

> 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 ;)

> Define MaxRtrAdvInterval as "MaxRtrAdvInterval" in RFC 4861 ?

Done, will be added to -09.

> 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.

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2019 11:59:21 +0900

> 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.

> 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).

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 17 Dec 2019 08:08:10 +0000

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 <[email-masked]>
Date: Tuesday, 17 December 2019 at 03:59
To: Jen Linkova <[email-masked]>
Cc: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>, 6man <[email-masked]>, 6man Chairs <[email-masked]>, Bob Hinden <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

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.

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).