From nobody Thu Oct 11 03:14:25 2018 Return-Path: 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 D0E26130DE2; Thu, 11 Oct 2018 03:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4mRy7DKxEZU3; Thu, 11 Oct 2018 03:14:13 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C915130DD6; Thu, 11 Oct 2018 03:14:11 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 20E98341B38; Thu, 11 Oct 2018 12:14:08 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/20439.15747); Thu, 11 Oct 2018 12:14:07 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 11 Oct 2018 12:14:07 +0200 (CEST) Received: from [195.176.110.240] (account ietf@trammell.ch HELO public-docking-etx-1572.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 70054875; Thu, 11 Oct 2018 12:14:07 +0200 From: "Brian Trammell (IETF)" Message-Id: <0A2FB385-324E-4B9B-948D-805EE1D27B22@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_43BA70BA-EB39-4453-BDE3-DF046FE5B548"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 12:14:06 +0200 In-Reply-To: <153920647209.5767.3153582437383065146@ietfa.amsl.com> Cc: Internet Architecture Board , IETF-Discussion To: architecture-discuss@ietf.org References: <153920647209.5767.3153582437383065146@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [arch-d] [IAB] I-D Action: draft-iab-wire-image-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 10:14:15 -0000 --Apple-Mail=_43BA70BA-EB39-4453-BDE3-DF046FE5B548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, This revision of the wire image draft addresses feedback received during = the call for comment period, specifically with respect to the scope of = the definition and the properties of the wire image, and better places = this document in the context of ongoing efforts to increase the = confidentiality of Internet traffic. Please direct further feedback and discussion to = architecture-discuss@ietf.org and iab@iab.org. Thanks, cheers, Brian > On 10 Oct 2018, at 23:21, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Internet Architecture Board IETF of = the IETF. >=20 > Title : The Wire Image of a Network Protocol > Authors : Brian Trammell > Mirja Kuehlewind > Filename : draft-iab-wire-image-00.txt > Pages : 9 > Date : 2018-10-10 >=20 > Abstract: > This document defines the wire image, an abstraction of the > information available to an on-path non-participant in a networking > protocol. This abstraction is intended to shed light on the > implications on increased encryption has for network functions that > use the wire image. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iab-wire-image/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-iab-wire-image-00 > https://datatracker.ietf.org/doc/html/draft-iab-wire-image-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_43BA70BA-EB39-4453-BDE3-DF046FE5B548 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlu/Im4ACgkQihK3vwvq RqPivRAAmTfT+NPl3uv1RvEcKPFE/ENvCwOdxvyw8BLmPIoiBRTAEWklvzG48RcW /tCjFeWhnqla+8i9tZVtkSSgZXaVX1fnm4bxaq+dMRQ8V0oW7NvfS+3+Fi7cA58R Zgd+BITMWqpFEPKdwIwm8W0+MGBmKpsCScVIKlxyw6aCwRIrlXR9yImi/o5iBDB2 AJ40Go0KaP1wzi/xeA2V6J934YLbjUe2MwJwKqOUp/wiO5QFEhejWTOwIe/4jdqH 0r3yUz39nPV03gz9tzCY55h5zo2PvKlDQgXu8KatLfdkwBzK+VsP2X9oya5UCJrO F2K4qY8ltZt25pZOksG6E+QJ5CudUzD4i2JmswrbG7bYuvJDzO5ih8LCe2QDHDW+ E0a6QI3fNfgYKm2AiGfhU1NHWznMr/XmDnwJAX8FP7vzqBhpuBrQCcmo13z91T9e ogqbzJ3tHD5GLdSASQ0F5M2445Nv9CM2PMF/JpfcbhxddrWWY8S0GEL8S1Hi0wbl 7y35ox9GvFevnCliSHDCvUic8h7FUnyPpakyv8bQi2/gyNJ063hiE+HpcM9cYeXG Qu0Qm21T7SkeH6EyUJx9jvph9744agR43JuSvAUj+J7fVDbUW1GjLqWWqS4wDMpa 1rM8oRITRr/HgwdrbrpouFyxZQbZ0gdqq4xm7JnAI/qE0hO8l1Q= =OJLN -----END PGP SIGNATURE----- --Apple-Mail=_43BA70BA-EB39-4453-BDE3-DF046FE5B548-- From nobody Sun Oct 14 17:42:10 2018 Return-Path: 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 A7A981286E3 for ; Sun, 14 Oct 2018 17:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 4T03JQ_y6QOx for ; Sun, 14 Oct 2018 17:42:06 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D98712777C for ; Sun, 14 Oct 2018 17:42:06 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id j23-v6so8772510pfi.4 for ; Sun, 14 Oct 2018 17:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V+8Ug6PLn5gfrflwE7KTRXPOQtRQsviYNAIOYMBCqcA=; b=WI4kpzXIofhjn9K0w04fMOTORb9uIuE8y7XrHkV+YQm61sZ9RR6jSz20WRuDl+4GS7 ykGHpP5am5g+Q+TAgJh5cGkFCSSNnTUCOXUDeGRXHPeYOzFxxAGxCY/CoBBbXTriM6PA nrwA6MmtVRFhJ2Fuvxc322vyoUDxm3nFIOjry5JJbfg9Io26uQ0AgxyluqGVxL4Gl3Xq AKgS8MCM2RD65wd2xBVvkyM8TchLMAnHTZ6uqeAM/C4dPYwES9MMA1qqIcuulU8GJdsX wpqu8vaGiqovHOnXmBgyZbFncftaqu3V8VC7mZ8JiX8Kr060a814zZl22JhLkVBPdJB6 bSmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V+8Ug6PLn5gfrflwE7KTRXPOQtRQsviYNAIOYMBCqcA=; b=tocdvPuno2vEG7/Y6a1XbyeaOyazohyTl9wyJ6HzxK4qJjp1eS1Qx5NtBAZ5xLNa/6 hm7hZZusOuRNB1+Y+rUmdd1+0TwwWDdRZHL3jPJmyMguNep+L3ixNk4DhyygvqYVZedF hYBUdCrISRqNoTAzp8fr7NsxuO1uZeeX0RJf/JkkwRy0xUV4/xXjqBiuyjua2EI8YSMx 5SLrnYy6ib3OmHxsS5BeX5zeBgd2jdhJvTz3RR10kcuKq1dhkoysUOhnDfh/SrxAvn5X 5aF9nmbMRQrVm8Y2gaOVFKRdBxIDobh5pSlNTAYbhHYAzsJrPVhJLg7Fqp2b+3xQ73fj QvYA== X-Gm-Message-State: ABuFfoh7ZFpkEb88cBhjdSYPpHO2H4DsdW8a9j0WblAYqLrp/dDgvrFM gfCVvg/UX2GSOigUlm5VrvmbN49G X-Google-Smtp-Source: ACcGV6122EvOh+Rl6mfLOrWRc96OeMhD8059bLAKo19jI3IXy3qG+yoRIBrXfMr/ghsaiZpO7jzwSg== X-Received: by 2002:a63:4c23:: with SMTP id z35-v6mr14217739pga.312.1539564125623; Sun, 14 Oct 2018 17:42:05 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id j5-v6sm9848149pgm.79.2018.10.14.17.42.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Oct 2018 17:42:04 -0700 (PDT) From: Brian E Carpenter To: architecture-discuss@ietf.org References: <153954555641.5558.6443982058036831464@ietfa.amsl.com> Message-ID: Date: Mon, 15 Oct 2018 13:42:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153954555641.5558.6443982058036831464@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [arch-d] Fwd: I-D Action: draft-carpenter-limited-domains-04.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 00:42:09 -0000 Hi, We have significantly updated this draft, with some reorganization of existing material, and two new sections added: 6. The Scope of Protocols in Limited Domains 7. Functional Requirements of Limited Domains We suggest discussion on the int-area@ietf.org list. Brian + Bing -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-04.txt Date: Sun, 14 Oct 2018 12:32:36 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-limited-domains-04.txt Pages : 22 Date : 2018-10-14 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions, and develops a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of limited domain membership and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-04 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 24 03:21:31 2018 Return-Path: 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 8BC5B130DC3 for ; Wed, 24 Oct 2018 03:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 q6e4WlXzNC4a for ; Wed, 24 Oct 2018 03:21:26 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730051.outbound.protection.outlook.com [40.107.73.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8584C130DC2 for ; Wed, 24 Oct 2018 03:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aWgSlhAX+Cb/rCLh8HYtiQF5F8zsmc2+KAx+Sr8eCrI=; b=oEAMDxhOB52ANkkpUg/mN8y7s+8O+7qABaHGO4rrvAwCCsyDQDdG+uLrr+f5z48P+uYOOeqzsqfI+HlYAM5PBOAWS3/IrkRg2/6X5ueXjhQfS2yapq6cCg3ACvL68iFfQ6AjJ3IdUfGfuOKHQTn4eiOTPNC6PuvO/qhE2EFxEIk= Received: from BN3PR0601MB1314.namprd06.prod.outlook.com (10.161.210.139) by BN3PR0601MB1298.namprd06.prod.outlook.com (10.161.209.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Wed, 24 Oct 2018 10:21:22 +0000 Received: from BN3PR0601MB1314.namprd06.prod.outlook.com ([fe80::6ddc:e11:56b8:b6ba]) by BN3PR0601MB1314.namprd06.prod.outlook.com ([fe80::6ddc:e11:56b8:b6ba%8]) with mapi id 15.20.1250.028; Wed, 24 Oct 2018 10:21:20 +0000 From: Dan York To: "architecture-discuss@ietf.org" Thread-Topic: New I-D: Considerations on Internet Consolidation and the Internet Architecture Thread-Index: AQHUa4NOBE2lZ/rxuEqu+g9agBuIOQ== Date: Wed, 24 Oct 2018 10:21:20 +0000 Message-ID: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-originating-ip: [2601:198:4101:7bd5:d9c7:247e:57c7:3894] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1298; 6:nyAXpwNRnWtqUqCneS4QNSRU/gGv26DkaILarb2grRd4pDA6XXMbE4724NaTWd7zfg2j6n+a3mGlNZzWbVhJ6EJ6yuS8T2RyfotPRV4qUDT/oaOe8+14OniQnyoej5yHUKJR9ukzHrKm36RBdvsOlAbV9xEohj1FB87gOYxJ52pSxOTZoZoino5HZ4rRdcSSfZRbQuU3rAUCNznzdvqpzeG6erlJKBmE6hiSynlqe02Pn7zYsk4QLmwcPxO43jSmjuISUuubDsOCYF3aOX2wO+kmx0dekVkJDdRyweNT20aTfL4dEh9h/Ef8z2txqiPC0xKXL18GCZQ03QTg3lA7y5hV0P1z7gmcWGtMFuRCl6MWx+2odmP26LjhV544dmC8Ov3jpuxDmWc8UC9n0g3by/RdHA4Nrg80OwHDxRPVcPWwPibAZMJMbrcwiwiAhZZ+UidU6uHUBdx7uGDsfNa9LtZ8fdoFzGsbwAaR+v5HvZM=; 5:jNQtHhzrEq+oMkVjPQEm6aB7//EcqfdUv0Or8le/H3yv+9H+dN14sKKvcMSsD81jZfXgdFBaHzO5SJHXhSyUyaAstvzoPm1PwTB2IA5JCid4+wE8MOE1aX7DEdgucWLO0pCu9D5/yI1FbSvokJCPAFHgjeSmqz6h+WGz29t+C0M=; 7:GMSsunUvmDSYMAKIirrmRd/pI4zBHaIlXJT0w6Ci0QszSUAYjOOjMh5AV1G8C/BWXbSl0ZNI+twmZBUINgKwLi2+bau96A1MboHm4PZ4TiyxN5b94rzJU2BhRykhxjDEsaves4J1vz4l+3domOwRWF5wV+oo/xkHjgxIi0be0e1AB21ODxsBwysgNDoGmHrCj6iwAB7OydLv+2D7qtsGExr1zecOWlsgyyvbuMf1GWpWohQAHINz3PjDdcvVlJxN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 193d4835-a255-48e2-0474-08d6399a7147 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN3PR0601MB1298; x-ms-traffictypediagnostic: BN3PR0601MB1298: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(4982022)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN3PR0601MB1298; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1298; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39850400004)(346002)(396003)(189003)(69234005)(199004)(7736002)(54896002)(97736004)(106356001)(966005)(2900100001)(14444005)(6512007)(6306002)(2501003)(5640700003)(606006)(68736007)(236005)(256004)(6436002)(6486002)(5250100002)(33656002)(14454004)(36756003)(316002)(53936002)(8936002)(8676002)(478600001)(486006)(99286004)(186003)(105586002)(71190400001)(2351001)(83716004)(81156014)(86362001)(6116002)(476003)(46003)(2616005)(71200400001)(25786009)(81166006)(6916009)(53376002)(2906002)(5660300001)(6506007)(102836004)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1298; H:BN3PR0601MB1314.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-microsoft-antispam-message-info: DL3VnKS1AaYrS2FaUw7fzUGNDXaRMz5mZuvFQ2MP/QpHDLiuWBjezUV0P7dYi3BU8nhGmNi4sulnv9emKDjVdXfRxyBgyiVmyNLflxaHVGuDTNIUypJxtTVYmj/z3Qj6eFgd/PY8PZzZeFi/M033RnfzQFjKitMBjaynOlu5GQL3cfl18JS69Q3om5s/tmvVkU5EVJcpQ2O8d0fkIGVD9RKpIwN9cgSsqcjJjRVT9EKuZYt83rgbTPiU0uVSrNcRg6m371CqjruLrgDUQ3KkELV5nAske9bVbLQx+Gan0F4c2MASBD7D7WPg5qRv59zwdGYSy12Bn2DWncOxDhkNjRyfeYkyrYq5B+PjpsdDP4Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_55E43924FFAE473EA43C90DB7C33321Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 193d4835-a255-48e2-0474-08d6399a7147 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 10:21:20.5386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1298 Archived-At: Subject: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 10:21:29 -0000 --_000_55E43924FFAE473EA43C90DB7C33321Cisocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCBKYXJpIEFya2tvIHB1Ymxpc2hlZCBhIG5ldyBkcmFmdCB5ZXN0ZXJkYXkgb24gYmVoYWxm IG9mIHNldmVyYWwgSUFCIG1lbWJlcnMgd2l0aCB0aGUgdGl0bGUgIkNvbnNpZGVyYXRpb25zIG9u IEludGVybmV0IENvbnNvbGlkYXRpb24gYW5kIHRoZSBJbnRlcm5ldCBBcmNoaXRlY3R1cmXigJ06 DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hcmtrby1pYWItaW50ZXJuZXQt Y29uc29saWRhdGlvbi0wMA0KDQpUaGUgdGV4dCBzdGF0ZXMgdGhhdCB0aGUgZHJhZnQgaXMgYmFz ZWQgb2ZmIG9mIHRoZSBJQUIgYmxvZyBwb3N0IGJhY2sgaW4gTWFyY2ggMjAxOCAtIGh0dHBzOi8v d3d3LmlldGYub3JnL2Jsb2cvY29uc29saWRhdGlvbi8gLSBhcyB3ZWxsIGFzIGEgbmV3IHBvc3Qg SmFyaSBhbmQgQnJpYW4gVHJhbW1lbGwgaGF2ZSB3cml0dGVuIGZvciB0aGUgQVBOSUMgYW5kIFJJ UEUgc2l0ZXM6IGh0dHBzOi8vYmxvZy5hcG5pYy5uZXQvMjAxOC8xMC8yNC9vcGluaW9uLWNvbnNv bGlkYXRpb24tY2VudHJhbGl6YXRpb24tYW5kLXRoZS1pbnRlcm5ldC1hcmNoaXRlY3R1cmUvDQoN ClRoZSBhYnN0cmFjdCBvZiB0aGUgSW50ZXJuZXQgRHJhZnQgaXM6DQoNCiAgIE1hbnkgb2YgdXMg aGF2ZSBoZWxkIGEgdmlzaW9uIG9mIHRoZSBJbnRlcm5ldCBhcyB0aGUgdWx0aW1hdGUNCiAgIGRp c3RyaWJ1dGVkIHBsYXRmb3JtIHRoYXQgYWxsb3dzIGNvbW11bmljYXRpb24sIHRoZSBwcm92aXNp b24gb2YNCiAgIHNlcnZpY2VzLCBhbmQgY29tcGV0aXRpb24gZnJvbSBhbnkgY29ybmVyIG9mIHRo ZSB3b3JsZC4gIEJ1dCBhcyB0aGUNCiAgIEludGVybmV0IGhhcyBtYXR1cmVkLCBpdCBzZWVtcyB0 byBhbHNvIGZlZWQgdGhlIGNyZWF0aW9uIG9mIGxhcmdlLA0KICAgY2VudHJhbGlzZWQgZW50aXRp ZXMgaW4gbWFueSBhcmVhcy4gIFRoaXMgcGhlbm9tZW5vbiBjb3VsZCBiZSBsb29rZWQNCiAgIGF0 IGZyb20gbWFueSBkaWZmZXJlbnQgYW5nbGVzLCBidXQgdGhpcyBtZW1vIGNvbnNpZGVycyB0aGUg dG9waWMgZnJvbQ0KICAgdGhlIHBlcnNwZWN0aXZlIG9mIGhvdyBhdmFpbGFibGUgdGVjaG5vbG9n eSBhbmQgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlDQogICBkcml2ZXMgZGlmZmVyZW50IG1hcmtldCBk aXJlY3Rpb25zLg0KDQpUaGlzIGxpc3Qgd2FzIHBvaW50ZWQgdG8gYXMgb25lIHBsYWNlIHRvIGRp c2N1c3MgdGhlIGRyYWZ0Og0KDQogICAiTm90ZTogSWYgeW91IGFyZSBpbnRlcmVzdGVkIG9uIHRo aXMgb3Igb3RoZXIgYXJjaGl0ZWN0dXJlLXJlbGF0ZWQNCiAgIHRvcGljcywgcGxlYXNlIHN1YnNj cmliZSB0byB0aGUgSUFCIGFyY2hpdGVjdHVyZS1kaXNjdXNzIG1haWxpbmcgbGlzdA0KICAgYXMg b25lIGZvcnVtIGZvciBkaXNjdXNzaW9uLuKAnQ0KDQpUaGUgbWFpbiBjb250ZW50IGVuZHMgd2l0 aCBhIHNlY3Rpb24gMywg4oCcQWN0aW9uc+KAnSwgdGhhdCBsaXN0cyB0aGVzZSBxdWVzdGlvbnMg Zm9yIGRpc2N1c3Npb246DQoNCiAgIEFyZSB0aGVyZSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgSW50 ZXJuZXQgYXJjaGl0ZWN0dXJlIHRoYXQgbm8gbG9uZ2VyDQogICBob2xkIGluIGEgd29ybGQgd2hl cmUgbGFyZ2VyLCBtb3JlIGNlbnRyYWxpc2VkIGVudGl0aWVzIHByb3ZpZGUgYmlnDQogICBwYXJ0 cyBvZiB0aGUgSW50ZXJuZXQgc2VydmljZT8gIElmIHRoZSB3b3JsZCBjaGFuZ2VzLCB0aGUgSW50 ZXJuZXQNCiAgIGFuZCBpdHMgdGVjaG5vbG9neS9hcmNoaXRlY3R1cmUgbWF5IGhhdmUgdG8gbWF0 Y2ggdGhvc2UgY2hhbmdlcy4NCiAgIEl0IGFwcGVhcnMgdGhhdCBsZXZlbCB0aGUgcGxheWluZyBm aWVsZCBmb3IgbmV3IGVudHJhbnRzIG9yIHNtYWxsDQogICBwbGF5ZXJzIGJyaW5ncyBwb3RlbnRp YWwgYmVuZWZpdHMuICBBcmUgdGhlcmUgdGVjaG5pY2FsIHNvbHV0aW9ucw0KICAgdGhhdCBhcmUg bWlzc2luZyB0b2RheT8NCg0KICAgQXNzdW1pbmcgdGhhdCBvbmUgZG9lcyBub3Qgd2lzaCBmb3Ig cmVndWxhdGlvbiwgdGVjaG5vbG9naWVzIHRoYXQNCiAgIHN1cHBvcnQgZGlzdHJpYnV0ZWQgYXJj aGl0ZWN0dXJlcywgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mDQogICBjdXJyZW50bHkg Y2VudHJhbGlzZWQgbmV0d29yayBmdW5jdGlvbnMsIG9yIGhlbHAgaW5jcmVhc2UgdXNlcidzDQog ICBjb250cm9sIGNhbiBiZSBiZW5lZmljaWFsLiAgRmVkZXJhdGlvbiwgZm9yIGV4YW1wbGUsIHdv dWxkIGhlbHANCiAgIGVuYWJsZSBkaXN0cmlidXRlZCBzZXJ2aWNlcyBpbiBzaXR1YXRpb25zIHdo ZXJlIHNtYWxsZXIgZW50aXRpZXMNCiAgIHdvdWxkIGxpa2UgdG8gY29sbGFib3JhdGUuDQoNCiAg IFNpbWlsYXJseSwgaW4gYW4gYXN5bW1ldHJpYyBwb3dlciBiYWxhbmNlIGJldHdlZW4gdXNlcnMg YW5kIHNlcnZpY2VzLA0KICAgdG9vbHMgdGhhdCBlbmFibGUgdGhlIHVzZXIgdG8gY29udHJvbCB3 aGF0IGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkIHRvDQogICBhIHBhcnRpY3VsYXIgc2VydmljZSBj YW4gYmUgdmVyeSBoZWxwZnVsLiAgU29tZSBzdWNoIHRvb2xzIGV4aXN0LCBmb3INCiAgIGluc3Rh bmNlLCBpbiB0aGUgcHJpdmFjeSBhbmQgdHJhY2tpbmctcHJldmVudGlvbiBtb2RlcyBvZiBwb3B1 bGFyDQogICBicm93c2VycyBidXQgd2h5IGFyZSB0aGVzZSBtb2RlcyBub3QgdGhlIGRlZmF1bHQs IGFuZCBjb3VsZCB3ZQ0KICAgZGV2ZWxvcCB0aGVtIGZ1cnRoZXI/DQoNCiAgIEl0IGlzIGFsc28g c3VycHJpc2luZyB0aGF0IGluIHRoZSBhZ2Ugb2Ygc29mdHdhcmUtZGVmaW5lZCBldmVyeXRoaW5n LA0KICAgd2UgY2FuIHByb2dyYW0gYWxtb3N0IGFueXRoaW5nIGVsc2UgZXhjZXB0IHRoZSBnbG9i YWxseSBwcm92aWRlZCwNCiAgIHBhY2thZ2VkIHNlcnZpY2VzLiAgT3BlbmluZyB1cCBpbnRlcmZh Y2VzIHdvdWxkIGFsbG93IHRoZSBidWlsZGluZyBvZg0KICAgYWRkaXRpb25hbCwgaW5ub3ZhdGl2 ZSBzZXJ2aWNlcywgYW5kIGJldHRlciBtYXRjaCB3aXRoIHVzZXJzJyBuZWVkcy4NCg0KICAgU2ls dmVyIGJ1bGxldHMgYXJlIHJhcmUsIG9mIGNvdXJzZS4gIEludGVybmV0IHNlcnZpY2UgbWFya2V0 cw0KICAgc29tZXRpbWVzIGZyYWdtZW50IHJhdGhlciB0aGFuIGNvb3BlcmF0ZSB0aHJvdWdoIGZl ZGVyYXRpb24uICBBbmQgdGhlDQogICBhc3ltbWV0cmljIHBvd2VyIGJhbGFuY2VzIGFyZSBlYXNp ZXN0IGNoYW5nZWQgd2l0aCBkYXRhIHRoYXQgaXMgaW4NCiAgIHlvdXIgY29udHJvbCwgYnV0IGl0 IGlzIG11Y2ggaGFyZGVyIHRvIGNoYW5nZSB3aGVuIHNvbWVvbmUgZWxzZSBob2xkcw0KICAgaXQu ICBOZXZlcnRoZWxlc3MsIHRoZSBleHBsb3JhdGlvbiBvZiBzb2x1dGlvbnMgdG8gZW5zdXJlIHRo ZQ0KICAgSW50ZXJuZXQgaXMga2VwdCBvcGVuIGZvciBuZXcgaW5ub3ZhdGlvbnMgYW5kIGluIHRo ZSBjb250cm9sIG9mIHVzZXJzDQogICBpcyB2ZXJ5IGltcG9ydGFudC4NCg0KICAgV2hhdCBJRVRG IHRvcGljcyB0aGF0IHNob3VsZCBiZSBwdXJzdWVkIHRvIGFkZHJlc3Mgc29tZSBvZiB0aGUgaXNz dWVzDQogICBhcm91bmQgY29uc29saWRhdGlvbj8NCg0KICAgV2hhdCBtZWFzdXJlbWVudHMgcmVs YXRpbmcgdG8gdGhlIGRldmVsb3BtZW50cyBjZW50cmFsaXphdGlvbiBvcg0KICAgY29uc29saWRh dGlvbiBzaG91bGQgYmUgcHVyc3VlZD8NCg0KICAgV2hhdCByZXNlYXJjaCAtLSBzdWNoIGFzIGRp c3RyaWJ1dGVkIEludGVybmV0IGFyY2hpdGVjdHVyZXMgLS0gc2hvdWxkDQogICBiZSBkcml2ZW4g Zm9yd2FyZD8NCg0KVGhleSBhcmUgYWxsIGdvb2QgcXVlc3Rpb25zLiBJIGRvIGhhdmUgc29tZSB0 aG91Z2h0cyBvZiBteSBvd24gb24gdGhlc2UgcXVlc3Rpb25zLCBidXQgSSB3aWxsIHNlbmQgdGhv c2UgaW4gc2VwYXJhdGUgbWVzc2FnZXMgKG9yIHBlcmhhcHMgd2lsbCB3cml0ZSBhYm91dCB0aGVt IGluIGFuIEktRCBvciBibG9nIHBvc3QpLg0KDQpEYW4NCg0KLS0NCkRhbiBZb3JrDQpEaXJlY3Rv ciBvZiBXZWIgU3RyYXRlZ3ksIEludGVybmV0IFNvY2lldHkNCnlvcmtAaXNvYy5vcmc8bWFpbHRv OnlvcmtAaXNvYy5vcmc+ICAgKzEtODAyLTczNS0xNjI0DQpKYWJiZXI6IHlvcmtAamFiYmVyLmlz b2Mub3JnPG1haWx0bzp5b3JrQGphYmJlci5pc29jLm9yZz4gIFNreXBlOiBkYW55b3JrICAgaHR0 cDovL3R3aXR0ZXIuY29tL2RhbnlvcmsNCg0KaHR0cDovL3d3dy5pbnRlcm5ldHNvY2lldHkub3Jn Lw0KDQo= --_000_55E43924FFAE473EA43C90DB7C33321Cisocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <4C24F1A15130614CBA5567F0AF203A79@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZZSSwgSmFyaSBBcmtrbyBwdWJsaXNoZWQgYSBu ZXcgZHJhZnQgeWVzdGVyZGF5IG9uIGJlaGFsZiBvZiBzZXZlcmFsIElBQiBtZW1iZXJzIHdpdGgg dGhlIHRpdGxlICZxdW90O0NvbnNpZGVyYXRpb25zIG9uIEludGVybmV0IENvbnNvbGlkYXRpb24g YW5kIHRoZSBJbnRlcm5ldCBBcmNoaXRlY3R1cmXigJ06DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYXJra28taWFiLWludGVybmV0LWNvbnNvbGlkYXRpb24tMDAiIGNsYXNz PSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hcmtrby1pYWItaW50ZXJuZXQt Y29uc29saWRhdGlvbi0wMDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSB0ZXh0IHN0YXRlcyB0aGF0IHRoZSBkcmFmdCBpcyBi YXNlZCBvZmYgb2YgdGhlIElBQiBibG9nIHBvc3QgYmFjayBpbiBNYXJjaCAyMDE4IC0mbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2NvbnNvbGlkYXRpb24vIiBjbGFzcz0i Ij5odHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2NvbnNvbGlkYXRpb24vPC9hPiZuYnNwOy0gYXMg d2VsbCBhcyBhIG5ldyBwb3N0IEphcmkgYW5kIEJyaWFuIFRyYW1tZWxsIGhhdmUNCiB3cml0dGVu IGZvciB0aGUgQVBOSUMgYW5kIFJJUEUgc2l0ZXM6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9ibG9n LmFwbmljLm5ldC8yMDE4LzEwLzI0L29waW5pb24tY29uc29saWRhdGlvbi1jZW50cmFsaXphdGlv bi1hbmQtdGhlLWludGVybmV0LWFyY2hpdGVjdHVyZS8iIGNsYXNzPSIiPmh0dHBzOi8vYmxvZy5h cG5pYy5uZXQvMjAxOC8xMC8yNC9vcGluaW9uLWNvbnNvbGlkYXRpb24tY2VudHJhbGl6YXRpb24t YW5kLXRoZS1pbnRlcm5ldC1hcmNoaXRlY3R1cmUvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGFic3RyYWN0IG9mIHRoZSBJ bnRlcm5ldCBEcmFmdCBpczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSIiPiAg IE1hbnkgb2YgdXMgaGF2ZSBoZWxkIGEgdmlzaW9uIG9mIHRoZSBJbnRlcm5ldCBhcyB0aGUgdWx0 aW1hdGUNCiAgIGRpc3RyaWJ1dGVkIHBsYXRmb3JtIHRoYXQgYWxsb3dzIGNvbW11bmljYXRpb24s IHRoZSBwcm92aXNpb24gb2YNCiAgIHNlcnZpY2VzLCBhbmQgY29tcGV0aXRpb24gZnJvbSBhbnkg Y29ybmVyIG9mIHRoZSB3b3JsZC4gIEJ1dCBhcyB0aGUNCiAgIEludGVybmV0IGhhcyBtYXR1cmVk LCBpdCBzZWVtcyB0byBhbHNvIGZlZWQgdGhlIGNyZWF0aW9uIG9mIGxhcmdlLA0KICAgY2VudHJh bGlzZWQgZW50aXRpZXMgaW4gbWFueSBhcmVhcy4gIFRoaXMgcGhlbm9tZW5vbiBjb3VsZCBiZSBs b29rZWQNCiAgIGF0IGZyb20gbWFueSBkaWZmZXJlbnQgYW5nbGVzLCBidXQgdGhpcyBtZW1vIGNv bnNpZGVycyB0aGUgdG9waWMgZnJvbQ0KICAgdGhlIHBlcnNwZWN0aXZlIG9mIGhvdyBhdmFpbGFi bGUgdGVjaG5vbG9neSBhbmQgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlDQogICBkcml2ZXMgZGlmZmVy ZW50IG1hcmtldCBkaXJlY3Rpb25zLjwvcHJlPg0KPGRpdiBjbGFzcz0iIj5UaGlzIGxpc3Qgd2Fz IHBvaW50ZWQgdG8gYXMgb25lIHBsYWNlIHRvIGRpc2N1c3MgdGhlIGRyYWZ0OiAmbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsmcXVvdDtOb3RlOiBJZiB5b3UgYXJlIGludGVyZXN0ZWQgb24gdGhpcyBvciBv dGhlciBhcmNoaXRlY3R1cmUtcmVsYXRlZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7dG9waWNzLCBwbGVhc2Ugc3Vic2NyaWJlIHRvIHRoZSBJQUIgYXJjaGl0ZWN0dXJlLWRpc2N1 c3MgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDthcyBvbmUg Zm9ydW0gZm9yIGRpc2N1c3Npb24u4oCdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgbWFpbiBjb250ZW50IGVuZHMgd2l0aCBhIHNl Y3Rpb24gMywg4oCcQWN0aW9uc+KAnSwgdGhhdCBsaXN0cyB0aGVzZSBxdWVzdGlvbnMgZm9yIGRp c2N1c3Npb246PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO0FyZSB0aGVyZSBhc3N1bXB0 aW9ucyBhYm91dCB0aGUgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlIHRoYXQgbm8gbG9uZ2VyPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtob2xkIGluIGEgd29ybGQgd2hlcmUgbGFyZ2Vy LCBtb3JlIGNlbnRyYWxpc2VkIGVudGl0aWVzIHByb3ZpZGUgYmlnPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDtwYXJ0cyBvZiB0aGUgSW50ZXJuZXQgc2VydmljZT8gJm5ic3A7SWYg dGhlIHdvcmxkIGNoYW5nZXMsIHRoZSBJbnRlcm5ldDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7YW5kIGl0cyB0ZWNobm9sb2d5L2FyY2hpdGVjdHVyZSBtYXkgaGF2ZSB0byBtYXRj aCB0aG9zZSBjaGFuZ2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7SXQgYXBw ZWFycyB0aGF0IGxldmVsIHRoZSBwbGF5aW5nIGZpZWxkIGZvciBuZXcgZW50cmFudHMgb3Igc21h bGw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3BsYXllcnMgYnJpbmdzIHBvdGVu dGlhbCBiZW5lZml0cy4gJm5ic3A7QXJlIHRoZXJlIHRlY2huaWNhbCBzb2x1dGlvbnM8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3RoYXQgYXJlIG1pc3NpbmcgdG9kYXk/PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7QXNzdW1pbmcgdGhhdCBvbmUgZG9lcyBub3Qgd2lzaCBmb3IgcmVndWxhdGlvbiwg dGVjaG5vbG9naWVzIHRoYXQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3N1cHBv cnQgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlcywgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25z IG9mPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtjdXJyZW50bHkgY2VudHJhbGlz ZWQgbmV0d29yayBmdW5jdGlvbnMsIG9yIGhlbHAgaW5jcmVhc2UgdXNlcidzPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtjb250cm9sIGNhbiBiZSBiZW5lZmljaWFsLiAmbmJzcDtG ZWRlcmF0aW9uLCBmb3IgZXhhbXBsZSwgd291bGQgaGVscDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ZW5hYmxlIGRpc3RyaWJ1dGVkIHNlcnZpY2VzIGluIHNpdHVhdGlvbnMgd2hl cmUgc21hbGxlciBlbnRpdGllczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7d291 bGQgbGlrZSB0byBjb2xsYWJvcmF0ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtTaW1pbGFybHksIGluIGFuIGFz eW1tZXRyaWMgcG93ZXIgYmFsYW5jZSBiZXR3ZWVuIHVzZXJzIGFuZCBzZXJ2aWNlcyw8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3Rvb2xzIHRoYXQgZW5hYmxlIHRoZSB1c2VyIHRv IGNvbnRyb2wgd2hhdCBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0bzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7YSBwYXJ0aWN1bGFyIHNlcnZpY2UgY2FuIGJlIHZlcnkgaGVscGZ1 bC4gJm5ic3A7U29tZSBzdWNoIHRvb2xzIGV4aXN0LCBmb3I8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwO2luc3RhbmNlLCBpbiB0aGUgcHJpdmFjeSBhbmQgdHJhY2tpbmctcHJldmVu dGlvbiBtb2RlcyBvZiBwb3B1bGFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDti cm93c2VycyBidXQgd2h5IGFyZSB0aGVzZSBtb2RlcyBub3QgdGhlIGRlZmF1bHQsIGFuZCBjb3Vs ZCB3ZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ZGV2ZWxvcCB0aGVtIGZ1cnRo ZXI/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7SXQgaXMgYWxzbyBzdXJwcmlzaW5nIHRoYXQgaW4gdGhlIGFnZSBv ZiBzb2Z0d2FyZS1kZWZpbmVkIGV2ZXJ5dGhpbmcsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDt3ZSBjYW4gcHJvZ3JhbSBhbG1vc3QgYW55dGhpbmcgZWxzZSBleGNlcHQgdGhlIGds b2JhbGx5IHByb3ZpZGVkLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7cGFja2Fn ZWQgc2VydmljZXMuICZuYnNwO09wZW5pbmcgdXAgaW50ZXJmYWNlcyB3b3VsZCBhbGxvdyB0aGUg YnVpbGRpbmcgb2Y8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2FkZGl0aW9uYWws IGlubm92YXRpdmUgc2VydmljZXMsIGFuZCBiZXR0ZXIgbWF0Y2ggd2l0aCB1c2VycycgbmVlZHMu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7U2lsdmVyIGJ1bGxldHMgYXJlIHJhcmUsIG9mIGNvdXJzZS4gJm5ic3A7 SW50ZXJuZXQgc2VydmljZSBtYXJrZXRzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJz cDtzb21ldGltZXMgZnJhZ21lbnQgcmF0aGVyIHRoYW4gY29vcGVyYXRlIHRocm91Z2ggZmVkZXJh dGlvbi4gJm5ic3A7QW5kIHRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YXN5 bW1ldHJpYyBwb3dlciBiYWxhbmNlcyBhcmUgZWFzaWVzdCBjaGFuZ2VkIHdpdGggZGF0YSB0aGF0 IGlzIGluPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDt5b3VyIGNvbnRyb2wsIGJ1 dCBpdCBpcyBtdWNoIGhhcmRlciB0byBjaGFuZ2Ugd2hlbiBzb21lb25lIGVsc2UgaG9sZHM8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2l0LiAmbmJzcDtOZXZlcnRoZWxlc3MsIHRo ZSBleHBsb3JhdGlvbiBvZiBzb2x1dGlvbnMgdG8gZW5zdXJlIHRoZTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7SW50ZXJuZXQgaXMga2VwdCBvcGVuIGZvciBuZXcgaW5ub3ZhdGlv bnMgYW5kIGluIHRoZSBjb250cm9sIG9mIHVzZXJzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDtpcyB2ZXJ5IGltcG9ydGFudC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtXaGF0IElFVEYgdG9waWNz IHRoYXQgc2hvdWxkIGJlIHB1cnN1ZWQgdG8gYWRkcmVzcyBzb21lIG9mIHRoZSBpc3N1ZXM8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2Fyb3VuZCBjb25zb2xpZGF0aW9uPzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwO1doYXQgbWVhc3VyZW1lbnRzIHJlbGF0aW5nIHRvIHRoZSBkZXZlbG9wbWVudHMg Y2VudHJhbGl6YXRpb24gb3I8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2NvbnNv bGlkYXRpb24gc2hvdWxkIGJlIHB1cnN1ZWQ/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7V2hhdCByZXNlYXJjaCAt LSBzdWNoIGFzIGRpc3RyaWJ1dGVkIEludGVybmV0IGFyY2hpdGVjdHVyZXMgLS0gc2hvdWxkPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtiZSBkcml2ZW4gZm9yd2FyZD88L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhleSBhcmUgYWxsIGdvb2QgcXVlc3Rpb25zLiBJIGRvIGhhdmUgc29tZSB0aG91Z2h0cyBv ZiBteSBvd24gb24gdGhlc2UgcXVlc3Rpb25zLCBidXQgSSB3aWxsIHNlbmQgdGhvc2UgaW4gc2Vw YXJhdGUgbWVzc2FnZXMgKG9yIHBlcmhhcHMgd2lsbCB3cml0ZSBhYm91dCB0aGVtIGluIGFuIEkt RCBvciBibG9nIHBvc3QpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRhbjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQotLTxiciBjbGFzcz0iIj4NCkRhbiBZb3JrPGJyIGNs YXNzPSIiPg0KRGlyZWN0b3Igb2YgV2ViIFN0cmF0ZWd5LCZuYnNwO0ludGVybmV0IFNvY2lldHk8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86eW9ya0Bpc29jLm9yZyIgY2xhc3M9IiI+eW9y a0Bpc29jLm9yZzwvYT4mbmJzcDsmbmJzcDsgJiM0MzsxLTgwMi03MzUtMTYyNCZuYnNwOzxiciBj bGFzcz0iIj4NCkphYmJlcjogPGEgaHJlZj0ibWFpbHRvOnlvcmtAamFiYmVyLmlzb2Mub3JnIiBj bGFzcz0iIj55b3JrQGphYmJlci5pc29jLm9yZzwvYT4gJm5ic3A7U2t5cGU6Jm5ic3A7ZGFueW9y ayAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vZGFueW9yayIgY2xhc3M9 IiI+aHR0cDovL3R3aXR0ZXIuY29tL2Rhbnlvcms8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pbnRlcm5ldHNvY2lldHkub3JnLyIgY2xhc3M9IiI+ aHR0cDovL3d3dy5pbnRlcm5ldHNvY2lldHkub3JnLzwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_55E43924FFAE473EA43C90DB7C33321Cisocorg_-- From nobody Wed Oct 24 08:10:03 2018 Return-Path: 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 46D78130DE5 for ; Wed, 24 Oct 2018 08:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 0EDyRInYTxON for ; Wed, 24 Oct 2018 08:09:57 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3DA28123FFD for ; Wed, 24 Oct 2018 08:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3nlsvgZK7RWNdMyRLhqQjIl23Z7Wg1IgFlt9KT4rfUo=; b=DU+jBdGEWVzGuyG0s8cVkGCrf XoeSCV868dr9TtofELgaW2reXF3Xe7x+ShSBgyeQMw1Y3rQF0TNRgTWLPo06LHr5Y4k5NQZfgtZLU 5XnKXqEHktBuhj8sUwcFqEWqoSjIOR4OnuPng39KdkK1QK6cq0rP6tyHKaUKWepGqb7QnIooUbLF4 CZqCUL2IfL4kBf61FcdEyozNz4IQ4Wwuyma3SR8QfccLUSAAISLoi5yt8Jn1eTnmdUS8LQmvPnjUa CoZR24DYm9ZcQXiXtVQZ4ndxEa3UcjF/kgE7ImCm++bCbbhUTwY6B0dtAQCldmxvvdhYT2QPutdib 4QzFNIdsA==; Received: from 106.0.208.46.dyn.plus.net ([46.208.0.106]:33908 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gFKnC-0003XI-IF; Wed, 24 Oct 2018 16:09:55 +0100 To: Jari ARKKO References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> Cc: Dan York , "architecture-discuss@ietf.org" From: Bob Briscoe Message-ID: <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> Date: Wed, 24 Oct 2018 16:09:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> Content-Type: multipart/alternative; boundary="------------6AC441CB6602EE80592538FC" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 15:10:01 -0000 This is a multi-part message in MIME format. --------------6AC441CB6602EE80592538FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Jari and all, Thx for writing this down. [and Dan, thx for pointing this out] 1/ Another way to look at this is that the folks that designed the Internet did a good job of making it business-model-agnostic, cos it was generally designed to be highly distributed, but it's working well as distributed technology under a highly centralized business model. 2/ On the 'Permissionless Completeness Problem', at whatever stage in history you look at a value chain (aka stack of businesses built atop each other) the top ones are typically closed. That doesn't mean they always will be. A common progression in industrial organization where there's a natural monopoly at a particular layer (say L) is: * at layer L business make a land-grab for the largest market share by appearing to be open and free * then the winner closes off layer L to lock their size advantage in * they build new products on top (layer M), locked-in to the layer below (L) * in order to expand, the winner starts wholesaling their layer L product, so other M businesses can build and innovate in different ways on top, rather than the winner having to maintain a retail relationship with everyone (but the winner keeps its competitors dependent on its layer L) * so, L gradually becomes a commodity (sometimes aided by market regulation), and all the action moves to layer M * layer M could in turn become the platform for the next set of applications at layer N, and the process repeats For instance, Microsoft became dominant in the PC market by repeating this process: its BIOS became the platform for DOS, then DOS the platform for Windows, then Windows the platform for Office, then Office became the platform for various forms of automation. And you can see how Microsoft has always opened up what used to be the highest layer as it tried to expand by wholesaling to allow others to create new markets faster than it could. The same could happen with all the apps built over maps and location services. Another example might be VR, which is starting as an app, but then it will probably just become a way to deliver new apps over a VR platform (e.g. virtual shopping, virtual theme parks, etc) and the VR platform itself will consolidate and commoditize. 3/ The important technical message is that it's much easier to start with an open platform so you can close it off and open it up again. Starting with closed technology is a dead-end. 4/ Finally, we have to remember that open innovation is only necessary to create new businesses and opportunities. You would expect there to be a more closed period when businesses milk their innovations. That's the stage when the businesses pull in the cash to allow them to invest in the next round of innovation. 5/ Of course, this is all a very optimistic view. What actually happens is that incumbents try to hold on to their gains for far too long, they use scurrilous tactics to undermine innovations by others, etc. etc. But that's all part of the rough and tumble, the rise and fall, of different businesses over decades and centuries. I'm just trying to give optimism over a (very) long run view. Bob On 24/10/2018 11:21, Dan York wrote: > FYI, Jari Arkko published a new draft yesterday on behalf of several > IAB members with the title "Considerations on Internet Consolidation > and the Internet Architecture”: > > https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00 > > The text states that the draft is based off of the IAB blog post back > in March 2018 - https://www.ietf.org/blog/consolidation/ - as well as > a new post Jari and Brian Trammell have written for the APNIC and RIPE > sites: > https://blog.apnic.net/2018/10/24/opinion-consolidation-centralization-and-the-internet-architecture/ > > The abstract of the Internet Draft is: > Many of us have held a vision of the Internet as the ultimate > distributed platform that allows communication, the provision of > services, and competition from any corner of the world. But as the > Internet has matured, it seems to also feed the creation of large, > centralised entities in many areas. This phenomenon could be looked > at from many different angles, but this memo considers the topic from > the perspective of how available technology and Internet architecture > drives different market directions. > This list was pointed to as one place to discuss the draft: > >    "Note: If you are interested on this or other architecture-related >    topics, please subscribe to the IAB architecture-discuss mailing list >    as one forum for discussion.” > > The main content ends with a section 3, “Actions”, that lists these > questions for discussion: > >    Are there assumptions about the Internet architecture that no longer >    hold in a world where larger, more centralised entities provide big >    parts of the Internet service?  If the world changes, the Internet >    and its technology/architecture may have to match those changes. >    It appears that level the playing field for new entrants or small >    players brings potential benefits.  Are there technical solutions >    that are missing today? > >    Assuming that one does not wish for regulation, technologies that >    support distributed architectures, open source implementations of >    currently centralised network functions, or help increase user's >    control can be beneficial.  Federation, for example, would help >    enable distributed services in situations where smaller entities >    would like to collaborate. > >    Similarly, in an asymmetric power balance between users and services, >    tools that enable the user to control what information is provided to >    a particular service can be very helpful.  Some such tools exist, for >    instance, in the privacy and tracking-prevention modes of popular >    browsers but why are these modes not the default, and could we >    develop them further? > >    It is also surprising that in the age of software-defined everything, >    we can program almost anything else except the globally provided, >    packaged services.  Opening up interfaces would allow the building of >    additional, innovative services, and better match with users' needs. > >    Silver bullets are rare, of course.  Internet service markets >    sometimes fragment rather than cooperate through federation.  And the >    asymmetric power balances are easiest changed with data that is in >    your control, but it is much harder to change when someone else holds >    it.  Nevertheless, the exploration of solutions to ensure the >    Internet is kept open for new innovations and in the control of users >    is very important. > >    What IETF topics that should be pursued to address some of the issues >    around consolidation? > >    What measurements relating to the developments centralization or >    consolidation should be pursued? > >    What research -- such as distributed Internet architectures -- should >    be driven forward? > > They are all good questions. I do have some thoughts of my own on > these questions, but I will send those in separate messages (or > perhaps will write about them in an I-D or blog post). > > Dan > > -- > Dan York > Director of Web Strategy, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org >  Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/ > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6AC441CB6602EE80592538FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Jari and all,

Thx for writing this down.
[and Dan, thx for pointing this out]

1/ Another way to look at this is that the folks that designed the Internet did a good job of making it business-model-agnostic, cos it was generally designed to be highly distributed, but it's working well as distributed technology under a highly centralized business model.

2/ On the 'Permissionless Completeness Problem', at whatever stage in history you look at a value chain (aka stack of businesses built atop each other) the top ones are typically closed. That doesn't mean they always will be. A common progression in industrial organization where there's a natural monopoly at a particular layer (say L) is:
  • at layer L business make a land-grab for the largest market share by appearing to be open and free
  • then the winner closes off layer L to lock their size advantage in
  • they build new products on top (layer M), locked-in to the layer below (L)
  • in order to expand, the winner starts wholesaling their layer L product, so other M businesses can build and innovate in different ways on top, rather than the winner having to maintain a retail relationship with everyone (but the winner keeps its competitors dependent on its layer L)
  • so, L gradually becomes a commodity (sometimes aided by market regulation), and all the action moves to layer M
  • layer M could in turn become the platform for the next set of applications at layer N, and the process repeats
For instance, Microsoft became dominant in the PC market by repeating this process: its BIOS became the platform for DOS, then DOS the platform for Windows, then Windows the platform for Office, then Office became the platform for various forms of automation. And you can see how Microsoft has always opened up what used to be the highest layer as it tried to expand by wholesaling to allow others to create new markets faster than it could.

The same could happen with all the apps built over maps and location services.

Another example might be VR, which is starting as an app, but then it will probably just become a way to deliver new apps over a VR platform (e.g. virtual shopping, virtual theme parks, etc) and the VR platform itself will consolidate and commoditize.

3/ The important technical message is that it's much easier to start with an open platform so you can close it off and open it up again. Starting with closed technology is a dead-end.

4/ Finally, we have to remember that open innovation is only necessary to create new businesses and opportunities. You would expect there to be a more closed period when businesses milk their innovations. That's the stage when the businesses pull in the cash to allow them to invest in the next round of innovation.

5/ Of course, this is all a very optimistic view. What actually happens is that incumbents try to hold on to their gains for far too long, they use scurrilous tactics to undermine innovations by others, etc. etc. But that's all part of the rough and tumble, the rise and fall, of different businesses over decades and centuries. I'm just trying to give optimism over a (very) long run view.


Bob

On 24/10/2018 11:21, Dan York wrote:
FYI, Jari Arkko published a new draft yesterday on behalf of several IAB members with the title "Considerations on Internet Consolidation and the Internet Architecture”:


The text states that the draft is based off of the IAB blog post back in March 2018 - https://www.ietf.org/blog/consolidation/ - as well as a new post Jari and Brian Trammell have written for the APNIC and RIPE sites: https://blog.apnic.net/2018/10/24/opinion-consolidation-centralization-and-the-internet-architecture/

The abstract of the Internet Draft is:
   Many of us have held a vision of the Internet as the ultimate
   distributed platform that allows communication, the provision of
   services, and competition from any corner of the world.  But as the
   Internet has matured, it seems to also feed the creation of large,
   centralised entities in many areas.  This phenomenon could be looked
   at from many different angles, but this memo considers the topic from
   the perspective of how available technology and Internet architecture
   drives different market directions.
This list was pointed to as one place to discuss the draft:  

   "Note: If you are interested on this or other architecture-related
   topics, please subscribe to the IAB architecture-discuss mailing list
   as one forum for discussion.”

The main content ends with a section 3, “Actions”, that lists these questions for discussion:

   Are there assumptions about the Internet architecture that no longer
   hold in a world where larger, more centralised entities provide big
   parts of the Internet service?  If the world changes, the Internet
   and its technology/architecture may have to match those changes.
   It appears that level the playing field for new entrants or small
   players brings potential benefits.  Are there technical solutions
   that are missing today?

   Assuming that one does not wish for regulation, technologies that
   support distributed architectures, open source implementations of
   currently centralised network functions, or help increase user's
   control can be beneficial.  Federation, for example, would help
   enable distributed services in situations where smaller entities
   would like to collaborate.

   Similarly, in an asymmetric power balance between users and services,
   tools that enable the user to control what information is provided to
   a particular service can be very helpful.  Some such tools exist, for
   instance, in the privacy and tracking-prevention modes of popular
   browsers but why are these modes not the default, and could we
   develop them further?

   It is also surprising that in the age of software-defined everything,
   we can program almost anything else except the globally provided,
   packaged services.  Opening up interfaces would allow the building of
   additional, innovative services, and better match with users' needs.

   Silver bullets are rare, of course.  Internet service markets
   sometimes fragment rather than cooperate through federation.  And the
   asymmetric power balances are easiest changed with data that is in
   your control, but it is much harder to change when someone else holds
   it.  Nevertheless, the exploration of solutions to ensure the
   Internet is kept open for new innovations and in the control of users
   is very important.

   What IETF topics that should be pursued to address some of the issues
   around consolidation?

   What measurements relating to the developments centralization or
   consolidation should be pursued?

   What research -- such as distributed Internet architectures -- should
   be driven forward?

They are all good questions. I do have some thoughts of my own on these questions, but I will send those in separate messages (or perhaps will write about them in an I-D or blog post).

Dan

--
Dan York
Director of Web Strategy, Internet Society
york@isoc.org   +1-802-735-1624 
Jabber: york@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6AC441CB6602EE80592538FC-- From nobody Wed Oct 24 09:32:49 2018 Return-Path: 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 74603130EA2 for ; Wed, 24 Oct 2018 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 mC2pgiX6SYER for ; Wed, 24 Oct 2018 09:32:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A56126F72 for ; Wed, 24 Oct 2018 09:32:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C53E8BE5B; Wed, 24 Oct 2018 17:32:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxYrtQcXLABX; Wed, 24 Oct 2018 17:32:18 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A0AEBE56; Wed, 24 Oct 2018 17:32:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1540398738; bh=TZWEpSW1ND2I1vpR6f5rY2BISOkv+wbvpAmZszD7OdU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BTpg89IkP32gIIvmaNlh/s5XV7eirIu+79+0DOXKn9w07oMIBVbBgBhpkIot9eyfJ UoCx8w/yb5zokhSWYNJTkyEy1rm7tHb60s97yhLR6sk+E5Pu7WNWH8XD65rkttoZTt NcxiFOxl44RpweDgHU3Lx8IpNJWnkGaOsfG7z5M0= To: Bob Briscoe , Jari ARKKO Cc: "architecture-discuss@ietf.org" References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> Date: Wed, 24 Oct 2018 17:32:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5Ik51zFqySgozaSscoAo2cwrNGPibw9HC" Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:32:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Ik51zFqySgozaSscoAo2cwrNGPibw9HC Content-Type: multipart/mixed; boundary="chNgDEIH6daF1KBJGSM1smPdyS1aFMMjb"; protected-headers="v1" From: Stephen Farrell To: Bob Briscoe , Jari ARKKO Cc: "architecture-discuss@ietf.org" Message-ID: <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> In-Reply-To: <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> --chNgDEIH6daF1KBJGSM1smPdyS1aFMMjb Content-Type: multipart/mixed; boundary="------------023921A976AC240D264391FF" Content-Language: en-GB This is a multi-part message in MIME format. --------------023921A976AC240D264391FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, While I like what you wrote, I'm not sure I follow this bit.. On 24/10/2018 16:09, Bob Briscoe wrote: >=20 > 3/ The important technical message is that it's much easier to start > with an open platform so you can close it off and open it up again. > Starting with closed technology is a dead-end. Again, I like the message but I'm not sure if one can justify that or not - do you have examples of starting with a closed technology forced it into a dead-end? Ta, S. --------------023921A976AC240D264391FF Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------023921A976AC240D264391FF-- --chNgDEIH6daF1KBJGSM1smPdyS1aFMMjb-- --5Ik51zFqySgozaSscoAo2cwrNGPibw9HC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvQnpEACgkQWrL68XsX K+p5tRAAjb1Zob7+nmNuBpHj77atnfv3Zcgadyr27PwXPezcC87J2w3rsmfYLvnY C1egv8HDykwC47WjcA5Ibfh3xS7XMiQuw4NoR7Og/3nMGcG2IpRXwVDkcCaYMWY2 UgB1M3fBYRqaLH4mIYmqUTeD6+0ciexcVLwWUrSBCsMV8LYPvYyXtRtHdRN+9qGJ cQKehoHLtpeJv4pL4M3RDM6RvU/EpY6P0TciSjoYP7EjBpwjuyXQjcl48qaLMJgn wyWeYjGk4a77Tp1dFsmjmuGOLU6JsWwGQaODwSG2xAnnsTfrnQdnXqknOe1hyxEN ftBg2syX+9zrfYFyb+QAjySwTM1z6hLGdjLzsXFmfiPhlxjEW8A6uKgAdnlnbIcF ve6IKGnTcYwFx9+TzDuzSJZSNTZGA49aXzuNlI9j079ev14CPdVYGv05ruEXzZMO Vt0WwJyXFBFmSitRgx+nxEbJuR3GtRKx3dNpZ/HtCQUBx3y8FxAxatylL4pppVHJ QKl3NTvq5rev8/7iKsKDaw1lpXZJ+675tCeAeI0RRwC1eZrWVBOjrff7JFRDlB7f 7CFGHIsYyjwnO7j9XnSBZ4j3RuNdbtqOtTHGzYQiY0BDvO1HqoDTLpYv58RD+0ie 7XjmgfugEx2AwrT2h7nAURZvDAzCAQPFnxiNtevmivoGEH70uJw= =GfJY -----END PGP SIGNATURE----- --5Ik51zFqySgozaSscoAo2cwrNGPibw9HC-- From nobody Wed Oct 24 12:15:20 2018 Return-Path: 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 6F7BF127148 for ; Wed, 24 Oct 2018 12:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4xkMIOizsspB for ; Wed, 24 Oct 2018 12:15:17 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B072312777C for ; Wed, 24 Oct 2018 12:15:16 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v6-v6so5830514ljc.11 for ; Wed, 24 Oct 2018 12:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0nmSaHfYc6DHKJZPHGeqOStt7csJwGcOZymOxJVcpto=; b=hMK/BuGM8fIf+SYdiCaFspJiCtW5DMdw2xnZS5BIMJBOaONPRvQVLtgscNIAirns/c srhdI93teFaJkUs77T4qB5lIP3LeUIJDybAkJj2jQoYNsSKh7GYeMPPADf1pN7BoSllN LzjqlWz07VDOeGa8SysTYUb2Zk87dL6wWeApa9IMPmvQqdPD4V25jH2iZTFTnBT3nSv6 5A7vKzCX/EfblINi2XlRiUsKtQCje5PHCftau3+HugT1CA4Nt/CWf0IVgRD/2EBzrkSb SsSahw+gUcOh+c5wPzevFjw5kwLPEAXMFKzbj79y+mmjWGMWE1eoJpL4ylovrys/jfjI YyLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0nmSaHfYc6DHKJZPHGeqOStt7csJwGcOZymOxJVcpto=; b=IZBky4Mju14wa4wF03bea22mnxGJJoZLFqrgd1t+d9c86NY0IJukiPnWFYcWp6+KUJ vzBpGBXycZKZrKbV9JBHzR6l3cZdVCppVEU5ilX2Co3JDRXEhljP5EEFdYynk8gRA01X UowW/VzeyuWj3d0TzsOJ2k/FYP1UqwzYja4gvizEVwdCN87C4vl0CDgckmAMBRlmvaFk K4mHGgGOEPj3PU8Ok67/y04VZHKznkzVmwitEaqNnvQ5MaD0/5R01we6VFJ+4yLRlFKS REAE+4eaAZnf2xqpHq0HOYb0Yl3EuDEaW9qFiyroQI5sK1JUEv0BXT3DBZxJI/5X3kOk yNVw== X-Gm-Message-State: AGRZ1gLPCnMK/M6rXcyFQLYdAYJJDdAK1BMJW1tmw/ulpZ2oW2jA+K2f XSaFuRNLfGmLxW4DMsXh8mfrvCy9Wli3jmqRUN1LvPMt X-Google-Smtp-Source: AJdET5dCvUp2MUx0AMvYGYpHTuW+j7Znuu2H0GX0qbEBevOeyGc27ppHoyzOO7HZpJwvDdifnp8VXE8No7PLrNzKTqw= X-Received: by 2002:a2e:197:: with SMTP id f23-v6mr2594152lji.144.1540408514763; Wed, 24 Oct 2018 12:15:14 -0700 (PDT) MIME-Version: 1.0 References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> In-Reply-To: <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Wed, 24 Oct 2018 14:15:02 -0500 Message-ID: To: Stephen Farrell Cc: Bob Briscoe , Jari Arkko , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000054df650578fe4e56" Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 19:15:20 -0000 --00000000000054df650578fe4e56 Content-Type: text/plain; charset="UTF-8" Hi, Stephen, On Wed, Oct 24, 2018 at 11:32 AM Stephen Farrell wrote: > > Hi Bob, > > While I like what you wrote, I'm not sure I follow this bit.. > > On 24/10/2018 16:09, Bob Briscoe wrote: > > > > 3/ The important technical message is that it's much easier to start > > with an open platform so you can close it off and open it up again. > > Starting with closed technology is a dead-end. > > Again, I like the message but I'm not sure if one can justify > that or not - do you have examples of starting with a closed > technology forced it into a dead-end? > I suspect that the people who can best answer this question are the least likely to be subscribed to this mailing list, but I thought the canonical examples for this in networking were the pre-IP computer networking technologies like IBM's SNA. And they were closed enough that everyone had their own - https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Competitors maps roughly on what I remember as an outsider. If you wanted internetworking and weren't latched onto one of those manufacturers, you were kind of forced into either using the Internet protocols or waiting for the OSI protocols to appear. Or both. I notice that Ross Callon's AD titles started out as OSI Transition and moved to OSI Coexistence :-) ... . I don't know whether Xerox XNS or AppleTalk would have qualified or not - I just wasn't there for either of them, in a meaningful way. Does that help? Spencer --00000000000054df650578fe4e56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Stephen,=C2=A0

