Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability.

Brian E Carpenter <> Mon, 06 July 2020 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAD433A0B71 for <>; Mon, 6 Jul 2020 15:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LN6pAlAXzGOE for <>; Mon, 6 Jul 2020 15:05:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F5E63A0B72 for <>; Mon, 6 Jul 2020 15:05:57 -0700 (PDT)
Received: by with SMTP id i14so1041321pfu.13 for <>; Mon, 06 Jul 2020 15:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L2N1Y1Q2lFe5Y8BGJSogsjaq/aDfTAVpvrKCgpDKq9Y=; b=lalfE21PYdMo9HW1duxO0RnXiN5JiGP29mBG77eUlf76dL0GjOijrvvb4YRFXDaDqZ hx+E8q52oJ9QKyKkzXmS/tQRhhVFCWZE9KxCvv9WKfB2WTRXb6gZcnXvmAoCF5dY6sh8 PDmnijqN6hooD3NCuoJPTPQWifQomBRcKxdXAIQilSGpZGrrCU9rzjD9hnLvZtE+NPPc iNnBLgP8wYyYg9rpWuHnnqG9WrGXzXm1Jb3EiEI84n0cyEcThccYVgj8wnUmDUrQPmeD YRtOO5yz/8MLASQqgMG3x5FedAVDRw3pzrPcBU2QfSJTq/I5aBMbtXzHnn7PcrtG6eQn I45A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=L2N1Y1Q2lFe5Y8BGJSogsjaq/aDfTAVpvrKCgpDKq9Y=; b=Aae5tzvQm3jfBBasF86hF6oPVjjP3S0sM0+Y9GD8dS1C9tz4OqaI8Tbvclmel2h+yI 20mFA3ea/9h3NuYhrYyZRFZg2/QNAU0i/42StWGqXHag/xVmQs07RVv5wmgViY7k3psg Iv0E/niYJXl+gjPsEQ6co9AzYrrh/yO+Jtlhf4wkRIDhZuyel7254z1MH7hpW8n7Hkyl 8KTaachR4/d5cLJBF5uVpzVFBZIM+ro9VAjZYgJcEcMtd85S2yrDMFLQbLY8pu1ycVfg J7bziu1uvJGiD9QLnlDrpS5JBqXyEehBkQ22Yof/qpbyIFq9o5L3CWaLICOK+bFJeElc AlZw==
X-Gm-Message-State: AOAM532iMJ/dURefNVef0IeY471bcuEuKhUu7h+a1C8MjbwXfpedKvf0 V34mh/eaRDINHceA93lbvRUIEDvz
X-Google-Smtp-Source: ABdhPJxw9YJ2AJs/ebqGQ39w8a9J6fJsjJv0cC/WXrcHJbM9Qf2h+NWFkeE5X2UrSGRiTk9ZjtjnoA==
X-Received: by 2002:a62:158d:: with SMTP id 135mr27985433pfv.287.1594073156412; Mon, 06 Jul 2020 15:05:56 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 73sm20573700pfy.24.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 15:05:55 -0700 (PDT)
To: Tommy Pauly <>, "" <>
References: <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 7 Jul 2020 10:05:52 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 22:05:59 -0000


A good topic. But there's an elephant in the corner of the room and I'm not sure you can ignore it. The same elephant is in the corner of the room where we're discussing the future role of the RFC Series Editor, although I've argued that it shouldn't be there because it's an IETF problem.

To what extent is the standards process itself the enemy of Evolvability, Deployability, and Maintainability? In particular, does the way we handle document revisions and interdependencies make it harder for implementors and operators do decide which features to implement and deploy? Why don't we issue many more of what RFC2026 calls "applicability statements"? Why don't we issue living documents that define which documents are part of a particular standard at a particular time?

It's not that we've never done this to some extent. RFC4294->RFC6434->RFC8504 is an example, but only 3 versions over 13 years is grossly inadequate. An update every 6 months might have been more appropriate.

SMTP has been the classical example for many years, and I suspect that RTCWEB might furnish another good example of this problem before long.

   Brian Carpenter

On 07-Jul-20 07:01, Tommy Pauly wrote:
> The IAB is considering starting a new program that would look at the Evolvability, Deployability, and Maintainability of Internet protocols. The description of the program is included at the bottom of this email.
> We’d like to get feedback on the proposed program topic and description. We’ll be considering this over the next few weeks, and your thoughts and input are welcome!
> Best,
> Tommy
> ======
> Evolvability, Deployability, & Maintainability (EDM) Program
> This program will focus on how to practically encourage best practices within the IETF to ensure that the IETF’s standards process considers protocol evolution, deployability, and long-term maintainability. This group will work on documents that catalog and analyze successful strategies for protocol evolution, deployment, and maintenance, such as updating and extending RFC 6709. Moreover, it will focus on ways to help promote and increase awareness of these strategies within the IETF via program meetings, workshops, and helping organize efforts within working groups and various IETF teams. The program will include members of the IESG and the tools team to help implement these strategies.
> The topics this group will consider include:
>     Evolvability: Encourage protocols to design for extensibility and greasing, and promote the use of extension points to prevent ossification. Make it easy for people, especially those who aren’t steeped in IETF process, to know which extension points are the right ones to use for a given protocol (and which ones should be considered more stable/ossified), and make sure there aren't high allocation barriers to use those extension points.
>     Deployability: Focus on how we make “running code” something that is better integrated into the working group process. Look at methods to catalog implementations, tools for tracking interoperability testing on different protocol versions, or repositories of which versions of protocols are implemented and used on the Internet. Discuss how deployments can advertise experiments they are running.
>     Maintainability: Many working groups have expressed a desire to have ways for the community of protocol designers and implementers to keep track of the current state of affairs in deployment patterns, known errata/bugs, or best practices. Help promote consistent ways to host non-RFC working group output, like FAQs, wikis, and discussion venues. Consider how this community involvement can continue and involve the right experts, even after a working group closes.
> The program will:
> • Engage with the IETF community and implementers outside of the IETF to identity successes and problem areas, and collect ideas for improvements.
> • Work with the IESG and directorates to determine how best practices for evolvability can best be applied during IESG review and IETF last call.
> • Work with the IESG and tools team on ways to connect implementers and communities that develop and maintain protocols, both while a working group is active, and after a working group has concluded its charter.
> _______________________________________________
> Architecture-discuss mailing list