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

Christopher Wood <caw@heapingbits.net> Fri, 10 July 2020 15:51 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD043A0E75 for <architecture-discuss@ietfa.amsl.com>; Fri, 10 Jul 2020 08:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=EngjHlk+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HF628d8a
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 DYBmT3Rgj0BD for <architecture-discuss@ietfa.amsl.com>; Fri, 10 Jul 2020 08:51:13 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5283A0E6E for <architecture-discuss@ietf.org>; Fri, 10 Jul 2020 08:51:13 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0EB765C0170 for <architecture-discuss@ietf.org>; Fri, 10 Jul 2020 11:51:13 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 10 Jul 2020 11:51:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=L6iAT B9YePevt8F6DZf69IT0F60/FHL0R8b+CCFSZLg=; b=EngjHlk+3i1E4Dc9f5czy dZJaxcXtzz+fxtNr02rVW9N902S9iRT7w0vXU3kbFZTFVfHVjAregy4ieptLACGh KvdNMAkKp9jYZkA6MfXcKy884vopzfUmXCRTiCQvfKugvIMkc+7O7BLCZAxnh3uY 7gHREKJbiltIjHqljGRmr4rndN80AzUB8klZwY9zH0q6se8Atb2ynRd3TQCUZ8Pd VEevO3Y8VbFUOtsg17bWrDZPNUzbB511sDqym7xcYMEu9hgVEhzsjMPEpTqHyLPm ntjlNrVsC5AvMKPp1ZzD2Qc4kKjuYuHxmwOXjoeXbe8K0zMFtx/FvuzDC+FrrkB3 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=L6iATB9YePevt8F6DZf69IT0F60/FHL0R8b+CCFSZ Lg=; b=HF628d8aVDmpJg50/oogjLvZvqclypJkD7kGn0OHK1ilBn0P+v3faMuAy ldYv82Zdk78Gy1+xcMVDy4FH0KisskQ5QnuNgdt6CpXUkoXP6XAV7u4Aat2yPfM1 uCuszaCK/IEAXrznZjeB6AQJYOxDIqmW57fNpUu8z+KE2yu4Te7eCqbPGgP31i+l gFlL98KWup/zP0Nigi2bIuGFpq9eKXktppqesKqywhzjhjrwNJcc0idYAsTalEkl xLgjwFMz1POcEjyi9t5p+oOGPAXswwSFDo+dG4FpHt0afI2tDZsHb9P+wi85Zozt 9iExgj0y4enCvlKxjgyRFtQ+7cMfg==
X-ME-Sender: <xms:cI4IX7kIzD-EndhaEbwKi-1uPaCS62RRH0pqu-_KmmM7yXJAfaQ0rg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvddugdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeffkefhudethf elleeuteelkedvfeehleefvdefieeggeejteevhfegffejffettdenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:cI4IX-0IODr0GBWUgv0yq9BfydyvoyM5z6g1VgmKU5IAFHVPBlG8xg> <xmx:cI4IXxoTvdlvIXhjtVWkb3EKe_gW1thMPuHWDcKEif237cBDRc0xvA> <xmx:cI4IXznqhQFgp-m7nm3s0ptJo-4aIiYTcuZkipB8oj8ujluLoWFIFA> <xmx:cY4IX41fyJcYFbdIcm-FQRCTvpELccrWfnucIEOYRBsEIRAZ4ZwHYA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8A50D3C00A1; Fri, 10 Jul 2020 11:51:12 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <fb397f5f-b792-4338-9112-a4a7a4d967c0@www.fastmail.com>
In-Reply-To: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com>
References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com>
Date: Fri, 10 Jul 2020 08:50:48 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: architecture-discuss@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/Gs5IhLqQIWeI8kW_DFp-4T8wIYM>
Subject: [arch-d] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fUHJvcG9zZWRfSUFCX3Byb2dy?= =?utf-8?q?am=3A=5FEvolvability=2C_=5FDeployability=3F=3D_=2C_=26_Maintain?= =?utf-8?q?ability=2E?=
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2020 15:51:16 -0000

Hi Tommy,

I think this is a terrific idea. All three areas are certainly worth exploring. Deployability and Maintainability in particular might even make sense as topics of their own program, separate from Evolvability. 

However we cut it, I'd like to see progress in the proposed areas, especially for the TLS WG. Methods and tooling support to help track ongoing implementations of protocol extensions would be valuable for the documents we publish and many drafts we have in flight. We have [1] and [2], though they're not well maintained. A common way to track this information for the community would be great.

Best,
Chris

[1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md
[2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md

On Mon, Jul 6, 2020, at 12:01 PM, 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@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>