Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Mikael Abrahamsson <swmike@swm.pp.se> Sat, 11 May 2019 06:52 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 BF36C1200DE for <ipv6@ietfa.amsl.com>; Fri, 10 May 2019 23:52:57 -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 cmZRxzUQhr_M for <ipv6@ietfa.amsl.com>; Fri, 10 May 2019 23:52:56 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 AC02F120091 for <ipv6@ietf.org>; Fri, 10 May 2019 23:52:55 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 95976B2; Sat, 11 May 2019 08:52:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557557570; bh=nI/MjTlHa6Xf+EdZnSjtDUdx8SAZ3sy/D18rp4FeCJ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Lp9lOycYiCmg0qdbhzTs+aDdqYYr+ap9UZfh+RiBwlHpwkW1e/Olka08kc32nzSfd LNCFDjUjL6627P8BTJ5+OfPjIzS8l8oNNRBAXy623nPzfEvY38OEvaWnI6fjxtO7pK Irpe8CKCrhJ03bYc1XYi2islI4U6SQQi/GAl3cR8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 91A14B1; Sat, 11 May 2019 08:52:50 +0200 (CEST)
Date: Sat, 11 May 2019 08:52:50 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: ipv6@ietf.org
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <98d88cbb-fa92-42b0-f707-37b4eedf4782@gmail.com>
Message-ID: <alpine.DEB.2.20.1905110839120.1824@uplift.swm.pp.se>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <alpine.DEB.2.20.1905091054560.1824@uplift.swm.pp.se> <CAJE_bqeDE9bwkMm63p_Dz+ha7_tLa38wA27YRK2n59D1g-qLrA@mail.gmail.com> <alpine.DEB.2.20.1905102204270.1824@uplift.swm.pp.se> <98d88cbb-fa92-42b0-f707-37b4eedf4782@gmail.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/eHJ0T4zrbWNIiL5fbjnWhmn7xp4>
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: Sat, 11 May 2019 06:52:58 -0000

On Sat, 11 May 2019, Brian E Carpenter wrote:

> It's always been my opinion that the flag is input to a heuristic; but 
> from time to time we've had pushback asking for it to be more 
> definitive.

It's been my take that regardless what we write in the document, it's 
going to be treated as a signal and the host will do whatever the device 
manufacturer thinks is best. The "SHOULD NOT" in term of "IPv4 operations" 
leave enough room for interpretation for that.

However, others have interpreted the document differently, so it's obvious 
that the text needs changing. I think we have rough consensus on the flag 
being a signal (much like the M/O flag) that the host can act on if it so 
desires. So if the text can be changed to actually say so, it seems to me 
this is acceptable to a rough majority and we could then progress the 
document.

I am not super happy about leaving the ambiguity out there (see the 
earlier discussion on different OSes doing different things when the M/O 
flag changes) but I think it's the prudent way because we can't predict 
all the use-cases out there, and the different types of devices. The 
implementors know this best, and the document could point out in the 
considerations section some things that have been brought up in the 
discussions so far.

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