[v6ops] Erik Kline's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Wed, 21 October 2020 20:49 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 AEFB13A07F5; Wed, 21 Oct 2020 13:49:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline 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
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <160331338169.29285.8506664356153222594@ietfa.amsl.com>
Date: Wed, 21 Oct 2020 13:49:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9C1AIo0Mds14AHitSoSC8dF0xUo>
Subject: [v6ops] Erik Kline's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)
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: Wed, 21 Oct 2020 20:49:42 -0000

Erik Kline 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:


[[ comments ]]

[ section 2.1 ]

* There should be some clarification that use of dynamic prefixes does
  not automatically imply flash renumbering, but rather that it increases
  the likelihood of a flash renumbering event occurring (basically make it
  clear that flash renumbering is the issue, not dynamically changing

* There's also more than one layer of PD stability to be considered: the
  stability of the block delegated from the ISP to the modem/ISP-provided
  CPE (discussed here), and (for example) the stability of the prefix that's
  subdelegated to another router in the home (in cases where the user has
  purchased an additional router to place between nodes in the home and the
  ISP CPE).  In this way, even with stable ISP->CPE prefix delegation, it
  might be possible for the home router to get a different subprefix on

[ section 2.2 ]

* This section should make it clear that magnitude of the impact is a
  function of these timers and that these defaults are not necessarily in
  common use.  The text strongly implies that all flash renumbering events
  impact hosts for 7 days, and I don't think that's true.  (I don't think
  I've been on any dynamic prefix network that used these defaults for a
  long time.)

[ section 2.3 ]

* I support Ben's observation about authenticated RAs.

[[ nits ]]

[ abstract ]

* "will continue using stale prefixes" -> "may continue using stale prefixes"
  or "could" or "might" or "are likely to"

  I think "will" is only correct under very certain circumstances.

  Same text change in the first paragraph of the introduction as well.

[ section 1 ]

* "and and" -> "and"

* "configure for": perhaps "configured from" the previously-advertised prefix