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

Lee Howard <lee@asgard.org> Wed, 24 October 2018 16:21 UTC

Return-Path: <lee@asgard.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 676F9130DF0 for <ipv6@ietfa.amsl.com>; Wed, 24 Oct 2018 09:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 vyBEQN7a3wzX for <ipv6@ietfa.amsl.com>; Wed, 24 Oct 2018 09:21:53 -0700 (PDT)
Received: from atl4mhob19.registeredsite.com (atl4mhob19.registeredsite.com [209.17.115.112]) by ietfa.amsl.com (Postfix) with ESMTP id CA44D1286E7 for <ipv6@ietf.org>; Wed, 24 Oct 2018 09:21:53 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id w9OGLpJJ016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <ipv6@ietf.org>; Wed, 24 Oct 2018 12:21:51 -0400
Received: (qmail 5906 invoked by uid 0); 24 Oct 2018 16:21:51 -0000
X-TCPREMOTEIP: 174.64.33.182
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 24 Oct 2018 16:21:51 -0000
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
To: ipv6@ietf.org
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> <1F8FC133-7887-457C-A316-D2E6FCD450E9@consulintel.es>
From: Lee Howard <lee@asgard.org>
Message-ID: <c9091a6e-7fe1-c435-924b-7dd9c53f6cd9@asgard.org>
Date: Wed, 24 Oct 2018 12:21:50 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <1F8FC133-7887-457C-A316-D2E6FCD450E9@consulintel.es>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ASNTQ6vQ73aNQ2wW2_ty-ZUK5Wc>
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 16:21:55 -0000

On 10/24/18 7:08 AM, JORDI PALET MARTINEZ wrote:
> Then the vendors that have the power to implement everything they want, definitively win,

Yes. The people who write the code that implements the protocols we use 
on the Internet are the ones who. . . do that.

>   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.

If two implementers can't tell from a draft what to do to make sure 
their implementations can interoperate, the draft should not advance, 
regardless of how good the idea is. In this case, one OS could say, 
"That's advisory, I'll ignore it and do everything over IPv4," another 
could say, "The router has no IPv4 but I'm using IPv4 for service 
discovery, so I'll keep doing it," and a third could say, "RA says no 
IPv4, I'm disabling the stack." All comply with the document as written, 
but those three systems would have a very hard time communicating.

What guidance would you give those implementers? Can we put that 
guidance into the draft?

>
> 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.

Implementation is not a guarantee of deployment.

Non-implementation is a guarantee of non-deployment.

>
> I'm sorry but it is discrimination.

Yes. We are trying to discriminate between clear documents and vague 
documents. From what I can see, developers can write completely 
compliant implementations that break communications between systems on a 
network.

We also discriminate between ideas that help and those that hurt, or 
even those that do no harm but are useless. If we never discriminated, 
we would publish every draft.

Lee

>
> 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.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------