Re: Conclusion of Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

Fernando Gont <fgont@si6networks.com> Mon, 13 July 2020 18:23 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4083A1656 for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 11:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BEcxjH0xyZmL for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 11:23:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25B03A164F for <ipv6@ietf.org>; Mon, 13 Jul 2020 11:23:16 -0700 (PDT)
Received: from [IPv6:2800:810:464:1f7:603e:8516:bae8:27ff] (unknown [IPv6:2800:810:464:1f7:603e:8516:bae8:27ff]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5517F280CEA; Mon, 13 Jul 2020 18:23:12 +0000 (UTC)
Subject: Re: Conclusion of Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
To: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <CC295D49-5981-41C3-B4DB-E064D66616CE@gmail.com> <4F9636F8-364A-4272-8D01-BFAA91D4A86C@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <606f0b2f-6351-438e-5376-a35f1e12cb69@si6networks.com>
Date: Mon, 13 Jul 2020 15:22:28 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <4F9636F8-364A-4272-8D01-BFAA91D4A86C@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bIFN5-FEMMgUyNxJAscGjUSwvC4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 18:23:19 -0000

Hello, Bob,

On 13/7/20 14:59, Bob Hinden wrote:
> This concludes the adoption call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events”
> 
> The chairs reading of results of the adoption call is that there is agreement that 6MAN w.g. should work on this problem, but there is not support for the solutions proposed in the document.
> 
> We found that Mikael Abrahamsson email captured this well:
> 
>    https://mailarchive.ietf.org/arch/msg/ipv6/01JrxBGiMmsKuB1bkks5NIgLxSQ
> 
>   "I agree that there are problems to be solved in this space (thus I support
>    adoption), but I think that the current version of the draft is way too
>    overengineered and "heavy handed". I think we can achieve all the benefit
>    without changing so much of current behavior.”
> 
> The authors are instructed to remove the contents from Section 4 (the section headers can stay but the contents should be replaced with “TBD”) and submit a new draft named <draft-ietf-6man-slaac-renum-00> with these changes.  We will approve that as a w.g. document.

Just double-checking: Are you suggesting that we remove Section 4.5 or 
that we remove the contents of the entire Section 4?

There have been objections against Section 4.5, but I haven't seen any 
to the proposals in Section 4. In fact, even explicit support for some 
of such sections have been voice (Lorenzo for Section 4.2, Jen for 
Section 4.1.1, etc.).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492