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

Toerless Eckert <> Mon, 06 July 2020 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7061B3A0B9B for <>; Mon, 6 Jul 2020 15:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MslxuG2sGGsz for <>; Mon, 6 Jul 2020 15:20:27 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFB613A0BAE for <>; Mon, 6 Jul 2020 15:20:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2783548442; Tue, 7 Jul 2020 00:20:20 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 9C302440043; Tue, 7 Jul 2020 00:20:20 +0200 (CEST)
Date: Tue, 7 Jul 2020 00:20:20 +0200
From: Toerless Eckert <>
To: Brian E Carpenter <>
Cc: Tommy Pauly <>, "" <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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:20:36 -0000


I thought to remember tht Warren mentioned last year some interest
in new processes for "living documents" primarily in OPS. Have
not tracked enough mailing lists to know if/what is happening (if anything),
but i agree that those different type of document lifecycle models
would be crucial to tackle the topics proposed.

But i think it would be perfect to simply learn by doing, and not
bother too much about FIRST working out the document structure and THEN
commit the payload.

Aka: this could be a good set of topics for a living-document-hackathon.


On Tue, Jul 07, 2020 at 10:05:52AM +1200, 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
> >
> >
> > 
> _______________________________________________
> Architecture-discuss mailing list