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

Ole Troan <otroan@employees.org> Tue, 23 October 2018 18:55 UTC

Return-Path: <otroan@employees.org>
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 BAE191310FD for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 11:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ZEsnIXVqnN3J for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 11:55:26 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9C71310D7 for <ipv6@ietf.org>; Tue, 23 Oct 2018 11:55:19 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 505F2FECC0D4; Tue, 23 Oct 2018 18:55:18 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 322B0860D2B; Tue, 23 Oct 2018 20:55:15 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
From: Ole Troan <otroan@employees.org>
In-Reply-To: <5E75F3CA-F1D2-4F4F-9CF7-EEEE59634C1E@gmail.com>
Date: Tue, 23 Oct 2018 20:55:15 +0200
Cc: Sander Steffann <sander@steffann.nl>, Fernando Gont <fgont@si6networks.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8B9777A-8EB2-40A8-B644-49BA027DEF99@employees.org>
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>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O0pwYfaVDxFYGr7ZyYkuK1a4kKk>
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: Tue, 23 Oct 2018 18:55:34 -0000

Hi Suresh,

>> Changed the subject because this discussion is now moving away from any specific draft.
>> 
>>> That's kind of my take, as well However, I think that asking for an
>>> implementation of the ipv6-only flag is a requirement that I have never
>>> seen for taking new work or publishing it, so it would be unfair to ask
>>> that to the authors of this particular I-D.
>> 
>> I'd like that to become the norm though. Having a running prototype can help enormously when writing specifications. My preference would be to move back to a base principle of running code and rough consensus, instead of only rough consensus.
> 
> If the WG decides to go on this path, I will be fully supportive of that. This model has worked out well for idr (see https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What I am uncomfortable with is that criterion being *selectively* applied to this draft as a prerequisite for progress. 

At least from my side (as the non-author co-chair) this wasn’t intended to apply a new requirement on this particular draft.
It was intended as a possible avenue for a draft that currently does not  have enough support in the working group to advance.

Best regards,
Ole