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

Toerless Eckert <> Tue, 07 July 2020 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 696983A00DF for <>; Tue, 7 Jul 2020 10:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZwBmteQzXtef for <>; Tue, 7 Jul 2020 10:37:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8667D3A0062 for <>; Tue, 7 Jul 2020 10:37:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75CA5548442; Tue, 7 Jul 2020 19:37:52 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 6CF8B440043; Tue, 7 Jul 2020 19:37:52 +0200 (CEST)
Date: Tue, 7 Jul 2020 19:37:52 +0200
From: Toerless Eckert <>
To: Tommy Pauly <>
Cc: "" <>
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: Tue, 07 Jul 2020 17:37:59 -0000

On Tue, Jul 07, 2020 at 08:47:39AM -0700, Tommy Pauly wrote:
> > For deployability on network "equipment", router/switches/gateways with
> > hardware accelerated forwarding and other processing planes, there
> > are additional considerations IMHO most important for this space:
> Yes, this language is a bit focused on end-hosts, but analogous considerations for routers, etc, would be good to include.

Happy to help, let me know if/when you want to go refining text.

> > This would all be great work to do if it was not executed ONLY via a current
> > IAB program. This is too important work to be subject to the whim of
> > IAB member interest. Its not maintaineable if its only done via an
> > IAB program.
> > 
> > IMHO, this should be an IAB AG (architecture group) that has IAB
> > members (like IESG members) as sponsors and creators, but which has
> > AG chairs running a standard RG/WG process, that can persist beyond
> > the terms of individual IAB members interests, and that isn't subject
> > to all the other issues i have with IAB processes.
> > 
> > Aka: No need to work on maintaineability if the process to work on
> > maintainability is not maintainable.
> The work of maintaining mechanisms here long-term probably doesn???t belong in an IAB program or group, but rather as something that is run by the IESG or a WG. This program could certainly recommend such a function.

Well, this is a more generic criticism on my behalf on the structure and IAB processes:
IETF WGs are not mean to work on long term architecture topics. thats for IAB.
IRTF GGs are not mean to work on long term architecture topics. thats for IAB.

Aka: Why are there no architecture groups equalling WG/RGs ? IMHO we clearly see
limits to the current process of IAB programs, and IMHO RG/WGs working better.

All the things you bring up ar goin to be long-term architecture work items,
i just can't see this to work well within IAB programs and it does not belong into
RG/WGs, we need AGs too IMHO