[v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 22 October 2020 10:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9F3A08AD; Thu, 22 Oct 2020 03:11:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>, v6ops@ietf.org, owen@delong.com, jiangsheng@huawei.com, mellon@fugue.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <160336150623.22400.9696222623015648417@ietfa.amsl.com>
Date: Thu, 22 Oct 2020 03:11:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/s7UicMNyxK1w8Pm5wC0axYUhT7c>
Subject: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-slaac-renum-04=3A_=28with_COMMENT=29?=
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 10:11:47 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-slaac-renum-04: 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-v6ops-slaac-renum/



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

Thank you for the work put into this document. It is easy to read but errs
sometimes on the anecdotes side rather than on the facts side (except for
Jordi's survey). As discussed before, I personaly wonder whether it is a real
problem for the IETF: it is largely about CPE/node implementation issues and
not a protocol one (even if I agree that the RFC 4861 default timers were badly
chosen 20 years ago).

Please find below a couple of non-blocking COMMENT points and one nit but
please also check: -  Ted Lemon's IoT directorate review with his note about
sleeping devices and time-outs:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-iotdir-telechat-lemon-2020-10-19/
- Sheng Jiang's Internet directorate review:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-intdir-telechat-jiang-2020-10-19/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"for an unacceptably long period of time, thus resulting in connectivity
problems." while the 'long period of time" is explained in the end of this
section, giving a hint would help the reader to appreciate the problem. I found
this introduction rather qualitative than quantitative.

"it is not an unusual behavior" may be... but, documenting (OS versions,
specific use cases) would make this argument stronger.

"there has been evidence that some 802.1x supplicants do not reset network
settings after successful 802.1x authentication." this is a very outdated
behavior of Windows if not mistaken and fixed years ago. In all cases,
documenting (OS version, specific case) would make this argument stronger.

"Lacking any explicit signaling to deprecate the previously-advertised
prefixes", as the explicit mechanism exists, I suggest to s/explicit/reliable/

"because of egress-filtering by the CPE or ISP" or is it ingress-filtering when
packets are sourced by an 'internal' host ?

"or routed elsewhere" I wonder how a packet could be routed elsewhere if the
source address is wrong. Policy-based routing ? Suggest to remove those words.

-- Section 2.1 --
Jordi's survey (a good one) does not say how often and how planned are those
prefix changes? My own /48 is not 'stable per contract' but has been stable for
7 years (as long as the BNG does not change it will stay the same as AAA & DHCP
are linked together at my ISP). So, the 37% is probably not meaning that 37% of
the CPE are changing of prefix everyday.

Did the authors check with the German ISP? AFAIK, the default policy has
changed.

Suggest to change the reference from RFC 4941 to the -bis document that is in
the same IESG telechat (so will not cause delay in the publication of this
document).

-- Section 2.3 --
No reply required but I find the last part of this section quite smart. I would
not have thought about this corner case ;-)

-- Section 2.5 --
"Not unusually, the two protocols are implemented in two different", I am
afraid that this is again 'anecdote' and not 'facts'. Citing implementations
details would make this statement stronger.

-- Section 3 --
To be honest, I was about to ballot a DISCUSS on this section as I think that
there could be other mitigation techniques. E.g., the ISP could advertise 2
prefixes by DHCP-PD for a while (would need to re-read DHCPv6 to be sure)
allowing an easier roll-over of the prefixes (esp. when planned prefix change).
Or possibly remove completely this section as 3.1 obvious and it is not
exhaustive.

-- Section 3.2 --
While I agree that the default timers are wrong and that the suggested values
are way better, this is a change in the CPE doing SLAAC and not in operator
settings (or did I badly understood 'operator' as 'network operator' in the
sense of ISP as opposed as residential user?). Is the same technique also
described in the SLAAC CPE document ?

== NITS ==

-- Section 3.2 --
The use of () in the first paragraph renders it difficult to parse. Consider
rewriting it.