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

Tommy Pauly <> Tue, 07 July 2020 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2E673A0EAE for <>; Tue, 7 Jul 2020 09:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 IKNck5w1lslQ for <>; Tue, 7 Jul 2020 09:13:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FBB23A0EEA for <>; Tue, 7 Jul 2020 09:13:59 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 067GBoQs012760; Tue, 7 Jul 2020 09:13:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=/DVS1Zx4hdzhlskvl8cQKcHOgTsnZopRU0pn8J3l0Sg=; b=Lfy2BvikfakSQtDIm5xDxdJzKCPCinfokRuXHJcKu4BXVKrt2mO5aqpl7TewgJZclcAR kKt9psSaObU2eI75C9vcjKniN7hRxw3R4XClcLrWrTnsnEFw2osLYNw1ZdKxfvh0B3qZ +VqNDIGgC0ikVbY/sbNUz69s5TDijQU/4uxButcynUf7mIsUB38/s7drZyeXVXbawxmv v4EfJMnJAmJD1pZ1BEfDuxL62gYGhwBEZ1tEZk+vgYwSOZL3c5++yieaOuzpv+H0fH2W 7J2e/B9eqmFPnl+A9bZ3g+NC7quZAbsHT/IJ/fJqxDi+/3FPlOlO5FsReVSKVa1Q8ARj eQ==
Received: from ( []) by with ESMTP id 322pbgpey4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 09:13:58 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT)
X-Va-T-CD: 12fa274a8ac4bdea3545590c5a22954d
X-Va-E-CD: bcd61776ccdadbe608423dce34dca614
X-Va-R-CD: bac555b35f687522e43a301dfa6af0af
X-Va-CD: 0
X-Va-ID: b297e4e9-7c48-4e42-8e9f-cda9dc0643b7
X-V-T-CD: 12fa274a8ac4bdea3545590c5a22954d
X-V-E-CD: bcd61776ccdadbe608423dce34dca614
X-V-R-CD: bac555b35f687522e43a301dfa6af0af
X-V-CD: 0
X-V-ID: 4f3febc9-9f69-426a-9f71-f2f14495eeb3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_09:2020-07-07, 2020-07-07 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tommy Pauly <>
In-reply-to: <>
Date: Tue, 07 Jul 2020 09:13:53 -0700
Cc: "" <>
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_09:2020-07-07, 2020-07-07 signatures=0
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: Tue, 07 Jul 2020 16:14:01 -0000

Hi Brian,

Thanks for your thoughts. I definitely do see the elephant there—but I think there is some good work to do that may in time let us better address the elephant.

I think our processes around standards can, at times, be stumbling blocks to these goals Evolvability, Deployability, and Maintainability. That being said, I don’t think they are fundamentally at odds. The RFC process we have works well for the pieces of work that need to be carefully reviewed, and “set in stone”. Having these stable references is good. But, as you point out, that same process and same format can be less conducive to the more “fluid” work we do, such as applicability statements, surveys of current deployments, etc.

I hope that discussions in this area can explore methods to complement our RFCs, without requiring an overhaul such as adding RFC-series living documents.

For example, we already have choices when we set up IANA registries to set a difficult bar (RFC required) or a very easy bar (first-come-first-served). That kind of choice has a large impact on how a protocol can develop and be used.

I’ve also seen fantastic work being done in some working groups to coordinate implementation testing and deployments, but this is ad-hoc and not easily found from within IETF tools like datatracker.

It may be that the discussions end up determining we need to update our relationship with the RFC process, but I think we can also point to successful ways to complement our standards documents with practices and resources that make our protocols safer to evolve, easier to evolve, and clearer to the community.


> On Jul 6, 2020, at 3:05 PM, Brian E Carpenter <> wrote:
> Tommy,
> 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.
> Regards
>   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