[v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: Discuss

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-v6ops-cpe-slaac-renum/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this easy-to-read document.

I support Erik Kline's DISCUSS points.

Please find below a couple of non-blocking COMMENT points and one nit but
please also check: -  Suresh Krishnan's IoT directorate review:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-iotdir-telechat-krishnan-2020-10-21/
- Sheng Jiang's Internet directorate review:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-intdir-telechat-jiang-2020-10-19/

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==
As observed by Sheng in his review and by Rob Wilton, the use of
normative-looking "MUST" is unusual in an informational document even with the
section 2 about requirement languages as the use of uppercase could confuse the
reader; or at least limit their use in the L-* text in section 3. Also, note
that RFC 2119 has been updated by RFC 8174.  The precedent set by RFC 7084
seems a bad one.

I will trust the responsible AD decision on this topic.


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

The shepherd write-up includes twice "a particular corner case where DHCPv6 is
being used to distribute effectively static addresses". Perhaps is it due for
not being a native English speaker, but, the use of "corner case" in a shepherd
write-up appears to me as weird and unexpected: is it the shepherd's opinion or
the WG consensus of being a 'corner case'. I read this as 'very rare case'
whereas I sincerely think, and Jordi's review indicates so, that this is not a
rare case.

-- Abstract --
I wonder why the word "IPv6" is never mentioned in the abstract while the whole
document is about IPv6. OTOH, perhaps the default IP version in 2020 is indeed
IPv6 ;-)

-- Section 3 --
Should the L-13 of RFC 7084 be also updated ? Briefly discussed in section 3.3

I wonder what is the actual structure of this section? There are 4 L-XX
requirements followed by 3 subsections and mapping between L-15 with section
3.1 and the same for L-16, L-17 but not for L-18 ?

As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415] that is
standard track

-- Section 3.2 --
There is a reference to section 2.1 of this document but the authors probably
meant section 3.1 of this document or Section 6.3 of [RFC8415].

Should the list of ND options include by default all options ? or at least
indicate that this is not an exhaustive list to allow for future ND options ?

-- Section 3.3 --
I agree with "IPv6 network renumbering is expected to take place in a planned
manner," but this sentence seems to contradict the premisses of
draft-ietf-v6ops-slaac-renum. Unsure how to reconciliate the two I-D (sharing
some authors ;-) ).

" since we acknowledge " suggest to slightly rewrite this sentence to make it
less personal.

Suggestion to mention whether RA are sent only on received RS, multicasted
immediately (the document mention periodically), or unicasted when possible
(some CPE keeps the mapping of all its unicast client notably on the Wi-Fi
side).