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

Toerless Eckert <tte@cs.fau.de> Sun, 29 December 2019 23:21 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 8B0831200D5 for <architecture-discuss@ietfa.amsl.com>; Sun, 29 Dec 2019 15:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.17
X-Spam-Level:
X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 4rEMlKgQCUXw for <architecture-discuss@ietfa.amsl.com>; Sun, 29 Dec 2019 15:21:55 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8531200CD for <architecture-discuss@iab.org>; Sun, 29 Dec 2019 15:21:55 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5F521548045; Mon, 30 Dec 2019 00:14:54 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5320F440059; Mon, 30 Dec 2019 00:14:54 +0100 (CET)
Date: Mon, 30 Dec 2019 00:14:54 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Patrik F?ltstr?m <paf=40frobbit.se@dmarc.ietf.org>
Cc: Scott Brim <scott.brim@gmail.com>, architecture-discuss@iab.org
Message-ID: <20191229231454.GJ8801@faui48f.informatik.uni-erlangen.de>
References: <ebcca2be-6839-8f43-d74f-0e863e32cd2d@cs.tcd.ie> <2068147434.6516.1577178675917@appsuite-gw1.open-xchange.com> <LO2P265MB05733E4BD5A72EDEF96D3DE2C2290@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <6.2.5.6.2.20191227130815.120fc690@elandnews.com> <LO2P265MB0573E1B462A3804525BB2646C2250@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <2CA4CBDC-CAB0-4E02-BC4C-40DF67FB64BC@tony.li> <LO2P265MB05733F3BE310F2B6DAFDA54FC2250@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <304321FD-CB1A-45FE-B67D-0C8ABA6F0BF5@frobbit.se> <CAPv4CP9nZXREJDu9bauseQ5DWsCv9vioYsRLirp25uqx+n=Nzg@mail.gmail.com> <E95AE27C-005B-48CE-8B24-38F344902B7F@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E95AE27C-005B-48CE-8B24-38F344902B7F@frobbit.se>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/UIZ1c0cY0-Fk3xeUHTEvbzUIfQ8>
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: Sun, 29 Dec 2019 23:21:57 -0000

On Sun, Dec 29, 2019 at 08:15:42AM +0100, Patrik F?ltstr?m wrote:
> Correct Scott, but I was more thinking of the fact ITU-T results might bind the members (the member States) by treaties, which implies the members do not have any choice but implement the outcomes. Just like ICANN outcomes are binding for the contracted parties in many cases.

Any example where the ITU-T work result itself includes contractual
obligations that where actually worked out by ITU-T ? As opposed to 
those obligations being drafted separately after the fact, aka: where
ITU-T jut provides the technical basis ?

> IETF do not have such arrangements. We implement if we like what IETF produce.

There is probably a lot more commercial interests hanging on a (limited
subset of) IETF output than legal one, but i am sure its not too
difficult to find legal requirements referring to IEF work result.

Toerless