On Wed, Oct 24, 2018 at 11:32 AM Stephen Farr= ell <stephen.farrell@cs.tcd= .ie> wrote:

Hi Bob,

While I like what you wrote, I'm not sure I follow this bit..

On 24/10/2018 16:09, Bob Briscoe wrote:
>
> 3/ The important technical message is that it's much easier to sta= rt
> with an open platform so you can close it off and open it up again. > Starting with closed technology is a dead-end.

Again, I like the message but I'm not sure if one can justify
that or not - do you have examples of starting with a closed
technology forced it into a dead-end?

I= suspect that the people who can best answer this question are the least li= kely to be subscribed to this mailing list, but I thought the canonical exa= mples for this in networking were the pre-IP computer networking technologi= es like IBM's SNA. And they were closed enough that everyone had their = own - https://en.wikipedia.org/wiki/IBM_Systems_Network_Archite= cture#Competitors maps roughly on what I remember as an outsider. If yo= u wanted internetworking and weren't latched onto one of those manufact= urers, you were kind of forced into either using the Internet protocols or = waiting for the OSI protocols to appear.=C2=A0

Or = both. I notice that Ross Callon's AD titles started out as OSI Transiti= on and moved to OSI Coexistence :-) ... .=C2=A0

I = don't know whether Xerox XNS or AppleTalk would have qualified or not -= I just wasn't there for either of them, in a meaningful way.=C2=A0

