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.
- Getting off Things - namely this mailing list tom p.
- Observations on (non-technical) changes affecting… Jari Arkko
- RE: Observations on (non-technical) changes affec… Linda Dunbar
- Re: Observations on (non-technical) changes affec… Jari Arkko
- RE: Observations on (non-technical) changes affec… Dave Cridland
- Re: Observations on (non-technical) changes affec… Randy Bush
- Re: Observations on (non-technical) changes affec… Melinda Shore
- Re: Observations on (non-technical) changes affec… Joel M. Halpern
- Re: Observations on (non-technical) changes affec… Rich Kulawiec
- Re: Observations on (non-technical) changes affec… Stephen Farrell
- Re: Observations on (non-technical) changes affec… Randy Bush
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Security for the Internet of Things and Other Thi… Jari Arkko
- RE: Observations on (non-technical) changes affec… Dirk Kutscher
- Re: Observations on (non-technical) changes affec… Jari Arkko
- Re: Observations on (non-technical) changes affec… Michael Richardson
- Re: Security for the Internet of Things and Other… Michael Richardson
- Re: Security for the Internet of Things and Other… Carsten Bormann
- Getting on with Things Eliot Lear
- Re: Security for the Internet of Things and Other… Theodore V Faber
- RE: Getting on with Things Adrian Farrel
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Stewart Bryant
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Stewart Bryant
- Re: Getting on with Things Eliot Lear
- Re: Observations on (non-technical) changes affec… Brian E Carpenter
- Re: Getting on with Things Michael Richardson
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Medel Ramirez
- Re: Security for the Internet of Things and Other… Phillip Hallam-Baker
- Re: Getting on with Things Gmail
- Re: Security for the Internet of Things and Other… Livingood, Jason
- Re: Security for the Internet of Things and Other… Scott Kitterman
- Re: Security for the Internet of Things and Other… Eliot Lear
- Re: Security for the Internet of Things and Other… Stewart Bryant
- Re: Observations on (non-technical) changes affec… Charles Eckel (eckelcu)
- Re: Observations on (non-technical) changes affec… Dave Crocker
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… Jari Arkko
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… Charles Eckel (eckelcu)
- Re: Observations on (non-technical) changes affec… l.wood
- Re: Observations on (non-technical) changes affec… George Michaelson
- Re: Observations on (non-technical) changes affec… Eggert, Lars
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… lloyd.wood
- Re: Observations on (non-technical) changes affec… Eggert, Lars
- Re: Observations on (non-technical) changes affec… S Moonesamy
- Re: Observations on (non-technical) changes affec… Joseph Lorenzo Hall
- Re: Observations on (non-technical) changes affec… Joseph Lorenzo Hall
- Re: Observations on (non-technical) changes affec… S Moonesamy
- Re: Observations on (non-technical) changes affec… Randy Bush
- RE: Observations on (non-technical) changes affec… Russ White
- Re: Observations on (non-technical) changes affec… Melinda Shore
- Re: Observations on (non-technical) changes affec… Eliot Lear