Subject: Warren Kumari's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 17 Dec 2019 08:16:29 -0800

Warren Kumari 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:
----------------------------------------------------------------------

Like Alexey, I found the Scaled Lifetime section tricky / overly complex - I'm
not actually quire sure why the value needs to be scaled by 8 -- the field is
13 bits, which gives ( I think!) a maximum value of 8192. If this were not
scaled, it would be 136 minutes (8192/60), or ~2 1/4 hours -- I might be
missing something, but surely if you haven't gotten an RA in much less than
that, you have some larger set of issues? I think that the complexity would be
an easier pill to swallow if there was some justification for the complexity
provided.

If the text is reworded, I *think* it might make sense to break the explanation
out of the main part of the "Option Format" bit, and do something like: "Scaled
Lifetime: 13-bit unsigned integer, see Section 5.1" and then put the
explanation text in Sec 5.1 - having it in this location makes the text feel
"squished" and leads to an attempt to be overly terse.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 18 Dec 2019 07:33:02 +1100

On Wed, Dec 18, 2019 at 3:16 AM Warren Kumari via Datatracker
<[email-masked]> wrote:
> that, you have some larger set of issues?

Not necessary. Sending unsolicited RAs once an hour is not so
uncommon. In general it would be undesirable to have an option with
maximum lifetime lower than the default router lifetime. It might lead
into a situation when the NAT64 prefix lifetime is less than the
router lifetime/3 so the prefix might get deprecated before an RA
arrived/the default router expires. What we are trying to achieve here
is to align both lifetimes.

> I think that the complexity would be

Makes sense, thanks for the suggestion! The text will be updated in  -09.

-- 
SY, Jen Linkova aka Furry