Re: Long-term IETF evolution thoughts

Marc Petit-Huguenin <petithug@acm.org> Mon, 13 June 2016 16:37 UTC

Return-Path: <petithug@acm.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8BB12D0F5 for <ietf@ietfa.amsl.com>; Mon, 13 Jun 2016 09:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level:
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 1TaYTIOUofBZ for <ietf@ietfa.amsl.com>; Mon, 13 Jun 2016 09:37:35 -0700 (PDT)
Received: from implementers.org (implementers.org [173.246.102.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EC612B062 for <ietf@ietf.org>; Mon, 13 Jun 2016 09:37:34 -0700 (PDT)
Received: from [IPv6:2602:ae:176e:3700:7d49:7f79:2efa:f821] (unknown [IPv6:2602:ae:176e:3700:7d49:7f79:2efa:f821]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 04AD92002F; Mon, 13 Jun 2016 18:37:32 +0200 (CEST)
Subject: Re: Long-term IETF evolution thoughts
To: Melinda Shore <melinda.shore@gmail.com>, ietf@ietf.org
References: <B937F6B4-248F-42B7-BBDB-C82B914C874C@ietf.org> <eb706622-69e6-2161-29d9-27e43d241030@acm.org> <b50a234b-0a78-34a3-e014-5438ed0d9cd8@gmail.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <0bffe186-237c-c904-75d8-ef42deb50a3a@acm.org>
Date: Mon, 13 Jun 2016 10:37:25 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0
MIME-Version: 1.0
In-Reply-To: <b50a234b-0a78-34a3-e014-5438ed0d9cd8@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AcGrpkUdOhF8sQ48muANasO2wRiVU9Rkb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/e0Tx0KQXNcEb4LdlTLWdERxzIrE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2016 16:37:37 -0000

On 06/12/2016 02:35 PM, Melinda Shore wrote:
> On 6/12/16 6:31 AM, Marc Petit-Huguenin wrote:
[...]
>> 3. Focus on linking open standards to code, operationals, and
>> interoperability.
>>
>> My view on this evolved these last years.  Few years ago I was
>> convinced that developing a reference implementation at the same time
>> than a specification and testing it against other people
>> implementations was the right way to to find bugs in the
>> specification.  I even applied that idea when RFC 6940 was developed.
>> Sure I found hundred of issues in the draft (and got "punished" for
>> it by becoming - with Dean Willis - informal editors of the draft).
>> But, in spite of my best efforts, my implementation could not cover
>> 100% of the specification, so if on the one hand that made the
>> specification better, on the other hand it certainly did not made the
>> specification good by any of my standards.
> 
> I think this is a fair point but I'd like to mention what I
> thought was one of the more interesting things to happen at an
> IETF hackathon, which is that one group found they couldn't
> implement a draft in its current form because it was wrong, and
> they needed to go back and fix the specification.  I understand
> that you're arguing that formal methods would provide greater
> coverage, and I agree (and I hope you'll set up a small side
> meeting or some such on this in Berlin), 
 
Yes hackathons are great, and that and rfc6982 are a huge improvements.  But that's short term, on the long-term we'll have to prove that our protocols works as expected (i.e are verifiable), not just randomly guess that they may work for the cases we know about.  That's also why I think that writing a draft should be simpler than it is today - not to attract more authors, but because soon we'll have to add a whole new layer of complexity on top of it.

The plan is to present my work in March in Chicago.  Meanwhile I'll be attending the reception in Berlin on Sunday, so if there is enough interest then we can setup a place and time during the week to discuss that.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug