Re: [arch-d] possible new IAB programme on Internet resilience

Lucy Lynch <llynch@civil-tongue.net> Tue, 31 December 2019 19:27 UTC

Return-Path: <llynch@civil-tongue.net>
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 331D412001E for <architecture-discuss@ietfa.amsl.com>; Tue, 31 Dec 2019 11:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 06JLcslmXCKO for <architecture-discuss@ietfa.amsl.com>; Tue, 31 Dec 2019 11:27:24 -0800 (PST)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id 7002D120013 for <architecture-discuss@iab.org>; Tue, 31 Dec 2019 11:27:24 -0800 (PST)
Received: from hans.rg.net (localhost [127.0.0.1]) by hans.rg.net (8.15.2/8.15.2) with ESMTPS id xBVJRHNS024850 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 19:27:17 GMT (envelope-from llynch@civil-tongue.net)
Received: from localhost (llynch@localhost) by hans.rg.net (8.15.2/8.15.2/Submit) with ESMTP id xBVJRHfA024847; Tue, 31 Dec 2019 19:27:17 GMT (envelope-from llynch@civil-tongue.net)
Date: Tue, 31 Dec 2019 19:27:17 +0000
From: Lucy Lynch <llynch@civil-tongue.net>
X-X-Sender: llynch@hans.rg.net
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: architecture-discuss@iab.org
In-Reply-To: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie>
Message-ID: <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net>
References: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie>
User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6558978127915502828=="
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/qo4evXDIVVDhgNKQ0XzzSMsXwpM>
Subject: Re: [arch-d] possible new IAB programme on Internet resilience
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, 31 Dec 2019 19:27:26 -0000


On Fri, 20 Dec 2019, Stephen Farrell wrote:

>
> Hiya,
>
> The IAB are considering starting up a programme on Internet
> resilience as described at [1]. We'd love to get feedback
> on that idea, the text at [1] and to find out if people
> would like to participate and what topics you might suggest
> be considered (or even better, what you'd actually do work
> on yourself:-).
>
> There's no specific deadline for this, but the IAB will
> consider this further in the new year, so if you could
> take a few minutes to share your thoughts on this before
> or over the holidays that'd be great.
>
> Thanks,
> S.
>
>
> [1] https://github.com/intarchboard/resilience/
>

Circling back to the top here.

I think this is a fine topic for an IAB program and I took the
draft charter to encompass resilience as both a technical and a
design problem. I am particularly interested in this statement:

Definition of resilience:

1]  the capability of a strained body to recover its size and shape
     after deformation caused especially by compressive stress
2]  an ability to recover from or adjust easily to misfortune or change

This program is mostly interested in definition #2.

I actually have my own concerns related to #1 as well and would hope that 
this program might consider the warping of the overall Internet model to 
accommodate currents trends or business practices.

As an example - an Internet optimized for the web may not be the same
internet that supports real time data collection and shared computation in 
the context of big science. How do we avoid closing out capabilities as we 
optimize for others? Narrowing of choices looks like a path to a limited 
and more brittle model to me.

I'm sad to see the thread degenerate into mostly policy concerns when
there are still fundamental design issues that need to be addressed.
Policy is one way of dealing with the outcomes of design and implementation 
but it seems to be a follow on and this charter is proposing a more 
technical examination of the root problem.

I could be wrong...


- Lucy
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss