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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 09 March 2016 19:20 UTC

Return-Path: <brian.e.carpenter@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 7B9BF12D538 for <ietf@ietfa.amsl.com>; Wed, 9 Mar 2016 11:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBhEFVOpQrH9 for <ietf@ietfa.amsl.com>; Wed, 9 Mar 2016 11:20:48 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 D4CB512D506 for <ietf@ietf.org>; Wed, 9 Mar 2016 11:20:47 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id 129so48230387pfw.1 for <ietf@ietf.org>; Wed, 09 Mar 2016 11:20:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IerOUQq2+Hh2HP5XNLFMAbtza2VlDCG1RxmcLh7hGj0=; b=yyI+gFV72i5xowDgvfqg0q5S4HMLxjpxrcCY29igx6XGe2DC8JvQyJxxVBf+WZ/Uxm ETM5uKnEs2JUeHkaIFWIelSbdmrM78Q1LAlGGMOW1Nb9L7owxlOsK9Raw2vIv84cQWZ7 dh8rIFXveB4LIi3d1HgJ35PtHxSWG61nwCvsZ110yRqkxh159CRzOa39G8tnvfUmnOL6 oG77i8gfc9Rmje13jvKuhoHSKYuUVfnDHNF4any55ENFtjBh7uRx9/zZ2VvCM2bl+uF8 hGhWripJ760tlDRZdIBcurjOAmDYf2NG/8xeCRbgaoUXknqkEoAaImlIjhTdm7unmaXR 3lCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IerOUQq2+Hh2HP5XNLFMAbtza2VlDCG1RxmcLh7hGj0=; b=cwvt3XA1yo+nZPTi604tcTw2cs/yKeZU5cDorfW1ULedqZSsyBN9Ahwjx2dJxspZjg RU7oApa3UyAHI8OGkRqtNN3yRaGE2+OuKrcu1SAYkiHrHQtBGsiruc0ncZ3tgBM90jmV xeesK8HwzQ2zcHMc3oF8GUL5L+wesK17BbmrsMwR0H8c5lfPIKmy6v5622yE5MPNH7nv zcqsBszfsp+/NVXyCmjjW49VxMtTFIQfQ7DFznhEXR/s1/Dhc4r7nnR098CkNXuX8xrM 3hJF5GOpuZ8jhzYFmyaF1Y8/l50nquWRF1kjzOLH6dNL3Fk/6mCli1A4bSl5rRlYqTAw 5v+g==
X-Gm-Message-State: AD7BkJK0y+cQVvT8tBFpfqidZX79bGwLjqpr7QK0mdtPm7ZjjCsZROvN34rjlnbtsiWSmg==
X-Received: by 10.98.13.88 with SMTP id v85mr30212371pfi.150.1457551247446; Wed, 09 Mar 2016 11:20:47 -0800 (PST)
Received: from ?IPv6:2406:e007:77c3:1:28cc:dc4c:9703:6781? ([2406:e007:77c3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f12sm20802pfd.87.2016.03.09.11.20.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 11:20:46 -0800 (PST)
Subject: Re: Observations on (non-technical) changes affecting IETF operations
To: Dirk Kutscher <Dirk.Kutscher@neclab.eu>, Jari Arkko <jari.arkko@piuha.net>, IETF <ietf@ietf.org>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <82AB329A76E2484D934BBCA77E9F5249A9FA6A7F@PALLENE.office.hd>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56E07791.6090109@gmail.com>
Date: Thu, 10 Mar 2016 08:20:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A9FA6A7F@PALLENE.office.hd>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/cX_GErfZOY5GDXYEM66AZHpNZpc>
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: Wed, 09 Mar 2016 19:20:49 -0000

On 09/03/2016 23:16, Dirk Kutscher 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)?

I was tempted to write "Well, Duh!" but maybe this *isn't* obvious to everybody. So yes, there is no doubt
that running code is a vital adjunct to successful standards work.

> Potential benefits:
> 
> - more running code -- better specification quality

Very specifically, WGs where somebody can say "When writing the code, I couldn't understand X",
or "When testing the code, I found that Y is wrong" produce better specifications.

> - FOSS as standards reference implementations -- promoting standards adoption

Perhaps equally important: providing a basis for interoperability tests.

BTW the choice of OS license is important: pick the wrong one and some people aren't
allowed to look at your code.

> - potentially: speeding up the process

Maybe not speeding up the IETF process itself, but certainly speeding up the time
to market (or the time to deciding the whole thing was a bad idea).

    Brian