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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F13D63A08C6 for <>; Tue, 7 Jul 2020 09:41:21 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 YMjDvO9kL_Fg for <>; Tue, 7 Jul 2020 09:41:20 -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 08DD23A08D4 for <>; Tue, 7 Jul 2020 09:41:19 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 067GaPco055734; Tue, 7 Jul 2020 09:41:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=1ecgVNqCVgV4UIT8dpYlQhgFjZurcpwCIZT7M4Kwqzk=; b=klwhd24xAuA+K4MSJ3KoP7I4bxHavLSn5TOW7FdgnBim7S7WZaQjPv6xCwe6/YIqi5+p IucA8aghVuvmKK8OedBQf6By80LHAosxMxukIWJLrvoMXbDxEMMFdDosy5gJjQCyyECI df5YPScqMG3r4aQ39yA8dRbm5Hyc8hppSr050uagiDj4uhxQaREWhf65NZnGmR+THTyq N58SEr9FRTVftxH/p1o1Gtaqn1H3XAcAehUsVkgBNVrSJaIatuEte8GkDMglDq03wH6G YRgXv5bxTyGcx6dwOv5C2n8buBzsYRonGafAwoZyJch3fjR+I+hYypqY9GgwwV1L2wfA sA==
Received: from ( []) by with ESMTP id 322re2futm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 09:41:05 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Tue, 07 Jul 2020 09:41:04 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Tue, 07 Jul 2020 09:41:04 -0700 (PDT)
X-Va-T-CD: 9ef1c94aca2a985c968936d4baa34f4e
X-Va-E-CD: e09119d25ab8b07de2747025f15c7ff3
X-Va-R-CD: 28b4ff53863a9a590a7a640f753ab2c8
X-Va-CD: 0
X-Va-ID: cc05fcc8-8ec4-4f5e-8ad1-606a0d5bf9ce
X-V-T-CD: 9ef1c94aca2a985c968936d4baa34f4e
X-V-E-CD: e09119d25ab8b07de2747025f15c7ff3
X-V-R-CD: 28b4ff53863a9a590a7a640f753ab2c8
X-V-CD: 0
X-V-ID: a7cce3ed-67d8-45ff-85c5-b349383244fd
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:41:03 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_2953DA2D-91CB-44B3-A6F3-1C67E0DB82C4"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 07 Jul 2020 09:41:02 -0700
In-reply-to: <>
To: S Moonesamy <>
References: <> <>
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:41:22 -0000

Hello S. Moonesamy,

Thanks for expressing your concern. I want to assure you that this program is not trying to replicate the role of the IESG or any working group, but rather to help coordinate conversations with the IESG, working groups, IETF community, and external communities. The specific focus of these discussions is to look at how we can achieve the architectural goals of an evolvable and maintainable protocol stack.

The problems we are trying to address are indeed architectural: can we avoid or mitigate the ossification of protocols? Can we promote the reuse and extension of IETF protocols and avoid duplication and non-interoperable proprietary solutions?

However, the solution-space involves improving how protocols are defined, how their extension points and allocation spaces are defined, and how working groups communicate and engage with implementer communities.

The proposed program would include IESG members, tools team members, WG chairs, implementers, etc. Those would be the bodies that actually enact changes. The role of the IAB here is to organize the discussions and highlight the impact on architecture.

Here are some references to highlight how this organizational role is indeed within the charter and role of the IAB:

“[The IAB] is also expected to play a role in assuring that
   the people responsible for evolving the Internet and its technology
   are aware of the essential elements of the Internet architecture.”
( <>)

"The IAB also helps connect different fields of expertise when this is needed to understand the full situation affecting the evolution of the Internet.” ( <>)


> On Jul 6, 2020, at 4:18 PM, S Moonesamy <> wrote:
> Hi Tommy,
> At 12:01 PM 06-07-2020, 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!
> One of the roles of the Internet Architecture Board (IAB) is to "provide oversight of the architecture for the protocols and procedures used by the Internet".  It is not a good idea, in my opinion, to stray too far from that role by, for example, replicating the role of the Internet Engineering Steering Group (IESG) or being involved in matters which are not under its (RFC) policy authority.
> I doubt that it is possible to make "running code" part of the working group process unless "running code" is interpreted as implementing a specification as software-in-the-lab.
> In 2017, the IAB issued a response to FCC-17-89.  It stated that "The IETF TRANS working group is nearing completion of work on a revision to Certificate Transparency".  The work is still incomplete.
> Is setting up a program to tackle a people problem is not a good recipe for success?  I suggest giving some thought to that.
> Regards,
> S. Moonesamy