Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events
draft-ietf-v6ops-cpe-slaac-renum-08

I support Rob's DISCUSS, for the reasons Barry gave.  In addition, I believe IETF consensus is to use BCP 14 in its entirety, not just the first half of it.

Also, this sentence gave me pause:

"This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality."

Maybe this should be an applicability statement, and thus Standards Track?

Thank you for responding to the SECDIR review (and thank you to the SECDIR reviewer, Chris Wood).

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

I support Erik Kline's DISCUSS points. 

I have cleared my previous blocking DISCUSS and thank you for addressing all my previous COMMENTS.

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 (addressed in -06, no more blocking, kept here for archive) ==

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.

== COMMENTS (addressed, kept for archives) ==

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

I support Rob's DISCUSS and agree that it would be better just to use the terms in lower case, rather than making them appear as special key words but disclaim the definition.  I'll note that RFC 7084 predates RFC 8174, and that the latter clarifies that using the terms in lower case has exactly the meaning that the disclaimer in Section 2 is trying (unsuccessfully) to make.

I also agree with Ben's comment that keeping the grammatical error "preferable" is unnecessary.  But if we end up getting rid of the whole thing, that becomes moot anyway.

Section 3

   o  WPD-10: CE Routers MUST by default use a stable IAID value that
      does not change between CE Router restarts, DHCPv6 client
      restarts, or interface state changes. e.g., Transient PPP
      interfaces.  See Section 3.2 for further details.

The text in Section 3.2 goes into a bit more detail to clarify that this
is basically a pre-existing requirement from RFC 8415, but the short
text here is easy to misread as imposing a requirement to use a stable
persistent identifier, which would have lousy privacy properties.  RFC
8415 does acknowledge this issue to some extent, but the most applicable
text about it seems to be in Section 4.5 of RFC 7844, that clarifies
that the IAID needs to be consistent for the association *as long as the
link-layer address remains constant*, which is a very natural scope and
consistent with best practices for simultaneously changing identifiers
at different layers when needed for privacy improvement.  It would be
great if we could spend a few words here to clarify that this is not a
permanent identifier that could be abused for tracking, perhaps "(Per
[RFC8415] it is still expected to change when the link-layer address
changes.)", though I was hoping to have something shorter.

Additionally, while RFC 8415 is clear that the IAID is assigned by the
client, this text might benefit from noting (e.g.) which interface it is
used on, since the CE router will often be on both ends of different
DHCPv6 exchanges.

Support changing intended status for this document.

Thank you all (authors, WG, ADs) for resolving my previous discuss issue.