Re: Observations on (non-technical) changes affecting IETF operations

Phillip Hallam-Baker <phill@hallambaker.com> Sun, 20 March 2016 18:52 UTC

Return-Path: <hallam@gmail.com>
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 D6A7512D543 for <ietf@ietfa.amsl.com>; Sun, 20 Mar 2016 11:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gNN0XoEHoBxJ for <ietf@ietfa.amsl.com>; Sun, 20 Mar 2016 11:52:02 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDA212D57A for <ietf@ietf.org>; Sun, 20 Mar 2016 11:52:00 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id e196so20076182lfg.1 for <ietf@ietf.org>; Sun, 20 Mar 2016 11:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=Y2s0L94CXyCvBSejGB9fkbHmtd5v32EB2x5jYYkpMVQ=; b=oqJnm/D26HcK/mBFX59dtlcZf3xSJFYw3tQKGgU4pZCfYXbOEdvq+siXuyGtYdAHW4 D6X0yGmBcZUaQZRa81Q1PjkeKCh+KIOu4K5OB4o5XUQcqe4JpJmXQM4Q0T5VFKt9sdE9 o33jhlfmTKIGq6JWDQn9S5nplUNjtRazGX04RtMGzFKUTYbs7NMW9DlGZjmLuP1KV8k0 ptDeAGQH2fRirIaPSPcpEeo38UoCGGV1F1XM4V7lyglDpKtynjF8p/Ch3F4tA2FLB4A6 /d9eMc5SVIfyv5UUUh29kbnoxCPdqx9XZYFWFLIJa2ZNGa7Nt6EkX5XoV1lOepk43UkI F0Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Y2s0L94CXyCvBSejGB9fkbHmtd5v32EB2x5jYYkpMVQ=; b=XHB4glGpc0+iicDcFrhxceYcY04yqQrPIdIW9GNtpsksreITM3V1+helF7Yn8V0nHU gh8czMsTlpIA1NswfiObQJ5FxSaov7chCAFzEN/N3ukgXWmDxmsWUo1EpUeZLmIiGelb 0fF8Umal9/l3UHKYoDEtylOdUyppTMUhWvwUEA5tR8s0rC4VWAc5+QyZE9+cqJP+xTM1 vCMvevcZnB0ijYqHpvDHeg9j8WGFVwQ/V1wHGwDKGOJc3WulQ1iXSvknB2rMvy1VK7Tu 9ES3Mi1y4I/dWa8OWIGhGR6qxOyRf8Zr2GDcG7f5rZTtE/f2tsgnx1rm8a7yVcmCXN7g Hykg==
X-Gm-Message-State: AD7BkJJRKeOqcFClpMfff/iofUYuNbPiqIXxulcWtnHBYLXrCBl18Not3yvsF+VS8mgjEV6o16hbNXvSbILJBg==
MIME-Version: 1.0
X-Received: by 10.25.24.150 with SMTP id 22mr5714904lfy.43.1458499918878; Sun, 20 Mar 2016 11:51:58 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.151.67 with HTTP; Sun, 20 Mar 2016 11:51:58 -0700 (PDT)
In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A9FA6A7F@PALLENE.office.hd>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <82AB329A76E2484D934BBCA77E9F5249A9FA6A7F@PALLENE.office.hd>
Date: Sun, 20 Mar 2016 14:51:58 -0400
X-Google-Sender-Auth: qFXOumB2EWn0gcrxleNdFnJfgzw
Message-ID: <CAMm+Lwh+eY4miBH6n2ttwz00ypx9tVv0A4rM2v=VMQi6LH1h+w@mail.gmail.com>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Oqha12fPjLBWjafBgqXtsIZ2aKE>
Cc: IETF <ietf@ietf.org>
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: Sun, 20 Mar 2016 18:52:05 -0000

On Wed, Mar 9, 2016 at 5:16 AM, Dirk Kutscher <Dirk.Kutscher@neclab.eu> wrote:
> Hi,
>
> good discussion starter.
>
> Two comments:
>
> 1) Open Source / Hackathon:
>
> The objective of the IETF should IMO be to develop open, high-quality specifications (in a timely manner...). We have been working with running code for ensuring implementability and interoperability. That's still a good thing, however, we could think about how we can make better use of Open Source for the specification process. (Following up on Dave Ward's lunch presentation some IETF meetings back.)
>
> For example, some IRTF RGs are working with reference implementations (of their core protocols) to promote experimentation, more research, future adoption.
>
> Would it make sense to promote similar models for the protocol specification process in IETF WGs (beyond the Hackathon concept)?


Over the past few years, I have been assembling tools that allow me to
automate different part of the standards writing process.

Last week, I used them to produce a first draft for a proposal for a
LURK protocol. In three days, I produced:

1) A draft describing the protocol
   a) Text describing protocol
   b) Examples from running code
   c) Reference section
2) Reference implementation

The code generator I use targets C# by default as it has many
advantages when using code generation tools over Java. But it can also
generate C code for production use.

The tools are all on GitHub and SourceForge under PHB Build Tools. The
draft is here:

https://tools.ietf.org/html/draft-hallambaker-lurk-00


One important side effect of this work is that the specs are a lot
more consistent and a lot more flexible than those created the hard
way, by hand. If someone wants to have the protocol in XML rather than
JSON, I can do that. Or I can do ASN.1 or TLS Schema or CBOR. If
someone wants a code library in PHP or a particular flavor of C++, no
problem, just write your own output scripts.

Another advantage is that it encourages you to factor out pieces that
can be used as common modules in other application layer protocols.

This is what WS-* should have been. All the functionality but without
the complexity.