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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 23 October 2018 20:03 UTC

Return-Path: <prvs=1834938bf9=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 37559130E1B for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 13:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] 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 SqDggRtzna5p for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 13:03:49 -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 9D4A8130EAA for <ipv6@ietf.org>; Tue, 23 Oct 2018 13:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1540325019; x=1540929819; 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; bh=lBefhWUajS06s7eFbC1jWn +6Byaj1Nh/+0B16MNMGtw=; b=fcpXClJQGJsoDxaBALYNqUy7gW2PWxbw7Qn+KQ AjIR3IXx9ogac1tRP6um2SJRtB2NDO73jhPYl7xnxiOMoBoZAKbbo+//9lFN4b6T Kf8O8Rw39vk/xZbeaaVqM89MW8zZhLuhGvtKRPrmSaNATs1OiST44mK3lo24GtDI c0QJ0=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 23 Oct 2018 22:03:39 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 23 Oct 2018 22:03:38 +0200
Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005921394.msg for <ipv6@ietf.org>; Tue, 23 Oct 2018 22:03:37 +0200
X-MDRemoteIP: 2001:470:1f09:495:c9bf:85e8:8702:51ad
X-MDHelo: [10.10.10.131]
X-MDArrival-Date: Tue, 23 Oct 2018 22:03:37 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1834938bf9=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: Tue, 23 Oct 2018 22:03:35 +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: Suresh Krishnan <suresh.krishnan@gmail.com>
CC: Sander Steffann <sander@steffann.nl>, Fernando Gont <fgont@si6networks.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Message-ID: <2DC241B3-310B-4A3A-BD4C-C0005FCE6155@consulintel.es>
Thread-Topic: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
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>
In-Reply-To: <9B53019C-3506-4C9E-AFCF-D6125FA1A65B@gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623177016_2112643325"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vFEg6ChEhOuuVQaOglSLHZdbE-Q>
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 20:03:52 -0000

Hi Suresh,

 

Very interesting pointers, however the point is not even the authors implementing something.

 

Let’s suppose there is a draft and nobody wants to implement it. Another draft is implemented. May be after some time the one that was not implemented get more market success than the other one.

 

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

 

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


Regards,

Jordi

 

 

 

De: Suresh Krishnan <suresh.krishnan@gmail.com>
Fecha: martes, 23 de octubre de 2018, 20:57
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: Sander Steffann <sander@steffann.nl>, Fernando Gont <fgont@si6networks.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

 

Hi Jordi,

 

On Oct 23, 2018, at 2:33 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

 

Hi,

I don't think this can be enforced and even less for a specific ID or WG.


And this will be discriminatory also if applied to all the IETF work.

There are many authors that don't have time, resources, access to the source code from vendors, or even knowledge, among many many many other possible reasons, to implement an ID they submit.

 

I don’t think there is an expectation that the implementations have to necessarily come from the draft authors. e.g. look at the codestand work

 

https://codestand.ietf.org/codestand/

 

where people can request implementations. The underlying thesis is that there are people who have implementation skills who might be looking for guidance on what to implement.



Also, there will be IDs which are not "implementable", etc., and clearly that doesn't disqualify that it may be a perfectly valid work.

 

Right. I am pretty sure this will be applicable only to Standards Track documents and the “not implementable” documents you mention will not be subject to this.




I guess this is a discussion that should be held at the general area list.

 

We have had this discussion multiple times over the past years.

 

RFC1264 (coincidently written by Bob) was the first document in this space requiring implementations before heading to Proposed Standard

RFC4794 obsoleted RFC1264 specifically pointing to the following text RFC2026  (which postdated RFC1264)

 

      Usually, neither implementation nor operational experience is
      required for the designation of a specification as a Proposed
      Standard.  However, such experience is highly desirable, and will
      usually represent a strong argument in favor of a Proposed
      Standard designation.
 
      The IESG may require implementation and/or operational experience
      prior to granting Proposed Standard status to a specification that
      materially affects the core Internet protocols or that specifies
      behavior that may have significant operational impact on the
      Internet.
 

and allows WGs to set their own rules. This is where things stand right now.

 

The current state of the art BCP is RFC7942 (which obsoleted RFC6982) that allows providing optional info about existing implementations and Section 4 of that document lists some of the benefits of doing so.

 

Thanks

Suresh

 



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