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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 007D63A0A01 for <>; Mon, 6 Jul 2020 13:01:42 -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 10l6GWQfkqCc for <>; Mon, 6 Jul 2020 13:01:39 -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 66A023A0A00 for <>; Mon, 6 Jul 2020 13:01:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 83B58548441; Mon, 6 Jul 2020 22:01:33 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 76822440043; Mon, 6 Jul 2020 22:01:33 +0200 (CEST)
Date: Mon, 6 Jul 2020 22:01:33 +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: Mon, 06 Jul 2020 20:01:42 -0000

Thanks, Tommy,


On Mon, Jul 06, 2020 at 12:01:58PM -0700, 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.

Std toerless rant#1: The Internet is the 10% above waterline of the iceberg which is IETF protocols. Please do not ignore the remaining other 90% of "private network" use. Maybe use term "ITF protocols" or something similar to make it clear whether you want to target 10% or 100% (or anything in between).

> 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.

I would like to see the work item point:
  "IESG safe documentation of extension point / behavior / possible benefits"

Explanation: i had a painfull IESG review of a draft of mine where we used
a simple terminology at the end of sections saying things like 

"future work may <example of use of an extension point / benefit / ...>".

The IESG review feedback (primarily from GEN) was that this draft looked
unfinished and should not be standardized because of the repeated use of the
term "future work". I had to remove all of this text, partially putting
things into non-normative appendices, etc.. pp.

In later IESG review i had to add some notes about future work with this

Now it is impossible (like in IMHO all other RFC) to easily find extension
point documentation in my draft consistently.

At the risk of getting into a similar endless debate as Mirja's good intentioned
update to "update", maybe there could be terminology like "FUTURE" that
allows to formally show / explain extension points. Or anything else to
easier document them through the IESG review process.

> 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.

I think you are listing what likely are the key issues for application/software
centric issues with deployability (down to at most host-stack).

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:

Models for internal behavior of forwarding/control-plane against which to
assess behavior/scalability/cost of proposed protocols (amount of state,
complexity of QoS / packet processing),.. Architecture direction to evolve
these type of protocol devices into a more "software centric" model.

For example, it took about a decade in my memory before IETF would even
include terms like RIB or FIB into routing area protocol RC because
"dogmatic" IETF persons did reject them in before as something not
externally visible and hence irrelevant to interop behavior.

We had last year a session to talk about router forwarding planes where
a bit of this was touched, but we never followed up with any documentation
in form of BCPs and the like. Obviously this is a lot of work, but
IMHO well worth it if not required for future evolution.

For example 2: I still have ongoing discussions with IESG about the validity
of internal interfaces between SW components in routers in standards track
documents, because it supposedly does not impact interoperability (between
devices), and the mere thought that these software components could be
from different vendors has not entered the mindset of most IESG people working
 with routers.

> 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.

Definitely, but... (see below)

> 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.

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.


> _______________________________________________
> Architecture-discuss mailing list