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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 July 2020 20:49 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 A24803A0A6A for <architecture-discuss@ietfa.amsl.com>; Tue, 21 Jul 2020 13:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=gmail.com
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 2u7PhVwBV7aa for <architecture-discuss@ietfa.amsl.com>; Tue, 21 Jul 2020 13:48:59 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 0D6983A0A69 for <architecture-discuss@ietf.org>; Tue, 21 Jul 2020 13:48:58 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id k27so31259pgm.2 for <architecture-discuss@ietf.org>; Tue, 21 Jul 2020 13:48:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sYrAS98FX+bWj/xNu+vA/N3wtdIlbgGYiZI7TgdKq3g=; b=X5eZ0cZLb7hActabl3oaI1bUTEsRSl4npmdUS+3v1i3tAqdMI7+LAR1BrWws4eHeDb R4neEWtDTFnU27m/Igf9Su/1xhFPyKCTX+OOnPuH36UoIFVCYNatmhloTH5s02EVkEFe M+0hajdNiIfgEZj72BKHM3yMSDQaqTcAPRFlOmg/u/ot7qzAxwr9l7BW52EJxfOvq6Bb YAQAzg2D6vKbwKcbfw5NWJI62jCvdfJvrX+JOa+E0cTIxemc0jQPCQLX/yfeexJCyufc OcnXNDrKaPyinMmUy4emr0EO6oT4F7nOD/8C/Da8paM3cuEKMSy4QQrRceSbZA/805BQ nw6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sYrAS98FX+bWj/xNu+vA/N3wtdIlbgGYiZI7TgdKq3g=; b=lK2/LpP7z2H2mIIMJPiAjxtqb22Ug48qOo8Vts4BMJwtvzFoF9FNsnp7/fGO+isJID EJEiEiQJpggw7MtvxZIjd4t5id7QjXIB/LHe2AXhcEBxpjRVyW2EZ6EFEhLk7kMwuCHG a2U1+kiNdep410nj35FwOWErJ/0cfD4aa+s0gd59uIt85gWs8pIJtb/edjSUiAoWK3mp nSFY0QERgNIV5RvacW91k18AXurzc90k/UDHB1BnrxZf0+Inykocwl7z5WdDhvg22A18 VvAH3YopWfuIomWjma8R5P10wfozAowQXAgI5BeVFmsCnW8zR1oZ+UD31wr//6Je1N5x /Q2A==
X-Gm-Message-State: AOAM530WfQ4AkAqjwFMBGu7yVashbE7QeA3ct2huGsdfYOAODcacM45+ L+VD24e5NCQW+0LdPVzdhItinwhj
X-Google-Smtp-Source: ABdhPJw7hnXjgoha8DWcpu93pgqjPAvDupcl9fLPLyFlWxnCvI2ayq4wRZ8tbInaQjuLmUBkSxhdng==
X-Received: by 2002:a63:d501:: with SMTP id c1mr24155057pgg.159.1595364537955; Tue, 21 Jul 2020 13:48:57 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id h1sm19351786pgn.41.2020.07.21.13.48.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2020 13:48:57 -0700 (PDT)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Christopher Wood <caw@heapingbits.net>
Cc: architecture-discuss@ietf.org
References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <fb397f5f-b792-4338-9112-a4a7a4d967c0@www.fastmail.com> <CAKKJt-fNX16Ap8afcg55DXj3DFb8mGYdB3MxHtLyyMN5a0eFLQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <ee8081e3-6ceb-e523-8f31-d870f975e43d@gmail.com>
Date: Wed, 22 Jul 2020 08:48:54 +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: <CAKKJt-fNX16Ap8afcg55DXj3DFb8mGYdB3MxHtLyyMN5a0eFLQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ke9gtANFC8u4VWXqmC5XRAaj9ec>
Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability.
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: Tue, 21 Jul 2020 20:49:01 -0000

Yes. I don't see C238 as disjoint from the problem I already raised:
https://mailarchive.ietf.org/arch/msg/architecture-discuss/A0ZP4w-UhX7Cu5E8gSPK1haSDWI/
In fact I even mentioned RTCWEB there.

Unsurprisingly, I think that if we don't tackle this problem, technical efforts on Evolvability, Deployability , & Maintainability will be futile.

Regards
   Brian Carpenter

On 22-Jul-20 02:06, Spencer Dawkins at IETF wrote:
> Because (for reasons I don't understand) I'm involved in AUTH48 processing for RTCWeb, I find myself wondering whether the proposed IAB program might include considering ways to avoid C-238-style protocol specification clusters, whether from the point of view of architectural oversight, standards process oversight, or RFC Editor oversight. 
> 
> If you're not aware of C238, check out https://www.rfc-editor.org/auth48/C238 for a truly amazing picture of what we are doing today. 
> 
> I'm sort of kidding, and sort of not. 
> 
> Best,
> 
> Spencer
> 
> On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood <caw@heapingbits.net <mailto:caw@heapingbits.net>> wrote:
> 
>     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 <mailto:Architecture-discuss@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/architecture-discuss
>     >
> 
>     _______________________________________________
>     Architecture-discuss mailing list
>     Architecture-discuss@ietf.org <mailto:Architecture-discuss@ietf.org>
>     https://www.ietf.org/mailman/listinfo/architecture-discuss
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>