Re: [Last-Call] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04

Ted Lemon <mellon@fugue.com> Tue, 20 October 2020 22:23 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDBE3A142C for <last-call@ietfa.amsl.com>; Tue, 20 Oct 2020 15:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbQPxdlsGlmQ for <last-call@ietfa.amsl.com>; Tue, 20 Oct 2020 15:23:25 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216E83A1436 for <last-call@ietf.org>; Tue, 20 Oct 2020 15:23:24 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id q26so444908qtb.5 for <last-call@ietf.org>; Tue, 20 Oct 2020 15:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=k1+08mZfCJe2uQIeC9I671DLbKf2gBrK/YoS4WqvgH11hrel/FNgKknuMlBMntazQs aI555tq4LSyCLK5rOyNYI00pMBMopjVvyuthRSTH9OBJlFmncBvwYTDq+I5yWSwcPjow Qf7PSZ3hkTqv/KFVAt9VJqo6+8t9wWjuxF43m3nPii830E4nM1bwoyio1rNxefvRzF8b HLIfuK6iqePNGtiyMIl2Du6IKCXze/psgnq5FJuKJ17qN/DyIAON4CoOpEN3uYkh6oqG XokjAnSbmGR3s65vJ/A07rQaMNz0ZHkgZojVF6YVBkOezMYg2lbUXUMcsKENn4Hwj1ya yHew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=elqm6O5n4MmnscDfI180ytevp10dFPEHmWeOdBYMGTc1K9L0zDw+JW8hrKrUykVmPQ 1ELWsr1LoyBdI3TRPp1inq6EbsV8aF0xTZYspcXiK+lX0+zgpAPwS0YE2+C5Gxh1POgO gH0VH+5d0/jgeCexpJ4LGtNHYGcQGLoaT/H9pLufHbjmmHpYOJd0LHXY5r3nD91g61+J EXTX0yijRxu/4tujgckkFzYezvyUDTf9OoGVeAWxBTH3vaTAHjDYsZmipH2L5/eB1XLt NKPbCghoxOcMK2vIBCnIKsBvuEZahJyL5xyniAuaudFYeycee+ZEp9AB0YjJn2trJdmZ L2cw==
X-Gm-Message-State: AOAM532pE0/PNFf8S/utKczUADnyEXKXMz5GtvI4AmQYh4H/WbB5v1SN nf/BczM41E0Gwgy8cTeSKGBOIw==
X-Google-Smtp-Source: ABdhPJzLLnbMaAb8u6c1VkfgguBlZC5NdhUQIO3DSuFIkAstJqWF1YWst7AjuKaH9yq0wa96rmJBPg==
X-Received: by 2002:ac8:48c7:: with SMTP id l7mr332029qtr.275.1603232603893; Tue, 20 Oct 2020 15:23:23 -0700 (PDT)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u11sm16253qtk.61.2020.10.20.15.23.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 15:23:23 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B1A116F7-A851-4318-A6A9-B22F40FF6FE4@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\))
Date: Tue, 20 Oct 2020 18:23:21 -0400
In-Reply-To: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com>
Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list <v6ops@ietf.org>, last-call@ietf.org
To: Fernando Gont <fgont@si6networks.com>
References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com>
X-Mailer: Apple Mail (2.3654.0.3.2.91)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Sj0veM5xGhqkcNfOhdkemrHJUg0>
Subject: Re: [Last-Call] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 22:23:28 -0000

On Oct 20, 2020, at 3:51 PM, Fernando Gont <fgont@si6networks.com> wrote:
>> This is relevant because some IoT deployments make use of sleepy devices that may only wake up once per day or even less frequently. The suggested parameters would be inappropriate for such a device.
> 
> Just me double-checking: Do you mean it would be to short for them?
> 
> Please note that the default router lifetime is 1800 seconds. So a host
> that sleeps for longer than that will presumably not have a default router when it wakes up, and would need to do a "refresh" procedure (RS/RA exchange) before it would be able to send a packet, anyway.

Right, in a situation like this, where the network is pretty stable, it would make sense to use longer lifetimes. Also bear in mind that the communication on this network might be between two hosts on the same link—one a data collector and one a reporting device. So the router lifetime might not be an issue. If the communication is going off-network, a longer router lifetime would be required.

>> At the same time such a device likely is not relying on RA, since it
>> would not be awake for periodic refreshes. Nevertheless the operational mitigations section could use some additional verbiage about applicability so that readers do not assume that the advice given there is universally applicable.
> 
> Please clarify the above, and based on that, we could craft some text if
> necessary.

What I’m suggesting is simply that you mention that the defaults you are recommending are really most applicable in home networks, and may not be applicable in various commercial networks, including the IoT deployment I used as an example.  IOW, make it clear that these defaults are not universally applicable. There’s no text right now that says that (unless I missed it).