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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 24 October 2018 11:08 UTC

Return-Path: <prvs=1835a99611=jordi.palet@consulintel.es>
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 95214130DE5 for <ipv6@ietfa.amsl.com>; Wed, 24 Oct 2018 04:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 NbKlgHi68_4i for <ipv6@ietfa.amsl.com>; Wed, 24 Oct 2018 04:08:14 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4E0130DC2 for <ipv6@ietf.org>; Wed, 24 Oct 2018 04:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1540379291; x=1540984091; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=ACprJR4Cmua0ejovnKdktVoqeJeE5Gnca3bjDW6CU04=; b=umFF4AHub0RMm MtW5gFUpBjm+mT93FyW/xdk/npU42VxJWJbZnHABf8qFPp1yvQAIhqA9/DHQ6vHv jo4vZC1PnMZhtrZRw3hfadZhvmslEKvfiX56xjBuHgWxRHkxFbcvygKZw5q7hOHm qhiyb36Q7zLKDVZ1atN4622l8fuePM=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 24 Oct 2018 13:08:11 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 24 Oct 2018 13:08:11 +0200
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005922193.msg for <ipv6@ietf.org>; Wed, 24 Oct 2018 13:08:10 +0200
X-MDRemoteIP: 2001:470:1f09:495:949:79ac:d87:8d7d
X-MDHelo: [10.10.10.99]
X-MDArrival-Date: Wed, 24 Oct 2018 13:08:10 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1835a99611=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.3.181015
Date: Wed, 24 Oct 2018 13:08:07 +0200
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Job Snijders <job@ntt.net>
CC: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Message-ID: <1F8FC133-7887-457C-A316-D2E6FCD450E9@consulintel.es>
Thread-Topic: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
References: <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> <2DC241B3-310B-4A3A-BD4C-C0005FCE6155@consulintel.es> <20181024103057.GD924@hanna.meerval.net>
In-Reply-To: <20181024103057.GD924@hanna.meerval.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cr6se9QIRWhFsqdEmlgrWLsGG3A>
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 11:08:17 -0000

Then the vendors that have the power to implement everything they want, definitively win, only because they are able to implement it, not necessarily because it is good or bad, and the argument of the implementation will be a tool to reach consensus, even if it takes longer, more versions, etc. This is real life.

Very good ideas that don't become standards because during the ID development don't get implemented (even if they will become implemented once they become RFCs), lose.

I'm sure there have been already many IETF documents that have been in both situations. Market decides at the end. But that's the thing: at the end, most of the time only when there is an RFC.

A couple of examples I can remember, IPv6 site local (it was an RFC) and draft-ietf-ipv6-dns-discovery, different process stages, both got implemented by many OS vendors and also Linux. No longer used.

I'm sorry but it is discrimination.

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Job Snijders <job@ntt.net>
Fecha: miércoles, 24 de octubre de 2018, 12:31
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    On Tue, Oct 23, 2018 at 10:03:35PM +0200, JORDI PALET MARTINEZ wrote:
    > Let’s suppose there is a draft and nobody wants to implement it.
    
    full stop. then the document does not need to be published.
    
    > Another draft is implemented. May be after some time the one that was
    > not implemented get more market success than the other one.
    
    fantastic, at that point the document can move forward again in the
    publication process. 'market success' implies running code came into
    existence.
    
    > This is discriminating both drafts in the IETF process, and we must
    > not do that. It may happen even “you have programmers” that are good
    > friends, they will do for me and in the other way around. Or I’m a
    > vendor, so I’ve the resource to do it.
    
    This is not discrimination. If authors don't have the capability to
    develop running code themselves, and also don't have access to resources
    nor are able to convince others to implement a protocol specification...
    the IETF's prime directive of interoperability can't be met anyway.
    
    Some ideas gain traction, some don't - this happens to all of us.
    
    > This will mean at the end that we balance the IETF work towards those
    > that can (somehow), get things implemented, even if is a bad work (I
    > understand that still need to follow the consensus, etc.).
    
    Bias towards getting things implemented is an excellent way to foster a
    stream of healthy specifications. Invariably the creation of running
    code leads to higher quality specifications as implementers provide
    their feedback to the WG. We don't work in the void, we're here to do
    tangible things. This is not an academic exercise.
    
    > At the end, we may have open source implementation of a draft, and not
    > being adopted by vendors, or in the other way around. That’s not a
    > good way to classify “good” or “bad” IETF work, also because after
    > some years, what was “bad” is adopted as good, and viceversa.
    
    I don't understand your 'open source' vs 'vendors' statement, they are
    the same, both are vendors. The publication license and cost are
    irrelevant.
    
    > I understand that when IETF started, it was very few work and it was
    > very easy to ask for code for everything, but our industry changed and
    > we can’t enforce that, even at WG level.
    
    I don't think 'our industry changed' means that we can now do without
    code. We can absolutely enforce it, also at the WG level. IDR working
    group is living proof. The QUIC and TLS13 groups have done excellent
    work and only got to the point where they are by investing time &
    resources to produce lots of running code.
    
    Raising the bar is a good thing!
    
    Kind regards,
    
    Job
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.