Does that help?=C2=A0

Spence= r
--00000000000054df650578fe4e56-- From nobody Wed Oct 24 12:43:08 2018 Return-Path: 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 AC57A124C04 for ; Wed, 24 Oct 2018 12:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SQmLyHcB; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=R8YP7hhH 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 rVlI_fLzPjJN for ; Wed, 24 Oct 2018 12:43:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1721212777C for ; Wed, 24 Oct 2018 12:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540410181; x=1543002181; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PSMfmwGgJIUeSdgTLuWfhXCQdmSvm5g44bfCeZKYW/c=; b=SQmLyHcBv3KVSNcSVXrz9I1bEuX9AXVI5PHm423GhZiQs8epC+8ZUZdHrp5lDXLP o8tX9PFB3OsAyZrnSyhmOJqE2qfFsxpm/wKiW3MTgggZnprQUbZ/cFk8s1u/nw0T qD4XZGAwDKs76OAtSVfCIoGIZeUlm37dOyB8JTLl8W4=; X-AuditID: c1b4fb25-55bff700000018b4-80-5bd0cb448dac Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.DF.06324.44BC0DB5; Wed, 24 Oct 2018 21:43:00 +0200 (CEST) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB501.ericsson.se (153.88.183.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 24 Oct 2018 21:43:00 +0200 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 24 Oct 2018 21:43:00 +0200 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 24 Oct 2018 21:43:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vy6y8QEvVNf2vaQBmFjwy1TQSA/2WEE9dV8t4JiymhA=; b=R8YP7hhHqfhoni+4RlZ72nTJOrf9oQ1fNdYx2gUElGcsSsC5L8HNcsDVdbyKWCwtQkVu+4ioV+h9ZQV0ycfjNBtSxhC/xcgV2soPLj1hI0rG5IX7pgcDklB1qKqFSaoIWO8rYbRJZin8LdxfZalg8syUHvaJDrAv96UPotQGjf4= Received: from AM5PR0701MB2530.eurprd07.prod.outlook.com (10.169.153.150) by AM5PR0701MB2852.eurprd07.prod.outlook.com (10.168.155.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.15; Wed, 24 Oct 2018 19:42:59 +0000 Received: from AM5PR0701MB2530.eurprd07.prod.outlook.com ([fe80::90e5:6d9b:3650:c6c7]) by AM5PR0701MB2530.eurprd07.prod.outlook.com ([fe80::90e5:6d9b:3650:c6c7%9]) with mapi id 15.20.1273.021; Wed, 24 Oct 2018 19:42:59 +0000 From: Jari Arkko To: Bob Briscoe CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture Thread-Index: AQHUa9HE4xlOjL/PPUGRocC6HFE/lg== Date: Wed, 24 Oct 2018 19:42:59 +0000 Message-ID: References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> In-Reply-To: <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jari.arkko@ericsson.com; x-originating-ip: [2001:1bc8:101:e900:1cea:4d16:9462:cd8d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2852; 6:dfuf5UpIJ60N0GldmpPRAjehNrudqaU5DiP/bRZ6gJjhTswdyix7WFfMvS8uZ+AogXxHlnjnNLQGKf05mP6ypHK6zhwgVSJyJDv6NCIh9rYpziEIac7Yz8RDQS6VJRFQZs246CONYxzWqrtH8CnqtPDG5otjdSmusBO+MikPWixTErbPxcqNGt9aZ3bqu7Oli9/RXg/Pme3RPIL1nmmzWZr8HeVQSg4hgATJOS3+r977QzUgRdBwLaYL5ppil7zfQQhOkqA7itl+AbK2svbUqJ9WyLD9PJRxISFSGeMqAVcXiL2esX2ZEH7seWMsGX/toxb4tO5rUedfFN+j6gjSRQeCHuichpM8A80MR31j3wKCEf4le//kobJwCtBkvD59F75RTRiChDDl2DgQA4/+CRtDO79foH5sVpHc8K1maEmSlTACFshsaGzCsyqJKqVXKDr0cHWhlZX3CJ+FVBCB9g==; 5:sQPrEPQyzoSGyXqfcIzl4GvkPGHEVwqncUsKa3bYpZr2FMtWCUYZMNJUcu2h6K9B0tWd7pHt4a7bCswOGuIsUI4cw4Ju5PXZM9KtyNwzo3AaG+WkNkJqYYn86r9W5wMgKWYJTQOhVK0QGsOlQ39NLFLz3LeDO6XlUaQX7LeC3OE=; 7:oB8KzbDjuRc42LlQkXp5mXhlizqr1gZluuAoF50Ozhf3yXxHyFx+9gTpXP+1qFY45+zLloPd44gWpYuYiINLeu1KiWqyWRMQXPGN0wlaDbWtM24OOKOnrX+mY6l0yIQ5Rrp4BkVsNkF6yPqgWnIO8A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9b536b04-6779-4e20-de69-08d639e8e726 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM5PR0701MB2852; x-ms-traffictypediagnostic: AM5PR0701MB2852: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM5PR0701MB2852; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2852; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(136003)(39860400002)(189003)(199004)(6436002)(102836004)(6512007)(54896002)(6486002)(486006)(316002)(6506007)(99936001)(44832011)(6246003)(53936002)(36756003)(83716004)(71200400001)(8676002)(2616005)(229853002)(50226002)(8936002)(99286004)(82746002)(2900100001)(186003)(7736002)(76176011)(81166006)(81156014)(33656002)(97736004)(46003)(446003)(11346002)(5660300001)(45080400002)(14454004)(86362001)(57306001)(4326008)(71190400001)(476003)(478600001)(2906002)(6916009)(68736007)(14444005)(256004)(25786009)(106356001)(5250100002)(105586002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2852; H:AM5PR0701MB2530.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bI5gTikZ1OcOn90ipDJZ5PLVi6Dexx/IuCLQw5mK7bEzNFwkSa5CW9qlv8oQXSIfrrg9h1er2LZ4867nY3fgyIadtvkUR43b88pnkom/iP4l/ElyoJA/f6pZPKoR+PZnLTY75dkh9hpajYH4F3iak4eTDU8udqfl1cvmEqe7rtiTKwLJYxAQG1sgP/3QLzIDSF9FB+tiObykh4kjInLVkkRIC/FutYnCXdFrRYYHVavMCieBGlgRoAsrnj0GiMBzynY5Uxq0Xmne9lqt4iuzD7iLXRA1y3nU0Izo37X+eIFdYP4R5/jhf+kvzXQYXyTqNCdkZdaZL/9O8YCA4HtxDBPjqwmzffny8fwZc2vC0zA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A0E6768D-350A-4E33-84A4-689D3ED8B7BF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9b536b04-6779-4e20-de69-08d639e8e726 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 19:42:59.1533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2852 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0iTYRTGe7/L9nkZvK1ND4pEq+imM63oYmVW0I0g/6jMRTnb5wV1k312 sUgswTKLtCxyWJugSd66jRIqQtkEJ+XMKLNENy3wWhpYo8z27S0I+u93zvOc854HXo6Wu9kQ Ll2fwxv12kyVxJ8pT3hsjNja7tQs/1YSs+behyJ2jd1lYTdR24f7nOz2qioPtYdK9F+v4zPT j/HGyI1J/mn1DTY623IJnRgvq5Dmo8bcC8iPA7wSbB3fKZHl2I7gZfHcC8jfy1MIHJeuICJ4 iwGPjghVFLy3mxixYHAJDY3WVooo5RQUDLslpPiE4PJYIS3OS/BSuF9j8Qocp8AL4c65BSLS eAvYzuhExxycCqUVZp9bgdPgbPsThrAaem90UKKd8U4WjieJbRmOhZ+j76TkOAFen7voYz+8 GTzdMz5GOAi+Oep9yWgcDD2DZookVoCrs11CWAlDA79YwmHwfKiIIrOJUDf9iBGfBbwOxt5E /bW8MhcjMSDgbgn0lA0hIkTAl2vXaMK7oXqsgSWmLgQjl6ulZFE4NF3niMcAjlYrKkHRpn/O I1yG4PPUcZMv5mxoKx9kSD8ZTLW9LOFlcLtyhCa8BJ4X1zD/9xdD0VTpH/8qGLFPIMIx4Klw /+F5UFbsklpQQC1SCryQnJUavULNG9OPCIJBr9bzOQ+Q97c1W38sbEJdo3EtCHNIFShLcDg1 clZ7TMjNakELvHvc9+qcKITRG/S8SiHDMx0auUynzT3JGw2HjUczeaEFhXKMKljmWv0wUY5T tTl8Bs9n88a/KsX5heSjvUHhVyvr76bsz+PStzzrOaj8dGhXyq4fYb9SZxZNK6VtTynZqxdW zT7zZOUOT+CsUGdcZJ6DrbYUxN40xSp22EaT+69nHA/4GL8x7urabMP0uHr4wPn4CNS/uS+r tdl9Ko8/HZ/xNqxz4uukaebW09uBO5M2zd8WWbpBso2z4opOFSOkaaOW0kZB+xsMP0pcdQMA AA== Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 19:43:07 -0000 --Apple-Mail=_A0E6768D-350A-4E33-84A4-689D3ED8B7BF Content-Type: multipart/alternative; boundary="Apple-Mail=_29DA1062-6B69-4E1F-8F01-09E26C4AEF31" --Apple-Mail=_29DA1062-6B69-4E1F-8F01-09E26C4AEF31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Bob for this. > 1/ Another way to look at this is that the folks that designed the = Internet did a good job of making it business-model-agnostic, cos it was = generally designed to be highly distributed, but it's working well as = distributed technology under a highly centralized business model. Yes. > 2/ On the 'Permissionless Completeness Problem', at whatever stage in = history you look at a value chain (aka stack of businesses built atop = each other) the top ones are typically closed. That doesn't mean they = always will be. A common progression in industrial organization where = there's a natural monopoly at a particular layer (say L) is: > at layer L business make a land-grab for the largest market share by = appearing to be open and free=20 > then the winner closes off layer L to lock their size advantage in > they build new products on top (layer M), locked-in to the layer below = (L) > in order to expand, the winner starts wholesaling their layer L = product, so other M businesses can build and innovate in different ways = on top, rather than the winner having to maintain a retail relationship = with everyone (but the winner keeps its competitors dependent on its = layer L) > so, L gradually becomes a commodity (sometimes aided by market = regulation), and all the action moves to layer M > layer M could in turn become the platform for the next set of = applications at layer N, and the process repeats > For instance, Microsoft became dominant in the PC market by repeating = this process: its BIOS became the platform for DOS, then DOS the = platform for Windows, then Windows the platform for Office, then Office = became the platform for various forms of automation. And you can see how = Microsoft has always opened up what used to be the highest layer as it = tried to expand by wholesaling to allow others to create new markets = faster than it could. >=20 > The same could happen with all the apps built over maps and location = services. >=20 > Another example might be VR, which is starting as an app, but then it = will probably just become a way to deliver new apps over a VR platform = (e.g. virtual shopping, virtual theme parks, etc) and the VR platform = itself will consolidate and commoditize. Yes, we=E2=80=99ve seen this movie many times (although I wouldn=E2=80=99t= necessarily exclude the existence of other movies as well). > 3/ The important technical message is that it's much easier to start = with an open platform so you can close it off and open it up again. = Starting with closed technology is a dead-end. Hmm. Not sure I entirely agree with you. I certainly think personally = that open technology is better than closed. But I don=E2=80=99t think = the world works like you say in all cases, there are plenty of examples = where something proprietary got developed and it flourishes. Of course, = in most cases that proprietary thing runs on top of more open things. = Nice cars run on public roads, cool gadgets use Internet for transport, = etc. And there=E2=80=99s nothing wrong with that, I believe in private = enterprising and innovation.=20 > 4/ Finally, we have to remember that open innovation is only necessary = to create new businesses and opportunities. You would expect there to be = a more closed period when businesses milk their innovations. That's the = stage when the businesses pull in the cash to allow them to invest in = the next round of innovation Everything has its time; at some point whatever market there was for, I = don=E2=80=99t know, say, horse-drawn carriages comes to an end and other = things replace it. Sometimes there are clever companies that can ride = the wave of new technology and move along to new things successfully, = sometimes they die in the process. That=E2=80=99s all good of course as = well. > 5/ Of course, this is all a very optimistic view. What actually = happens is that incumbents try to hold on to their gains for far too = long, they use scurrilous tactics to undermine innovations by others, = etc. etc. But that's all part of the rough and tumble, the rise and = fall, of different businesses over decades and centuries. I'm just = trying to give optimism over a (very) long run view. I am also very optimistic :-) You make a valid point of course that things will evolve and change. And = sometimes entities on a market will either be forced out or will = voluntarily move. And sometimes they make the market they leave more = easily accessible, more open. And at other times they didn=E2=80=99t = leave until the whole thing was no longer necessary :-) But I don=E2=80=99t think this relieves us from the need to understand = the world as it is today, to understand the tussles and power struggles = and the role of technology in it, or to try to see if there are things = we can improve. Jari --Apple-Mail=_29DA1062-6B69-4E1F-8F01-09E26C4AEF31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Bob for this.

1/ Another way to look at this is that the folks that designed the Internet did a good job of making it business-model-agnostic, cos it was generally designed to be highly distributed, but it's working well as distributed technology under a highly centralized business model.

Yes.

2/ On the 'Permissionless Completeness Problem', at whatever stage in history you look at a value chain (aka stack of businesses built atop each other) the top ones are typically closed. That doesn't mean they always will be. A common progression in industrial organization where there's a natural monopoly at a particular layer (say L) is:
  • at layer L business make a land-grab for the = largest market share by appearing to be open and free
  • then the winner closes off layer L to lock their = size advantage in
  • they build new products on top (layer M), locked-in = to the layer below (L)
  • in order to expand, the winner starts wholesaling = their layer L product, so other M businesses can build and innovate in different ways on top, rather than the winner having to maintain a retail relationship with everyone (but the winner keeps its competitors dependent on its layer L)
  • so, L gradually becomes a commodity (sometimes = aided by market regulation), and all the action moves to layer M
  • layer M could in turn become the platform for the = next set of applications at layer N, and the process repeats
For instance, Microsoft became dominant in the PC market by repeating this process: its BIOS became the platform for DOS, then DOS the platform for Windows, then Windows the platform for Office, then Office became the platform for various forms of automation. And you can see how Microsoft has always opened up what used to be the highest layer as it tried to expand by wholesaling to allow others to create new markets faster than it could.

The same could happen with all the apps built over maps and location services.

Another example might be VR, which is starting as an app, but then it will probably just become a way to deliver new apps over a VR platform (e.g. virtual shopping, virtual theme parks, etc) and the VR platform itself will consolidate and commoditize.

Yes, = we=E2=80=99ve seen this movie many times (although I wouldn=E2=80=99t = necessarily exclude the existence of other movies as = well).

3/ The important technical message is that it's much easier to start with an open platform so you can close it off and open it up again. Starting with closed technology is a dead-end.

Hmm. = Not sure I entirely agree with you. I certainly think personally that = open technology is better than closed. But I don=E2=80=99t think the = world works like you say in all cases, there are plenty of examples = where something proprietary got developed and it flourishes. Of course, = in most cases that proprietary thing runs on top of more open things. = Nice cars run on public roads, cool gadgets use Internet for transport, = etc. And there=E2=80=99s nothing wrong with that, I believe in private = enterprising and innovation. 

4/ Finally, we have to remember that open innovation is only necessary to create new businesses and opportunities. You would expect there to be a more closed period when businesses milk their innovations. That's the stage when the businesses pull in the cash to allow them to invest in the next round of innovation

Everything has its time; at some point whatever = market there was for, I don=E2=80=99t know, say, horse-drawn carriages = comes to an end and other things replace it. Sometimes there are clever = companies that can ride the wave of new technology and move along to new = things successfully, sometimes they die in the process. That=E2=80=99s = all good of course as well.

5/ Of course, this is all a very optimistic view. What actually happens is that incumbents try to hold on to their gains for far too long, they use scurrilous tactics to undermine innovations by others, etc. etc. But that's all part of the rough and tumble, the rise and fall, of different businesses over decades and centuries. I'm just trying to give optimism over a (very) long run view.

I am also = very optimistic :-)

You make a valid = point of course that things will evolve and change. And sometimes = entities on a market will either be forced out or will voluntarily move. = And sometimes they make the market they leave more easily accessible, = more open. And at other times they didn=E2=80=99t leave until the whole = thing was no longer necessary :-)

But = I don=E2=80=99t think this relieves us from the need to understand the = world as it is today, to understand the tussles and power struggles and = the role of technology in it, or to try to see if there are things we = can improve.

Jari


= --Apple-Mail=_29DA1062-6B69-4E1F-8F01-09E26C4AEF31-- --Apple-Mail=_A0E6768D-350A-4E33-84A4-689D3ED8B7BF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMvDCCBfIw ggPaoAMCAQICEH4FpBDRFc+VBCx+mWtm5bAwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE3MTIxNTEyMzI1MloXDTIwMTIxNTEyMzI1MVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzAR BgNVBAMMCkphcmkgQXJra28xJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJra29AZXJpY3Nzb24uY29t MRAwDgYDVQQFEwdMTUZKQUFSMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApfp0Or2a mZpqHenqngBbX/HZwC5HOI3cQGLGsKZr+OdpVl6Z8KoNk0ZRqpGMfsdZ78DG8VWdz3h6q5zEciEW tPeIhZ7rZfYXuiVtQbo6EWeG9flzqy8TzZvoJ4x07HbSJD3SNk9ArSPu8VdShoaEO6/RkmL5CBlG bqP8oNJApAWcxZGZrCc+TTf20uXC9VXggbTOhS0vThUIKk4Vrq89oLQEzgiz43RQg9KlSS8lPEoD rNhb5uZEAm4/iI+ZQX5PnhWxTNyalGz92Gj8Wf/XVH+uxRqyRiWZ0RZYTx4sxnaIGM79s8/KlzeN difwj1jbLHFgdOcvah/OHOpDMDS8ZwIDAQABo4IBvTCCAbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgG CCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRp dmlkdWFsY2F2My5jZXIwIgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBR4gHkmRNOtf0OskjVPOX1ScEdVozAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj 2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAJJUvEJM2TB80V1XcgeiNK/Q ePVqVJA92ncBVsfeBqeu3IF4PMBSAaDso8XI98Dy3U3p8PKlz9KL+ap7F+tQNAGv0o2Ht5IytJW8 QtZ1pca1mzu1/hvEDH+biNd4lMdJ1K4w98upbMQ/GlzeaE6RfKhbn3BlNxbnMrCBWbA/CEuF4RGz muydkbLCoxqfyrMn83A0ZZ67yq9+5OYezJqNTMbDgH4QE7+4JVsU8OujPoYLv60hc73J0w4SV+tX oM1EnuWYu+epqlb4AhmQxQf8P79g1aB3vumEw+tAI7bHlVmdJLWHYCEtphrjPiam2wT8oc8y5gdA j6yryaV2luKQCjGoSK9wVVG0fCzym91jWgWPGZs6RhFRRy49cJNaE3GS6QSe1CBwCqpsF4TqdO6U LGHypRbeRz3pJ7hORACETs/nvyPYHeTBzdTiVWMCoWHoYNd9gSTw2utA/VGabesrlDPcTqPRv4HT VP8I/TtrhnrcG3b85rUBFDzWMF8L1wtXqBXQYdYUV7sFCAxZnNl17mxBxei/pNemd67utP5UswMW QmpRfUFbTAueKHLX3hIVchYinp1yFWTNag5zAam4zxZ6PCG9JlLGxzeTHUwSvWnp4srsQas7RqnJ teI7NqYYkwfYDI5c6yawccdPmK8LOdt0ZED2c69rS3z6hARwORInMIIGwjCCBKqgAwIBAgIQU7h+ g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0G A1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2 NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAA uFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh 7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrAS F8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxA EgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLE PXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqH MRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5 r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0Y Gaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL /zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGj ggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50 ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwt My50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYw FAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwg Pdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEL BQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJ nuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNg vgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1R uRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst 821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkm agp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4ar MUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNr ZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9 hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5 j0Qpj5aQMYICvTCCArkCAQEwWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEH4FpBDRFc+VBCx+mWtm5bAwCQYF Kw4DAhoFAKCCATcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgx MDI0MTk0MjU3WjAjBgkqhkiG9w0BCQQxFgQU2EzqBFq7KPIJsOHNAU6B/b8pbJUwagYJKwYBBAGC NxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEH4FpBDRFc+VBCx+mWtm5bAwbAYLKoZIhvcNAQkQAgsx XaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MwIQfgWkENEVz5UELH6Za2blsDANBgkqhkiG9w0BAQEFAASCAQCH XUm38jFGoeUf7ZvlYI/s7SEsOkLiSmVxP89hLPlTlsqBOv3IFTuN2KADJ2o05t14ZobwRof+8RRx 58ex/fTuUsFyKlbv2t4yPWaYxduZdiZYL/o4MP3+puSwhXeH4i5HOdjW/KkBvEwYlHVriJfnunXr 8CjXMuEjoZZdlwHwJM9lDhjHYyIcuy27wWyub2i5Q2rVAZUaNg20a6sayIaX5VU+Ev09vmUDhIy6 6o3RKKA3GpdV7WuQGV/fkHeLX7SnTbU02HvGYdRi99qWgaU+/Zthx8UsfhHglb4N9rCY6S2hp73E uOK4fawO3pB+k89GiV9Nl/JodybmKjSc1K70AAAAAAAA --Apple-Mail=_A0E6768D-350A-4E33-84A4-689D3ED8B7BF-- From nobody Wed Oct 24 14:14:27 2018 Return-Path: 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 B2516128B14 for ; Wed, 24 Oct 2018 14:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 G3ueDbHN_UdO for ; Wed, 24 Oct 2018 14:14:23 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 AC240126CC7 for ; Wed, 24 Oct 2018 14:14:23 -0700 (PDT) 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 9BF2254802D for ; Wed, 24 Oct 2018 23:14:19 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 89E58440210; Wed, 24 Oct 2018 23:14:19 +0200 (CEST) Date: Wed, 24 Oct 2018 23:14:19 +0200 From: Toerless Eckert To: architecture-discuss@ietf.org Message-ID: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 21:14:26 -0000 > draft-arkko-iab-internet-consolidation: > It is also surprising that in the age of software-defined everything, > we can program almost anything else except the globally provided, > packaged services. Opening up interfaces would allow the building > of additional, innovative services, and better match with users' > needs. One key problem in this is the blinders IETF traditionally puts on in designating Internet Standards stamps only to what IETF considers to be relevant interoperability: IPC (protocols) between componts across some (even if imaginary) wire. To create more innovation, opportunity and agility of technology evolution in the network itself, we need to encourage a framework we we get interoperating software components inside network devices. Yet none of that can be Internet Standards, as seen in typical examples like all the layer APIs we're doing that must all be informational (TAPS etc.). Aka: "Think inside the box" wrt to IETF's scope of standards track interoperability. Lets not have us convert everything that needs to interoperate inside a box into protocols that look like they could be happening on an outside wire just to be able to become Internet Standards. And interoperability is just one part. Overall SW inside the box designs could become much more of an encouraged topic for the IETF. Cheers Toerless From nobody Wed Oct 24 14:45:44 2018 Return-Path: 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 44E24130DE9 for ; Wed, 24 Oct 2018 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 dne40RbBO2Y2 for ; Wed, 24 Oct 2018 14:45:39 -0700 (PDT) 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 89BC6128B14 for ; Wed, 24 Oct 2018 14:45:39 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 76352548137 for ; Wed, 24 Oct 2018 23:45:34 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 66ED8440210; Wed, 24 Oct 2018 23:45:34 +0200 (CEST) Date: Wed, 24 Oct 2018 23:45:34 +0200 From: Toerless Eckert To: architecture-discuss@ietf.org Message-ID: <20181024214534.6rtz62i443lscfth@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [arch-d] IETF standards: monopoly playbook (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 21:45:41 -0000 In the gloom & doom section the text could be a lot more explicit about the playbook for vertical market monopolies that has created the biggest players. E.g: Create a platform for competing entities offering service/products, then leverage the fact that this platform of yours allows you to spy on those entities and unfairly compete with them. Or better yet pass on their business data to some less unsuspectfull third party that does that. Publically preach net neutrality, but behind the curtain collude with others to get unfair advantges in the market, like placing your content caches into network operators knowing this model will not be supported by network operators for any set of competing OTT content providers. Attempt to commoditize your competitors by making the IETF standardize technology to reduce revenue opportunities for them and maximize yours. Go to congress and ensure your business is unregulated while theirs is highly regulated. Preach privacy when it helps exactly with this goal but waste hours in congres diffusing the fact how you are the worst in abusing user data. and so on and so forth A lot of stuff that is happening on the Internet would have brought down any other infrastructures such as roads or banking and/or be prohibited there. Cheers Toerless From nobody Wed Oct 24 15:24:50 2018 Return-Path: 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 BD480130DE9 for ; Wed, 24 Oct 2018 15:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ianpeter.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 WMaLmP3iIKRy for ; Wed, 24 Oct 2018 15:24:47 -0700 (PDT) Received: from node171.myfcloud.com (li1827-163.members.linode.com [172.104.250.163]) (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 EA348130DC7 for ; Wed, 24 Oct 2018 15:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ianpeter.com; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TQyNTZJHatfAac1O0XK7yiTzo7B0uAjrewGc02wowq8=; b=BuVgs82paCY/aAXjbZ70c7VdB O2I3rGyot8VN7nc/UEJCoLhh/Ra54doQyjfMZAvnZaNjxz0/zYHkjRlLojgRNWzB62GxHdy85rQ10 hCpqIIbO+g3sPSbctbYdi6168/f41yfFyDAKbu+KvpZEt/8+QnJRHL2XrV/LxcgqDCGTI=; Received: from [121.216.193.94] (port=63941 helo=[192.168.0.5]) by node171.myfcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gFRZx-0000WZ-Ta; Wed, 24 Oct 2018 22:24:42 +0000 From: "ian.peter@ianpeter.com" To: "Jari Arkko" , "Bob Briscoe" Cc: "architecture-discuss@ietf.org" Date: Wed, 24 Oct 2018 22:23:38 +0000 Message-Id: In-Reply-To: References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> Reply-To: "ian.peter@ianpeter.com" User-Agent: eM_Client/7.1.33101.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBC549D611-D1F6-4B9D-9751-BF5894B0E9E0" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - node171.myfcloud.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ianpeter.com X-Get-Message-Sender-Via: node171.myfcloud.com: authenticated_id: ian.peter@ianpeter.com X-Authenticated-Sender: node171.myfcloud.com: ian.peter@ianpeter.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 22:24:50 -0000 --------=_MBC549D611-D1F6-4B9D-9751-BF5894B0E9E0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for raising this important issue. Just to add an historical=20 perspective: The Internet was not the first new media that was going to create an=20 utopian connected world. Tim Wu points this out very clearly in "The=20 Master Switch" (2010) - which also clearly predicted this consolidation=20 in the Internet space. From electricity and telephony on, and through=20 radio and television, we can see new media which originally had quite=20 different uses until the monopolisation took over. The telephone was "a=20 universal wire system for the electrical transmission of intelligence";=20 radio was originally conceived as something more like ham radio=20 communications than a consolidated broadcasting model: the movie camera=20 did not foresee Hollywood: and television was going to be an interactive=20 media as well. So we should not be surprised at what has happened with the Internet and=20 with the fact that this consolidated model is becoming the dominant=20 model of internet usage, and to many people what it is all about. We can=20 expect that narrowing to a few platforms to continue. I mention this because, to answer Jari's question, I cannot see how=20 tweaking standards in any of the previous media would have changed this=20 phenomena. So I am not sure anything can be done in this area. What probably is necessary is anti-trust measures - and I believe this=20 is the theme of Wu's new book "The Curse of Bigness - Antitrust in the=20 New Gilded Age) - there is a review at=20 http://www.boundary2.org/2018/10/richard-hill-too-big-to-be-review-of-wu-th= e-curse-of-bigness-antitrust-in-the-new-gilded-age/). I personally think the challenge is bigger than just economic domination=20 - because how people think and what they think about political issues is=20 to a largely degree determined by dominant media players. Elections can=20 be determined by dominant media players, and, as Henry Kissinger points=20 out in "How the Enlightenment Ends" (see=20 https://www.theatlantic.com/magazine/archive/2018/06/henry-kissinger-ai-cou= ld-mean-the-end-of-human-history/559124/),=20 the capacity of humans to think critically is also severely challenged=20 by the way the Internet and associated technologies have evolved. I just wanted to provide this background: because the problem is=20 substantial, and much though I would welcome any technical development=20 that helped to address this, I don't think there will be one. Which doesn't mean there is no role for the technical community or for=20 IAB. All of us can help raise awareness of what is happening and the=20 ramifications. Perhaps this draft - perhaps with some amendments - can=20 serve a useful purpose in awareness raising of the substantial issues=20 raised by media consolidation. Ian Peter > --------=_MBC549D611-D1F6-4B9D-9751-BF5894B0E9E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for raising this important issue. Just to add an historical perspe= ctive:

The Internet was not the first new media= that was going to create an utopian connected world. Tim Wu points this out = very clearly in "The Master Switch" (2010) - which also clearly predicted= this consolidation in the Internet space. From electricity and telephony on= , and through radio and television, we can see new media which originally h= ad quite different uses until the monopolisation took over. The telephone w= as "a universal wire system for the electrical transmission of intelligence= "; radio was originally conceived as something more like ham radio communic= ations than a consolidated broadcasting model: the movie camera did not for= esee Hollywood: and television was going to be an interactive media as well= . =C2=A0

So we should not be surprised at what h= as happened with the Internet and with the fact that this consolidated mode= l is becoming the dominant model of internet usage, and to many people what = it is all about. We can expect that narrowing to a few platforms to contin= ue.

I mention this because, to answer Jari's que= stion, I cannot see how tweaking standards in any of the previous media wou= ld have changed this phenomena. So I am not sure anything can be done in th= is area.

What probably is necessary is anti-trus= t measures - and I believe this is the theme of Wu's new book "The Curse of = Bigness - Antitrust in the New Gilded Age) - there is a review at=C2=A0http://www.boundary2.org/2018/10/richard-hill-too-big-to-be-re= view-of-wu-the-curse-of-bigness-antitrust-in-the-new-gilded-age/).=C2= =A0

I personally think the challenge is bigger t= han just economic domination - because how people think and what they think = about political issues is to a largely degree determined by dominant media = players. Elections can be determined by dominant media players, and, as He= nry Kissinger points out in "How the Enlightenment Ends" (see=C2=A0ht= tps://www.theatlantic.com/magazine/archive/2018/06/henry-kissinger-ai-could= -mean-the-end-of-human-history/559124/), the capacity of humans to thin= k critically is also severely challenged by the way the Internet and associ= ated technologies have evolved.

I just wanted to = provide this background: because the problem is substantial, and much thou= gh I would welcome any technical development that helped to address this, I = don't think there will be one.=C2=A0

Which does= n't mean there is no role for the technical community or for IAB. =C2=A0All = of us can help raise awareness of what is happening and the ramifications. = Perhaps this draft - perhaps with some amendments - can serve a useful pur= pose in awareness raising of the substantial issues raised by media consoli= dation.


Ian Peter


--------=_MBC549D611-D1F6-4B9D-9751-BF5894B0E9E0-- From nobody Wed Oct 24 20:41:51 2018 Return-Path: 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 CEA5C128D68 for ; Wed, 24 Oct 2018 20:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=open-xchange.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 9LQqOnHblhGF for ; Wed, 24 Oct 2018 20:41:48 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 13EF5130934 for ; Wed, 24 Oct 2018 20:41:47 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id B704E6A324; Thu, 25 Oct 2018 05:41:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1540438905; bh=QFLB1Mm6xeLaevonqFNrBOEnifPh9069Kp6e7Gxdo6Y=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Ui0Q5k72PEA4gQRio8PH/vKOT4zXoRGT5mePxeYAS4wl+v98onund63J8oljzSxNU rJe+MHq4n5WfFcMVZ5iEcvgDcKpWem8F/TvSo8mvQELq13N8batAkLI/ekWrN0o0HK 2CoPWYupVkkR4YTAH1hYs7M27LOW5o79F82VC4vOox7zA4u63Q5KYe1ucZDZuCLiax eGQ8A6T8DHjYDk+zH868fG6uVb2+bZizU03LQg2G0WpP05S68E0UL4Wz/ymR4WY/Np 917brkowfXoIxWyLrOuMlYtEsxvGfy1NCdUDJJJY+GHf0Nh2jBRcbYRaUeDAlSb2Lu 3BYf3yfr9+DLw== Received: from null (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id AA2723C05BB; Thu, 25 Oct 2018 05:41:45 +0200 (CEST) Date: Thu, 25 Oct 2018 05:41:45 +0200 (CEST) From: Vittorio Bertola To: Dan York , architecture-discuss@ietf.org Message-ID: <2076480643.29453.1540438905630@appsuite.open-xchange.com> In-Reply-To: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29452_1406847657.1540438905623" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev18 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 03:41:51 -0000 ------=_Part_29452_1406847657.1540438905623 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il 24 ottobre 2018 alle 12.21 Dan York ha scritto: >=20 > FYI, Jari Arkko published a new draft yesterday on behalf of several = IAB members with the title "Considerations on Internet Consolidation and th= e Internet Architecture=E2=80=9D: >=20 Just a couple of days ago on the HRPC list I was saying that we should writ= e a draft entitled "Centralization and consolidation are an attack", so it = looks like the IAB read in our minds :-) I find the draft right on spot and well thought out. It mentions all the si= tuations that I find more troubling, from email to DNS-over-HTTPS going thr= ough social networks (I would have added a couple of lines on instant messa= ging as well, as it was the intermediate consolidation/walled-garden-constr= uction step between email and social networks, and it's one of the best exa= mples of how the lack of federation led to cumbersome user experiences). I would perhaps add a consideration on another problem: the more the Intern= et's services get consolidated into the hands of a few companies, often con= centrated in very few parts of the world, the more this creates tensions ar= ound cultural diversity (for example, in standards on which online content/= behaviour is acceptable and how to deal with the unacceptable ones) and aro= und national sovereignty, which promote negative reactions leaning towards = fragmentation and the rejection of the permissionless innovation and multis= takeholder management model. As for the remediation, though in the end some situations (as we saw with t= he GDPR) may only be addressed by the dreaded last resort of regulation, I = think that before releasing new protocols the IETF should pay more attentio= n to their potential centralizing effects - perhaps a specific "centralizat= ion considerations" section could be added when appropriate. One could also think whether the IETF should actually be proactive in promo= ting protocol development work aimed at "opening up" fields that otherwise = will only evolve towards the usual set of walled gardens: for example, I am= currently also working on online identity management (distributed and fede= rated single sign-on, data flow and consent management etc) which, unless a= ppropriate standards are created and promoted, is going to be the next inst= ant-messaging-like mess of non-interoperable services - and identity is now= adays the fundamental layer for pretty much everything else. It would be useful to understand what the next steps for this draft could b= e and how can one contribute effectively. Regards,=20 -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com= =20 Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_29452_1406847657.1540438905623 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20
Il 24 ottobre 2018 alle 12.21 Dan York <york@isoc.org> ha scritto:= =20
=20
FYI, Jari Arkko published a new draft yesterday on behalf of severa= l IAB members with the title "Considerations on Internet Consolidation and = the Internet Architecture=E2=80=9D:
Just a couple of days ago on the HRPC list I was saying that we should w= rite a draft entitled "Centralization and consolidation are an attack", so = it looks like the IAB read in our minds :-)

I find the draft right on spot and well thought out. It mentions all the= situations that I find more troubling, from email to DNS-over-HTTPS going = through social networks (I would have added a couple of lines on instant me= ssaging as well, as it was the intermediate consolidation/walled-garden-con= struction step between email and social networks, and it's one of the best = examples of how the lack of federation led to cumbersome user experiences).

I would perhaps add a consideration on another problem: the more the Int= ernet's services get consolidated into the hands of a few companies, often = concentrated in very few parts of the world, the more this creates tensions= around cultural diversity (for example, in standards on which online conte= nt/behaviour is acceptable and how to deal with the unacceptable ones) and = around national sovereignty, which promote negative reactions leaning towar= ds fragmentation and the rejection of the permissionless innovation and mul= tistakeholder management model.

As for the remediation, though in the end some situations (as we saw wit= h the GDPR) may only be addressed by the dreaded last resort of regulation,= I think that before releasing new protocols the IETF should pay more atten= tion to their potential centralizing effects - perhaps a specific "centrali= zation considerations" section could be added when appropriate.

One could also think whether the IETF should actually be proactive in pr= omoting protocol development work aimed at "opening up" fields that otherwi= se will only evolve towards the usual set of walled gardens: for example, I= am currently also working on online identity management (distributed and f= ederated single sign-on, data flow and consent management etc) which, unles= s appropriate standards are created and promoted, is going to be the next i= nstant-messaging-like mess of non-interoperable services - and identity is = nowadays the fundamental layer for pretty much everything else.

It would be useful to understand what the next steps for this draft coul= d be and how can one contribute effectively.

Regards, 

-- 

Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20 ------=_Part_29452_1406847657.1540438905623-- From nobody Thu Oct 25 02:16:43 2018 Return-Path: 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 CEE7D12F1AC for ; Thu, 25 Oct 2018 02:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.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 Wd5WpxtjcaON for ; Thu, 25 Oct 2018 02:16:39 -0700 (PDT) Received: from rgout03.bt.lon5.cpcloud.co.uk (rgout0301.bt.lon5.cpcloud.co.uk [65.20.0.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AD130E29 for ; Thu, 25 Oct 2018 02:16:38 -0700 (PDT) X-OWM-Source-IP: 10.110.13.1 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 20 X-VadeSecure-score: verdict=clean score=20/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 20 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtkedrgeelgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucgotffhvedqqdeurggukfhmphhorhhtrghntggvucdlvddtmdenucfjughrpeffhfhrvffkjghfufggtgfgkgfrsehtjegttddttdejnecuhfhrohhmpeghihhllhhirghmpgflpgfiucfqvhgvrhhinhhgthhonhcuoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqeenucffohhmrghinhepghhlohgsrghlnhgvthdrtghordhukhenucfkphepuddtrdduuddtrddufedruddpkeeirddufedtrdehvddriedvnecurfgrrhgrmhephhgvlhhopeifvggsmhgrihhlvdegrdgsthdrvgigthdrtghptghlohhuugdrtghordhukhdpihhnvghtpedutddruddutddrudefrddupdhmrghilhhfrhhomhepoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeorghrtghhihhtvggtthhurhgvqdguihhstghushhssehivghtfhdrohhrgheqpdhrtghpthhtohepoehivghtfhessghosggsrhhishgtohgvrdhnvghtqedprhgtphhtthhopeeojhgrrhhirdgrrhhkkhhosegvrhhitghsshhonhdrtghomheqpdhrtghpthhtohepoehsthgvphhhvghnrdhfrghrrhgvlhhlsegtshdrthgtugdrihgvqeenucevlhhushhtvghrufhiiigvpedt Received: from webmail24.bt.ext.cpcloud.co.uk (10.110.13.1) by rgout03.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5BB6CF6501C112B1; Thu, 25 Oct 2018 10:15:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1540458998; bh=OSQVGhFJwPGEYy2ub4m3dl6lmpJQqiIIp54UsCELSt0=; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version; b=wKIWa0Tyd07O+q99Au1CtTlkQ9Ykv7Ujzzd2FWhqtAFZQbFjpugzjYnVfysnAHmUbwAXbxmyWDROnG71q70g08jp/cOyzKgo/o9QaJdzZ5BYOObOcx2dr+6YnIi7esyrEd3lhc1VKAc+mePs8BHvWdkqN8TPA+rltu7zqX3cM2w= Date: Thu, 25 Oct 2018 10:15:54 +0100 (BST) From: William_J_G Overington Reply-To: wjgo_10009@btinternet.com To: stephen.farrell@cs.tcd.ie, jari.arkko@ericsson.com, ietf@bobbriscoe.net Cc: architecture-discuss@ietf.org Message-ID: <9785868.8018.1540458954067.JavaMail.defaultUser@defaultHost> In-Reply-To: <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-UID: 50601 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.130.52.62] Epoch[1540458954030] Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 09:16:42 -0000 Stephen Farrell wrote: > Hi Bob, > While I like what you wrote, I'm not sure I follow this bit.. > On 24/10/2018 16:09, Bob Briscoe wrote: >> >> 3/ The important technical message is that it's much easier to start >> with an open platform so you can close it off and open it up again. >> Starting with closed technology is a dead-end. > Again, I like the message but I'm not sure if one can justify that or not - do you have examples of starting with a closed technology forced it into a dead-end? An example is that where a business develops a software product that it considers will only need to use the languages of Western Europe and decides to use 8-bit character encoding because that is all that is needed. Unicode was readily available to use, but the business decided that 8-bit character codes was all that was needed. Some time later, maybe several years later, a need is found to extend the languages available to be used with the product to include Polish and Czech. As 8-bit character encoding cannot do that easily - yes, old fashioned code pages, but it gets problematic - the business has to decide whether the need for expansion is not to be followed up or whether a major rewriting of the software needs to be funded. Had the business used Unicode in the first place, even though the software product at the time only needed to be used for the languages of Western Europe, then when the need for Polish and Czech arose, expansion would have been straightforward and Japanese and various Indian languages could be straightforwardly included too, as well as many other languages. Also, embarrassment could be avoided when one of the customers asks for a version in Welsh, mentioning that the business was claiming that all the languages of Western Europe are supported. Please consider the possibility of a business producing an app for a mobile device that implements the invention described in the following publication and publications linked from it. http://www.users.globalnet.co.uk/~ngo/a_completed_publication_about_localizable_sentences_research.pdf The link is safe, it is a personal webspace hosted by Plusnet PLC on their server. If the business were to decide just to support English, French, German, Italian and Spanish to start and decided that an 8-bit character encoding were sufficient for its needs, then all might go well. Then support for Danish and Swedish might be added. All might still be going well. It would be when support for Japanese and Polish and Welsh were needed that the problems would start. Yet if the business starts with a Unicode encoding for the characters, then the later expansion would be straightforward. The same set of languages might still be used at the start, but the technological capacity to expand the set to any language that can be encoded using Unicode is there for use if needed later, even though not used at the start. William Overington Thursday 25 October 2018 From nobody Thu Oct 25 07:49:19 2018 Return-Path: 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 49312130E69 for ; Thu, 25 Oct 2018 07:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 jxA6PdSeV50D for ; Thu, 25 Oct 2018 07:49:13 -0700 (PDT) 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 AADBA130E5A for ; Thu, 25 Oct 2018 07:49:12 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 21CBD5485CE; Thu, 25 Oct 2018 16:49:08 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 15B12440210; Thu, 25 Oct 2018 16:49:08 +0200 (CEST) Date: Thu, 25 Oct 2018 16:49:08 +0200 From: Toerless Eckert To: wjgo_10009@btinternet.com Cc: stephen.farrell@cs.tcd.ie, jari.arkko@ericsson.com, ietf@bobbriscoe.net, architecture-discuss@ietf.org Message-ID: <20181025144907.vzhxosjw5fyo5lij@faui48f.informatik.uni-erlangen.de> References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> <9785868.8018.1540458954067.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9785868.8018.1540458954067.JavaMail.defaultUser@defaultHost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 14:49:16 -0000 To me this example is more around support for agile extensibility/evolution as opposed to waterfall committee designs. In the early nineties at least one router companies claim to fame in certain circles was that when a problem was reported by a customer, they would receive a fixed version of the router software within 24 hours and would deploy them in 24 themselves. I think these days these two number are the same, but the unit has changed from hours to weeks and the probability for it to happen at all went from 90% to 30%. So while the network industry is stuck in ossification and slowdown, the principle was perfected in other industries to create a lot more innovation and business growth e.g.: apps in DCs, devops, etc. pp. In DCs, these principles are also applied to networking, but only as far as it can be done with software that others than the infrastructure owner can develop. This is what the networking industry at large outside the DC needs to get back to, but that would require more focus of the IETF on software and systems architecture as opposed to only interoperability on wires via protocols. See my prior email wrt. IETF and standards. Cheers Toerless On Thu, Oct 25, 2018 at 10:15:54AM +0100, William_J_G Overington wrote: > Stephen Farrell wrote: > > > Hi Bob, > > > While I like what you wrote, I'm not sure I follow this bit.. > > > On 24/10/2018 16:09, Bob Briscoe wrote: > >> > >> 3/ The important technical message is that it's much easier to start > >> with an open platform so you can close it off and open it up again. > >> Starting with closed technology is a dead-end. > > > Again, I like the message but I'm not sure if one can justify that or not - do you have examples of starting with a closed technology forced it into a dead-end? > > An example is that where a business develops a software product that it considers will only need to use the languages of Western Europe and decides to use 8-bit character encoding because that is all that is needed. Unicode was readily available to use, but the business decided that 8-bit character codes was all that was needed. > > Some time later, maybe several years later, a need is found to extend the languages available to be used with the product to include Polish and Czech. > > As 8-bit character encoding cannot do that easily - yes, old fashioned code pages, but it gets problematic - the business has to decide whether the need for expansion is not to be followed up or whether a major rewriting of the software needs to be funded. > > Had the business used Unicode in the first place, even though the software product at the time only needed to be used for the languages of Western Europe, then when the need for Polish and Czech arose, expansion would have been straightforward and Japanese and various Indian languages could be straightforwardly included too, as well as many other languages. > > Also, embarrassment could be avoided when one of the customers asks for a version in Welsh, mentioning that the business was claiming that all the languages of Western Europe are supported. > > Please consider the possibility of a business producing an app for a mobile device that implements the invention described in the following publication and publications linked from it. > > http://www.users.globalnet.co.uk/~ngo/a_completed_publication_about_localizable_sentences_research.pdf > > The link is safe, it is a personal webspace hosted by Plusnet PLC on their server. > > If the business were to decide just to support English, French, German, Italian and Spanish to start and decided that an 8-bit character encoding were sufficient for its needs, then all might go well. Then support for Danish and Swedish might be added. All might still be going well. It would be when support for Japanese and Polish and Welsh were needed that the problems would start. Yet if the business starts with a Unicode encoding for the characters, then the later expansion would be straightforward. The same set of languages might still be used at the start, but the technological capacity to expand the set to any language that can be encoded using Unicode is there for use if needed later, even though not used at the start. > > William Overington > > Thursday 25 October 2018 > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Oct 25 07:52:48 2018 Return-Path: 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 1A8CF130E69 for ; Thu, 25 Oct 2018 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Cc0cMGo/; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=diWRyXCH 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 srAqiDoomQJd for ; Thu, 25 Oct 2018 07:52:44 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7B860130E6A for ; Thu, 25 Oct 2018 07:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540479161; x=1543071161; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BtmzQj0VB8T7h9DGIoE08d6zTgv/kA4EYJvd+Levais=; b=Cc0cMGo/WkpwOqJT/2QlrZtVHbQyoxYLw5rqFMWUCRkXJyIpaNz2pgyY0d3FQfGI Pke/HpFewoZ8KhzAfHE/OBrO3yaZQcdSPgn35KBT3xTxIbwMKF2ebJYbTxCWhU/B N/kHNN0lW5LMCCTJov3Zjtc6BoCRoP7msOW5bP9dozI=; X-AuditID: c1b4fb2d-887c49e00000434d-b7-5bd1d8b95b99 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.3F.17229.9B8D1DB5; Thu, 25 Oct 2018 16:52:41 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 25 Oct 2018 16:52:40 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 25 Oct 2018 16:52:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oxif9+qjDSg2uHGpOgb5D4sRsk/F6mY2M3w3Ur9ybW0=; b=diWRyXCH1e8E6m15wiM5jU50GmPrF2dW/K1Xz326+AWSZcK8KKpFFlLAs5zxV7Gimk8DaXicxGeH7+EQTPBh8zTuTw3O4i2yjxAjH/DK2Ooax5tYw8aZ0AM0U+cI/CuR5tOhgLkuzcmy2Nq6WGPLPxzCiKtHUQ4+ZKR4qH8rmmw= Received: from VI1PR0701MB2541.eurprd07.prod.outlook.com (10.168.139.142) by VI1PR0701MB2349.eurprd07.prod.outlook.com (10.168.137.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.8; Thu, 25 Oct 2018 14:52:39 +0000 Received: from VI1PR0701MB2541.eurprd07.prod.outlook.com ([fe80::d0c0:4101:f960:374a]) by VI1PR0701MB2541.eurprd07.prod.outlook.com ([fe80::d0c0:4101:f960:374a%5]) with mapi id 15.20.1273.021; Thu, 25 Oct 2018 14:52:39 +0000 From: Jari Arkko To: Toerless Eckert CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture Thread-Index: AQHUbHJg4xlOjL/PPUGRocC6HFE/lg== Date: Thu, 25 Oct 2018 14:52:39 +0000 Message-ID: <69A20C3F-1128-427B-8DA4-6E72F69C9B76@ericsson.com> References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <106237e8-b67d-83c7-0953-3a8b5be857d9@bobbriscoe.net> <027dc82c-1402-61e6-5ea0-1dbf1060dbeb@cs.tcd.ie> <9785868.8018.1540458954067.JavaMail.defaultUser@defaultHost> <20181025144907.vzhxosjw5fyo5lij@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20181025144907.vzhxosjw5fyo5lij@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jari.arkko@ericsson.com; x-originating-ip: [2001:1bc8:101:e900:1cea:4d16:9462:cd8d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2349; 6:pmaBneNx0TEJeva+p2faTABe7hoJM4myZRRpFa6vB3XlT+8cuJsZ09nZK5pnj2c5nLKIazOoJuJf7bZrqJul86sGUeK/FLhu/0kvIDXSNn/Pq83fFMuRrOgtnfZG6o61VeiCLhBy+giMpr/BvLJwfgae5y7dGXFgydfUWoWT+ypa4CGQ5/dy95cPVqJxPu2i0FqWVUZW8/a9961vm/UdCOQGz20Ye2DNUGJOxuMCKSmboCJYuRmF9Sa53F9BoSx5H4PEq+AMer4hRfr12H4lLNyEQKkLnwwXNa90suZII8+gcm1s+jA/h2xhCiTH+tB/2b2bqXZCCN7qrsrVRMWI8eYC+yC/j+beerWV6Mo9akXK9fJVR+ooF5e44lRevWdP/Z2S7v+T+Mx4MY0lRpX3hQuVCuks3GxAUPDNxoOczukykF/z52myt0K6avHM+4QodExBHWgzU97oEiy7C3MKaw==; 5:Y+QQb4MvLu8DrPNdFCOAIOOLPWwTTvoh7kg8wWpTdqkQmqnhsijmmzhIUPKRlrEwX5bHJopGqmzd3j5KothgvXk8Ydb7IY847Cffc7oFL+VXJftXyzujvK6RfYYfFQtafOtqJJiNK+Aa6kBCFRFFQeCdR8wr6wjTKaKxeU5dmXU=; 7:4rwXJhZsjz1I/MS4LigTPqkFEo77Xg/CGJYUesn9j0oS9c+P2rdF3aIZ3LFBYyqxI0+vcuuemEXfH9Lw6M38fmusL7bopndU4RmnvEaXNp0yiapStaAgQo/TPYyjEqakmJrnHyN1nPwZZ/LzZVEAnQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fbf69d99-f10a-4755-cc22-08d63a8982aa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2349; x-ms-traffictypediagnostic: VI1PR0701MB2349: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(4983020)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2349; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2349; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(396003)(366004)(39860400002)(199004)(189003)(305945005)(11346002)(4270600006)(50226002)(7736002)(6436002)(19618925003)(6486002)(588024002)(99936001)(5660300001)(71190400001)(6246003)(6916009)(478600001)(57306001)(4326008)(229853002)(6512007)(14454004)(8936002)(81156014)(81166006)(83716004)(8676002)(53936002)(33656002)(82746002)(86362001)(105586002)(76176011)(558084003)(102836004)(36756003)(71200400001)(25786009)(44832011)(6506007)(68736007)(2616005)(97736004)(316002)(256004)(46003)(93886005)(99286004)(446003)(5250100002)(6116002)(2900100001)(2906002)(186003)(106356001)(476003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2349; H:VI1PR0701MB2541.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1PNL3VBTtij+/zCPCSPuniqJ04qZGRWFP0iGNNB4eRrV69LeVI17AUkoCOWiatoRAQCnnawOB7kktvqESGgL3vWCXLrjZ73HZ4hN3sz7bJPUD9npaEMafV0Dr6o/SuKidVS786yyZ2k+085AaeK0+YQ+2VN/9Z6SqC/IGSWfpQUE82v12pwysJzAcjQbIKZOtpVykMfSiWSNtH1F5qfgD3WLuRBfgM0l/UZXXdk3s96IkeObKn6UeBZjuxENGmKVp5QNWMw+FLcWEPoMqHRWhNkVsfBywFln4pnEAxj0joWhkfeEWKgVwnYLomVURHYIB9Q2VYiwaDaFE6+ThV8cH3OSB+w1fl7YxrYsCcqsW2k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_8189ED43-909A-4F01-B2CD-98180A80594C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fbf69d99-f10a-4755-cc22-08d63a8982aa X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 14:52:39.4814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2349 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85W2ez1ZvXBy3MVViiU0tB00oxwaCivpVWNvTkTJ26M00L QoVgKnlJjRyiZoql5qXMS1peUKJG1lLc0gjnLcQER2mYGe14JvTt9zzP//9cXl6atO0XONPx SjWjUsoTpUIxVX6h84ZXt1Ef5aO7dyig9UuuIGDEsE6GEBHlbUsoorZ2jThHRIqDY5nE+HRG 5X38qljxsuUHkdIsy5ib7hZkIbNnHhLRgP3APNmzjWNbPIxgouN0HhJbeBXBzItCkg9qCeiq Hye4gMJFJHTNtQv5ygMCVsbbKd4/j2A5N4ZjIfaAtvpqIcf2eB+MtD+2aGiaxGEwlB3Lpe1w HBRXVJG8RAE5uh6KZxm0/e4gOKbwAdC28OtJ8AkorjNQ/NynBKw9r9k0i/B5GNffRxwj7Ai/ 3jVtmknsBBOzVQR/pz2Y9Dohzw6wMPNXwPMe6FvIJXhvJDRudGzuCfgoLI37bkk+VeUjbi5g oxBGC75Z+3jBclkZyfMZGH5URfCiUQR9mjHrYE8Y0LyieE6GBn2ldbAHaIa0RBHy1f63q9bi J3EpgpzsGlK7efUueFs+S/EiV+hcqrDkuYf0hJKHiE/7w+Kw2cpBsFYxbWU3KM03batGdANy YBmWTYo7fETGqOJjWDZZKVMy6mfI8pcG2te9ulDjYuggwjSSbpfUt+ijbAXydDYzaRDtt/SZ bm38iJwpZbKSkdpLwq5YypJYeeZNRpUcrUpLZNhB5EJTUieJrKE30hbHydVMAsOkMKqtKkGL nLOQzVia2PuywTBVu5K6nDZpjpiKl4quOYn6XlN+6m6HN7dMdQUZ4Se/nm3VpXo7ChovLW6Q Oz80+7j6vL+7Ohyo+DxgDLSLdvszami6Y7z4XTMIztfjguvC+8UloV57hSYb0TFN4e360J8H K3cknUqonu91CZKEFJp2+z4xGt3d/aUUq5D7epAqVv4Pya68YFMDAAA= Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 14:52:46 -0000 --Apple-Mail=_8189ED43-909A-4F01-B2CD-98180A80594C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Good point. I agree. Jari --Apple-Mail=_8189ED43-909A-4F01-B2CD-98180A80594C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMvDCCBfIw ggPaoAMCAQICEH4FpBDRFc+VBCx+mWtm5bAwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE3MTIxNTEyMzI1MloXDTIwMTIxNTEyMzI1MVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzAR BgNVBAMMCkphcmkgQXJra28xJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJra29AZXJpY3Nzb24uY29t MRAwDgYDVQQFEwdMTUZKQUFSMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApfp0Or2a mZpqHenqngBbX/HZwC5HOI3cQGLGsKZr+OdpVl6Z8KoNk0ZRqpGMfsdZ78DG8VWdz3h6q5zEciEW tPeIhZ7rZfYXuiVtQbo6EWeG9flzqy8TzZvoJ4x07HbSJD3SNk9ArSPu8VdShoaEO6/RkmL5CBlG bqP8oNJApAWcxZGZrCc+TTf20uXC9VXggbTOhS0vThUIKk4Vrq89oLQEzgiz43RQg9KlSS8lPEoD rNhb5uZEAm4/iI+ZQX5PnhWxTNyalGz92Gj8Wf/XVH+uxRqyRiWZ0RZYTx4sxnaIGM79s8/KlzeN difwj1jbLHFgdOcvah/OHOpDMDS8ZwIDAQABo4IBvTCCAbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgG CCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRp dmlkdWFsY2F2My5jZXIwIgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBR4gHkmRNOtf0OskjVPOX1ScEdVozAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj 2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAJJUvEJM2TB80V1XcgeiNK/Q ePVqVJA92ncBVsfeBqeu3IF4PMBSAaDso8XI98Dy3U3p8PKlz9KL+ap7F+tQNAGv0o2Ht5IytJW8 QtZ1pca1mzu1/hvEDH+biNd4lMdJ1K4w98upbMQ/GlzeaE6RfKhbn3BlNxbnMrCBWbA/CEuF4RGz muydkbLCoxqfyrMn83A0ZZ67yq9+5OYezJqNTMbDgH4QE7+4JVsU8OujPoYLv60hc73J0w4SV+tX oM1EnuWYu+epqlb4AhmQxQf8P79g1aB3vumEw+tAI7bHlVmdJLWHYCEtphrjPiam2wT8oc8y5gdA j6yryaV2luKQCjGoSK9wVVG0fCzym91jWgWPGZs6RhFRRy49cJNaE3GS6QSe1CBwCqpsF4TqdO6U LGHypRbeRz3pJ7hORACETs/nvyPYHeTBzdTiVWMCoWHoYNd9gSTw2utA/VGabesrlDPcTqPRv4HT VP8I/TtrhnrcG3b85rUBFDzWMF8L1wtXqBXQYdYUV7sFCAxZnNl17mxBxei/pNemd67utP5UswMW QmpRfUFbTAueKHLX3hIVchYinp1yFWTNag5zAam4zxZ6PCG9JlLGxzeTHUwSvWnp4srsQas7RqnJ teI7NqYYkwfYDI5c6yawccdPmK8LOdt0ZED2c69rS3z6hARwORInMIIGwjCCBKqgAwIBAgIQU7h+ g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0G A1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2 NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAA uFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh 7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrAS F8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxA EgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLE PXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqH MRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5 r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0Y Gaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL /zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGj ggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50 ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwt My50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYw FAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwg Pdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEL BQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJ nuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNg vgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1R uRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst 821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkm agp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4ar MUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNr ZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9 hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5 j0Qpj5aQMYICvTCCArkCAQEwWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEH4FpBDRFc+VBCx+mWtm5bAwCQYF Kw4DAhoFAKCCATcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgx MDI1MTQ1MjIzWjAjBgkqhkiG9w0BCQQxFgQUx1Iuvk+eyUS1aSj92maGPxDYfuMwagYJKwYBBAGC NxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEH4FpBDRFc+VBCx+mWtm5bAwbAYLKoZIhvcNAQkQAgsx XaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MwIQfgWkENEVz5UELH6Za2blsDANBgkqhkiG9w0BAQEFAASCAQAU 7mgDXXOBzU8bDS0RyngBB1xE+j4s2mdOO07Fcy+nbzZnxDW/xkR3LzPusmg+EIL3PdCU72qhl+Vt 3CZo7oK0amNXbTrY+rcdDNAT0uRCNlgmngv0h8BcrTfaJbGiB/yfdxUqtIiefmIBXwpGBLN5XSvd GccTm9duJqUNZycd8YRv4Ax/tkGEGjkJmkZCyUNoNzGMXi3tUq9joyn+izkiGWdntKAIPIZnH+jX OgU5qwo1949u2tPpp35WEj0lB+pLL5EznrAGyEKdo+KxrG6EJ0HR6hCfAqspPe4aIR8CcPoJeMZT GVN2YjN9gI98T1ylFnPFRW6w4tciRuhiUkWgAAAAAAAA --Apple-Mail=_8189ED43-909A-4F01-B2CD-98180A80594C-- From nobody Fri Oct 26 02:44:03 2018 Return-Path: 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 CBB561252B7 for ; Fri, 26 Oct 2018 02:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 VZ-sG246hQMX for ; Fri, 26 Oct 2018 02:43:58 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999CD12F1A2 for ; Fri, 26 Oct 2018 02:43:58 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gFyep-0007ao-ST for architecture-discuss@ietf.org; Fri, 26 Oct 2018 11:43:56 +0200 To: architecture-discuss@ietf.org References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <2076480643.29453.1540438905630@appsuite.open-xchange.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <44c4f00c-246c-857e-037b-6a9be12aae92@digitaldissidents.org> Date: Fri, 26 Oct 2018 11:43:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2076480643.29453.1540438905630@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d9e86a85729c02611f348d7c163f195f Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 09:44:02 -0000 Hi all, Thanks a lot for this document and the discussion. A lot of economic drivers and examples are mentioned on the lists as well as in the draft, such as for instance: Consolidation is driven by economic factors relating to scale and ability to reach a large market over the Internet. In general, an efficient market such as the Internet tends to enable winners to take large market shares. Whereas there are also theories around that claim that the distributed architecture of the Internet would lead to a perfect market which would guarantee competition. It would be great if the authors would engage a bit more with economic theory (and or political economy literature). For instance, there are also a lot of costs involved with centralization. And why does email federate and social media don't? While reading your draft I regularly asked myself: is this a description, an explanation, or a conversation starter? I hope your draft can be more clear about which parts describe the current state of affairs, and which part explain it. Some other text based notes: The usage of powerful here is not quite clear to me. Does it mean stable, versatile, or something else? Paradoxically, if the underlying network is sufficiently powerful, the applications on top can evolve without similar pressures for interoperability, leading to the closed but highly valuable services discussed above. We call this the Permissionless Completeness Problem. Here you discuss the network-effect of email services. To what extend is this technical? And t what extend is this limited to email services? For instance, some technical issues have historically not been easy to solve, such as e-mail spam, which has lead to reliance on non- technical solutions. Today, it is becoming increasingly difficult to run your own mail services, essentially forcing many organisations and individuals to employ larger providers. The issues relate directly to size of entities; no one can afford to disconnect from the largest providers. But as a small entity, there is little leverage to convince peer entities or various supporting white/ blacklist entities to deal with you properly. Here you describe that more data = better, whereas several pieces of research have shown that it is not the amount of data, but the accuracy and relevance of it. And these do not necessarily increase with more data. Many Internet services are based on gathering data about users, and using that data for, for instance, targeted advertisements. More data from more users makes it possible to run a service more accurately or with better results; here again scale brings advantages. Here a link to Geoff Huston's semial blog is probably in order http://www.circleid.com/posts/20170311_the_internet_gilded_age/ Another trend is that more and more content is becoming available locally, from a content delivery or provider function directly on your own ISP's network. We predict that eventually most content will be delivered this way, reducing the role that global IP connections across the Internet play. By some metrics this has already happened; what practical - positive or negative - impacts might this have on the Internet technology? Here you argue that bigger entities can better a innovating and using more recent technology, but is this really true? I thought smaller organization could actually move faster. There are also security tradeoffs. Large entities are generally better equipped to move to more recent and more secure technology. For instance, the Domain Name System (DNS) shows signs of ageing but due to the legacy of deployed systems, has changed very slowly. Newer technology developed at the IETF enables DNS queries to be performed confidentially, but its deployment is happening mostly in browsers that use global DNS resolver services, such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and better security for end users. Here you describe that the world changes, and that therefore the Internet architecture should adapt. But the relation is also the other way around! The architecture is facilitating oligopolies: If the world changes, the Internet and its technology/architecture may have to match those changes. These were just some first thoughts, but am looking forward to following the discussion and reading it again! Best, Niels On 10/25/2018 05:41 AM, Vittorio Bertola wrote: >> Il 24 ottobre 2018 alle 12.21 Dan York ha scritto: >> >> FYI, Jari Arkko published a new draft yesterday on behalf of several >> IAB members with the title "Considerations on Internet Consolidation >> and the Internet Architecture”: > Just a couple of days ago on the HRPC list I was saying that we should > write a draft entitled "Centralization and consolidation are an attack", > so it looks like the IAB read in our minds :-) > > I find the draft right on spot and well thought out. It mentions all the > situations that I find more troubling, from email to DNS-over-HTTPS > going through social networks (I would have added a couple of lines on > instant messaging as well, as it was the intermediate > consolidation/walled-garden-construction step between email and social > networks, and it's one of the best examples of how the lack of > federation led to cumbersome user experiences). > > I would perhaps add a consideration on another problem: the more the > Internet's services get consolidated into the hands of a few companies, > often concentrated in very few parts of the world, the more this creates > tensions around cultural diversity (for example, in standards on which > online content/behaviour is acceptable and how to deal with the > unacceptable ones) and around national sovereignty, which promote > negative reactions leaning towards fragmentation and the rejection of > the permissionless innovation and multistakeholder management model. > > As for the remediation, though in the end some situations (as we saw > with the GDPR) may only be addressed by the dreaded last resort of > regulation, I think that before releasing new protocols the IETF should > pay more attention to their potential centralizing effects - perhaps a > specific "centralization considerations" section could be added when > appropriate. > > One could also think whether the IETF should actually be proactive in > promoting protocol development work aimed at "opening up" fields that > otherwise will only evolve towards the usual set of walled gardens: for > example, I am currently also working on online identity management > (distributed and federated single sign-on, data flow and consent > management etc) which, unless appropriate standards are created and > promoted, is going to be the next instant-messaging-like mess of > non-interoperable services - and identity is nowadays the fundamental > layer for pretty much everything else. > > It would be useful to understand what the next steps for this draft > could be and how can one contribute effectively. > > Regards,  > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Fri Oct 26 23:22:09 2018 Return-Path: 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 B238A130E01 for ; Fri, 26 Oct 2018 23:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 m-1CWJQ4Widr for ; Fri, 26 Oct 2018 23:22:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id A7E62130DD5 for ; Fri, 26 Oct 2018 23:22:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BF0C66020B; Sat, 27 Oct 2018 09:22:04 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sD1PlWRMO7M; Sat, 27 Oct 2018 09:22:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 125406601A0; Sat, 27 Oct 2018 09:22:03 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> Date: Sat, 27 Oct 2018 09:22:01 +0300 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 06:22:08 -0000 > Aka: "Think inside the box" wrt to IETF's scope of standards track > interoperability. Lets not have us convert everything that needs to > interoperate inside a box into protocols that look like they could be > happening on an outside wire just to be able to become Internet > Standards. Yes, agreed. Jari From nobody Sat Oct 27 12:24:21 2018 Return-Path: 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 8170212D4E7 for ; Sat, 27 Oct 2018 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 fTKn83QScRwa for ; Sat, 27 Oct 2018 12:24:18 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441BA127133 for ; Sat, 27 Oct 2018 12:24:18 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id 30-v6so1952769plb.10 for ; Sat, 27 Oct 2018 12:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=08Qrm64utw6kokmhlPmu23CauVPqTRDwAmpnPn/EI9s=; b=OsOQt6LJfCKZ7FjqFS0ArAs6S8oLCA0yrJQ7sEsgp2y+P3L/bvl32O6DM6sDXuR+80 Uc0hIH5M6PoIKoXwPNpDcxADcK2NWyHAAnR8PWdstPU1GzVJ01t6x4WOBEm/ehTykOuy 55km57OVUiPg2pjE8AjiU2GLxR+SHhsS82xSPXGkkbS1qRGKa5iqCULXEdE4OkXSp+8t nR/2trJFgMrD7B/Uj2PkcMXWr1E7ffHom4YYkctQkF/fRaKBgQhiqBk2yE/ohd/iMjZh vwVty8DtErh30bWpLeI1ZDN0qrd64jEJXp3kE4M2hSD7R23BmTQmtFAomJfERaI9jW2/ UYcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=08Qrm64utw6kokmhlPmu23CauVPqTRDwAmpnPn/EI9s=; b=ScpLl41wla1ILOi5jBQSkZRXhZyoZkBhLvZHHmczmI+sWwjmEnYZfmjkZ7kKIIVRkT b+os04pcc6hnwYOolXfjLYzFGd8wMd8IKLpMXF1NH/kMQeCPPDf8h3KEBYy5YoQ6BbRO PzIhKbSPev57ere/DdVl6C3fFrgG57x+mZdNZD0Oq4IvaOzdId9sVICNAOIOg2sUNQk/ AJkqeBMIu++84f07SLrDXP5hNaPA+Z8Y6sQzMk1+yYp35nLixu3Ynmpv3HlFxoP/a/cz /VTMopLrjZR5UcAV8tD826kzYuxlkimJwWDwO/vyjC9AOQIweOHdt+Fn6tXsfVhmXSqn 3+kg== X-Gm-Message-State: AGRZ1gIMmqvPr9eNHvqbMobjXT+6F6pIpBcY4MMNwo5bhxU1Mi2X7FSh e1kkbM52D8zm7badba7hO5gj1HZz X-Google-Smtp-Source: AJdET5cFZxV7hsyrKDvuq7+3xDTN+c48KaJV50BL8v2wqGjlNcU4bw2HCfqKQMrzhnOdeiHXkLwfDA== X-Received: by 2002:a17:902:6bc9:: with SMTP id m9-v6mr8352660plt.106.1540668257144; Sat, 27 Oct 2018 12:24:17 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id m25-v6sm7508502pgb.67.2018.10.27.12.24.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 12:24:15 -0700 (PDT) To: Jari Arkko , Toerless Eckert Cc: architecture-discuss@ietf.org References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> From: Brian E Carpenter Message-ID: Date: Sun, 28 Oct 2018 08:24:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 19:24:20 -0000 On 2018-10-27 19:22, Jari Arkko wrote: > >> Aka: "Think inside the box" wrt to IETF's scope of standards track >> interoperability. Lets not have us convert everything that needs to >> interoperate inside a box into protocols that look like they could be >> happening on an outside wire just to be able to become Internet >> Standards. > > Yes, agreed. Yes, and this resonates with the analysis in draft-carpenter-limited-domains-04, especially https://tools.ietf.org/html/draft-carpenter-limited-domains-04#section-6 and https://tools.ietf.org/html/draft-carpenter-limited-domains-04#section-7 Our conclusion is that we need to define the box properly and securely. Brian From thomas.beaver.ietf@gmail.com Sun Oct 28 13:35:10 2018 Return-Path: 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 BCA3C1277CC for ; Sun, 28 Oct 2018 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pNzinkrF5Yco for ; Sun, 28 Oct 2018 13:35:07 -0700 (PDT) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170FA127332 for ; Sun, 28 Oct 2018 13:35:07 -0700 (PDT) Received: by mail-it1-x142.google.com with SMTP id e81-v6so8754954itc.1 for ; Sun, 28 Oct 2018 13:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ZQedrQGOhbv+DeV3i7syL5MSQW286BRr9krqLXavJz4=; b=JX2DA2o2CQanvUl/WQgKUTf4geDfTcQUr9GWQNJMfQ7PWjL0lNYO8FNLx1JPa+8n4z xrq58PEvFItgrppRdNJhDci0xLzCfQxMfqFGip+mytukW0u5OC10OPA3pm/S4sJuOLuG DN+wcBF41qZ6ZzWrj0mGunae/G1UKqDkJQOsRysDbUKWqCtgjORhX7xPqln0Cqp6TWEp M1OGOJLnluDPlywFzv/YNgfvFHq1OUewWDJrGSoqBWQRtjPdBBOOdRpWrG05JvMKpZ1S nejb0nOWv0NXzwsrssPgiimlu5I2KfqJ9vIp7ySS5PqTVNyT6lBcDjHQoPoh6esISKAF cQ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZQedrQGOhbv+DeV3i7syL5MSQW286BRr9krqLXavJz4=; b=XatJJF1d3prHfPKGZRnqj794iqaB8AZ/+eMDvNAS3KI7FGRDwYXDOuG6967rBYZHHZ sJTKHdC19eDVnBpPyU+Vf7VVlHWKapyVdhvRyDeqq1XPFhy9Uzd/nhrERvpv30hWHDvg B8mlV0siVWmzRncP0abvTXpGsh6CT3YNPnvoxuB4waAxBmXFdMNTJuFs3hrpUOX1b2Zg rB71zvHd8HuMLMDn0xlSham6X7wlKgrfmhOoBR8/AcM95eDRTRUeyJVBeil+ra+IjRVN 06UdzNbEU8Ffy2lCKguECrTnmXhOVejbw2zHktZhBddXu1W+ZUVq4LHQ/VMfxST7Tzap BpBQ== X-Gm-Message-State: AGRZ1gJzjBrx/TMv63+T0tuSbRoSTqIlc+KE3ndPD45xIzgQ2+xK7JAx qV5QhUcmRAa32SLTguA/Yo9p97My X-Google-Smtp-Source: AJdET5eQSRGxyo07RJSRw0Qcax8AxbdEnmZJm8K9GkYeSFLWwJ4d8EHrDgH0IKPLLJCt1jpYKAFAug== X-Received: by 2002:a05:660c:3c9:: with SMTP id c9mr8141396itl.130.1540758905982; Sun, 28 Oct 2018 13:35:05 -0700 (PDT) Received: from [172.20.0.222] ([70.126.0.198]) by smtp.gmail.com with ESMTPSA id h123-v6sm5402810ith.21.2018.10.28.13.35.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Oct 2018 13:35:05 -0700 (PDT) To: architecture-discuss@ietf.org References: <55E43924-FFAE-473E-A43C-90DB7C33321C@isoc.org> <2076480643.29453.1540438905630@appsuite.open-xchange.com> From: Thomas Beaver Message-ID: Date: Sun, 28 Oct 2018 16:35:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2076480643.29453.1540438905630@appsuite.open-xchange.com> Content-Type: multipart/alternative; boundary="------------3740570FE835A0E1061AEB53" Content-Language: en-US Archived-At: Subject: Re: [arch-d] New I-D: Considerations on Internet Consolidation and the Internet Architecture 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 20:36:10 -0000 This is a multi-part message in MIME format. --------------3740570FE835A0E1061AEB53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Niels, Just tossing in my 2c about one particular thing that you questioned. "The usage of powerful here is not quite clear to me. Does it mean stable, versatile, or something else? Paradoxically, if the underlying network is sufficiently powerful, the applications on top can evolve without similar pressures for interoperability, leading to the closed but highly valuable services discussed above. We call this the Permissionless Completeness Problem." I agree that it should be clarified. However, my interpretation of "powerful" in this paragraph is based loosely off the various metrics that have been covered in other protocols such as EIGRP. More specifically, "Bandwidth, Reliability, Load, and Delay". These metrics have been around for a long time but have rarely been used. New developments such as Segment Routing are attempting to give the applications more control over what it requires such as low latency or high bandwidth. Segment Routing deployed in an operators network with various link types will allow applications to take the best path for their use case scenario, in turn enhancing the customer experience. In this situation, Segment Routing would facilitate a "powerful" network. https://tools.ietf.org/html/rfc8402 Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Regards, Thomas Beaver On 10/26/2018 5:43 AM, Niels ten Oever wrote: > Hi all, > > Thanks a lot for this document and the discussion. A lot of economic > drivers and examples are mentioned on the lists as well as in the draft, > such as for instance: > > Consolidation is driven by economic factors relating to scale and > ability to reach a large market over the Internet. In general, an > efficient market such as the Internet tends to enable winners to take > large market shares. > > Whereas there are also theories around that claim that the distributed > architecture of the Internet would lead to a perfect market which would > guarantee competition. It would be great if the authors would engage a > bit more with economic theory (and or political economy literature). For > instance, there are also a lot of costs involved with centralization. > And why does email federate and social media don't? > > While reading your draft I regularly asked myself: is this a > description, an explanation, or a conversation starter? I hope your > draft can be more clear about which parts describe the current state of > affairs, and which part explain it. > > Some other text based notes: > > The usage of powerful here is not quite clear to me. Does it mean > stable, versatile, or something else? > > Paradoxically, if the underlying network is sufficiently powerful, > the applications on top can evolve without similar pressures for > interoperability, leading to the closed but highly valuable services > discussed above. We call this the Permissionless Completeness > Problem. > > Here you discuss the network-effect of email services. To what extend is > this technical? And t what extend is this limited to email services? > > For instance, some technical issues have historically not been easy > to solve, such as e-mail spam, which has lead to reliance on non- > technical solutions. Today, it is becoming increasingly difficult to > run your own mail services, essentially forcing many organisations > and individuals to employ larger providers. The issues relate > directly to size of entities; no one can afford to disconnect from > the largest providers. But as a small entity, there is little > leverage to convince peer entities or various supporting white/ > blacklist entities to deal with you properly. > > Here you describe that more data = better, whereas several pieces of > research have shown that it is not the amount of data, but the accuracy > and relevance of it. And these do not necessarily increase with more data. > > Many Internet services are based on gathering data about users, and > using that data for, for instance, targeted advertisements. More > data from more users makes it possible to run a service more > accurately or with better results; here again scale brings > advantages. > > Here a link to Geoff Huston's semial blog is probably in order > http://www.circleid.com/posts/20170311_the_internet_gilded_age/ > > Another trend is that more and more content is becoming available > locally, from a content delivery or provider function directly on > your own ISP's network. We predict that eventually most content will > be delivered this way, reducing the role that global IP connections > across the Internet play. By some metrics this has already happened; > what practical - positive or negative - impacts might this have on > the Internet technology? > > Here you argue that bigger entities can better a innovating and using > more recent technology, but is this really true? I thought smaller > organization could actually move faster. > > There are also security tradeoffs. Large entities are generally > better equipped to move to more recent and more secure technology. > For instance, the Domain Name System (DNS) shows signs of ageing but > due to the legacy of deployed systems, has changed very slowly. > Newer technology developed at the IETF enables DNS queries to be > performed confidentially, but its deployment is happening mostly in > browsers that use global DNS resolver services, such as Cloudflare's > 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and > better security for end users. > > Here you describe that the world changes, and that therefore the > Internet architecture should adapt. But the relation is also the other > way around! The architecture is facilitating oligopolies: > > If the world changes, the Internet > and its technology/architecture may have to match those changes. > > These were just some first thoughts, but am looking forward to following > the discussion and reading it again! > > Best, > > Niels > > > On 10/25/2018 05:41 AM, Vittorio Bertola wrote: > >> Il 24 ottobre 2018 alle 12.21 Dan York ha scritto: > >> > >> FYI, Jari Arkko published a new draft yesterday on behalf of several > >> IAB members with the title "Considerations on Internet Consolidation > >> and the Internet Architecture”: > > Just a couple of days ago on the HRPC list I was saying that we should > > write a draft entitled "Centralization and consolidation are an attack", > > so it looks like the IAB read in our minds :-) > > > > I find the draft right on spot and well thought out. It mentions all the > > situations that I find more troubling, from email to DNS-over-HTTPS > > going through social networks (I would have added a couple of lines on > > instant messaging as well, as it was the intermediate > > consolidation/walled-garden-construction step between email and social > > networks, and it's one of the best examples of how the lack of > > federation led to cumbersome user experiences). > > > > I would perhaps add a consideration on another problem: the more the > > Internet's services get consolidated into the hands of a few companies, > > often concentrated in very few parts of the world, the more this creates > > tensions around cultural diversity (for example, in standards on which > > online content/behaviour is acceptable and how to deal with the > > unacceptable ones) and around national sovereignty, which promote > > negative reactions leaning towards fragmentation and the rejection of > > the permissionless innovation and multistakeholder management model. > > > > As for the remediation, though in the end some situations (as we saw > > with the GDPR) may only be addressed by the dreaded last resort of > > regulation, I think that before releasing new protocols the IETF should > > pay more attention to their potential centralizing effects - perhaps a > > specific "centralization considerations" section could be added when > > appropriate. > > > > One could also think whether the IETF should actually be proactive in > > promoting protocol development work aimed at "opening up" fields that > > otherwise will only evolve towards the usual set of walled gardens: for > > example, I am currently also working on online identity management > > (distributed and federated single sign-on, data flow and consent > > management etc) which, unless appropriate standards are created and > > promoted, is going to be the next instant-messaging-like mess of > > non-interoperable services - and identity is nowadays the fundamental > > layer for pretty much everything else. > > > > It would be useful to understand what the next steps for this draft > > could be and how can one contribute effectively. > > > > Regards, > > > > -- > > > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > > vittorio.bertola at open-xchange.com > > Office @ Via Treviso 12, 10144 Torino, Italy > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss at ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > Niels ten Oever > Researcher and PhD Candidate > Datactive Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > --------------3740570FE835A0E1061AEB53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Niels,

Just tossing in my 2c about one particular thing that you questioned.

  "The usage of powerful here is not quite clear to me. Does it mean
  stable, versatile, or something else?
  
     Paradoxically, if the underlying network is sufficiently powerful,
     the applications on top can evolve without similar pressures for
     interoperability, leading to the closed but highly valuable services
     discussed above.  We call this the Permissionless Completeness
     Problem."

I agree that it should be clarified. However, my interpretation of 
"powerful" in this paragraph is based loosely off the various metrics 
that have been covered in other protocols such as EIGRP. More 
specifically, "Bandwidth, Reliability, Load, and Delay". These 
metrics have been around for a long time but have rarely been used. 

New developments such as Segment Routing are attempting to give 
the applications more control over what it requires such as low 
latency or high bandwidth. Segment Routing deployed in an operators 
network with various link types will allow applications to take the 
best path for their use case scenario, in turn enhancing the customer 
experience. 

In this situation, Segment Routing would facilitate a "powerful" network.


https://tools.ietf.org/html/rfc8402


   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   "segments".  A segment can represent any instruction, topological or
   service based.  A segment can have a semantic local to an SR node or
   global within an SR domain.  SR provides a mechanism that allows a
   flow to be restricted to a specific topological path, while
   maintaining per-flow state only at the ingress node(s) to the SR
   domain.

   SR can be directly applied to the MPLS architecture with no change to
   the forwarding plane.  A segment is encoded as an MPLS label.  An
   ordered list of segments is encoded as a stack of labels.  The
   segment to process is on the top of the stack.  Upon completion of a
   segment, the related label is popped from the stack.

   SR can be applied to the IPv6 architecture, with a new type of
   routing header.  A segment is encoded as an IPv6 address.  An ordered
   list of segments is encoded as an ordered list of IPv6 addresses in
   the routing header.  The active segment is indicated by the
   Destination Address (DA) of the packet.  The next active segment is
   indicated by a pointer in the new routing header.


Regards,

Thomas Beaver
On 10/26/2018 5:43 AM, Niels ten Oever wrote:
Hi all,

Thanks a lot for this document and the discussion. A lot of economic
drivers and examples are mentioned on the lists as well as in the draft,
such as for instance:

   Consolidation is driven by economic factors relating to scale and
   ability to reach a large market over the Internet.  In general, an
   efficient market such as the Internet tends to enable winners to take
   large market shares.

Whereas there are also theories around that claim that the distributed
architecture of the Internet would lead to a perfect market which would
guarantee competition. It would be great if the authors would engage a
bit more with economic theory (and or political economy literature). For
instance, there are also a lot of costs involved with centralization.
And why does email federate and social media don't?

While reading your draft I regularly asked myself: is this a
description, an explanation, or a conversation starter? I hope your
draft can be more clear about which parts describe the current state of
affairs, and which part explain it.

Some other text based notes:

The usage of powerful here is not quite clear to me. Does it mean
stable, versatile, or something else?

   Paradoxically, if the underlying network is sufficiently powerful,
   the applications on top can evolve without similar pressures for
   interoperability, leading to the closed but highly valuable services
   discussed above.  We call this the Permissionless Completeness
   Problem.

Here you discuss the network-effect of email services. To what extend is
this technical? And t what extend is this limited to email services?

   For instance, some technical issues have historically not been easy
   to solve, such as e-mail spam, which has lead to reliance on non-
   technical solutions.  Today, it is becoming increasingly difficult to
   run your own mail services, essentially forcing many organisations
   and individuals to employ larger providers.  The issues relate
   directly to size of entities; no one can afford to disconnect from
   the largest providers.  But as a small entity, there is little
   leverage to convince peer entities or various supporting white/
   blacklist entities to deal with you properly.

Here you describe that more data = better, whereas several pieces of
research have shown that it is not the amount of data, but the accuracy
and relevance of it. And these do not necessarily increase with more data.

   Many Internet services are based on gathering data about users, and
   using that data for, for instance, targeted advertisements.  More
   data from more users makes it possible to run a service more
   accurately or with better results; here again scale brings
   advantages.

Here a link to Geoff Huston's semial blog is probably in order
http://www.circleid.com/posts/20170311_the_internet_gilded_age/

   Another trend is that more and more content is becoming available
   locally, from a content delivery or provider function directly on
   your own ISP's network.  We predict that eventually most content will
   be delivered this way, reducing the role that global IP connections
   across the Internet play.  By some metrics this has already happened;
   what practical - positive or negative - impacts might this have on
   the Internet technology?

Here you argue that bigger entities can better a innovating and using
more recent technology, but is this really true? I thought smaller
organization could actually move faster.

   There are also security tradeoffs.  Large entities are generally
   better equipped to move to more recent and more secure technology.
   For instance, the Domain Name System (DNS) shows signs of ageing but
   due to the legacy of deployed systems, has changed very slowly.
   Newer technology developed at the IETF enables DNS queries to be
   performed confidentially, but its deployment is happening mostly in
   browsers that use global DNS resolver services, such as Cloudflare's
   1.1.1.1 or Google's 8.8.8.8.  This results in faster evolution and
   better security for end users.

Here you describe that the world changes, and that therefore the
Internet architecture should adapt. But the relation is also the other
way around! The architecture is facilitating oligopolies:

   If the world changes, the Internet
   and its technology/architecture may have to match those changes.

These were just some first thoughts, but am looking forward to following
the discussion and reading it again!

Best,

Niels


On 10/25/2018 05:41 AM, Vittorio Bertola wrote:
>> Il 24 ottobre 2018 alle 12.21 Dan York <york at isoc.org> ha scritto:
>>
>> FYI, Jari Arkko published a new draft yesterday on behalf of several
>> IAB members with the title "Considerations on Internet Consolidation
>> and the Internet Architecture”: 
> Just a couple of days ago on the HRPC list I was saying that we should
> write a draft entitled "Centralization and consolidation are an attack",
> so it looks like the IAB read in our minds :-)
> 
> I find the draft right on spot and well thought out. It mentions all the
> situations that I find more troubling, from email to DNS-over-HTTPS
> going through social networks (I would have added a couple of lines on
> instant messaging as well, as it was the intermediate
> consolidation/walled-garden-construction step between email and social
> networks, and it's one of the best examples of how the lack of
> federation led to cumbersome user experiences).
> 
> I would perhaps add a consideration on another problem: the more the
> Internet's services get consolidated into the hands of a few companies,
> often concentrated in very few parts of the world, the more this creates
> tensions around cultural diversity (for example, in standards on which
> online content/behaviour is acceptable and how to deal with the
> unacceptable ones) and around national sovereignty, which promote
> negative reactions leaning towards fragmentation and the rejection of
> the permissionless innovation and multistakeholder management model.
> 
> As for the remediation, though in the end some situations (as we saw
> with the GDPR) may only be addressed by the dreaded last resort of
> regulation, I think that before releasing new protocols the IETF should
> pay more attention to their potential centralizing effects - perhaps a
> specific "centralization considerations" section could be added when
> appropriate.
> 
> One could also think whether the IETF should actually be proactive in
> promoting protocol development work aimed at "opening up" fields that
> otherwise will only evolve towards the usual set of walled gardens: for
> example, I am currently also working on online identity management
> (distributed and federated single sign-on, data flow and consent
> management etc) which, unless appropriate standards are created and
> promoted, is going to be the next instant-messaging-like mess of
> non-interoperable services - and identity is nowadays the fundamental
> layer for pretty much everything else.
> 
> It would be useful to understand what the next steps for this draft
> could be and how can one contribute effectively.
> 
> Regards, 
> 
> -- 
> 
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola at open-xchange.com <mailto:vittorio.bertola at open-xchange.com> 
> Office @ Via Treviso 12, 10144 Torino, Italy
> 
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3
--------------3740570FE835A0E1061AEB53-- From nobody Mon Oct 29 07:28:20 2018 Return-Path: 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 BD994130E29 for ; Mon, 29 Oct 2018 07:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 qp_v0lnnmXZU for ; Mon, 29 Oct 2018 07:28:17 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 EFD89130D7A for ; Mon, 29 Oct 2018 07:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ubR+1BOkV4OMWza5TFp0KUo30gYRxCVjodImqT4YpLk=; b=G2ui8eckNKOEYu7jM/LY0ZUud 7352rV99ZBfdW6qi0MuZD3yGpupQyCEUbhu1I1KXdUQHofLS84fKYg8NTSrkHDMk3JMooCPyPQE/7 Aom94EBHZjIffK05K7hNCpGv3uiZszdRxHIXDOBwsN7t25Y5l6GqouuZHmmljF+s2KF52KKUBXj+l nJLxU9Z7YAioG52v7lnq0pT9zEKmyFXTRtDGyUfaVY0a0Bf1o6gh4ZPYCReThhX3n5v+t0ofc5a9k OYcxeZHDT0aU4sWn9A7gd2r8dAeHmZp4YdR0t/Ck6PCC80rVRpo+kR488B92IhkDB1GxiugqhVGSp AnETil2eA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54351 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gH8Wb-002g5y-6n; Mon, 29 Oct 2018 10:28:13 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> Date: Mon, 29 Oct 2018 07:28:12 -0700 Cc: Toerless Eckert , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 14:28:19 -0000 > On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >=20 >=20 >> Aka: "Think inside the box" wrt to IETF's scope of standards track >> interoperability. Lets not have us convert everything that needs to >> interoperate inside a box into protocols that look like they could be >> happening on an outside wire just to be able to become Internet >> Standards. >=20 > Yes, agreed. I=E2=80=99m not sure I understand. Behaviors that are =E2=80=9Cinside a box=E2=80=9D don=E2=80=99t interact = with anything and should be up to the implementer. The interface is what needs to be designed - based on externally visible = behavior, whether on-host or off-host. We need to get beyond this incorrect notion of =E2=80=9Con the wire=E2=80=9D= as defining anything other than message syntax; semantics and behavior = are never defined merely by looking at messages. Joe From nobody Mon Oct 29 07:55:03 2018 Return-Path: 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 5F796130F56 for ; Mon, 29 Oct 2018 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 fIw9xxT5X_HK for ; Mon, 29 Oct 2018 07:54:58 -0700 (PDT) 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 4011712F18C for ; Mon, 29 Oct 2018 07:54:57 -0700 (PDT) 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 6431A548152; Mon, 29 Oct 2018 15:54:53 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 52AF9440210; Mon, 29 Oct 2018 15:54:53 +0100 (CET) Date: Mon, 29 Oct 2018 15:54:53 +0100 From: Toerless Eckert To: Joe Touch Cc: Jari Arkko , architecture-discuss@ietf.org Message-ID: <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 14:55:03 -0000 Joe: What is external ? Two VM/container inside a PC each one representing a router ? How about i want to give up the silly notion that i have to pass some virtual-link represenations of packets but instead pass pointers to cross-VM shared memory ? I want to be able to sell these VMs as i sell physical devices and enable customers to interoperate them inside a physical box. RTT=0, loss=0, why would i need TCP between these VMs ? Interoperability is based on the unit of products we want to enable to be plugged together into a network. I think we need to look more into what markets we can better enable by looking more into software as those units. We're starting to do that IMHO more and more north/southbound with netconf/yang/PCE and the like to enable centralized controller SDN network evolution, but the closer we get to the software components that likely only need to interoperate in a single physcial box, the more we shy away and stifle modular, multi-vendor interoperable on-box software. Cheers Toerless On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: > > > > On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: > > > > > >> Aka: "Think inside the box" wrt to IETF's scope of standards track > >> interoperability. Lets not have us convert everything that needs to > >> interoperate inside a box into protocols that look like they could be > >> happening on an outside wire just to be able to become Internet > >> Standards. > > > > Yes, agreed. > > I???m not sure I understand. > > Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. > > The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. > > We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. > > Joe > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Oct 29 08:04:04 2018 Return-Path: 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 C3B3213105D for ; Mon, 29 Oct 2018 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=strayalpha.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 yZT3ta1HuaAD for ; Mon, 29 Oct 2018 08:03:46 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A8A0D13104A for ; Mon, 29 Oct 2018 08:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Jgxv8red5uMcuK9+O2UTjzJH+i1NlUue9xC/WyUivSA=; b=AiQ+rLjwj83jQOMCbyjkew1bl hIq7uoe3Pi9udfkBKQfrVZr4u9wDCi9jpRp4Jwn1Rz0/L5S/DYQ1issznr1rQF2Nm7Cbzfg2OiDGd neAT7SPLn4ClCEC7BLWLIyGJSjSno3BBzRoEWzwRUfrv1zPXBrNriG+PrO159ZgT60tFe4JkY1M0z /mWCG4bckIY/7UH/qVSrn60NCQrXw09eUVA/H0SSJzalSDfI45EQShAd4LsQCjWsdUMo2LK4Q6BHg NBeesJPmb2+RdJ9N0XfSHq84g9VgzFD0SStYXKY3OL1YKCSVpGpSPzPlBmIVYaf1ycmFGmbk02U9d pqTHsZJoQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56800 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gH94u-0035Bx-Ca; Mon, 29 Oct 2018 11:03:43 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16A404) In-Reply-To: <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> Date: Mon, 29 Oct 2018 08:03:39 -0700 Cc: Jari Arkko , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:03:53 -0000 > On Oct 29, 2018, at 7:54 AM, Toerless Eckert wrote: >=20 > Joe: >=20 > What is external ? Two VM/container inside a PC each one representing a ro= uter ? > How about i want to give up the silly notion that i have to pass some > virtual-link represenations of packets but instead pass pointers to > cross-VM shared memory ? I want to be able to sell these VMs as i > sell physical devices and enable customers to interoperate them inside > a physical box. RTT=3D0, loss=3D0, why would i need TCP between these > VMs ? If you are forcing that implementation, you don=E2=80=99t. It you admit that= the real power of virtualization is that those boxes can be anywhere, you d= o. What you really want is a two level spec in that case - one that defines the= inter operation based on info sharing or exchange, and one or more others t= hat explains how to do that sharing or transfer over a variety of mechanisms= . >=20 > Interoperability is based on the unit of products we want to enable to > be plugged together into a network. I think we need to look more into > what markets we can better enable by looking more into software as those > units. We're starting to do that IMHO more and more north/southbound > with netconf/yang/PCE and the like to enable centralized controller SDN > network evolution, but the closer we get to the software components that > likely only need to interoperate in a single physcial box, the more we shy= > away and stifle modular, multi-vendor interoperable on-box software. The more you assume is inside one box the less options the you give the impl= ementer. That isn=E2=80=99t networking anymore, and I agree that if that is your goal= , you don=E2=80=99t want to use network protocols. Joe >=20 > Cheers > Toerless >=20 >> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>=20 >>=20 >>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>>=20 >>>=20 >>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>> interoperability. Lets not have us convert everything that needs to >>>> interoperate inside a box into protocols that look like they could be >>>> happening on an outside wire just to be able to become Internet >>>> Standards. >>>=20 >>> Yes, agreed. >>=20 >> I???m not sure I understand. >>=20 >> Behaviors that are ???inside a box??? don???t interact with anything and s= hould be up to the implementer. >>=20 >> The interface is what needs to be designed - based on externally visible b= ehavior, whether on-host or off-host. >>=20 >> We need to get beyond this incorrect notion of ???on the wire??? as defin= ing anything other than message syntax; semantics and behavior are never def= ined merely by looking at messages. >>=20 >> Joe >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Oct 29 09:07:13 2018 Return-Path: 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 A2041130DE9 for ; Mon, 29 Oct 2018 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 uO9vugnAPbYn for ; Mon, 29 Oct 2018 09:07:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 B8419130DBE for ; Mon, 29 Oct 2018 09:07:07 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 05A30548145; Mon, 29 Oct 2018 17:07:03 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E9F1A440210; Mon, 29 Oct 2018 17:07:02 +0100 (CET) Date: Mon, 29 Oct 2018 17:07:02 +0100 From: Toerless Eckert To: Joe Touch Cc: architecture-discuss@ietf.org Message-ID: <20181029160702.szukudgin6hygeik@faui48f.informatik.uni-erlangen.de> References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 16:07:12 -0000 On Mon, Oct 29, 2018 at 08:03:39AM -0700, Joe Touch wrote: > > What is external ? Two VM/container inside a PC each one representing a router ? > > How about i want to give up the silly notion that i have to pass some > > virtual-link represenations of packets but instead pass pointers to > > cross-VM shared memory ? I want to be able to sell these VMs as i > > sell physical devices and enable customers to interoperate them inside > > a physical box. RTT=0, loss=0, why would i need TCP between these > > VMs ? > > If you are forcing that implementation, you don???t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do. I am not forcing anything, but this type of communication inside boxes will become more and more important and should considered to be in scope of interoperability scenarios for the IETF. Also consider your VMs L2s are RDMA/RoCE domains. Your subnets all just have shared memory, no message passing. All i am saying is that IETF shouldn't counter requests to standardize interoperating components with the historic notion of what those components must be (physcial boxes and wires/radio). > What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transfer over a variety of mechanisms. In this specific transport protocol example thats probably right as long there is only an end-to-end (not segmented) transport architecture. > > Interoperability is based on the unit of products we want to enable to > > be plugged together into a network. I think we need to look more into > > what markets we can better enable by looking more into software as those > > units. We're starting to do that IMHO more and more north/southbound > > with netconf/yang/PCE and the like to enable centralized controller SDN > > network evolution, but the closer we get to the software components that > > likely only need to interoperate in a single physcial box, the more we shy > > away and stifle modular, multi-vendor interoperable on-box software. > > The more you assume is inside one box the less options the you give the implementer. Indeed. Because i want to enable multi-vendor interoperating SW components on boxes for more agility and innovation. Because the market may want to buy software and whiteboxes. Sometimes its also just common sense from experience even if just a single vendor may implement the modules: It took IP Multicast in the IETF something like 10 years before it was permitted to talk about terms like MRIB/MFIB. And only because implementations that didn't come up with this internal modularity and software interfaces didn't work correctly. Aka: multiple arguments why this is beneficial/desirable. Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? Cheers Toerless > That isn???t networking anymore, and I agree that if that is your goal, > you don???t want to use network protocols. > Joe > > > > > Cheers > > Toerless > > > >> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: > >> > >> > >>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: > >>> > >>> > >>>> Aka: "Think inside the box" wrt to IETF's scope of standards track > >>>> interoperability. Lets not have us convert everything that needs to > >>>> interoperate inside a box into protocols that look like they could be > >>>> happening on an outside wire just to be able to become Internet > >>>> Standards. > >>> > >>> Yes, agreed. > >> > >> I???m not sure I understand. > >> > >> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. > >> > >> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. > >> > >> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. > >> > >> Joe > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Oct 29 09:37:10 2018 Return-Path: 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 E21981310A8 for ; Mon, 29 Oct 2018 09:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 uDY76hEp9Lmu for ; Mon, 29 Oct 2018 09:37:00 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D48A6131083 for ; Mon, 29 Oct 2018 09:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eC85M++XL2TyoDAmS2Tg7FqH4+K2nX05JCL5+MG0Vgc=; b=HvFtTYaEMck0NH02ajCfbGTrk XZRQHT/c1QajxanmVT8ucr0/bji+IegKkgjfWani8gXyOrFR9jHXtP2pl7AzW9GNK5/FBhqot+pw2 8fKAvlLBQYBTJAnB1cY0gQiy27Xos1VKUiSCSZRkEb90hgsLJG/Vqndzeeds4dtc/uvWaoasWz/gY f9sTAEqqsYHU4fJ7HY7nIRTiVXVdQ9Le5GyHS+KA4cvXTVaEQv5ejicwqGGRlcck+UxXDjj52c52M XxdYlbwB6yKTCB2gqJKuBWz1znZaJ54V2FKZ3/FPkNBEfTgrKbXWTtChoOo5eDJIIPCcz1Q8qrDOf m2xZ5cySA==; Received: from [172.58.23.200] (port=61702 helo=[IPv6:2607:fb90:5a8a:fa7f:4daa:95a4:f977:714]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHAX9-004CUN-PM; Mon, 29 Oct 2018 12:36:59 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16A404) In-Reply-To: <20181029160702.szukudgin6hygeik@faui48f.informatik.uni-erlangen.de> Date: Mon, 29 Oct 2018 09:36:54 -0700 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0049817A-10BB-45A1-88FE-E6887BD3920A@strayalpha.com> References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> <20181029160702.szukudgin6hygeik@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 16:37:09 -0000 > On Oct 29, 2018, at 9:07 AM, Toerless Eckert wrote: >=20 > On Mon, Oct 29, 2018 at 08:03:39AM -0700, Joe Touch wrote: >>> What is external ? Two VM/container inside a PC each one representing a r= outer ? >>> How about i want to give up the silly notion that i have to pass some >>> virtual-link represenations of packets but instead pass pointers to >>> cross-VM shared memory ? I want to be able to sell these VMs as i >>> sell physical devices and enable customers to interoperate them inside >>> a physical box. RTT=3D0, loss=3D0, why would i need TCP between these >>> VMs ? >>=20 >> If you are forcing that implementation, you don???t. It you admit that th= e real power of virtualization is that those boxes can be anywhere, you do. >=20 > I am not forcing anything, but this type of communication inside boxes > will become more and more important and should considered to be in scope > of interoperability scenarios for the IETF.=20 >=20 > Also consider your VMs L2s are RDMA/RoCE domains. Your subnets all > just have shared memory, no message passing.=20 >=20 > All i am saying is that IETF shouldn't counter requests to standardize > interoperating components with the historic notion of what those > components must be (physcial boxes and wires/radio). If you an define these in an OS-independent way, sure.=20 >=20 >> What you really want is a two level spec in that case - one that defines t= he inter operation based on info sharing or exchange, and one or more others= that explains how to do that sharing or transfer over a variety of mechanis= ms. >=20 > In this specific transport protocol example thats probably right as long > there is only an end-to-end (not segmented) transport architecture. >=20 >>> Interoperability is based on the unit of products we want to enable to >>> be plugged together into a network. I think we need to look more into >>> what markets we can better enable by looking more into software as those= >>> units. We're starting to do that IMHO more and more north/southbound >>> with netconf/yang/PCE and the like to enable centralized controller SDN >>> network evolution, but the closer we get to the software components that= >>> likely only need to interoperate in a single physcial box, the more we s= hy >>> away and stifle modular, multi-vendor interoperable on-box software. >>=20 >> The more you assume is inside one box the less options the you give the i= mplementer. >=20 > Indeed. Because i want to enable multi-vendor interoperating SW > components on boxes for more agility and innovation. Because the market > may want to buy software and whiteboxes. >=20 > Sometimes its also just common sense from experience even if just a > single vendor may implement the modules: It took IP Multicast in the IETF > something like 10 years before it was permitted to talk about terms > like MRIB/MFIB. And only because implementations that didn't come up > with this internal modularity and software interfaces didn't work=20 > correctly. >=20 > Aka: multiple arguments why this is beneficial/desirable. >=20 > Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? They are already in that track. I think that=E2=80=99s a mistake - they=E2=80= =99re experimental at best st this point.=20 Joe=20 >=20 > Cheers > Toerless >=20 >> That isn???t networking anymore, and I agree that if that is your goal, >> you don???t want to use network protocols. >=20 >=20 >> Joe >>=20 >>>=20 >>> Cheers >>> Toerless >>>=20 >>>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>>>=20 >>>>=20 >>>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote:= >>>>>=20 >>>>>=20 >>>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>>>> interoperability. Lets not have us convert everything that needs to >>>>>> interoperate inside a box into protocols that look like they could be= >>>>>> happening on an outside wire just to be able to become Internet >>>>>> Standards. >>>>>=20 >>>>> Yes, agreed. >>>>=20 >>>> I???m not sure I understand. >>>>=20 >>>> Behaviors that are ???inside a box??? don???t interact with anything an= d should be up to the implementer. >>>>=20 >>>> The interface is what needs to be designed - based on externally visibl= e behavior, whether on-host or off-host. >>>>=20 >>>> We need to get beyond this incorrect notion of ???on the wire??? as def= ining anything other than message syntax; semantics and behavior are never d= efined merely by looking at messages. >>>>=20 >>>> Joe >>>>=20 >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>=20 >>> --=20 >>> --- >>> tte@cs.fau.de >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Oct 29 10:32:56 2018 Return-Path: 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 19AE7131050 for ; Mon, 29 Oct 2018 10:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 mLW7YGILIpbF for ; Mon, 29 Oct 2018 10:32:51 -0700 (PDT) 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 E7804131023 for ; Mon, 29 Oct 2018 10:32:50 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 908CB548145; Mon, 29 Oct 2018 18:32:46 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 845DF440210; Mon, 29 Oct 2018 18:32:46 +0100 (CET) Date: Mon, 29 Oct 2018 18:32:46 +0100 From: Toerless Eckert To: Joe Touch Cc: architecture-discuss@ietf.org Message-ID: <20181029173246.3qcbz7eovhu36waf@faui48f.informatik.uni-erlangen.de> References: <20181024211419.g7bvx7hzcmzffwkm@faui48f.informatik.uni-erlangen.de> <5C195327-DF82-4D2C-973E-4604E0C41C67@piuha.net> <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> <20181029160702.szukudgin6hygeik@faui48f.informatik.uni-erlangen.de> <0049817A-10BB-45A1-88FE-E6887BD3920A@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0049817A-10BB-45A1-88FE-E6887BD3920A@strayalpha.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 17:32:53 -0000 On Mon, Oct 29, 2018 at 09:36:54AM -0700, Joe Touch wrote: > > Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? > > They are already in that track. I think that???s a mistake - they???re experimental at best st this point. Great. Status changes of the two key documents seem to have been recent, wasn't aware of it. Re. experimental vs. standard on those: These do not have the traditional (network protocol) risks and missing experience data points that we use to select experimental. All the functionality (AFAIK) exists across existing APIs, just fragmented across OS, IP version, transport proto and so on. So i think we don't know what we don't yet know and therefore we should be bold and go for standard. I am sure we will learn what aspects of future API standards specific to APIs would need to be added to the rules guiding experimental vs. standard track selection. Toerless > Joe > > > > > Cheers > > Toerless > > > >> That isn???t networking anymore, and I agree that if that is your goal, > >> you don???t want to use network protocols. > > > > > >> Joe > >> > >>> > >>> Cheers > >>> Toerless > >>> > >>>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: > >>>> > >>>> > >>>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: > >>>>> > >>>>> > >>>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track > >>>>>> interoperability. Lets not have us convert everything that needs to > >>>>>> interoperate inside a box into protocols that look like they could be > >>>>>> happening on an outside wire just to be able to become Internet > >>>>>> Standards. > >>>>> > >>>>> Yes, agreed. > >>>> > >>>> I???m not sure I understand. > >>>> > >>>> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. > >>>> > >>>> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. > >>>> > >>>> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. > >>>> > >>>> Joe > >>>> > >>>> _______________________________________________ > >>>> Architecture-discuss mailing list > >>>> Architecture-discuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>> > >>> -- > >>> --- > >>> tte@cs.fau.de > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Oct 29 17:40:58 2018 Return-Path: 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 60302131001 for ; Mon, 29 Oct 2018 17:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=calebvalle-net-in.20150623.gappssmtp.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 sARd_XId7bNi for ; Mon, 29 Oct 2018 17:40:53 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B5312426A for ; Mon, 29 Oct 2018 17:40:52 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id k19-v6so8873463oic.11 for ; Mon, 29 Oct 2018 17:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=calebvalle-net-in.20150623.gappssmtp.com; s=20150623; h=from:mime-version:references:in-reply-to:date:message-id:subject:to; bh=I9dZdpJD29RleNbX24fcc8Vp/Nt6zOajsKSFZZWYMp0=; b=CqbbaFtdURGva9z6emRQGt+6W229ORd0Wi902dft3ozHhFRGb2XWrSXXsppWan5Coi 7I0sZ4jzR6+6FzJNdFIVOCuaqjwElGJyNrveigawzRqyhQLsPyNGBUJt4Z1SAbnr4Hea M41mvfLeMBGJJ7F32Krh3x1j17Qi8uJeXRvuQDsGq4fuU2LQdwGCUA7jz2Ar0l7ajvPz +BVJeV7J8KJtEdQ3z5pzY33RAxii0W5Y1mFBNwGNZTnYPstdAkiovI8hxeV6K3sC9jHj rLsVgblmMbB+uY30EBAXQI5kNOlxelJ018pwMDHdo4sMqK9f09wyVSfB2BU3Z5XvI4xB GWdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to; bh=I9dZdpJD29RleNbX24fcc8Vp/Nt6zOajsKSFZZWYMp0=; b=gsWJb3qQ1g6vN+Yl6Qf60bmJt07aqgQ3uBmr8nG9S1JtX4jDUEEbvzuR0hIDTIddFN vkQYjpoUf/hMPO3nuXJ1zY1W1FaSgLBKMAFnHBZt+pMsB/oBV38c6MaAMtGuhJw7EZOB tw/1VqjT32LkPYH15+jACk/NqJUMpsUJMs/l+LRyy3yIWG9ZrJuCLFR+NL968iWOB6Kn odnMc5xiNCQN+yWlx28sB+v2Rw+i/rSFp3HsZ1ZEtCrt3CGIGLUrbgQhiQsbHTQGu+d9 ck/YFMckmzbzrRaFWQMkHCvVDciZDZwXEBZJu/a3w+QptwiW4EiCZGgodNUg94TLXA4K juzw== X-Gm-Message-State: AGRZ1gLflWRS7narkyprCI5oDViificxYC1CGtT7gPE+2zy8Ys0VfyXt 2Rve1NUOwVr3qoMVdd9ruE/GWNG4E/tMZQS37dxxmLuQf4A= X-Google-Smtp-Source: AJdET5eUpKRLDLvZfTFEFzEgYXQRMmQjkr6C+FqoowUgWLCy6sI40PiTNtbImAM/UEPwN3fCQYdGxcpEIkqO/2alB+U= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr10210142oib.339.1540860047735; Mon, 29 Oct 2018 17:40:47 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Oct 2018 19:40:47 -0500 From: Victor Valle Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Mon, 29 Oct 2018 19:40:47 -0500 Message-ID: To: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [arch-d] Architecture-discuss Digest, Vol 45, Issue 12 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 00:40:57 -0000 Unsubscribe from this service email Sent from my iPhone > On Oct 29, 2018, at 10:32 AM, architecture-discuss-request@ietf.org wrote: > > Send Architecture-discuss mailing list submissions to > architecture-discuss@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/architecture-discuss > or, via email, send a message with subject or body 'help' to > architecture-discuss-request@ietf.org > > You can reach the person managing the list at > architecture-discuss-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Architecture-discuss digest..." > > > Today's Topics: > > 1. Re: IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) (Toerless Eckert) > 2. Re: IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) (Joe Touch) > 3. Re: IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) (Toerless Eckert) > 4. Re: IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) (Joe Touch) > 5. Re: IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) (Toerless Eckert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Oct 2018 15:54:53 +0100 > From: Toerless Eckert > To: Joe Touch > Cc: Jari Arkko , architecture-discuss@ietf.org > Subject: Re: [arch-d] IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) > Message-ID: > <20181029145453.c3nf47t3224n577w@faui48f.informatik.uni-erlangen.de> > Content-Type: text/plain; charset=us-ascii > > Joe: > > What is external ? Two VM/container inside a PC each one representing a router ? > How about i want to give up the silly notion that i have to pass some > virtual-link represenations of packets but instead pass pointers to > cross-VM shared memory ? I want to be able to sell these VMs as i > sell physical devices and enable customers to interoperate them inside > a physical box. RTT=0, loss=0, why would i need TCP between these > VMs ? > > Interoperability is based on the unit of products we want to enable to > be plugged together into a network. I think we need to look more into > what markets we can better enable by looking more into software as those > units. We're starting to do that IMHO more and more north/southbound > with netconf/yang/PCE and the like to enable centralized controller SDN > network evolution, but the closer we get to the software components that > likely only need to interoperate in a single physcial box, the more we shy > away and stifle modular, multi-vendor interoperable on-box software. > > Cheers > Toerless > >> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >> >> >>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>> >>> >>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>> interoperability. Lets not have us convert everything that needs to >>>> interoperate inside a box into protocols that look like they could be >>>> happening on an outside wire just to be able to become Internet >>>> Standards. >>> >>> Yes, agreed. >> >> I???m not sure I understand. >> >> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. >> >> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. >> >> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. >> >> Joe >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > > > > ------------------------------ > > Message: 2 > Date: Mon, 29 Oct 2018 08:03:39 -0700 > From: Joe Touch > To: Toerless Eckert > Cc: Jari Arkko , architecture-discuss@ietf.org > Subject: Re: [arch-d] IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > >> On Oct 29, 2018, at 7:54 AM, Toerless Eckert wrote: >> >> Joe: >> >> What is external ? Two VM/container inside a PC each one representing a router ? >> How about i want to give up the silly notion that i have to pass some >> virtual-link represenations of packets but instead pass pointers to >> cross-VM shared memory ? I want to be able to sell these VMs as i >> sell physical devices and enable customers to interoperate them inside >> a physical box. RTT=0, loss=0, why would i need TCP between these >> VMs ? > > If you are forcing that implementation, you don?t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do. > > What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transfer over a variety of mechanisms. > >> >> Interoperability is based on the unit of products we want to enable to >> be plugged together into a network. I think we need to look more into >> what markets we can better enable by looking more into software as those >> units. We're starting to do that IMHO more and more north/southbound >> with netconf/yang/PCE and the like to enable centralized controller SDN >> network evolution, but the closer we get to the software components that >> likely only need to interoperate in a single physcial box, the more we shy >> away and stifle modular, multi-vendor interoperable on-box software. > > The more you assume is inside one box the less options the you give the implementer. > > That isn?t networking anymore, and I agree that if that is your goal, you don?t want to use network protocols. > > Joe > >> >> Cheers >> Toerless >> >>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>> >>> >>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>>> >>>> >>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>>> interoperability. Lets not have us convert everything that needs to >>>>> interoperate inside a box into protocols that look like they could be >>>>> happening on an outside wire just to be able to become Internet >>>>> Standards. >>>> >>>> Yes, agreed. >>> >>> I???m not sure I understand. >>> >>> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. >>> >>> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. >>> >>> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. >>> >>> Joe >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> -- >> --- >> tte@cs.fau.de > > > > ------------------------------ > > Message: 3 > Date: Mon, 29 Oct 2018 17:07:02 +0100 > From: Toerless Eckert > To: Joe Touch > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) > Message-ID: > <20181029160702.szukudgin6hygeik@faui48f.informatik.uni-erlangen.de> > Content-Type: text/plain; charset=us-ascii > > On Mon, Oct 29, 2018 at 08:03:39AM -0700, Joe Touch wrote: >>> What is external ? Two VM/container inside a PC each one representing a router ? >>> How about i want to give up the silly notion that i have to pass some >>> virtual-link represenations of packets but instead pass pointers to >>> cross-VM shared memory ? I want to be able to sell these VMs as i >>> sell physical devices and enable customers to interoperate them inside >>> a physical box. RTT=0, loss=0, why would i need TCP between these >>> VMs ? >> >> If you are forcing that implementation, you don???t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do. > > I am not forcing anything, but this type of communication inside boxes > will become more and more important and should considered to be in scope > of interoperability scenarios for the IETF. > > Also consider your VMs L2s are RDMA/RoCE domains. Your subnets all > just have shared memory, no message passing. > > All i am saying is that IETF shouldn't counter requests to standardize > interoperating components with the historic notion of what those > components must be (physcial boxes and wires/radio). > >> What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transfer over a variety of mechanisms. > > In this specific transport protocol example thats probably right as long > there is only an end-to-end (not segmented) transport architecture. > >>> Interoperability is based on the unit of products we want to enable to >>> be plugged together into a network. I think we need to look more into >>> what markets we can better enable by looking more into software as those >>> units. We're starting to do that IMHO more and more north/southbound >>> with netconf/yang/PCE and the like to enable centralized controller SDN >>> network evolution, but the closer we get to the software components that >>> likely only need to interoperate in a single physcial box, the more we shy >>> away and stifle modular, multi-vendor interoperable on-box software. >> >> The more you assume is inside one box the less options the you give the implementer. > > Indeed. Because i want to enable multi-vendor interoperating SW > components on boxes for more agility and innovation. Because the market > may want to buy software and whiteboxes. > > Sometimes its also just common sense from experience even if just a > single vendor may implement the modules: It took IP Multicast in the IETF > something like 10 years before it was permitted to talk about terms > like MRIB/MFIB. And only because implementations that didn't come up > with this internal modularity and software interfaces didn't work > correctly. > > Aka: multiple arguments why this is beneficial/desirable. > > Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? > > Cheers > Toerless > >> That isn???t networking anymore, and I agree that if that is your goal, >> you don???t want to use network protocols. > > >> Joe >> >>> >>> Cheers >>> Toerless >>> >>>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>>> >>>> >>>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>>>> >>>>> >>>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>>>> interoperability. Lets not have us convert everything that needs to >>>>>> interoperate inside a box into protocols that look like they could be >>>>>> happening on an outside wire just to be able to become Internet >>>>>> Standards. >>>>> >>>>> Yes, agreed. >>>> >>>> I???m not sure I understand. >>>> >>>> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. >>>> >>>> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. >>>> >>>> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. >>>> >>>> Joe >>>> >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> -- >>> --- >>> tte@cs.fau.de >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > > > > ------------------------------ > > Message: 4 > Date: Mon, 29 Oct 2018 09:36:54 -0700 > From: Joe Touch > To: Toerless Eckert > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) > Message-ID: <0049817A-10BB-45A1-88FE-E6887BD3920A@strayalpha.com> > Content-Type: text/plain; charset=utf-8 > > > >> On Oct 29, 2018, at 9:07 AM, Toerless Eckert wrote: >> >> On Mon, Oct 29, 2018 at 08:03:39AM -0700, Joe Touch wrote: >>>> What is external ? Two VM/container inside a PC each one representing a router ? >>>> How about i want to give up the silly notion that i have to pass some >>>> virtual-link represenations of packets but instead pass pointers to >>>> cross-VM shared memory ? I want to be able to sell these VMs as i >>>> sell physical devices and enable customers to interoperate them inside >>>> a physical box. RTT=0, loss=0, why would i need TCP between these >>>> VMs ? >>> >>> If you are forcing that implementation, you don???t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do. >> >> I am not forcing anything, but this type of communication inside boxes >> will become more and more important and should considered to be in scope >> of interoperability scenarios for the IETF. >> >> Also consider your VMs L2s are RDMA/RoCE domains. Your subnets all >> just have shared memory, no message passing. >> >> All i am saying is that IETF shouldn't counter requests to standardize >> interoperating components with the historic notion of what those >> components must be (physcial boxes and wires/radio). > > If you an define these in an OS-independent way, sure. > >> >>> What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transfer over a variety of mechanisms. >> >> In this specific transport protocol example thats probably right as long >> there is only an end-to-end (not segmented) transport architecture. >> >>>> Interoperability is based on the unit of products we want to enable to >>>> be plugged together into a network. I think we need to look more into >>>> what markets we can better enable by looking more into software as those >>>> units. We're starting to do that IMHO more and more north/southbound >>>> with netconf/yang/PCE and the like to enable centralized controller SDN >>>> network evolution, but the closer we get to the software components that >>>> likely only need to interoperate in a single physcial box, the more we shy >>>> away and stifle modular, multi-vendor interoperable on-box software. >>> >>> The more you assume is inside one box the less options the you give the implementer. >> >> Indeed. Because i want to enable multi-vendor interoperating SW >> components on boxes for more agility and innovation. Because the market >> may want to buy software and whiteboxes. >> >> Sometimes its also just common sense from experience even if just a >> single vendor may implement the modules: It took IP Multicast in the IETF >> something like 10 years before it was permitted to talk about terms >> like MRIB/MFIB. And only because implementations that didn't come up >> with this internal modularity and software interfaces didn't work >> correctly. >> >> Aka: multiple arguments why this is beneficial/desirable. >> >> Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? > > They are already in that track. I think that?s a mistake - they?re experimental at best st this point. > > Joe > >> >> Cheers >> Toerless >> >>> That isn???t networking anymore, and I agree that if that is your goal, >>> you don???t want to use network protocols. >> >> >>> Joe >>> >>>> >>>> Cheers >>>> Toerless >>>> >>>>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>>>> >>>>> >>>>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>>>>> >>>>>> >>>>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>>>>> interoperability. Lets not have us convert everything that needs to >>>>>>> interoperate inside a box into protocols that look like they could be >>>>>>> happening on an outside wire just to be able to become Internet >>>>>>> Standards. >>>>>> >>>>>> Yes, agreed. >>>>> >>>>> I???m not sure I understand. >>>>> >>>>> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. >>>>> >>>>> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. >>>>> >>>>> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. >>>>> >>>>> Joe >>>>> >>>>> _______________________________________________ >>>>> Architecture-discuss mailing list >>>>> Architecture-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>> >>>> -- >>>> --- >>>> tte@cs.fau.de >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> -- >> --- >> tte@cs.fau.de > > > > ------------------------------ > > Message: 5 > Date: Mon, 29 Oct 2018 18:32:46 +0100 > From: Toerless Eckert > To: Joe Touch > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] IETF standards: think inside the box (re: > draft-arkko-iab-internet-consolidation) > Message-ID: > <20181029173246.3qcbz7eovhu36waf@faui48f.informatik.uni-erlangen.de> > Content-Type: text/plain; charset=us-ascii > > On Mon, Oct 29, 2018 at 09:36:54AM -0700, Joe Touch wrote: >>> Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ? >> >> They are already in that track. I think that???s a mistake - they???re experimental at best st this point. > > Great. Status changes of the two key documents seem to have been > recent, wasn't aware of it. > > Re. experimental vs. standard on those: These do not have the > traditional (network protocol) risks and missing experience data > points that we use to select experimental. All the functionality > (AFAIK) exists across existing APIs, just fragmented across OS, > IP version, transport proto and so on. So i think we don't know what > we don't yet know and therefore we should be bold and go for standard. > > I am sure we will learn what aspects of future API standards specific to APIs > would need to be added to the rules guiding experimental vs. standard > track selection. > > Toerless > >> Joe >> >>> >>> Cheers >>> Toerless >>> >>>> That isn???t networking anymore, and I agree that if that is your goal, >>>> you don???t want to use network protocols. >>> >>> >>>> Joe >>>> >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>>> On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote: >>>>>> >>>>>> >>>>>>> On Oct 26, 2018, at 11:22 PM, Jari Arkko wrote: >>>>>>> >>>>>>> >>>>>>>> Aka: "Think inside the box" wrt to IETF's scope of standards track >>>>>>>> interoperability. Lets not have us convert everything that needs to >>>>>>>> interoperate inside a box into protocols that look like they could be >>>>>>>> happening on an outside wire just to be able to become Internet >>>>>>>> Standards. >>>>>>> >>>>>>> Yes, agreed. >>>>>> >>>>>> I???m not sure I understand. >>>>>> >>>>>> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer. >>>>>> >>>>>> The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host. >>>>>> >>>>>> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages. >>>>>> >>>>>> Joe >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture-discuss mailing list >>>>>> Architecture-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>>> >>>>> -- >>>>> --- >>>>> tte@cs.fau.de >>>> >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> -- >>> --- >>> tte@cs.fau.de > > -- > --- > tte@cs.fau.de > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > ------------------------------ > > End of Architecture-discuss Digest, Vol 45, Issue 12 > ****************************************************