IETF Logo Mail Archive

Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 24 October 2018 06:47 UTC

Return-Path: <swmike@swm.pp.se>
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 C9FDD12870E for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 23:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 G-jROXLTl4Dg for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 23:47:32 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D801286E3 for <ipv6@ietf.org>; Tue, 23 Oct 2018 23:47:32 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5481EB3; Wed, 24 Oct 2018 08:47:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1540363650; bh=2SxyqLWwBHlvg3EjjWpIyedFJ2HmPOGzEdGrPpvUtHE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eQWnAi6P4RcSbI6MtEBx4mWffuvBMA+yOIHq+5jYDQVQonvN3+aby9ymZ6g66+j1M ACr2msAse8Nlu5Ff+tV1Rm7GQEYMyPLRreFgEVgERkgfC8v6kttwfjyM1CSstLbX1s 5NUi7qeEkXVGOxWORd/I2OLRjBAUcBp2e2Bz9oBg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4FE10B0; Wed, 24 Oct 2018 08:47:30 +0200 (CEST)
Date: Wed, 24 Oct 2018 08:47:30 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Fernando Gont <fgont@si6networks.com>
cc: ipv6@ietf.org
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
In-Reply-To: <37ba23b3-df19-9c2a-bdbe-ba7a99d72d05@si6networks.com>
Message-ID: <alpine.DEB.2.20.1810240844180.26856@uplift.swm.pp.se>
References: <CAFU7BASO_ByzbanhLKnWV280O_fASd-8W+ujpj3sN6d2-whw2w@mail.gmail.com> <CACWOCC-u7aAPwAOcixYvt2On=-o_8X25GhqdXTfA+tWRC1o2XA@mail.gmail.com> <3beca72e-19c5-10af-02e5-c21a90d77100@gmail.com> <20181019.223739.271916573.sthaug@nethelp.no> <4f58643c-272e-507e-3282-c87befd42395@gmail.com> <0927741c-4e8e-fcf7-ddd6-3ba500ba4c3d@si6networks.com> <7B48A11D-31DE-443C-B73A-14642EA0A397@jisc.ac.uk> <7526af75-4359-6fc6-e39b-eb94024a04de@si6networks.com> <E1BB1232-C1A2-496A-8157-0682D91EED42@steffann.nl> <5E75F3CA-F1D2-4F4F-9CF7-EEEE59634C1E@gmail.com> <C46C990E-0A4F-4731-8CB1-FD204858935E@consulintel.es> <9B53019C-3506-4C9E-AFCF-D6125FA1A65B@gmail.com> <1157b739-3a66-8d45-e3e1-e5f904dfb9bc@asgard.org> <a00607f9-7ced-f889-b5cb-c2fe16367d73@si6networks.com> <66759b73-0a22-e1a9-49db-21154e8e1267@gmail.com> <37ba23b3-df19-9c2a-bdbe-ba7a99d72d05@si6networks.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TKmMrpOA3UuAJ4JEwbwcO-1-DDo>
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: Wed, 24 Oct 2018 06:47:34 -0000

On Wed, 24 Oct 2018, Fernando Gont wrote:

> If, when sending the bit set you get each node doing it's own thing (one 
> reduces timers, another disables the stack forever, another disables it 
> but might re-enable it when the bit is no longer set, etc.), that would 
> be an undesirable outcome. Me, I think it should be clear what to do 
> with the bit, and the exceptions (the corner cases when you might go 
> against the advice) should be spelled out.

I don't think we'll ever get to an agreement on what a device should do, 
short term. There could be some kind of BCP document, but that'd have to 
be an operational document and that would definitely require running 
code to test it out.

Also we have no working group where we can discuss it, sunset4 is no more.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email