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

Tommy Pauly <tpauly@apple.com> Tue, 07 July 2020 15:47 UTC

Return-Path: <tpauly@apple.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 33AB53A0EBC for <architecture-discuss@ietfa.amsl.com>; Tue, 7 Jul 2020 08:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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=apple.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 cNY3SeV6BmvW for <architecture-discuss@ietfa.amsl.com>; Tue, 7 Jul 2020 08:47:52 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FDC3A0EB2 for <architecture-discuss@iab.org>; Tue, 7 Jul 2020 08:47:48 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 067FcD2n061853; Tue, 7 Jul 2020 08:47:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=GvSx0CYG9U4044lRwuG9/KfCwol51YYfk3qY9fG2BPk=; b=i/zeMkeGHN/3HZODKKp5b2FCdnAWqX3tzkHBFw0BG/e2JagifIX2Dw85az0dqseKThC+ P3gzSFPDP+CVxzDPFbg11JiGgahQ9E6UM5UqxN7h82QPh3Y77g9ZNKX2ymPRQnr6OXgI bfFxNOd0U67r6qJ3m+9GJht63rtQa0+HoHHm76ttLxIrwBGYV1TMGKeisS6J33eeLo5H zjIL6IeuLlJXk4UmAzRPoF0WBx4WG9S5LLfosjSieGWz87oGOw0kXusDaIGGJtzQkfJc 68ftgUTKB7j5vWfzLIGtrzCDqo920sEiCo2tKDzc+0QQmVCCoCvKDrD1JvZtXTK2ajEz +Q==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 3239fpd45q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 08:47:41 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD300JWRVVGR740@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 07 Jul 2020 08:47:41 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD300K00VP56Z00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 08:47:41 -0700 (PDT)
X-Va-A:
X-Va-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7
X-Va-E-CD: bcd61776ccdadbe608423dce34dca614
X-Va-R-CD: bac555b35f687522e43a301dfa6af0af
X-Va-CD: 0
X-Va-ID: b325e389-abba-477d-82e6-f9f64a1718c2
X-V-A:
X-V-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7
X-V-E-CD: bcd61776ccdadbe608423dce34dca614
X-V-R-CD: bac555b35f687522e43a301dfa6af0af
X-V-CD: 0
X-V-ID: 41685eef-f0a3-477b-a2f6-0e2e636b1667
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_08:2020-07-07, 2020-07-07 signatures=0
Received: from [17.235.29.10] (unknown [17.235.29.10]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD300O3JVVFYD00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 08:47:40 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de>
Date: Tue, 07 Jul 2020 08:47:39 -0700
Cc: "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Content-transfer-encoding: quoted-printable
Message-id: <DAF6DCDC-A3AF-49DE-A3F8-28878D9BC04C@apple.com>
References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_08:2020-07-07, 2020-07-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/7SEnI9cW_2w4HN5WsPfQ696NFx0>
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, 07 Jul 2020 15:47:54 -0000

Hi Toerless,

> On Jul 6, 2020, at 1:01 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> Thanks, Tommy,
> 
> inline
> 
> 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).

Sure! “IETF protocols” can be used here—or perhaps just “networking protocols”. This should be inclusive.
> 
>> 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
> terminology, 
> 
> 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.

This is a useful point to bring up. I think discussing ways of highlighting extension points, either via standard text in documents, or by highlighting in a registry like IANA, would be a valuable tool to have across protocols.

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

Yes, this language is a bit focused on end-hosts, but analogous considerations for routers, etc, would be good to include.

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

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.

Best,
Tommy

> 
> Cheers
>    Toerless
> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 
> 
> -- 
> ---
> tte@cs.fau.de