From nobody Sat Feb 1 02:02:03 2020 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 A07A3120811 for ; Sat, 1 Feb 2020 02:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 l-XXPtgJUfsP for ; Sat, 1 Feb 2020 02:02:00 -0800 (PST) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 B149512080D for ; Sat, 1 Feb 2020 02:02:00 -0800 (PST) Received: by mail-oi1-x243.google.com with SMTP id d62so9869252oia.11 for ; Sat, 01 Feb 2020 02:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gxRWIXDneFi9ge++yaLnBmWX32JYn8kvHNLv8kIztM4=; b=B4ez36+6C7rXcVLLg2g0hfN3UNMI3GbSENZg6AXuJFw9lzywAE2Qgu3mPtn1g/1pQ9 dyFVygbQ0nvZKpWy3EZjt0PrbzOcm9FRtYLTMXO9jJndw9wy1w+ZC9bgMg98snKHF+wd Z4QaRd1fdJRyIUcSfZBFCakbrUjhnuKxwZdjDIw5J9XIMhCD5myImu/omTETg9calX7C 8AZXw+GZyHwHgj6LkjC0K13q3m4GIa5iCL9qXVysW+KUuT58W0Tfryd3pfN0GMcp0xH7 LtLf8D8FvGthoxZSIaHEGjib+5xWqg2XBPqiWnrlHJypZh1B5uTsKX7prZO/9s+w+Zgy zIlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gxRWIXDneFi9ge++yaLnBmWX32JYn8kvHNLv8kIztM4=; b=sVKXl66rrS6H6WAfhrKSltPAsvlnWCzUg81AC7OwMYqZJqIn2HTi3dvklBY6nxL50t DpbHWOPNfF8dDn1WGJoYHFoDPfIYczp6A09VEdaiUSL694cbxkeWifg0r/Yic0hxY8f3 WwKZkOBKkSkntV2Fpk220fmENknJwDDCQbkAoKxtrpv0qzB97fy1h6sGTjis5adbyBI1 zXJSE+te0dliXU8sMjI0wG33lPuIw5QCjTqm89SNlP5hpAqLQpbDD/8jk5hKil7qg2D/ CQBLuIOYJG2DHQjUnPVglYplN7gSLzk6v+ZNsx2UWcXiyWqZ5tqOF7yZJBz63bRSlgCG BqxA== X-Gm-Message-State: APjAAAULuvHsIJwsQrrlvl5XdqqwnC5B0t8iVrgBg0zHo99ksIrNt72x iJy9XYADL5Kn1sobOyVbzu4o/k+WvZ/JMTGRXCRADQ== X-Google-Smtp-Source: APXvYqx5F0XcHfk0+yn9ETPTcopSeBE09p6n56xO4eXXel7dciUU3vkAgGs/WaSSK0+L7bEXI9crIsPLQqKY4m/JAOg= X-Received: by 2002:aca:f587:: with SMTP id t129mr7188769oih.143.1580551319788; Sat, 01 Feb 2020 02:01:59 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 1 Feb 2020 02:01:59 -0800 (PST) From: Guntur Wiseno Putra Date: Sat, 1 Feb 2020 17:01:59 +0700 Message-ID: To: architecture-discuss@ietf.org, public-informationarchitecture@w3.org Content-Type: multipart/alternative; boundary="000000000000f72123059d80c70a" Archived-At: Subject: [arch-d] Open Standards Everywhere, The Web & the IETF 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, 01 Feb 2020 10:02:03 -0000 --000000000000f72123059d80c70a Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss & public-informationarchitecture, * Open Standards Everywhere, The Web & the IETF It is about secure web server by using the latest open security standards & availability of websites across global network of networks which is the (open, globally-connected, trustworthy, and secure) Internet... based on the latest and secured standards coming out of the Internet Engineering Task Force. " As part of our Action Plan 2020, this Open Standards Everywhere will be our way to help people operating different kinds of servers to both see the value in new open Internet standards and also understand how to deploy those standards. By the end of 2020, our goal is to see an increase in security and availability of web servers across the Internet through the usage of TLS, DNSSEC, IPv6, and HTTP/2. We will also continue to monitor and evolve the project documentation around web servers. For example, as HTTP3/QUIC moves out into deployment, we will look to build that into this project". https://www.internetsociety.org/issues/open-standards-everywhere/ Regard, Guntur Wiseno Putra --000000000000f72123059d80c70a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear architecture-discuss &
public-informationarchitectu= re,




<= br>
* Open Standards Everywhere, The Web & the IETF

It is about secure web server by using the latest open security standar= ds & availability of websites across global network of networks which i= s the (open, globally-connected, trustworthy, and secure) Internet... based= on the latest and secured standards coming out of the Internet Engineering= Task Force.

" As part of our Action Plan 2020, this Open Standards Everywhere will= be our way to help people operating different kinds of servers to both see= the value in new open Internet standards and also understand how to deploy= those standards.

By the end of 2020, our goal is to see an increase in security and availabi= lity of web servers across the Internet through the usage of TLS, DNSSEC, I= Pv6, and HTTP/2.

We will also continue to monitor and evolve the project documentation aroun= d web servers. For example, as HTTP3/QUIC moves out into deployment, we wil= l look to build that into this project".

https://www.internetsociety.org/issues/open-standards-everywhere/
Regard,
Guntur Wiseno Putra
--000000000000f72123059d80c70a-- From nobody Sat Feb 1 06:51:39 2020 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 0BA4C120830 for ; Sat, 1 Feb 2020 06:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=fLSqUUmg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s2XkvFun 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 hWzDTvVWBdkv for ; Sat, 1 Feb 2020 06:51:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A308112082F for ; Sat, 1 Feb 2020 06:51:35 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E28B2220A5; Sat, 1 Feb 2020 09:51:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 01 Feb 2020 09:51:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Y e+4vWVqIk4HQBX01rllonC/Ws8kIpD+Ib9M5dkodQU=; b=fLSqUUmg8EziECsg8 o5ucgGcy2BmViTHfKp7LDM/pw0pmCvGXSy1Eb7BZ/m5/K5Exy2Wje1PktyQT1DY1 Nuxr4pvsuVPRTz651R9ncIof9LmTGtj1vWthw38+yh4eHzoEgOdliktrgRH32DiB ZjBXD5dTarM+n8PAEB2lex/b3IjRD4olOHiAb4f8+jaxRXrE+7qP+nPOlNWwUMjO dTYA7xaCG1S1o8tKt4lUx3lywpMuapULHBPiKfOhWVkWNFDqnD9vUfghN1ACRodP 7HQacQ7uzMxs8aTAyPMD2jOg4Ib2ti5Ukd29pDKe+iQZKSTUvkq8fvzXxT5rGWdx UdsFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Ye+4vWVqIk4HQBX01rllonC/Ws8kIpD+Ib9M5dkod QU=; b=s2XkvFunC2vbuI40+y+MQpqLWL2ds1L7aORAmoJs03grhqJC0mGjCdi/q 9CMcsn66xu6FQ3Bf9HOdapNwckvVUD3CzeGv+1U/tO9GggrDieaT+oy1fTS+pJts o/VY43ZvZUNWthAj7j8CKVYSCYOhzVrj+/vyXXJSAW/7Emhb+qF4mjmBNW67QfmH SIZCuA6gNHUXnfbfj7UtGZE+x2AXTXNh1cXxbXBh6nUb/m9XJXNw0Cu4G8hyW/SG Xr+cwfj/XcUhzJ5NrQn/VWFwRQNLthlJCgNgAH8tJHCB/wzJHHt5S55JJDkxjqD4 kYwNMDrgIkPd5RG5+sVEAiEX09jaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgedvgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeegiedrudegtd drhedurddvgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.3.137] (unknown [46.140.51.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 46A673280062; Sat, 1 Feb 2020 09:51:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> Date: Sat, 1 Feb 2020 15:51:31 +0100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.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: Sat, 01 Feb 2020 14:51:38 -0000 > On 25 Jan 2020, at 12:58 am, S Moonesamy wrote: >=20 > Hi Mark, > At 09:36 PM 23-01-2020, Mark Nottingham wrote: >> I'm not sure what you mean. I don't see a literal question mark near = the reference in the published text document. >=20 > Sorry for not being clear. There isn't a literal question mark. I'll = try and explain the point. There is the following text: "We embrace = technical concepts such as decentralized control ..." The reality is = that the "control" has moved in the opposite direction, i.e. there is = centralization. The "social good" is being challenged because of = significant cases of misuse. The misuse range from the impact on the = individual to impact at country level. Ah. I agree that centralisation is a concern, and the IAB has been = talking about it quite a bit recently. >> As explained elsewhere in the document, we don't rely on end users = coming to present their case in person, as it were. >=20 > On whom does the IAB rely on to present the case? >=20 > Is it the governments which represent the users as that is usually = what governments do? There is text in the draft which states that it is = not automatic. Is it the advocacy groups which participate in the = Internet Engineering Task Force? Is it the engineer who participates in = the Internet Engineering Task Force? I'm a bit confused by your line of questioning here. Section 4.1 = explains why we need to account for users' needs, but shouldn't expect = users to just show up and represent them. So, it suggests some ways we = might improve over the status quo.=20 No one person or organisation represents' users needs; it's much more = complex than that. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sat Feb 1 15:18:38 2020 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 1A12612004A for ; Sat, 1 Feb 2020 15:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 LX084S6L1GXN for ; Sat, 1 Feb 2020 15:18:35 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 76BAF120025 for ; Sat, 1 Feb 2020 15:18:35 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.43.241]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 011NIM7V028740 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Feb 2020 15:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580599114; x=1580685514; i=@elandsys.com; bh=aPtTuSy4Teqm5LHSB03vclIrythxOEVHaIvzBMMVZxk=; h=Date:To:From:Subject:In-Reply-To:References; b=Dnf5M0TbcnaElwhYLjONDiX0Sm42xbCntpazzLpe7tzdxpWigPjQgqFrjB+ok+xRt ZP/H/WjvkhTPk7M4+TS1AXQEciOLq1wB3ABNRlZ0/L5SSAQmqEVXo8Pj6ux6SmkByW ZkuuQCg/dADX1/qeVPkQlF4BIdefQ/bu4vX7x244= Message-Id: <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Feb 2020 15:18:07 -0800 To: Mark Nottingham , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.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: Sat, 01 Feb 2020 23:18:36 -0000 Hi Mark, At 06:51 AM 01-02-2020, Mark Nottingham wrote: >I'm a bit confused by your line of questioning here. Section 4.1 >explains why we need to account for users' needs, but shouldn't >expect users to just show up and represent them. So, it suggests >some ways we might improve over the status quo. > >No one person or organisation represents' users needs; it's much >more complex than that. I apologize for the strong reply and the line of questioning. The questions which I sent were difficult ones. It is, as you mentioned, a complex matter. Some parts in Section 4.1 are about accounting for users' needs by engaging with groups which are representative of the users. Such an approach would not unfeasible. One way in which organizations tackle that is to identify some form of representativity where users are represented under civil society. Regards, S. Moonesamy From nobody Sat Feb 1 22:50:20 2020 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 464D31200DE for ; Sat, 1 Feb 2020 22:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ra8TCZlKydou for ; Sat, 1 Feb 2020 22:50:16 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 6A3C3120020 for ; Sat, 1 Feb 2020 22:50:16 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id a15so10686990otf.1 for ; Sat, 01 Feb 2020 22:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o7cdGCQxWtrwYdFdT9J5+oVhBOAdZkx/ObBZN/p6IVk=; b=KtFqxHB5/ElBad5mMinrm6JaLANeGMy0Fp9Qe47LnLhjDJ8tNi6i3U9/02JFkcieIx 3Jd/YL+7A35csBi3nqZZZX0MFBqNqt60nRAmjOe2s6DXX16Vf61c4W8V0qKFUoCmxhVn MoVfuAPKJ7E0bkhWgPQhLg1v41zpCYYHFXJio8FqGrGxgaytDOEW2ZZTmzikLTW5Mn5h DUvKyGUuQVK7DDYsHuaXSehSW/10NHF/NcUQZmlO7j2tf4A+SzH5CfEXJvx8ULbs4VX/ HoET0nDg/VNdLCnSPX12V3Di1nInCCvJ/RhLu0i61gt5ZmzOMUTB/OG3bIsy6KhXik1x 5Zmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o7cdGCQxWtrwYdFdT9J5+oVhBOAdZkx/ObBZN/p6IVk=; b=HAgv3eR7yLORVedYi01v7NY5QDsvwXnvEZEIyepQ/2Pfv7umHPPK7El9wjdSL/uzqe xakSLKfL2kpFLhernyo83cS+iO6JRoh2wD4KS7V3Ayy8Zsiz2epFv5qF3Zq4ZbB6hS1q uLEgPF1KOufgBisUqPrFM25C5oEB4/mSZ54PWYigu3oX9NRR5+JFQjNTXl7BV00vHqc3 EudmBJM2Y+fDc9Rpl/ycPalucGO4M90N11OG9wnchXHaAsw13BX3++9gZMjeRZRLFiat BewPI3iggiKaTxuHaLFaH4qdNLdrrwTO3EGBvp1kgLEREfU7Eu1BP4rI2jYqAtKmfYgm 08nw== X-Gm-Message-State: APjAAAV6VlbrtTmaCS/J4WVvjCirKqyCaXoVDAjFOLOvKbDfwVSVATK0 7VpXb0cRxcMHzELnWet6OiahDFlOwKzofl2gsSdr6Q== X-Google-Smtp-Source: APXvYqxtvA2H084W7IX9bCYen4EJrcizoutZ4N1SfwrgXN4hFlc6wU8m9mxZnkHlo/L4Rl4hneTTQCYDrjJmrVPvIS0= X-Received: by 2002:a9d:831:: with SMTP id 46mr14006429oty.295.1580626215755; Sat, 01 Feb 2020 22:50:15 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 1 Feb 2020 22:50:15 -0800 (PST) In-Reply-To: <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> From: Guntur Wiseno Putra Date: Sun, 2 Feb 2020 13:50:15 +0700 Message-ID: To: S Moonesamy Cc: Mark Nottingham , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001ce36a059d923874" Archived-At: Subject: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.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: Sun, 02 Feb 2020 06:50:19 -0000 --0000000000001ce36a059d923874 Content-Type: text/plain; charset="UTF-8" Dear S. Monesamy, Mark & architecture-discuss, Representativity of the Internet Users as Individuals, Organization and civil society is about Legitimacy...? The Internet and Individuals as users in a network society...: may it not help to arrive at such an understanding of representativity and legitimacy...? "An Individual/person, by network society with ICTs as a structural matrix of experiences, of meanings and values, is a momentous synthesis, or a conflict domain --there may be still existed conflicts accompanying her/his choices of acts--, of networks of things/languages with/for/to/among which s/he celebrates/affirmes her/his life/existence..". I said so --with additions here-- in in messages in the thread " Possible new IAB program on Internet trust model evolution" of this architecture-discuss list https://mailarchive.ietf.org/arch/msg/architecture-discuss/CIlb9iJRv-4m7gUeK8dGiVAEJts https://mailarchive.ietf.org/arch/msg/architecture-discuss/9oNuNqcJa4POZPWasivW7iKSqEY Regard, Guntur Wiseno Putra Pada Minggu, 02 Februari 2020, S Moonesamy menulis: > Hi Mark, > At 06:51 AM 01-02-2020, Mark Nottingham wrote: > >> I'm a bit confused by your line of questioning here. Section 4.1 explains >> why we need to account for users' needs, but shouldn't expect users to just >> show up and represent them. So, it suggests some ways we might improve over >> the status quo. >> >> No one person or organisation represents' users needs; it's much more >> complex than that. >> > > I apologize for the strong reply and the line of questioning. The > questions which I sent were difficult ones. It is, as you mentioned, a > complex matter. > > Some parts in Section 4.1 are about accounting for users' needs by > engaging with groups which are representative of the users. Such an > approach would not unfeasible. One way in which organizations tackle that > is to identify some form of representativity where users are represented > under civil society. > > Regards, > S. Moonesamy > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000001ce36a059d923874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear S. Monesamy, Mark &
architecture-discuss,=C2=A0



Representativity of the Internet U= sers as Individuals, Organization and civil society is about Legitimacy...?=

The Internet and Individuals as users in a network society...:=C2=A0 may it= not help to arrive at such an understanding of representativity and legiti= macy...?


"An Individual/person, by network society with ICTs as a structura= l matrix of experiences, of meanings and values, is a momentous synthesis, = or a conflict domain --there may be still existed conflicts accompanying he= r/his choices of acts--, of networks of things/languages with/for/to/among = which s/he celebrates/affirmes her/his life/existence..".


I said so --with additions here-- in in messages in the thread " Possi= ble new IAB program on Internet trust model evolution" of this archite= cture-discuss list

https://mailarchive.ietf.org/arch/msg/architecture-= discuss/CIlb9iJRv-4m7gUeK8dGiVAEJts

https://mailarchive.ietf.org/arch/msg/architecture-= discuss/9oNuNqcJa4POZPWasivW7iKSqEY

Regard,Guntur Wiseno Putra


Pada Minggu, 02 Februari 2020, S Moone= samy <sm+iet= f@elandsys.com> menulis:
Hi Mark,=
At 06:51 AM 01-02-2020, Mark Nottingham wrote:
I'm a bit confused by your line of questioning here. Section 4.1 explai= ns why we need to account for users' needs, but shouldn't expect us= ers to just show up and represent them. So, it suggests some ways we might = improve over the status quo.

No one person or organisation represents' users needs; it's much mo= re complex than that.

I apologize for the strong reply and the line of questioning.=C2=A0 The que= stions which I sent were difficult ones.=C2=A0 It is, as you mentioned, a c= omplex matter.

Some parts in Section 4.1 are about accounting for users' needs by enga= ging with groups which are representative of the users.=C2=A0 Such an appro= ach would not unfeasible.=C2=A0 One way in which organizations tackle that = is to identify some form of representativity where users are represented un= der civil society.

Regards,
S. Moonesamy
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--0000000000001ce36a059d923874-- From nobody Sun Feb 2 01:26:01 2020 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 6B8E712008B for ; Sun, 2 Feb 2020 01:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 25q3SOrFwKLe for ; Sun, 2 Feb 2020 01:25:58 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD8120048 for ; Sun, 2 Feb 2020 01:25:58 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.43.241]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0129PeV8004369 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Feb 2020 01:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580635552; x=1580721952; i=@elandsys.com; bh=iv73tIH2HxR/kiIzgpDOv2470OXMX1dK33bAr+EmNKA=; h=Date:To:From:Subject:In-Reply-To:References; b=tyNs+0y6HTHqzH6lplc/AtBf5ixoXe+4af50C+fureUc0mj8970Wa+hdidhrFtZ4u Ou08Bl5eeFNS3oanERsxeBSrxOjp82hrvtirSW/z4K+xXgQo8oirPkVnHdhXlWNhok 5k8H4IgZxKNdPwNNXoc8ZjJl3RHXzlJuTfvZgBk8= Message-Id: <6.2.5.6.2.20200202000748.0be03018@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Feb 2020 00:21:50 -0800 To: Guntur Wiseno Putra , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.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: Sun, 02 Feb 2020 09:25:59 -0000 Dear Guntur, At 10:50 PM 01-02-2020, Guntur Wiseno Putra wrote: >Representativity of the Internet Users as Individuals, Organization >and civil society is about Legitimacy...? Yes. >The Internet and Individuals as users in a network society...: may >it not help to arrive at such an understanding of representativity >and legitimacy...? The short answer is no. Regards, S. Moonesamy From nobody Sun Feb 2 05:55:03 2020 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 00962120131 for ; Sun, 2 Feb 2020 05:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 acIQhtbYbPge for ; Sun, 2 Feb 2020 05:54:58 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 8C26112010D for ; Sun, 2 Feb 2020 05:54:58 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id r27so11101071otc.8 for ; Sun, 02 Feb 2020 05:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VWVnRz32iyHDTkHUpZH3HvTC1j1IRoZ9t58uZzRmeC0=; b=WcFqoovLH0bNvw9z2tKbohpBixpvsZ1FFZ7OmT/dzFeRr4BFaHNq/mKT0m05H8Od3p TRKggjaW2Je3/TZZQcOq8FzxcsgMPbHF1Vfsol4bCzn5+NURit7OqH9b4raXlzNwdNAI g9Rj8LHejDX6MLmZLbqTqQi9GO0+Zp5kUVH0KU6oD8fSebhr0ME2PIRZ/4BkCDhdQkgq dm7/4pdMQFNmacPVG/dlUV8FHqUkyVPcsUajyvxeq/5h6li3+g1oR9wGhLBsneS1IBlg 1ndZDLEVhHdroMGn2BVWmk1lurTAqzbSQKqrAFZB9NYVZFe7pQDj+64SNPmO09TM9SdZ nH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VWVnRz32iyHDTkHUpZH3HvTC1j1IRoZ9t58uZzRmeC0=; b=BYvvPgNi5mVYdUqY8sDy+c8npsvw0NRKoxzhh52FmRdgKKK/Gq4ZRk1ZBzLe8lY6kK QBu+zh1jiffxSp2rgSrHQPHbigzPYdnTDGzKsVQerLtmkPb9xXdFMvYhvdB9TBgpBayn urfIGZ8th5I/9g1qaoVcbKng+0aG6cXqq2MHjzMSOytadwGdFPhbdkXbN6mnY6XJANzY XPQvBgHRPOn8EMGWfSFKl169X9Cuz6Iahh5xk9Na0TsvzejBWAprYwpfNWboqx/czzRt wsTpLbueIZx9teJDyINXc3o6rpxCg8d+nTNITRNBUOIYlpRvMYFpNC8Ho9p5JBKpdg/C U4fw== X-Gm-Message-State: APjAAAW5MP5zSV3f6PXSx7APyTSTvnlPAi7IwkSpvbMAymZc4l4Gjfvk HvYIPkLSarUEYf8loKDjGap84NiPjGd9HPB7Mcf0Wg== X-Google-Smtp-Source: APXvYqy9xj0NXt24IMD5vq338929sDVCOnHaniV3OAXUxR04iXE5VKs6wY36T4Pamc4KUYBxo7Kc4DS342Zdn/pIf9Y= X-Received: by 2002:a9d:170a:: with SMTP id i10mr14294996ota.284.1580651697844; Sun, 02 Feb 2020 05:54:57 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 2 Feb 2020 05:54:57 -0800 (PST) In-Reply-To: <6.2.5.6.2.20200202000748.0be03018@elandnews.com> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> <6.2.5.6.2.20200202000748.0be03018@elandnews.com> From: Guntur Wiseno Putra Date: Sun, 2 Feb 2020 20:54:57 +0700 Message-ID: To: S Moonesamy Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6b59d059d982639" Archived-At: Subject: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.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: Sun, 02 Feb 2020 13:55:01 -0000 --000000000000f6b59d059d982639 Content-Type: text/plain; charset="UTF-8" Dear S. Moonesamy & architecture-discuss, May we say about "building trust for legitimacy to represent", "legitimacy to represent for trust"...? --as one is legitimated when another or others trust(s) to that one (her/him)...? Such basic understandings below may help to arrive at a notions of "trust" in the Internet which is about networks of computers, of communications, of languages (1). Networks of Interests (of meanings and values): Trusts and Distrusts... - when the interests are understood/accepted by either/all parties involved there are (networks of) trusts. - when the interests are not understood/accepted by either/all parties involved there are (networks of) distrusts. Should we note that there are in-between areas made possible by those "either" in those points above, which is about as non-total trust well as non-total distrust --it is supposedly about "degrees" of "little", "enough", "much"... In relation to "individuals in a network society", especially to "the Internet users as individuals in a network society"--as mentioned in the previous message--, the problem of "legitimacy for representativity" is about how building trust for legitimacy to represent (2). Thus we may say about "networked representativity". (1) so it is about identifying critical points of security: those threats and trusts --actual and potential. It is related with my previous message at this architecture-discuss list "Possible new IAB program on Internet trust model evolution" https://mailarchive.ietf.org/arch/msg/architecture-discuss/WIhsj9iVwZAMAzx3cFciuVW2GXw (2) J. F. Lyotard in "The Postmodern Conditions: a Report on Knoweledge" section "Elementary Nature of Social Tie: Postmodern Perspective mentioned about "the self" as one "exists in a fabric of relations which is now getting more complex and mobile" as it "is always be placed on nodal points in (a) certain circuit of communication". Regard, Guntur Wiseno Putra Pada Minggu, 02 Februari 2020, S Moonesamy menulis: > Dear Guntur, > At 10:50 PM 01-02-2020, Guntur Wiseno Putra wrote: > >> Representativity of the Internet Users as Individuals, Organization and >> civil society is about Legitimacy...? >> > > Yes. > > The Internet and Individuals as users in a network society...: may it not >> help to arrive at such an understanding of representativity and >> legitimacy...? >> > > The short answer is no. > > Regards, > S. Moonesamy > --000000000000f6b59d059d982639 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear S. Moonesamy &=C2=A0
architecture-discuss,


May we say about "building trust for legitimacy t= o represent", "legitimacy to represent for trust"...? --as o= ne is legitimated when another or others trust(s) to that one (her/him)...?=

Such basic understandings below may help to arrive at a notions of "tr= ust" in the Internet which is about networks of computers, of communic= ations, of languages (1).

Networks of Interests (of meanings and values): Trusts and Distrusts...
- when the interests are understood/accepted by either/all parties involved= there are (networks of) trusts.

- when the interests are not understood/accepted by either/all parties invo= lved there are (networks of) distrusts.

Should we note that there are in-between areas made possible by those "= ;either" in those points above, which is about as non-total trust well= as non-total distrust --it is supposedly about "degrees" of &quo= t;little", "enough", "much"...

In relation to "individuals in a network society", especially to = "the Internet users as individuals in a network society"--as ment= ioned in the previous message--, the problem of "legitimacy for repres= entativity"=C2=A0 is about how building trust for legitimacy to repres= ent (2). Thus we may say about "networked representativity".



(1)=C2=A0 so it is about identifying critical points of security: those thr= eats and trusts --actual and potential. It is related with my previous mess= age at this architecture-discuss list "Possible new IAB program on Int= ernet trust model evolution"

https://mailarchive.ietf.org/arch/msg/architecture-= discuss/WIhsj9iVwZAMAzx3cFciuVW2GXw

(2) J. F. Lyotard in "The Postmodern Conditions: a Report on Knoweledg= e" section "Elementary Nature of Social Tie: Postmodern Perspecti= ve mentioned about "the self" as one "exists in a fabric of = relations which is now getting more complex and mobile" as it "is= always be placed=C2=A0 on nodal points in (a) certain circuit of communica= tion".=C2=A0


Regard,
Guntur Wiseno Putra

Pada Minggu, 02 Februari 2020, S Moonesamy <= sm+ietf@elandsys.com> menu= lis:
Dear Guntur,
At 10:50 PM 01-02-2020, Guntur Wiseno Putra wrote:
Representativity of the Internet Users as Individuals, Organization and civ= il society is about Legitimacy...?

Yes.

The Internet and Individuals as users in a network society...:=C2=A0 may it= not help to arrive at such an understanding of representativity and legiti= macy...?

The short answer is no.

Regards,
S. Moonesamy
--000000000000f6b59d059d982639-- From nobody Sun Feb 2 13:05:48 2020 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 4B78B120127 for ; Sun, 2 Feb 2020 13:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 nWIBQXGAevrV for ; Sun, 2 Feb 2020 13:05:45 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B371312006E for ; Sun, 2 Feb 2020 13:05:45 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.201.182]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 012L5Ubr026690 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Feb 2020 13:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580677541; x=1580763941; i=@elandsys.com; bh=jlaPmI/pPT6H3lgyLyZVSoDThveh015yUFCosh7Mg2k=; h=Date:To:From:Subject:In-Reply-To:References; b=wc1EI1c6ReKgZ7GpvJ2mOzkeXqhCdZY4IpUJ5EP3V4Zb0iUUNPXfNGWUCkHQH9EDt SL0JgzHPfNdpVDMWGqrabx0aWKOlwskBJRfA3etKzjLrUov81Ok6jXIMLeawBylg+4 VoWqZbPf4pbjjgT0hz42ChpGJa3QSJPIZMZzMjvk= Message-Id: <6.2.5.6.2.20200202114823.0801adc8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Feb 2020 13:03:21 -0800 To: Guntur Wiseno Putra , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> <6.2.5.6.2.20200202000748.0be03018@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.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: Sun, 02 Feb 2020 21:05:46 -0000 Dear Guntur, At 05:54 AM 02-02-2020, Guntur Wiseno Putra wrote: >May we say about "building trust for legitimacy to represent", >"legitimacy to represent for trust"...? --as one is legitimated when >another or others trust(s) to that one (her/him)...? I would not say that. It can be a balancing act between various interests and/or imperatives. Regards, S. Moonesamy From nobody Sun Feb 2 18:18:39 2020 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 16ABD120817 for ; Sun, 2 Feb 2020 18:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 63CxEhcedrQx for ; Sun, 2 Feb 2020 18:18:36 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 2990C12002F for ; Sun, 2 Feb 2020 18:18:36 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id a15so12197176otf.1 for ; Sun, 02 Feb 2020 18:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5+HJmbpIff8OACkXkx7cbv11ogGg6fqDUXYhr4Eh7RE=; b=dMplMcQrF14jpCJw8mRuP+dgpo7pyG/Rxw9NaDq9eOhTFy8xi2Kc7lfx3Sa2tsDhDR SWzbnNUll8nkxxKYCSxzJQ7S+K5ojAe6/zpSa2mnJknECTIEpdXeoNTiemWw5ku/VXWq 4HtsT7FP9nFYUGJhZpoTFgfb/HEhW7ch0QM95G8oLsEFWoovjcP9XdgdhYDahuQfO/+K xuvvz2Q9Qwak5s5EhtRw5/9JjH9gPJ7OiyucN5up8lO8dOXuqOTzN0Tw5rbOj0BbnKh7 lJjxwYeR9mIXj1v3NUCYgOQjd6X1SDRT/cDwDir6oimHBcrpUI2S2NB/pr6qF4YDp1sR GZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5+HJmbpIff8OACkXkx7cbv11ogGg6fqDUXYhr4Eh7RE=; b=Hwo2SKyf8xHemDYlboAH+lTfR+LFKHoIqI2Kdqz8A4+RpmmSVtBZxHi28LUWZB5Ggp TVphvHALaiYPwIl0Piht/BPW3BE41JvaE9g0pu16pf+stKY2BguuGKj/f9R/aU17smfW HpV5vaSp6W2wValnGKAXflQ0gEsENjCgFTogPriWuJxCDd1azII2ICk+tt5gfZpjiBWH Wg8xD/ef/31bP11+O+7yMR8TUukv/sHjgy0yN18opXYNYaDBkSN/i/i5GeW8wEbBg4hl 6IrSNVsCUfs4OVRrQRx8hJE96zazsP1jhD4maRsLdJ0QQM7F8QDGPDtQemL6okbJzZNp qErQ== X-Gm-Message-State: APjAAAWkr1e21iWIdDpII+zeVRxMagit26kqJeBaojEtx7wbnmn5Znso PHfTBrtEDf+D8sZjsNK4s24raPLybR+TcCdpJJlTDw== X-Google-Smtp-Source: APXvYqyKF97WqlM1uRqe0yFd1p0xVzNkZDNfXEH6aZwb5+pqI03LvDLhh77m4litodW1U8DtzFkjbB3Qjpr8IzGYpLg= X-Received: by 2002:a9d:65da:: with SMTP id z26mr16183959oth.197.1580696315318; Sun, 02 Feb 2020 18:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 2 Feb 2020 18:18:34 -0800 (PST) In-Reply-To: <6.2.5.6.2.20200202114823.0801adc8@elandnews.com> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> <6.2.5.6.2.20200201143228.0bf6db10@elandnews.com> <6.2.5.6.2.20200202000748.0be03018@elandnews.com> <6.2.5.6.2.20200202114823.0801adc8@elandnews.com> From: Guntur Wiseno Putra Date: Mon, 3 Feb 2020 09:18:34 +0700 Message-ID: To: S Moonesamy Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005f538c059da28a44" Archived-At: Subject: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.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, 03 Feb 2020 02:18:38 -0000 --0000000000005f538c059da28a44 Content-Type: text/plain; charset="UTF-8" Dear S. Moonesamy & architecture-discuss, S.M: I would not say that. It can be a balancing act between various interests and/or imperatives. GWP: Wheels need to stand to walk...: it is a matter of "balance"... That is about a wheel system. But, the performance of system at times needs to destroy its (/system's) entropy (1), its balance which is about a balance at higher levels of encompassing bigger/broader interests/imperatives (: It is not only about either me or you but people surrounding also...): which is about a new balance. Does it not mean such an egoism related with security, that subjects (be it as human well as non-human) struggle for its self-security. Thus, there are problems of ethics and aesthetics here, as we are thinking as men: about what is just and about what is beautiful. Note: (1) J. F. Lyotard said about system performance and entropy/balance in the same paragraph with his explanation about "the self" I mentioned in the previous message. * to make additions in the last paragraph of my previous message: In relation to "individuals in a network society", especially to "the Internet users as individuals in a network society"--as mentioned in the previous message--, the problem of "legitimacy for representativity" is about how building trust for legitimacy to represent interests(2). "Who the Internet users trust (their interest, meanings and values) to..."? "Why and how do they trust them to..."? Those are among others questions arisen in, what we may name, "networked representativity". Regard, Guntur Wiseno Putra Pada Senin, 03 Februari 2020, S Moonesamy menulis: > Dear Guntur, > At 05:54 AM 02-02-2020, Guntur Wiseno Putra wrote: > >> May we say about "building trust for legitimacy to represent", >> "legitimacy to represent for trust"...? --as one is legitimated when >> another or others trust(s) to that one (her/him)...? >> > > I would not say that. It can be a balancing act between various interests > and/or imperatives. > > Regards, > S. Moonesamy > --0000000000005f538c059da28a44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear S. Moonesamy &
architecture-discuss,

S.= M: I would not say that.=C2=A0 It can be a balancing act between various in= terests and/or imperatives.

GWP: Wheels need t= o stand to walk...: it is a matter of "balance"... That is about = a wheel system.

But, the performance of system at times needs to destroy its (/system's= ) entropy (1), its balance which is about a balance at higher levels of enc= ompassing bigger/broader interests/imperatives (: It is not only about eith= er me or you but people surrounding also...): which is about a new balance.=

Does it not mean such an egoism related with security, that subjects (be it= as human well as non-human) struggle for its self-security.

Thus, there are problems of ethics and aesthetics here, as we are thinking = as men: about what is just and about what is beautiful.

<= /div>




Note:= =C2=A0

(1) J. F. Lyotard said about system perform= ance and entropy/balance in the same paragraph with his explanation about &= quot;the self" I mentioned in the previous message.


* to make additions in the last paragraph of my previ= ous message:


In relation to "i= ndividuals in a network society", especially to "the Internet use= rs as individuals in a network society"--as mentioned in the previous = message--, the problem of "legitimacy for representativity"=C2=A0= is about how building trust for legitimacy to represent interests(2). &quo= t;Who the Internet users trust (their interest, meanings and values) to...&= quot;? "Why and how do they trust them to..."? Those are among ot= hers questions arisen in, what we may name, "networked representativit= y".


Regard,
Gunt= ur Wiseno Putra

Pada Senin, 03 Februari 2020, S Moonesamy <sm+ietf@elandsys.com> menulis:
Dear Guntur,
At 05:54 AM 02-02-2020, Guntur Wiseno Putra wrote:
May we say about "building trust for legitimacy to represent", &q= uot;legitimacy to represent for trust"...? --as one is legitimated whe= n another or others trust(s) to that one (her/him)...?

I would not say that.=C2=A0 It can be a balancing act between various inter= ests and/or imperatives.

Regards,
S. Moonesamy
--0000000000005f538c059da28a44-- From nobody Tue Feb 4 00:29:44 2020 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 C89E112012A for ; Tue, 4 Feb 2020 00:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 UeK3r-sj8qAW for ; Tue, 4 Feb 2020 00:29:41 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABBA120074 for ; Tue, 4 Feb 2020 00:29:40 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.197.182]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0148TN6F013214 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Feb 2020 00:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580804975; x=1580891375; i=@elandsys.com; bh=lzgtra8bj/NFEY6PTZYAmUFe5xNQEWeofqxsmGKArbk=; h=Date:To:From:Subject:In-Reply-To:References; b=OR3kMTN51MDcpAzEBJXMypRNuZ/DIY8IohesZWVCio66b8c2RjJ3Gs6DtIk0NklKA Tu0tlEj08h5Qm9Gdmw/mG3/E6Ve1vpRt0iXoeVMIYXePUkZod1M3ltsxwrE9MfbIUD 88l+tcy8K7tx9yQ6ZxDxbC98tPWksWb8TQ8lLtIc= Message-Id: <6.2.5.6.2.20200204002004.0d32f5d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 04 Feb 2020 00:28:59 -0800 To: Alvaro Retana , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy 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, 04 Feb 2020 08:29:42 -0000 Hi Alvaro, At 06:54 AM 09-01-2020, Alvaro Retana wrote: >(2) Liaison managers (to other organizations) represent the interests >of the IETF, should they be subject to a similar COI policy? Maybe it >is not appropriate to include them in this specific policy, but I >didn't find anything in rfc4052 related to this point. I'll comment on (2). The communication from an IETF Liaison Manager is expected to "represent the IETF". The designated authority is within the IETF. Would it be okay if the IAB were to set a policy or would it be up to the IESG to do that? Regards, S. Moonesamy From nobody Tue Feb 4 00:40:29 2020 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 1A457120122 for ; Tue, 4 Feb 2020 00:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3Bw1EG7zt9CO for ; Tue, 4 Feb 2020 00:40:25 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0: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 A0431120074 for ; Tue, 4 Feb 2020 00:40:25 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id i1so17629855oie.8 for ; Tue, 04 Feb 2020 00:40:25 -0800 (PST) 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=0Q/N3QUIKb4pNApUUbtuhNey7LQ/mTVsdMIcdxZ+Tuc=; b=MrKs4GexB1VzzvCGrgNLT8tUONf+bJMRjxCmiN7VJUegzm55ejY26RnHJt3+LrBEBS WVoKmsAXyhGf/r+1blCiBWwiI152AzoPjajrAKSE2vcO9/1B+1LZUM+zl1Ukbij0dcuF K/C759fRxOvlDwegwiZMoB/7YLCiB7HWh5Vexw3+AE1oK84jMy1TKHHt1YoDGh4Lr/8/ xzfxfN/sF/Et0mSdHUgPkzhoR7Qud3GFTyxER2REAv4G95tWPtad91MwUQ4lHfQrqTES p/7H6U1xZgpeQmV4kCpScoPVkrU/sTEtECGV3VX5mkmyH9S/4H0hcOnQ1w4XWmF7BiGS JgWw== 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=0Q/N3QUIKb4pNApUUbtuhNey7LQ/mTVsdMIcdxZ+Tuc=; b=eFAjr841J3IGmNHcCM1PI4ie21nbcVgige8xE7JEHffzn/bJR2kCmncafQroYXlQ0y n+mzu3U5ymXmi27rNqr3tL7LPhXsk11oQyF2zo37/Yd0oNgMYNclMb4pZoRmsaKfkOag 3oTWf85FY0is6vhuDhIWXakgYxO0xkAPOwYIs6SrIj3c9OZGQXqluKh+D/iEQvgaQMwd p+R842dMfsS3kDkft1WLBR+fmJDXXC1hB8qpNilEOsCjLmJ28QrNQnuHJluTo3ZE2kl2 CGg9ZRVqrJrg0ktS/EB1a2XHHYeC+feWM4SWVz5y4/RiDPO6LN9XujP1lUqvJly/+lZu f9cQ== X-Gm-Message-State: APjAAAXiUMVv0Wlg2j/2VbAbfgIIQmIpNOCCMi+IPcZjo/s/gJiG8dEY GmpcEG8WiXdZIh+J/HMFsEdDFddCAheF5APzhNA= X-Google-Smtp-Source: APXvYqyEyAzCAVOFDYbtYVNyuiLcXsjee0YOboF5HZYBhOxjPyo+LNyP64VTX+p4gD/n51Jz/a4LAS2yPzheN+JMc2E= X-Received: by 2002:a05:6808:658:: with SMTP id z24mr2746576oih.91.1580805624914; Tue, 04 Feb 2020 00:40:24 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <6.2.5.6.2.20200204002004.0d32f5d8@elandnews.com> In-Reply-To: <6.2.5.6.2.20200204002004.0d32f5d8@elandnews.com> From: Ted Hardie Date: Tue, 4 Feb 2020 09:39:58 +0100 Message-ID: To: S Moonesamy Cc: Alvaro Retana , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb6713059dbbfdc6" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy 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, 04 Feb 2020 08:40:28 -0000 --000000000000bb6713059dbbfdc6 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 9:29 AM S Moonesamy wrote: > Hi Alvaro, > At 06:54 AM 09-01-2020, Alvaro Retana wrote: > >(2) Liaison managers (to other organizations) represent the interests > >of the IETF, should they be subject to a similar COI policy? Maybe it > >is not appropriate to include them in this specific policy, but I > >didn't find anything in rfc4052 related to this point. > > I'll comment on (2). The communication from an IETF Liaison Manager > is expected to "represent the IETF". The designated authority is > within the IETF. Would it be okay if the IAB were to set a policy or > would it be up to the IESG to do that? > > For the appointments made by the IAB, the IAB has set policy in the past, e.g. https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-liaison-compensation/ . Individuals must also follow the policies of the body to which they are appointed. Those appointed by the IAB to the ISOC Board of Trustees, for example, follow the board's conflict of interest policy. regards, Ted > Regards, > S. Moonesamy > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000bb6713059dbbfdc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 9:29 AM S Moonesam= y <sm+ietf@elandsys.com>= ; wrote:
Hi Alvaro,
At 06:54 AM 09-01-2020, Alvaro Retana wrote:
>(2) Liaison managers (to other organizations) represent the interests >of the IETF, should they be subject to a similar COI policy?=C2=A0 Mayb= e it
>is not appropriate to include them in this specific policy, but I
>didn't find anything in rfc4052 related to this point.

I'll comment on (2).=C2=A0 The communication from an IETF Liaison Manag= er
is expected to "represent the IETF".=C2=A0 The designated authori= ty is
within the IETF.=C2=A0 Would it be okay if the IAB were to set a policy or =
would it be up to the IESG to do that?

For the appointments made by the IAB, the IAB has set= policy in the past, e.g. htt= ps://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-stat= ement-on-liaison-compensation/ .=C2=A0=C2=A0 Individuals must also foll= ow the policies of the body to which they are appointed.=C2=A0 Those appoin= ted by the IAB to the ISOC Board of Trustees, for example, follow the board= 's conflict of interest policy.

regards,

Ted

=C2=A0
Regards,
S. Moonesamy

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000bb6713059dbbfdc6-- From nobody Tue Feb 4 11:41:13 2020 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 3E4D6120803 for ; Tue, 4 Feb 2020 11:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 pKgIKO66bRrc for ; Tue, 4 Feb 2020 11:41:09 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8012022E for ; Tue, 4 Feb 2020 11:41:09 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.131.51]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 014JerkK006416 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Feb 2020 11:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580845265; x=1580931665; i=@elandsys.com; bh=k5uBGIfofvnt7jPs0Pted75Onpq1Z6p22uonSXDtSZ0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z4MYM9JH0WAjFVEXwsD61Fd9UsyASKm/ILIwchsGGNsCVwc5prCVSKdsty1vFo0XL lx5xa19+Rj3yXMAOijalKG554FEH3C9V7vZPR95nH+HJzPrqzFmUiECEC89M6LTCcT V25vXVP0UckrjbNRKht541LsHmPj8mHOiXC6JvEs= Message-Id: <6.2.5.6.2.20200204110733.0beec4a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 04 Feb 2020 11:40:41 -0800 To: Ted Hardie , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <6.2.5.6.2.20200204002004.0d32f5d8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy 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, 04 Feb 2020 19:41:10 -0000 Hi Ted, At 12:39 AM 04-02-2020, Ted Hardie wrote: >For the appointments made by the IAB, the IAB has set policy in the >past, e.g. >https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-liaison-compensation/ >. Individuals must also follow the policies of the body to which >they are appointed. Those appointed by the IAB to the ISOC Board of >Trustees, for example, follow the board's conflict of interest policy. Thanks for pointing to the IAB statement. The mail archives show that there was an IAB statement without any significant discussion whereas RFC 4052 went through IESG Evaluation. RFC 4052 was not set by the body doing the appointment. Regards, S. Moonesamy From nobody Wed Feb 5 15:19:42 2020 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 9FA4B1200A4 for ; Wed, 5 Feb 2020 15:19:38 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 SdstGfY2_pBn for ; Wed, 5 Feb 2020 15:19:36 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 3855B120100 for ; Wed, 5 Feb 2020 15:19:36 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id zPPCi0SNJ0JsVzTxHiNTXY; Wed, 05 Feb 2020 23:19:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1580944775; bh=T3rQM6l84XFQjVQ0r+CkDjYcLUpeix6NC0lUBCGnhTw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RfPOWKGBXUiqhfSCI1NxJophxB0oF0560AntrRMF7DAilnWb3aWPzkpS28LRlrsf7 hLDM/Y976Z37Kx08qoaOu/OIMP/OSuil/l/b5/ZL8JEEFtvNrx1N4VS0SHhWnHw3gF +zvSi1nFU3z0ab61gnQ53uKu1dTUyDchkrzEEp/xkx6C5DfYC6YBBIW3Olzn0hUQk3 Kcsj8dhL79BrSfS1Bj81HToWPIwfOlONbrAUByJs7fJLD/ei7T0TEfnRueea4D7QIQ av/QlSYNUEsBj4ZqsPzRrOCKrU8lKslaJSA49eLlxjTZudEtuJKtIib3Z6fiiMq2sf V3FPjyAvzugxw== Received: from [IPv6:2601:152:4400:437c:1909:41e4:4efe:613f] ([IPv6:2601:152:4400:437c:1909:41e4:4efe:613f]) by resomta-ch2-12v.sys.comcast.net with ESMTPSA id zTxFivl9xlDXezTxFinDOx; Wed, 05 Feb 2020 23:19:34 +0000 X-Xfinity-VMeta: sc=0.00;st=legit To: architecture-discuss@ietf.org, iab@iab.org, last-call@ietf.org References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> From: Michael StJohns Message-ID: Date: Wed, 5 Feb 2020 18:19:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 05 Feb 2020 23:19:38 -0000 On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-for-the-users-02. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available for inspection at: > > > The Call for Comment will last until 2020-03-04. Please send comments to > architecture-discuss@ietf.org and iab@iab.org. > > Abstract: > > This document explains why the IAB believes the IETF should consider > end users as its highest priority concern, and how that can be done. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Does this document represent an IAB consensus/aspiration or is this Mark writing as an IAB member? If the former, Mark should be listed as Editor, and the document should include text indicating how the IAB arrived at consensus (e.g. "This document represents the consensus of the IAB arrived at through (internal discussions | discussions with the community | workshop results | etc) " ).   If the latter, the document should indicate "This document represents the author's personal opinion". Later, Mike From nobody Wed Feb 5 15:31:06 2020 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 15883120848; Wed, 5 Feb 2020 15:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_HELO_NONE=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=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 UBDQpAIn0JNI; Wed, 5 Feb 2020 15:31:03 -0800 (PST) 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 9D1261200A4; Wed, 5 Feb 2020 15:31:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 057BFBE4D; Wed, 5 Feb 2020 23:31:00 +0000 (GMT) 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 YdhpRGYLgEKh; Wed, 5 Feb 2020 23:30:58 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3772BE4C; Wed, 5 Feb 2020 23:30:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580945458; bh=U8FqWE0xsqVuZrnYE0G5iUH8Fprg+sLIEDUjlzeS7wg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jCe6hErGf+K+uAFj44TDWa+FFawuGY24IBX3Yjq3NABeXASL01puLJmvcpirjmwL8 m6lKD5p5b/nw7foAt1zu4GkZP06cVwoW4g6pXDs5SnSgDUfkYUkBGzWPLtfbx0DEoA 0bS/tEkm4ZHxETvEGHXjMvl4Aj19BZNiC6KcBNl8= To: Michael StJohns , architecture-discuss@ietf.org, iab@iab.org, last-call@ietf.org References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: Date: Wed, 5 Feb 2020 23:30:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ShMAbA4KTKvB0dvDbRS3gbdXMckdvx8cQ" Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 05 Feb 2020 23:31:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ShMAbA4KTKvB0dvDbRS3gbdXMckdvx8cQ Content-Type: multipart/mixed; boundary="Shmy8eoHiZQusKJ0zKWeJ0SU6q69dAbMa"; protected-headers="v1" From: Stephen Farrell To: Michael StJohns , architecture-discuss@ietf.org, iab@iab.org, last-call@ietf.org Message-ID: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> In-Reply-To: --Shmy8eoHiZQusKJ0zKWeJ0SU6q69dAbMa Content-Type: multipart/mixed; boundary="------------BDF80D481E6739ABA5118381" Content-Language: en-US This is a multi-part message in MIME format. --------------BDF80D481E6739ABA5118381 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, On 05/02/2020 23:19, Michael StJohns wrote: > On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: >> This is an announcement of an IETF-wide Call for Comment on >> draft-iab-for-the-users-02. >> >> The document is being considered for publication as an Informational R= FC >> within the IAB stream, and is available for inspection at: >> >> >> The Call for Comment will last until 2020-03-04. Please send comments = to >> architecture-discuss@ietf.org and iab@iab.org. >> >> Abstract: >> >> =C2=A0=C2=A0=C2=A0 This document explains why the IAB believes the IET= F should consider >> =C2=A0=C2=A0=C2=A0 end users as its highest priority concern, and how = that can be done. >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > Does this document represent an IAB consensus/aspiration or is this Mar= k > writing as an IAB member? >=20 > If the former, Mark should be listed as Editor, and the document should= > include text indicating how the IAB arrived at consensus (e.g. "This > document represents the consensus of the IAB arrived at through > (internal discussions | discussions with the community | workshop > results | etc) " ).=C2=A0=C2=A0 If the latter, the document should indi= cate "This > document represents the author's personal opinion". I don't recall other documents being as formal as that about it, but sure, if/when the IAB decide to publish this after community comment then it could be clearer that it's an IAB document, e.g. by having Mark as editor as you suggest. That it is an IAB document seems fairly clear to me from the filename and from the IAB adoption call etc. that was sent to this list back last June/July, but I guess that's a while back. Cheers, S. >=20 > Later, Mike >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --------------BDF80D481E6739ABA5118381 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------BDF80D481E6739ABA5118381-- --Shmy8eoHiZQusKJ0zKWeJ0SU6q69dAbMa-- --ShMAbA4KTKvB0dvDbRS3gbdXMckdvx8cQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl47UDAACgkQWrL68XsX K+rdBw/+JYZlVLiyrwGrnJb153uGbO3BluXrdRUvGVPRwdkkrQcVZbKwMmgEt/n6 WZm/3SEgZinPwG+EW6iZqKWZmJiS53PrBlEEob1oV0FJS05PiPsRvm9q6iumJYkJ R6Wj+8wGzzdxRsr7uyozriMnemOtG4hb1Xx/OchCBrs1hiqZTsowb/kG361qoTZl /tdytPIHbhrUvOvxaB60cb+zR04aJSWCv0Q4uA1c4T9nP+bTnzHMtw6iOYhYh07w 4bIYqxCHGtAJL61bF3jPwzEbV9KZO5tbFZHounoMPxHsQvQvVGgNcx03Mey8u4jF XVEms2ia0tz3x+BRxHZzxOFGVJmAUP+WxukiZ/YILAZTdSMhSDUVa5lk+RBzV2kC At67E61M05Atq+KU28XiewlzScqRZy5ktMrIS2zzrKsIoCo53Z2xpUZMpxZRhXzQ yCbPKw7ABalhMU5O9HvZAvaR2UIruY0anOGK9YnOr/YuNqw8eEMbpknPmSCQdiAY w7ZDofb3suNEe88SPiyp6fR2EOP7voYxRfLhDPcC8vg8Pp7aVOJHmdmGtPXgiNKk O3eTXYoR/r2H9LIxkXRxb8ocpo0aFOn4FYxSn0pqczN+TUui6gkNHGLtyfOxsayC 74YyjopaKhPMapYr7xxUMsOthlmJR/tly1niwb2MpBD8WpR7pZA= =+7sz -----END PGP SIGNATURE----- --ShMAbA4KTKvB0dvDbRS3gbdXMckdvx8cQ-- From nobody Wed Feb 5 16:04:25 2020 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 5B43E1200A4; Wed, 5 Feb 2020 16:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oxSkmq-rzQO2; Wed, 5 Feb 2020 16:04:19 -0800 (PST) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 19C7312008D; Wed, 5 Feb 2020 16:04:19 -0800 (PST) Received: by mail-il1-x144.google.com with SMTP id p8so3475629iln.12; Wed, 05 Feb 2020 16:04:19 -0800 (PST) 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=0CLglRLUkNLBjYdSdV1GKPrUEV41d1pGneC59t9ZHM0=; b=sR5BnYvceUbQw0qiZUzL0zXaHcYXr23/gix3phP9ya0stAncPV+tjFSF6s5IKXPXI2 +5CdKwGQIhDsxNokaJaYzkzTlpls4WvjfYyI9WCOx+9/d4KfWlR8WjVusbidyRw0cV5K I5nvwPPkdI0TxGSYFDIdRtUVW7uM9iCg3KkeNRxxf8FwFieHo7n+OxubBgDRs8eENrxE so/zlvCWXGL5maDAQZoLecxWTBPbfH4gY3NhEWYowL0k40ypUUqDusyiAPEXHNZX+igJ OnZhpitmKf3qcAU3OGdWBQ4eTGOh5Hs9xjZpa/FGQMasrR1mNhvSvWuAEAEQWwM2D2et k2Uw== 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=0CLglRLUkNLBjYdSdV1GKPrUEV41d1pGneC59t9ZHM0=; b=sVo+jjpVbDBTOlmDI4QpXDv7Uz57+Ynieo6LjF/etJNT3tWLu/wAjxALARbNhFtW5A aPLcU+Ume0S0UVyeQTYbKJp6Z4BrlgHMgm0ec3q2lSTl2J3lbvLbNWPLczQX8oWmxxkZ dyJVStMhocqE61u9flWvW4DQxnR8LGQcI7TBsvUelmDdl2LpxqHevxVZucGSPuaEmqH6 YMJ8XbR1DVAJSHlBkbj3RQPOG6j6vc26DpWAGevfdAe+8ZwvI8X0m2C4KKnsmEL9rHWi AIl43sD1z8fvzA0s7yNsZzsTv15pe7g0efHRm4MKFZcLi2rFjPUzCgCajhVIxgGmV1DY rP0Q== X-Gm-Message-State: APjAAAX6+wAJPyLhv1+DF1kv8/rQyjvg8NpYGtB5ZVZol5egDe3F/A8z gw+HAZ4PFhUOC2mlZIYVjHGFdvWwT1w7GQo9dGM= X-Google-Smtp-Source: APXvYqyF4oyWbbNe8IKMtnrwGvllLkmOoUomC8TJGWswSU70zgCHVvaJdBRu3bH5Z3aurx3U7dTYdqySxmh9IeZJp/Q= X-Received: by 2002:a92:990b:: with SMTP id p11mr825689ili.254.1580947458117; Wed, 05 Feb 2020 16:04:18 -0800 (PST) MIME-Version: 1.0 References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> In-Reply-To: From: Rob Sayre Date: Wed, 5 Feb 2020 16:04:03 -0800 Message-ID: To: Michael StJohns Cc: architecture-discuss@ietf.org, iab@iab.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000a653e1059ddd0378" Archived-At: Subject: Re: [arch-d] [Last-Call] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 00:04:21 -0000 --000000000000a653e1059ddd0378 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 5, 2020 at 3:20 PM Michael StJohns wrote: > On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: > > This is an announcement of an IETF-wide Call for Comment on > > draft-iab-for-the-users-02. > > > > The document is being considered for publication as an Informational RFC > > within the IAB stream, and is available for inspection at: > > > > > > The Call for Comment will last until 2020-03-04. Please send comments to > > architecture-discuss@ietf.org and iab@iab.org. > > > > Abstract: > > > > This document explains why the IAB believes the IETF should consider > > end users as its highest priority concern, and how that can be done. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > Does this document represent an IAB consensus/aspiration or is this Mark > writing as an IAB member? > > If the former, Mark should be listed as Editor, and the document should > include text indicating how the IAB arrived at consensus (e.g. "This > document represents the consensus of the IAB arrived at through > (internal discussions | discussions with the community | workshop > results | etc) " ). If the latter, the document should indicate "This > document represents the author's personal opinion". > Are there competing opinions on the IAB? "The Internet is not for End Users" ? "The Internet is for Network Operators" ? thanks, Rob --000000000000a653e1059ddd0378 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 5, 2020 at 3:20 PM Michae= l StJohns <mstjohns@comcast.net<= /a>> wrote:
O= n 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-for-the-users-02.
>
> The document is being considered for publication as an Informational R= FC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/d= raft-iab-for-the-users/>
>
> The Call for Comment will last until 2020-03-04. Please send comments = to
> arc= hitecture-discuss@ietf.org and iab@iab.org.
>
> Abstract:
>
>=C2=A0 =C2=A0 =C2=A0This document explains why the IAB believes the IET= F should consider
>=C2=A0 =C2=A0 =C2=A0end users as its highest priority concern, and how = that can be done.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Annou= nce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-a= nnounce

Does this document represent an IAB consensus/aspiration or is this Mark writing as an IAB member?

If the former, Mark should be listed as Editor, and the document should include text indicating how the IAB arrived at consensus (e.g. "This <= br> document represents the consensus of the IAB arrived at through
(internal discussions | discussions with the community | workshop
results | etc) " ).=C2=A0=C2=A0 If the latter, the document should ind= icate "This
document represents the author's personal opinion".

Are there competing opinions on the IAB?
"The Internet is not for End Users" ?
&quo= t;The Internet is for Network Operators" ?

th= anks,
Rob

--000000000000a653e1059ddd0378-- From nobody Wed Feb 5 16:24:26 2020 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 A0DFC12001E for ; Wed, 5 Feb 2020 16:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 7q3nRAIpmqFz for ; Wed, 5 Feb 2020 16:24:21 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 C438C12007C for ; Wed, 5 Feb 2020 16:24:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48CfLs55rpz6GD4n; Wed, 5 Feb 2020 16:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580948661; bh=Dlk3hEPmegbZ4CJ+HL9fRt4xDUov1pbgrUSc4FAhKXY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Wt7mcy9gdNjMuTeA8nFI7TpZ2aQO5JPHrx/DnnChPhnSmeExqNwhpBdAYQFGB5UUw GaIvFRONSY0mWFR8zKpp/PGeSbCz0mxGm6zy0mW8yLQ/bg8o5wuOHMD65l4Am/QD4J sWUTXdZXmwElqZ68ZibXmLlr9K5QSbXC+Ll+Tk1o= X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48CfLs1894z6GD4m; Wed, 5 Feb 2020 16:24:20 -0800 (PST) To: architecture-discuss@ietf.org, iab@iab.org References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 5 Feb 2020 19:24:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 00:24:25 -0000 I find this document very frustrating. The explicit recommendations seem reasonable. But the underlying tone that the End User concerns should take precedence over everything else seems to be incorrect. And therefore the initial tone seems to send the wrong message. To provide several examples, the Internet is "for" many participants. It is for the folks offering services over the Internet. It is for the many sensors and small devices which are expected to outnumber human users by a significant margin in the near term. It is "for" the folks who run it, as if they can not operate the network then it won't do anyone else any good. I believe many of these concerns were raised by other people during earlier discussions of the document. Assuming efforts were made to address those concerns, the changes seem to me to be insufficient. Yours, Joel On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-for-the-users-02. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available for inspection at: > > > The Call for Comment will last until 2020-03-04. Please send comments to > architecture-discuss@ietf.org and iab@iab.org. > > Abstract: > > This document explains why the IAB believes the IETF should consider > end users as its highest priority concern, and how that can be done. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From nobody Wed Feb 5 17:34:15 2020 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 E0D9D120113 for ; Wed, 5 Feb 2020 17:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 n4LwnPny2ae9 for ; Wed, 5 Feb 2020 17:34:12 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 E9DD51200FB for ; Wed, 5 Feb 2020 17:34:11 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id 2so2147644pfg.12 for ; Wed, 05 Feb 2020 17:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=TrX/Ke0bhUL0LqWOc9XZHqrOD8Yt/9hNySdJ2rueyFM=; b=GCM138wSiW02LgszlRt04H3lPnKbywlCFMrLIY2T2kTNdRXMnOm5iMN7D5EWc9v/hL lVVSl7TYn4V8raHa7faZAYEAGcCYOMm+S889IzaUkysNvIj6Mb7U/QmWj7sepkJGKqz/ Uza9vmnPuspEo6hem8iJyA45mkOSp2K+QMWUvhQ2ACSzRLK/U8kbScL9tRLdo2hlToe4 X90aQoK0ofsy44j+hMz7p8VHGHw1uXTSgb9JnXSA8jj8okwCmzxd9W/YeuBFMKNuuXQW Eoql4hULgpnD/N+z+5uKGd9lNAAnXsfBHTOFVzY0bevL8wRBnq6VgzdvuKX9bCCKABi1 HdiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=TrX/Ke0bhUL0LqWOc9XZHqrOD8Yt/9hNySdJ2rueyFM=; b=Lsr3lycDM0IcGMem+W61M6fJijuqcK7FvoEul8YPHz77Q5u9dTkDtaT9XtJuWB1CD1 S8Dy2r8lwsyZXZ3qtrwaekNJc9R+2x89bYLQkv6X9XqALzBl9P/Ptg66Un0E5e8FZxW2 TAKIHBJB7xK2LMXELGQO3ijQFTJmE2f5jXrOKGZQpaY7bO4RP6Lz0anpWb/9MJhYdNGd cH/FCgymq0POSubFmDwAL4+eC4fnXll4yG2F1M9jz2Kt5OueTmrc50j5oTXwfIa3gLXk fuTeymfdML2o+BUN7GB3Jzj7q47/0ssmUBcNhQLjC9WJsCRAudxzeW8CqW80uoSN1ArQ 71mA== X-Gm-Message-State: APjAAAV+xsqdwLKUt6VJWZBdVdtTyCrY1xwt6OTNVdYx1xiKY6VmCKZ/ ZVzJObuBCQNQSSRBcgeFsGwmdfCI X-Google-Smtp-Source: APXvYqzw+VxZcFJUrivscvy6JGqEaukF5ZLbmHzQE2fhM28zVS27w9IAJBzmWtzLKPwX+ohTli9dgQ== X-Received: by 2002:a63:513:: with SMTP id 19mr904179pgf.28.1580952850577; Wed, 05 Feb 2020 17:34:10 -0800 (PST) Received: from ?IPv6:2600:380:8047:36be:959b:75f9:dd4d:e980? ([2600:380:8047:36be:959b:75f9:dd4d:e980]) by smtp.gmail.com with ESMTPSA id a69sm749182pfa.129.2020.02.05.17.34.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Feb 2020 17:34:10 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-70502164-2206-4119-A1BA-07907B19B3EB Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Wed, 5 Feb 2020 17:34:08 -0800 Message-Id: References: Cc: architecture-discuss@ietf.org, iab@iab.org In-Reply-To: To: "Joel M. Halpern" X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 01:34:14 -0000 --Apple-Mail-70502164-2206-4119-A1BA-07907B19B3EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are a number of ways to interpret this IAB draft. If one looks at it a= s a refutation of David Clark=E2=80=99s =E2=80=9CTussle=E2=80=9D work (see: h= ttps://www.researchgate.net/publication/2868953_Tussle_in_Cyberspace_Definin= g_Tomorrow's_Internet) then Joel=E2=80=99s frustrations follow naturally.=20= Personally, I hope the goal of the document is not to referee the =E2=80=9CT= ussle=E2=80=9D by declaring the user as the official winner. That would be s= illy, if only because such a declaration would not help =E2=80=9Cthe user=E2= =80=9D or any other =E2=80=9CTussle=E2=80=9D participant.=20 So I choose to see the draft=E2=80=99s contribution as pointing out IoT chal= lenges compared with trends in the mobile and web application space (e.g. no= permission model or =E2=80=9Capp store=E2=80=9D rules limiting the damage t= hat can be done by badly implemented or malicious devices).=20 Given these widely varying reactions, the document seems like it could use a= good edit to strengthen the impact of its main points. > On Feb 5, 2020, at 4:24 PM, Joel M. Halpern wrote: >=20 > =EF=BB=BFI find this document very frustrating. >=20 > The explicit recommendations seem reasonable. >=20 > But the underlying tone that the End User concerns should take precedence o= ver everything else seems to be incorrect. And therefore the initial tone s= eems to send the wrong message. >=20 > To provide several examples, the Internet is "for" many participants. It i= s for the folks offering services over the Internet. It is for the many sen= sors and small devices which are expected to outnumber human users by a sign= ificant margin in the near term. It is "for" the folks who run it, as if th= ey can not operate the network then it won't do anyone else any good. >=20 > I believe many of these concerns were raised by other people during earlie= r discussions of the document. Assuming efforts were made to address those c= oncerns, the changes seem to me to be insufficient. >=20 > Yours, > Joel >=20 >> On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: >> This is an announcement of an IETF-wide Call for Comment on >> draft-iab-for-the-users-02. >> The document is being considered for publication as an Informational RFC >> within the IAB stream, and is available for inspection at: >> >> The Call for Comment will last until 2020-03-04. Please send comments to >> architecture-discuss@ietf.org and iab@iab.org. >> Abstract: >> This document explains why the IAB believes the IETF should consider >> end users as its highest priority concern, and how that can be done. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-70502164-2206-4119-A1BA-07907B19B3EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are a number of ways= to interpret this IAB draft. If one looks at it as a refutation of David Cl= ark=E2=80=99s =E2=80=9CTussle=E2=80=9D work (see: https://www.researchgate.net/publication/2868953_Tussle_in_Cyb= erspace_Defining_Tomorrow's_Internet) then Joel=E2=80=99s frustrations f= ollow naturally. 

Pers= onally, I hope the goal of the document is not to referee the =E2=80=9CTussl= e=E2=80=9D by declaring the user as the official winner. That would be silly= , if only because such a declaration would not help =E2=80=9Cthe user=E2=80=9D= or any other =E2=80=9CTussle=E2=80=9D participant. 

So I choose to see the draft=E2=80=99s contri= bution as pointing out IoT challenges compared with trends in the mobile and= web application space (e.g. no permission model or =E2=80=9Capp store=E2=80= =9D rules limiting the damage that can be done by badly implemented or malic= ious devices). 

Given t= hese widely varying reactions, the document seems like it could use a good e= dit to strengthen the impact of its main points.

<= blockquote type=3D"cite">On Feb 5, 2020, at 4:24 PM, Joel M. Halpern <jmh= @joelhalpern.com> wrote:

=EF=BB=BFI find this document very frustrating.

The explicit recommendations seem reasonable= .

But the underlying tone that the End User= concerns should take precedence over everything else seems to be incorrect.=  And therefore the initial tone seems to send the wrong message.

To provide several examples, the Internet is "fo= r" many participants. It is for the folks offering services over the Interne= t.  It is for the many sensors and small devices which are expected to o= utnumber human users by a significant margin in the near term.  It is "= for" the folks who run it, as if they can not operate the network then it wo= n't do anyone else any good.

I believe many= of these concerns were raised by other people during earlier discussions of= the document.  Assuming efforts were made to address those concerns, t= he changes seem to me to be insufficient.

Y= ours,
Joel

On 2/5/2020 5:48= PM, IAB Executive Administrative Manager wrote:
This is an announcement of an IETF-wide Call for Comment on
draft-iab-for-the-users-= 02.
The document is b= eing considered for publication as an Informational RFC
within the IAB stream, and is available f= or inspection at:
<= ;https://datatracker.ietf.org/doc/draft-iab-for-the-users/>
The Call for Comment will last unt= il 2020-03-04. Please send comments to
architecture-discuss@ietf.org and iab@iab.org.
<= /blockquote>
Abstract:
   This document explains w= hy the IAB believes the IETF should consider
   end users as its highest priority= concern, and how that can be done.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org<= br>
https://www.ietf.org/mailman= /listinfo/ietf-announce

______= _________________________________________
Architecture-discu= ss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss
= --Apple-Mail-70502164-2206-4119-A1BA-07907B19B3EB-- From nobody Wed Feb 5 17:43:17 2020 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 0B4B612008D for ; Wed, 5 Feb 2020 17:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 nDcZhFh4SNkH for ; Wed, 5 Feb 2020 17:43:11 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7696812011A for ; Wed, 5 Feb 2020 17:43:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5634D22139; Wed, 5 Feb 2020 20:43:10 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 05 Feb 2020 20:43:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ONZLfx jLGwuOPTLTTKopaq4pJNYvmY73Cq7RTtK1T8M=; b=Sfimi/tw43AiKxl5RgRP6k RaR5Aj0IzT9zpP7KndhS80DvLuZ4q0Yz0udikCSBTG/UhZQUEYJpckRcBAf1L87D VkJUCE1mD74fNkQ4VAcQyLUXrpghdIXB7cbTW/W9odc9BzhXtpBFKcTtuHtcsljZ ReUS5N+YpUot3ev4vUoB6Ck8HORfskigrZ6rklipkXDCMSz0WhYkRZrnvW09Z2ZZ Olsj54/h4nAZaav763j9Lo+SoKi7HeZ1zDpGtdg1R1HaLmnzY/cZxOvicZzQp7BA FsLzLyuppcdgSnZimIMtre8MBZW1ZY156FmAE5+hDUe312BQF4ObgzNHv2NHC2Rg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedvgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucfkphepuddtkedrvddvuddrudektddrudehne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhr vgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A0A6B30600DC; Wed, 5 Feb 2020 20:43:09 -0500 (EST) To: iab@iab.org, "architecture-discuss@ietf.org" References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> From: Keith Moore Message-ID: <052aa2af-1d52-16c3-b7b7-9d1df1a7590b@network-heretics.com> Date: Wed, 5 Feb 2020 20:43:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------22E78663B80D6741C81F8C79" Content-Language: en-US Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 01:43:16 -0000 This is a multi-part message in MIME format. --------------22E78663B80D6741C81F8C79 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm generally ok with the document as written.   But I wonder if (in spite of its long history), it doesn't go far enough.   In particular it doesn't provide many examples of users' interests like privacy, security, reliability, maintainability, supportability, ease of use, platform-independence, etc. The example cited in 4.2 of web browsers having multiple interoperable implementations, while somewhat true, seems like a poor one - since there seem to be a dearth of independent implementations that are usable and actively maintained.   The web has become so complex that a reasonably complete implementation is daunting and even Microsoft has given up trying to maintain its own.   The very widespread disregard for users' privacy on today's web seems to indicate that the web has not evolved to favor the interests of end users.   The demands of content-providers, rather than those of users, seem to have dictated the limitations of the current web, and efforts to reduce users' privacy risks seem like a drop in the bucket. A few additional nits: In these situations, when one of those parties is an "end user" of the Internet - for example, a person using a Web browser, mail client, or another agent that connects to the Internet - the Internet Architecture Board argues that the IETF should favor their interests over those of parties. s/those of parties/those of other parties/ In this document, "end users," means non-technical users whose activities IETF standards are designed to support, sometimes indirectly. s/non-technical users/non-technical human users/ --------------22E78663B80D6741C81F8C79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'm generally ok with the document as written.   But I wonder if (in spite of its long history), it doesn't go far enough.   In particular it doesn't provide many examples of users' interests like privacy, security, reliability, maintainability, supportability, ease of use, platform-independence, etc.  

The example cited in 4.2 of web browsers having multiple interoperable implementations, while somewhat true, seems like a poor one - since there seem to be a dearth of independent implementations that are usable and actively maintained.   The web has become so complex that a reasonably complete implementation is daunting and even Microsoft has given up trying to maintain its own.   The very widespread disregard for users' privacy on today's web seems to indicate that the web has not evolved to favor the interests of end users.   The demands of content-providers, rather than those of users, seem to have dictated the limitations of the current web, and efforts to reduce users' privacy risks seem like a drop in the bucket.

A few additional nits:


   In these situations, when one of those parties is an "end user" of
   the Internet - for example, a person using a Web browser, mail
   client, or another agent that connects to the Internet - the Internet
   Architecture Board argues that the IETF should favor their interests
   over those of parties.

s/those of parties/those of other parties/

   In this document, "end users," means non-technical users whose
   activities IETF standards are designed to support, sometimes
   indirectly.

s/non-technical users/non-technical human users/



--------------22E78663B80D6741C81F8C79-- From nobody Wed Feb 5 18:25:30 2020 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 5277012011A for ; Wed, 5 Feb 2020 18:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 4Fry651xMT0K for ; Wed, 5 Feb 2020 18:25:26 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 948C51200A4 for ; Wed, 5 Feb 2020 18:25:26 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id zVUNisvUwtdfMzWr7ixrdN; Thu, 06 Feb 2020 02:25:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1580955925; bh=YX/MNwZkHCGLxYkdezlwIbypOtZQ+yvRKr/21xIXkQY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=o4HndPgK9LxvgyzWTTd5EH3wHitZRONTUwX12AdJS9iXE08O6u0YHvXn6Q6rBm6D1 ARVuHlcNRS7J0UtzGCz+7VqZRfcb5GLdpqITb8YZlPe5j9bgAPyKH7KzJPg1D7Mr6k mzEts50UvyM+I6BfQGVEuj8dZekfSIdaAQLpf4AALPM7BSGmb0xNR129DR6KbHeRxw zzCGnr5WD481lx2Fk5fUuZWJd0l/UN1gTzKHZBKmVEb0buYfRSw2q3yAv2GgJlUj3B CfBEc1KL3LAtoKh5wIHGwzZG+y+W3u5QcC35e84c8mpLZsZYYddRQx1pOG19GGZSdJ AoMMXiuwdj54Q== Received: from [IPv6:2601:152:4400:437c:1909:41e4:4efe:613f] ([IPv6:2601:152:4400:437c:1909:41e4:4efe:613f]) by resomta-ch2-14v.sys.comcast.net with ESMTPSA id zWr5iclFkVh07zWr5iykq1; Thu, 06 Feb 2020 02:25:24 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit To: Rob Sayre Cc: last-call@ietf.org, iab@iab.org, architecture-discuss@ietf.org References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> From: Michael StJohns Message-ID: <446af639-f4f8-04c6-73dc-4061b420cd75@comcast.net> Date: Wed, 5 Feb 2020 21:25:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D3AA5EFDA54B5ECA26756758" Content-Language: en-US Archived-At: Subject: Re: [arch-d] [Last-Call] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 02:25:28 -0000 This is a multi-part message in MIME format. --------------D3AA5EFDA54B5ECA26756758 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/5/2020 7:04 PM, Rob Sayre wrote: > > > On Wed, Feb 5, 2020 at 3:20 PM Michael StJohns > wrote: > > On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote: > > This is an announcement of an IETF-wide Call for Comment on > > draft-iab-for-the-users-02. > > > > The document is being considered for publication as an > Informational RFC > > within the IAB stream, and is available for inspection at: > > > > > > The Call for Comment will last until 2020-03-04. Please send > comments to > > architecture-discuss@ietf.org > and iab@iab.org > . > > > > Abstract: > > > >     This document explains why the IAB believes the IETF should > consider > >     end users as its highest priority concern, and how that can > be done. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > Does this document represent an IAB consensus/aspiration or is > this Mark > writing as an IAB member? > > If the former, Mark should be listed as Editor, and the document > should > include text indicating how the IAB arrived at consensus (e.g. "This > document represents the consensus of the IAB arrived at through > (internal discussions | discussions with the community | workshop > results | etc) " ).   If the latter, the document should indicate > "This > document represents the author's personal opinion". > > > Are there competing opinions on the IAB? > > "The Internet is not for End Users" ? > "The Internet is for Network Operators" ? > > thanks, > Rob > Hi Rob - You may have an assumption that differs from mine to whit:   "All documents published in the IAB stream represent IAB consensus" vs "A document in the IAB stream can originate from the IAB as an IAB consensus document, or from individuals within the IAB or from others that have information that the IAB that believes is important enough to bring to the attention of the community but that might not be more appropriate for one of the other streams".   My assumption is the latter.  The IAB has ... less? different? ... rules with respect to what gets published than the IETF stream, the IRTF stream or the ISE stream.  I assume an IAB consensus on publication, not necessarily a consensus of the content of the document.  I also assume that what the IAB finds important may differ from what the IESG/IETF/IRTF or ISE might consider important - at least at the time of publication. For example - this could have been the first of two documents from the IAB - one supporting the proposition, and one arguing against.  Or even three - the third with some sort of synthesis of the two.  In otherwords, a discussion of architecture. Hence the question of provenance. Later, Mike --------------D3AA5EFDA54B5ECA26756758 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/5/2020 7:04 PM, Rob Sayre wrote:


On Wed, Feb 5, 2020 at 3:20 PM Michael StJohns <mstjohns@comcast.net> wrote:
On 2/5/2020 5:48 PM, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-for-the-users-02.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-for-the-users/>
>
> The Call for Comment will last until 2020-03-04. Please send comments to
> architecture-discuss@ietf.org and iab@iab.org.
>
> Abstract:
>
>     This document explains why the IAB believes the IETF should consider
>     end users as its highest priority concern, and how that can be done.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

Does this document represent an IAB consensus/aspiration or is this Mark
writing as an IAB member?

If the former, Mark should be listed as Editor, and the document should
include text indicating how the IAB arrived at consensus (e.g. "This
document represents the consensus of the IAB arrived at through
(internal discussions | discussions with the community | workshop
results | etc) " ).   If the latter, the document should indicate "This
document represents the author's personal opinion".

Are there competing opinions on the IAB?

"The Internet is not for End Users" ?
"The Internet is for Network Operators" ?

thanks,
Rob


Hi Rob -

You may have an assumption that differs from mine to whit:   "All documents published in the IAB stream represent IAB consensus" vs "A document in the IAB stream can originate from the IAB as an IAB consensus document, or from individuals within the IAB or from others that have information that the IAB that believes is important enough to bring to the attention of the community but that might not be more appropriate for one of the other streams".   My assumption is the latter.  The IAB has ... less? different? ... rules with respect to what gets published than the IETF stream, the IRTF stream or the ISE stream.  I assume an IAB consensus on publication, not necessarily a consensus of the content of the document.  I also assume that what the IAB finds important may differ from what the IESG/IETF/IRTF or ISE might consider important - at least at the time of publication.

For example - this could have been the first of two documents from the IAB - one supporting the proposition, and one arguing against.  Or even three - the third with some sort of synthesis of the two.  In otherwords, a discussion of architecture.

Hence the question of provenance.

Later, Mike





--------------D3AA5EFDA54B5ECA26756758-- From nobody Wed Feb 5 19:06:38 2020 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 C38881200A4 for ; Wed, 5 Feb 2020 19:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 l8idFC9z0a15 for ; Wed, 5 Feb 2020 19:06:33 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154: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 1924512006E for ; Wed, 5 Feb 2020 19:06:33 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-04v.sys.comcast.net with ESMTP id zWrei9xrB9m4ozXUuiJZFv; Thu, 06 Feb 2020 03:06:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1580958392; bh=TKa06TXMr9ShjAHruDe6YK+Vz8UBUurd+y+ARHm2c08=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kZLTAASvnEyWEicaxP/nfd1G/+TqfA3yhHbHbe4gKctFwnyInMpnpAd1/fomkex32 1QWPJKQrHX/WfgqLXRVrHU9yXj1e46kRBNN3XpKLgtX8JVIgpZl1DasdEQZSGQNqjc mIBMTWt/ALZ30ShAOT9A/gAPVgWYFwAEqQVZYV/OYjEQmB7lltwdYdKqDE6OsYC5ML w2hm8xlFROAFCpbusUThU9o8FhxIEpTX1yt8ykyLcmCcZFPXoQVxxy6/ph/jP6G+To /eYKY4crMwN4UGboAwdZJHspjzMF+1wP5T4DxkbkztcPE7rF8/3HxVVy15MXRoY0So w3LHyXvltBJOQ== Received: from [IPv6:2601:152:4400:437c:1909:41e4:4efe:613f] ([IPv6:2601:152:4400:437c:1909:41e4:4efe:613f]) by resomta-po-14v.sys.comcast.net with ESMTPSA id zXUqiQtMNjTRJzXUriau02; Thu, 06 Feb 2020 03:06:30 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit To: Stephen Farrell , last-call@ietf.org, IAB , architecture-discuss@ietf.org References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <08e8a377-ec4c-00ca-eea8-fb8e882db1f5@cs.tcd.ie> From: Michael StJohns Message-ID: <3c0fbc2f-87db-89f2-a1ad-b2233db38d25@comcast.net> Date: Wed, 5 Feb 2020 22:06:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <08e8a377-ec4c-00ca-eea8-fb8e882db1f5@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------D13164B58EA5FDFB65EEDCF1" Content-Language: en-US Archived-At: Subject: Re: [arch-d] [Last-Call] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 03:06:36 -0000 This is a multi-part message in MIME format. --------------D13164B58EA5FDFB65EEDCF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/5/2020 7:01 PM, Stephen Farrell wrote: > Hiya, > > On 05/02/2020 23:51, Michael StJohns wrote: >> On 2/5/2020 6:30 PM, Stephen Farrell wrote >>> I don't recall other documents being as formal as that about it, >>> but sure, if/when the IAB decide to publish this after community >>> comment then it could be clearer that it's an IAB document, e.g. by >>> having Mark as editor as you suggest. That it is an IAB document >>> seems fairly clear to me from the filename and from the IAB >>> adoption call etc. that was sent to this list back last June/July, >>> but I guess that's a while back. >> Um.. yes, I know it's an IAB stream document - which does not >> necessarily imply that it is a consensus document of the entire IAB.> >> And going back and re-reading the announcement, it looks too much >> like a last call request rather than a call for "help us make the >> document better".   I'm not sure why anyone would assume that the >> IAB hadn't yet decided to publish it or something very like it. > Well, to be fair, there was a public call for comment > before the IAB adopted this. OK - then you're NOT asking for discussion on whether to publish?  :-)   No worries - I can work with either. > >> As far as I can tell from the published RFC's - documents that >> represent IAB consensus on a policy matter are mostly published as >> "Editor" and have something that identifies how you got there: E.g. >> RFC8558 had Ted as editor and included this in the status: >> >>> This document is a product of the Internet Architecture Board >>> (IAB) and represents information that the IAB has deemed valuable >>> to provide for permanent record. It represents the consensus of >>> the Internet Architecture Board (IAB). Documents approved for >>> publication by the IAB are not candidates for any level of >>> Internet Standard; see Section 2 of RFC 7841. >> Documents that are more "spec"ish (i.e. the RFC v3 format) either >> have an editor or a technical expert as the author.  And even then >> you get the same statement - see RFC8546 and 8700 >> >> Those are the last three IAB stream documents published.  Going >> back further a "tech"ish document omitted the "Consensus of the IAB" >> statement - RFC6574 - simply a report from a workshop. >> >> That being said, these are all statements in the status section >> which will be different from the ID to the RFC. > Yep, the above seems (to me) like a good comment that could > be handled without having to invent some new strict process > for IAB stream document boilerplate - I'd hope that some > variation in how these things are presented/worded is ok. I think that it needs to be brought forward to the ID in some form - or it needs to be included in the call for comments. Somewhere before the RFC editor gets it. > >> It would be >> useful for a policy document (I use the term "policy" loosely here) >> to have that consensus statement be made somewhere. Mostly in other >> documents its pretty clear how we got there - some event, some >> workshop, some question asked at a plenary that's being answered. >> >> Here - I'm not sure what triggered the IAB into writing it and >> worse, I'm not sure what affect you want it to have on the formal >> IETF processes. Context would be good, actionable recommendations >> would be better. > That (the question of effects) seems like a separate > point. Surely section 4 of the draft is all about > actionable recommendations though so I'm a bit confused > as to what you mean? The key word is "actionable".    I went back and re-read section 4 and what I got was aspirational rather than actionable. 4.1. comes closest to actionable with the "hold a co-located workshop" comment.  And even that is kind of weak.  More along the lines of "To husband this process of getting community buy-in we've asked ISOC to work with us to create workshops for the next N ISOC meetings with each of those workshops targeted at one of these communities.  The IAB will provide an overview of the IETF process, near future architecture changes and challenges, and how non-participation by that community might result in an architecture which does not meet their needs.   We will then solicit involvement in an IAB sponsored workshop retreat whose output shall be a community centric set of guidelines that will be presented to the IETF community for possible inclusion in the standards process" -  or something like that. I have no idea of what "We should also create explicit...." means in section 4.2.    If feels like a bit of a non sequitur here.  In any event, browsers are not protocols.  The underlying protocols evolved to meet functional and the browsers evolved GUI needs. Discussing HTTP and HTML evolution rather than browsers in this section might be more appropriate and more on point for the IETF. Then we can talk about how that maps to the IOT space and what we/IAB/IETF can do about it. In 4.3 "Negative impact on users" not being defined limits defining useful actions.   At least consider how you might measure those impacts in a relatively objective way.  Maybe reach out to someone like KC for help in identifying ways to do those measurements.   If it can't be measured, then it's going to revert to politics and money. 4.4 seems to be a restatement of the Prisoner's dilemma problem in some form.    E.g. how do you identify and balance costs to entities that might not have any reason to cooperate? 4.5 mostly deprioritizes the value of the work product of the standards writers vs the "needs of end users".  Basically, this doesn't meet the financial needs test.  Unless you're having the end users compensate the writers/implementers in some manner, there is little incentive to put their needs ahead of the writers.   At best, you can say that when choosing between two equally costly choices, you should pick the one that least impacts the end user - again - if you can identify that impact. Later, Mike > > Cheers, > S. > >> Later, Mike >> >> >> >> >> >> --------------D13164B58EA5FDFB65EEDCF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/5/2020 7:01 PM, Stephen Farrell wrote:
Hiya,

On 05/02/2020 23:51, Michael StJohns wrote:

On 2/5/2020 6:30 PM, Stephen Farrell wrote

I don't recall other documents being as formal as that about it,
but sure, if/when the IAB decide to publish this after community
comment then it could be clearer that it's an IAB document, e.g. by
having Mark as editor as you suggest. That it is an IAB document
seems fairly clear to me from the filename and from the IAB
adoption call etc. that was sent to this list back last June/July, 
but I guess that's a while back.

Um.. yes, I know it's an IAB stream document - which does not 
necessarily imply that it is a consensus document of the entire IAB.>
And going back and re-reading the announcement, it looks too much
like a last call request rather than a call for "help us make the
document better".    I'm not sure why anyone would assume that the
IAB hadn't yet decided to publish it or something very like it.

Well, to be fair, there was a public call for comment
before the IAB adopted this.

OK - then you're NOT asking for discussion on whether to publish?  :-)   No worries - I can work with either.




As far as I can tell from the published RFC's - documents that
represent IAB consensus on a policy matter are mostly published as
"Editor"Â  and have something that identifies how you got there: E.g.
RFC8558 had Ted as editor and included this in the status:


This document is a product of the Internet Architecture Board
(IAB) and represents information that the IAB has deemed valuable
to provide for permanent record.  It represents the consensus of
the Internet Architecture Board (IAB).  Documents approved for 
publication by the IAB are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.

Documents that are more "spec"ish (i.e. the RFC v3 format) either
have an editor or a technical expert as the author.   And even then
you get the same statement - see RFC8546 and 8700

Those are the last three IAB stream documents published.   Going
back further a "tech"ish document omitted the "Consensus of the IAB" 
statement - RFC6574 - simply a report from a workshop.

That being said, these are all statements in the status section
which will be different from the ID to the RFC.

Yep, the above seems (to me) like a good comment that could
be handled without having to invent some new strict process
for IAB stream document boilerplate - I'd hope that some
variation in how these things are presented/worded is ok.

I think that it needs to be brought forward to the ID in some form - or it needs to be included in the call for comments.  Somewhere before the RFC editor gets it.  




It would be
useful for a policy document (I use the term "policy" loosely here)
to have that consensus statement be made somewhere.  Mostly in other
documents its pretty clear how we got there - some event, some
workshop, some question asked at a plenary that's being answered.

Here - I'm not sure what triggered the IAB into writing it and
worse, I'm not sure what affect you want it to have on the formal
IETF processes.  Context would be good, actionable recommendations
would be better.

That (the question of effects) seems like a separate
point. Surely section 4 of the draft is all about
actionable recommendations though so I'm a bit confused
as to what you mean?

The key word is "actionable".    I went back and re-read section 4 and what I got was aspirational rather than actionable.   

4.1. comes closest to actionable with the "hold a co-located workshop" comment.  And even that is kind of weak.  More along the lines of "To husband this process of getting community buy-in we've asked ISOC to work with us to create workshops for the next N ISOC meetings with each of those workshops targeted at one of these communities.  The IAB will provide an overview of the IETF process, near future architecture changes and challenges, and how non-participation by that community might result in an architecture which does not meet their needs.   We will then solicit involvement in an IAB sponsored workshop retreat whose output shall be a community centric set of guidelines that will be presented to the IETF community for possible inclusion in the standards process" -  or something like that.

I have no idea of what "We should also create explicit...." means in section 4.2.    If feels like a bit of a non sequitur here.  In any event, browsers are not protocols.  The underlying protocols evolved to meet functional and the browsers evolved GUI needs.  Discussing HTTP and HTML evolution rather than browsers in this section might be more appropriate and more on point for the IETF.  Then we can talk about how that maps to the IOT space and what we/IAB/IETF can do about it.

In 4.3 "Negative impact on users" not being defined limits defining useful actions.   At least consider how you might measure those impacts in a relatively objective way.  Maybe reach out to someone like KC for help in identifying ways to do those measurements.   If it can't be measured, then it's going to revert to politics and money.

4.4 seems to be a restatement of the Prisoner's dilemma problem in some form.    E.g. how do you identify and balance costs to entities that might not have any reason to cooperate? 

4.5 mostly deprioritizes the value of the work product of the standards writers vs the "needs of end users".  Basically, this doesn't meet the financial needs test.  Unless you're having the end users compensate the writers/implementers in some manner, there is little incentive to put their needs ahead of the writers.   At best, you can say that when choosing between two equally costly choices, you should pick the one that least impacts the end user - again - if you can identify that impact.


Later, Mike




Cheers,
S.


Later, Mike


--------------D13164B58EA5FDFB65EEDCF1-- From nobody Thu Feb 6 02:15:05 2020 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 146B5120233; Thu, 6 Feb 2020 02:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1EtxSyzgfRAy; Thu, 6 Feb 2020 02:14:54 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 2033E1200D6; Thu, 6 Feb 2020 02:14:54 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id p8so4924837oth.10; Thu, 06 Feb 2020 02:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tGRmWqqhXnT9+maZdREha/wkaRw8mX+FfPOjlbGqWlU=; b=uIxOQETzv0vE5+NHbUoXJajiG628CJUCLv2qXJzfi8i35PixA74/Ak6ylvt1OFqEF4 d8W0Yawt3QMRi+39nCWdvQSPvqIqd2NjfKCZO3LNMW3ni56Pz/k6rmpRLvp66SeDPR4H V4p7uFSLaOWLEZIRDsQM0SPx0x5rnaNbRMXWMraY6VFd02mnh8UxvidQSj8NIJ6djR0h K5NESk86DowlrCSiiukIgNoMmP+Y0aFYw3FYzEFc20oMrxI5ZgSfF0znY4CKSRQax1ij aMU3HdVi+Cw1UCvVInSW7ajTnJihcxg1Ij1yg0lwQ+ZZPKLGbqKvVzeHr/5BFOrboU3r Kmgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tGRmWqqhXnT9+maZdREha/wkaRw8mX+FfPOjlbGqWlU=; b=e35YOK4rG+OefJ4msBP25aPbR0tSd2SNtYhNvv49ehfaDDniwfkg3hdLDaya18lBZV gynwzfDuopVxBgbTfVvj5AvncbBQhSmddmtpIW2N3ohOmzkFiBjkvWC/D64W8ALpCj6G Rs2KHVNkkib5hIVQJ4HhmH7tPgp8rQHm5WLlroPAiwzd0zXj5ODjcQxTcxNMGt6npLrC 6++gw3qfxIPXE/p/0FGY/FNS3b5yTNWg67GgBlFDKo3+3LKy7FJ9Siu8vV0C+uNfmpOm xViT9cHtJn9HFnuqb1p0nlBSo06b+4X/1bjzy7I8GeD5ZLtQQlFUb+xXqLV6Wm06sW2F AjYw== X-Gm-Message-State: APjAAAXKAAF2u875dkGhIhRVo+vSu6bh9tWzFV9t+fvKWztpNzuPmOOt rkZgQkORAx3Fmg4q99LsaFKusdIOISETe+Y99UU= X-Google-Smtp-Source: APXvYqxOB8vi8qB9F597izqK54kPtEtLTx2nwruXYJNKW8CXOIiYTmhdsT0im593kTmkrdKDmtOnRyDF/q4L07nB/Ww= X-Received: by 2002:a9d:170a:: with SMTP id i10mr29412750ota.284.1580984093366; Thu, 06 Feb 2020 02:14:53 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 6 Feb 2020 02:14:52 -0800 (PST) In-Reply-To: <3c0fbc2f-87db-89f2-a1ad-b2233db38d25@comcast.net> References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <08e8a377-ec4c-00ca-eea8-fb8e882db1f5@cs.tcd.ie> <3c0fbc2f-87db-89f2-a1ad-b2233db38d25@comcast.net> From: Guntur Wiseno Putra Date: Thu, 6 Feb 2020 17:14:52 +0700 Message-ID: To: Michael StJohns Cc: Stephen Farrell , "last-call@ietf.org" , IAB , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047dd81059de58b18" Archived-At: Subject: Re: [arch-d] Call for Comment: (The Internet is for End Users) 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, 06 Feb 2020 10:14:58 -0000 --00000000000047dd81059de58b18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Concerning with section 4.1. of the draf "Engaging with Internet Community" may the "free" collecting of readings I am making inspire minds related with such a greater networked communities of reading, a greater networked libraries... (Minds which are perhaps about user-based interest groups, pedagogy of networks, savant networkers...?) I am "freely" collecting, among others, informational sources on how The Internet (Engineering Task Force) is about Society, Technology and Policy (1): ***### The Internet: Society, Technology and Policy A current situation of the Internet is among others about "society", "technology" and "policy" as it is shown by "2019 ISOC Global Internet Report Consolidation in the Internet Economy" especially section "Takeaways & Observations: Responses to Consolidation" pointing to "Examples of government responses", "Examples of responses from other stakeholders" and a question "Will governance efforts remain siloed"? (pp. 51-7) https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/= InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf The Internet (Engineering Task Force): Society, Technology and Policy I finded it out the IETF Journal: "IETF News: Integrating The Worlds of Technology Design and Policy" By: Dilawar Grewal PhD, Date: July 6 2016 RFC 3935-The mission Statement of the IETF said that high quality, relevant technical documents produced by the IETF to make the Internet works better are meant to =E2=80=9C=E2=80=A6influence the way people design, use, and ma= nage the Internet,=E2=80=9D alludes to things other than just technical standards. U= se and management are often related to things like policies, the human factor, behaviors, rights, acceptability, implementation criteria and protocols, and even politics. It is in this context that this paper explores the IETF experience for participants in the Internet Society Fellowship to the IETF Programme". https://www.ietfjournal.org/integrating-the-worlds-of-technology-design-and= -policy/ Another article "IETF News: Internet Regulators, Technologists Seek Ongoing Dialogue" By: Carolyn Duffy Marsan, Date: July 6, 2016 "The Internet Society should continue to foster dialogue between Internet policymakers and IETF technologists with the goal of creating a more open and secure Internet. That was the consensus of an Internet Society-sponsored panel discussion held in Buenos Aires during IETF 95 entitled, Public Policy and Internet Technology Development". https://www.ietfjournal.org/internet-regulators-technologists-seek-ongoing-= dialogue/ ... ... ... "IETF NEWS: ISOC Panel Addresses Regulation, Innovation, and the Internet" By: Carolyn Duffy Marsan, Date: October 6, 2011 "What will drive the Internet=E2=80=99s evolution in the future: market for= ces or government regulation? This was the topic debated by a panel of experts at an Internet Society-sponsored luncheon held in Quebec City in conjunction with the IETF 81 meeting. Panelists, including experts from across the IETF community, predicted a future of increasing regulation given how the Internet has become critical infrastructure for both government and industry. ...". https://www.ietfjournal.org/isoc-panel-addresses-regulation-innovation-and-= the-internet/ ***### Note: (1) It is in the "Internet Society Open Forum Library" I am making the "free" collection beginning with Manuel Catells" "Informationalism, Technology and Network Society", mediated by the ITU of the UN Report "...Leveraging Tech... and 2019 ISOC Global Internet Report especially of "Responses to Consolidation" looking at governments' and other stake holders' "Responses to Consolidation". Accessing the library needs an ISOC membership account as I knows it https://connect.internetsociety.org/viewdocument/informationalism-technolog= y-and-ne?CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Dlibraryd= ocuments#ItemCommentPanel Regard, Guntur Wiseno Putra Pada Kamis, 06 Februari 2020, Michael StJohns menulis: > On 2/5/2020 7:01 PM, Stephen Farrell wrote: > > Hiya, > > On 05/02/2020 23:51, Michael StJohns wrote: > > On 2/5/2020 6:30 PM, Stephen Farrell wrote > > I don't recall other documents being as formal as that about it, > but sure, if/when the IAB decide to publish this after community > comment then it could be clearer that it's an IAB document, e.g. by > having Mark as editor as you suggest. That it is an IAB document > seems fairly clear to me from the filename and from the IAB > adoption call etc. that was sent to this list back last June/July, > but I guess that's a while back. > > Um.. yes, I know it's an IAB stream document - which does not > necessarily imply that it is a consensus document of the entire IAB.> > And going back and re-reading the announcement, it looks too much > like a last call request rather than a call for "help us make the > document better".=C3=82 =C3=82 =C3=82 I'm not sure why anyone would assu= me that the > IAB hadn't yet decided to publish it or something very like it. > > Well, to be fair, there was a public call for comment > before the IAB adopted this. > > OK - then you're NOT asking for discussion on whether to publish? :-) > No worries - I can work with either. > > > As far as I can tell from the published RFC's - documents that > represent IAB consensus on a policy matter are mostly published as > "Editor"=C3=82 and have something that identifies how you got there: E.g= . > RFC8558 had Ted as editor and included this in the status: > > > This document is a product of the Internet Architecture Board > (IAB) and represents information that the IAB has deemed valuable > to provide for permanent record. It represents the consensus of > the Internet Architecture Board (IAB). Documents approved for > publication by the IAB are not candidates for any level of > Internet Standard; see Section 2 of RFC 7841. > > Documents that are more "spec"ish (i.e. the RFC v3 format) either > have an editor or a technical expert as the author.=C3=82 =C3=82 And eve= n then > you get the same statement - see=C3=82 RFC8546 and 8700 > > Those are the last three IAB stream documents published.=C3=82 =C3=82 Go= ing > back further a "tech"ish document omitted the "Consensus of the IAB" > statement - RFC6574 - simply a report from a workshop. > > That being said, these are all statements in the status section > which will be different from the ID to the RFC. > > Yep, the above seems (to me) like a good comment that could > be handled without having to invent some new strict process > for IAB stream document boilerplate - I'd hope that some > variation in how these things are presented/worded is ok. > > I think that it needs to be brought forward to the ID in some form - or i= t > needs to be included in the call for comments. Somewhere before the RFC > editor gets it. > > > It would be > useful for a policy document (I use the term "policy" loosely here) > to have that consensus statement be made somewhere.=C3=82 Mostly in othe= r > documents its pretty clear how we got there - some event, some > workshop, some question asked at a plenary that's being answered. > > Here - I'm not sure what triggered the IAB into writing it and > worse, I'm not sure what affect you want it to have on the formal > IETF processes.=C3=82 Context would be good, actionable recommendations > would be better. > > That (the question of effects) seems like a separate > point. Surely section 4 of the draft is all about > actionable recommendations though so I'm a bit confused > as to what you mean? > > The key word is "actionable". I went back and re-read section 4 and > what I got was aspirational rather than actionable. > > 4.1. comes closest to actionable with the "hold a co-located workshop" > comment. And even that is kind of weak. More along the lines of "To > husband this process of getting community buy-in we've asked ISOC to work > with us to create workshops for the next N ISOC meetings with each of tho= se > workshops targeted at one of these communities. The IAB will provide an > overview of the IETF process, near future architecture changes and > challenges, and how non-participation by that community might result in a= n > architecture which does not meet their needs. We will then solicit > involvement in an IAB sponsored workshop retreat whose output shall be a > community centric set of guidelines that will be presented to the IETF > community for possible inclusion in the standards process" - or somethin= g > like that. > > I have no idea of what "We should also create explicit...." means in > section 4.2. If feels like a bit of a non sequitur here. In any event= , > browsers are not protocols. The underlying protocols evolved to meet > functional and the browsers evolved GUI needs. Discussing HTTP and HTML > evolution rather than browsers in this section might be more appropriate > and more on point for the IETF. Then we can talk about how that maps to > the IOT space and what we/IAB/IETF can do about it. > > In 4.3 "Negative impact on users" not being defined limits defining usefu= l > actions. At least consider how you might measure those impacts in a > relatively objective way. Maybe reach out to someone like KC for help in > identifying ways to do those measurements. If it can't be measured, the= n > it's going to revert to politics and money. > > 4.4 seems to be a restatement of the Prisoner's dilemma problem in some > form. E.g. how do you identify and balance costs to entities that migh= t > not have any reason to cooperate? > > 4.5 mostly deprioritizes the value of the work product of the standards > writers vs the "needs of end users". Basically, this doesn't meet the > financial needs test. Unless you're having the end users compensate the > writers/implementers in some manner, there is little incentive to put the= ir > needs ahead of the writers. At best, you can say that when choosing > between two equally costly choices, you should pick the one that least > impacts the end user - again - if you can identify that impact. > > > Later, Mike > > > > Cheers, > S. > > > Later, Mike > > > > > > > > > --00000000000047dd81059de58b18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear architecture-discuss,



Concerning with section 4.1. of the draf "Engaging with Internet Commu= nity" may the "free" collecting of readings I am making insp= ire minds related with such a greater networked communities of reading, a g= reater networked libraries... (Minds which are perhaps about user-based int= erest groups, pedagogy of networks, savant networkers...?)


I am "freely" collecting, among others, informational sources on = how The Internet (Engineering Task Force) is about Society, Technology and = Policy (1):


***###

The Internet: Society, Technology and Policy


A current situation of the Internet is among others about "society&quo= t;, "technology" and "policy" as it is shown by "2= 019 ISOC Global Internet Report Consolidation in the Internet Economy"= especially section "Takeaways & Observations: Responses to Consol= idation" pointing to "Examples of government responses", &qu= ot;Examples of responses from other stakeholders" and a question "= ;Will governance efforts remain siloed"? (pp. 51-7)

=C2=A0https://future.internetsociety.org/2019/wp-content/upload= s/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheIn= ternetEconomy.pdf



The Internet (Engineering Task Force): Society, Technology and Policy

I finded it out the IETF Journal: "IETF News: Integrating The Worlds o= f Technology Design and Policy"
By: Dilawar Grewal PhD, Date: July 6 2016

RFC 3935-The mission Statement of the IETF said that high quality, relevant= technical documents produced by the IETF to make the Internet works better= are meant to =E2=80=9C=E2=80=A6influence the way people design, use, and m= anage the Internet,=E2=80=9D alludes to things other than just technical st= andards. Use and management are often related to things like policies, the = human factor, behaviors, rights, acceptability, implementation criteria and= protocols, and even politics. It is in this context that this paper explor= es the IETF experience for participants in the Internet Society Fellowship = to the IETF Programme".

https://www.ietfjournal.org/integrating-the-worlds-of-= technology-design-and-policy/


Another article "IETF News: Internet Regulators, Technologists Seek On= going Dialogue"
By: Carolyn Duffy Marsan, Date: July 6, 2016


"The Internet Society should continue to foster dialogue between Inter= net policymakers and IETF technologists with the goal of creating a more op= en and secure Internet. That was the consensus of an Internet Society-spons= ored panel discussion held in Buenos Aires during IETF 95 entitled, Public = Policy and Internet Technology Development".

https://www.ietfjournal.org/internet-regulators-techn= ologists-seek-ongoing-dialogue/

...
...
...



"IETF NEWS: ISOC Panel Addresses Regulation, Innovation, and the Inter= net"
By: Carolyn Duffy Marsan, Date: October 6, 2011

"What will drive the Internet=E2=80=99s evolution in the future: marke= t forces or government regulation? This was the topic debated by a panel of= experts at an Internet Society-sponsored luncheon held in Quebec City in c= onjunction with the IETF 81 meeting.

Panelists, including experts from across the IETF community, predicted a fu= ture of increasing regulation given how the Internet has become critical in= frastructure for both government and industry.

...".

https://www.ietfjournal.org/isoc-panel-addresses-= regulation-innovation-and-the-internet/



***###




Note:

(1) It is in the "Internet Society Open Forum Library" I am makin= g the "free" collection beginning with Manuel Catells" "= ;Informationalism, Technology and Network Society", mediated by the IT= U of the UN Report "...Leveraging Tech... and 2019 ISOC Global Interne= t Report especially of "Responses to Consolidation" looking at go= vernments' and other stake holders' "Responses to Consolidatio= n".


Accessing the library needs an ISOC membership account as I knows it

https://connect.internetsociety.o= rg/viewdocument/informationalism-technology-and-ne?CommunityKey=3D3a9fa082-= a518-475d-9e7f-ecec4ffe56dd&tab=3Dlibrarydocuments#ItemCommentPanel=





Regard,
Guntur Wiseno Putra



<= div>




Pada Kamis, 06 Feb= ruari 2020, Michael StJohns <mstjohns@comcast.net> menulis:
=20 =20 =20
On 2/5/2020 7:01 PM, Stephen Farrell wrote:
Hiya,

On 05/02/2020 23:51, Michael StJohns wrote:

On 2/5/2020 6:30 PM, Stephen Farrell wrote

I don't recall other documents being as formal as that a=
bout it,
but sure, if/when the IAB decide to publish this after community
comment then it could be clearer that it's an IAB document, e.g. by
having Mark as editor as you suggest. That it is an IAB document
seems fairly clear to me from the filename and from the IAB
adoption call etc. that was sent to this list back last June/July,=20
but I guess that's a while back.

Um.. yes, I know it's an IAB stream document - which does =
not=20
necessarily imply that it is a consensus document of the entire IAB.>
And going back and re-reading the announcement, it looks too much
like a last call request rather than a call for "help us make the
document better".=C3=82 =C3=82 =C3=82  I'm not sure why anyone wou=
ld assume that the
IAB hadn't yet decided to publish it or something very like it.

Well, to be fair, there was a public call for comment
before the IAB adopted this.

OK - then you're NOT asking for discussion on whether to publish?=C2=A0 :-)=C2=A0=C2=A0 No worries - I can work with either. 



      

        
As far as I can tell from the published RFC's - documents =
that
represent IAB consensus on a policy matter are mostly published as
"Editor"=C3=82  and have something that identifies how you got th=
ere: E.g.
RFC8558 had Ted as editor and included this in the status:



        

          
This document is a product of the Internet Architecture Boar=
d
(IAB) and represents information that the IAB has deemed valuable
to provide for permanent record.  It represents the consensus of
the Internet Architecture Board (IAB).  Documents approved for=20
publication by the IAB are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.


        

        
Documents that are more "spec"ish (i.e. the RFC v3 f=
ormat) either
have an editor or a technical expert as the author.=C3=82 =C3=82  And even =
then
you get the same statement - see=C3=82 RFC8546 and 8700

Those are the last three IAB stream documents published.=C3=82 =C3=82  Goin=
g
back further a "tech"ish document omitted the "Consensus of =
the IAB"=20
statement - RFC6574 - simply a report from a workshop.

That being said, these are all statements in the status section
which will be different from the ID to the RFC.


      

      
Yep, the above seems (to me) like a good comment that could
be handled without having to invent some new strict process
for IAB stream document boilerplate - I'd hope that some
variation in how these things are presented/worded is ok.

    

    
I think that it needs to be brought forward to the ID in some
      form - or it needs to be included in the call for comments.=C2=A0
      Somewhere before the RFC editor gets it.=C2=A0 

    

    


    

    

      

      

        
It would be
useful for a policy document (I use the term "policy" loosely her=
e)
to have that consensus statement be made somewhere.=C3=82  Mostly in other
documents its pretty clear how we got there - some event, some
workshop, some question asked at a plenary that's being answered.

Here - I'm not sure what triggered the IAB into writing it and
worse, I'm not sure what affect you want it to have on the formal
IETF processes.=C3=82  Context would be good, actionable recommendations
would be better.


      

      
That (the question of effects) seems like a separate
point. Surely section 4 of the draft is all about
actionable recommendations though so I'm a bit confused
as to what you mean?

    

    
The key word is "actionable".=C2=A0=C2=A0=C2=A0 I went bac=
k and re-read section
      4 and what I got was aspirational rather than actionable.=C2=A0=C2=A0=
=C2=A0 

    

    
4.1. comes closest to actionable with the "hold a co-located
      workshop" comment.=C2=A0 And even that is kind of weak.=C2=A0 Mo=
re along the
      lines of "To husband this process of getting community buy-in
      we've asked ISOC to work with us to create workshops for the next
      N ISOC meetings with each of those workshops targeted at one of
      these communities.=C2=A0 The IAB will provide an overview of the IETF
      process, near future architecture changes and challenges, and how
      non-participation by that community might result in an
      architecture which does not meet their needs.=C2=A0=C2=A0 We will the=
n
      solicit involvement in an IAB sponsored workshop retreat whose
      output shall be a community centric set of guidelines that will be
      presented to the IETF community for possible inclusion in the
      standards process" -=C2=A0 or something like that.

    
I have no idea of what "We should also create explicit...."=
; means
      in section 4.2.=C2=A0=C2=A0=C2=A0 If feels like a bit of a non sequit=
ur here.=C2=A0 In
      any event, browsers are not protocols.=C2=A0 The underlying protocols
      evolved to meet functional and the browsers evolved GUI needs.=C2=A0
      Discussing HTTP and HTML evolution rather than browsers in this
      section might be more appropriate and more on point for the IETF.=C2=
=A0
      Then we can talk about how that maps to the IOT space and what
      we/IAB/IETF can do about it.

    

    
In 4.3 "Negative impact on users" not being defined limits
      defining useful actions.=C2=A0=C2=A0 At least consider how you might =
measure
      those impacts in a relatively objective way.=C2=A0 Maybe reach out to
      someone like KC for help in identifying ways to do those
      measurements.=C2=A0=C2=A0 If it can't be measured, then it's =
going to revert
      to politics and money.

    

    
4.4 seems to be a restatement of the Prisoner's dilemma problem
      in some form.=C2=A0=C2=A0=C2=A0 E.g. how do you identify and balance =
costs to
      entities that might not have any reason to cooperate?=C2=A0 

    

    
4.5 mostly deprioritizes the value of the work product of the
      standards writers vs the "needs of end users".=C2=A0 Basica=
lly, this
      doesn't meet the financial needs test.=C2=A0 Unless you're ha=
ving the
      end users compensate the writers/implementers in some manner,
      there is little incentive to put their needs ahead of the
      writers.=C2=A0=C2=A0 At best, you can say that when choosing between =
two
      equally costly choices, you should pick the one that least impacts
      the end user - again - if you can identify that impact.

    

    


    

    
Later, Mike

    


    

    


    

    

      
Cheers,
S.



      

        
Later, Mike







        

        

      

    

    


    

  





--00000000000047dd81059de58b18--


From nobody Thu Feb  6 03:01:47 2020
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 394051202DD; Thu,  6 Feb 2020 03:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 To8_Njs9XdjD; Thu,  6 Feb 2020 03:01:43 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BC6120271; Thu,  6 Feb 2020 03:01:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1024; q=dns/txt; s=iport; t=1580986903; x=1582196503; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ORimX3mbWRO96EzLWOAaUQVj32W3ZZJBal6Yu3abQTs=; b=XHyONeo4gIafFIMFjsM7XFCcs6v9Stn3hb/Vy0JXX7oFAg6E3cmVBzWK j8HrpmpbUWHmRLq1D0oCI9jrOJr9jUcWmxrI/aP7qm3oilPWFq+f3ijOQ H22Qyvh0+KEMXeNOPwbeHg7ezJzT6NWX27Jem0D8qi5toqe+0K7JnWfxZ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAADM8Dte/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYIogUAhEoQ/iQOIJZlAgXsJAQEBDAEBLwEBhEACgmA?= =?us-ascii?q?2Bw4CAw0BAQQBAQECAQUEbYVDhWcBBAEdBlYQCxoCJgICVwYngxKCXCCqO3W?= =?us-ascii?q?BMoVKhRiBDioBjDuCAIE4IIJMPoRLgxAygiwEr2uCRIJOk3gbmwumVoMvAgQ?= =?us-ascii?q?GBQIVgVkIKj6BGjMaCBsVZQGBWWk9EhgNjlWOD0ADjmQBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,409,1574121600"; d="scan'208";a="23025425"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Feb 2020 11:01:41 +0000
Received: from dhcp-10-61-105-197.cisco.com (dhcp-10-61-105-197.cisco.com [10.61.105.197]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 016B1e1Q022790 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Feb 2020 11:01:40 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Eliot Lear 
In-Reply-To: 
Date: Thu, 6 Feb 2020 12:01:40 +0100
Cc: architecture-discuss@ietf.org, iab@iab.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> 
To: Michael StJohns 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-Outbound-SMTP-Client: 10.61.105.197, dhcp-10-61-105-197.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [arch-d] [Last-Call] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 11:01:45 -0000

Hi Mike,

>=20
> Does this document represent an IAB consensus/aspiration or is this =
Mark writing as an IAB member?
>=20
> If the former, Mark should be listed as Editor, and the document =
should include text indicating how the IAB arrived at consensus (e.g. =
"This document represents the consensus of the IAB arrived at through =
(internal discussions | discussions with the community | workshop =
results | etc) " ).   If the latter, the document should indicate "This =
document represents the author's personal opinion=E2=80=9D.


I think you have the wrong end of the stick on this one.  If those on =
the top material wrote the vast majority, there is not a need to claim =
only editorship.  The boilerplate at the front of the document makes it =
clear whether or not the document represents IAB consensus (see RFC =
7841).

This is as it should be.  Otherwise we are speaking in codes that people =
outside the club will not understand, and they have a hard enough time =
as is.

Eliot








From nobody Thu Feb  6 03:05:09 2020
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 0E3F71202DD; Thu,  6 Feb 2020 03:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 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, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BdSPZRt1qbwn; Thu,  6 Feb 2020 03:05:01 -0800 (PST)
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 67E0F12025D; Thu,  6 Feb 2020 03:05:01 -0800 (PST)
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 739FE6A25F; Thu,  6 Feb 2020 12:04:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1580987099; bh=D2bo8g47r6G3wg9LwfB8/mFCGbg+Yg643Tddj8LiHtI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=1/pzRGiT8OHk6bEyu95tZ61xwVrAGUU2zLBDGxccGknwnP1i5VG3py5fRrQaqlQdO cA7YSb1Uch/B7jRQSWjdX6N+4Ux6xBc4I5ZYTubAJMWUnzTj5QGETR4LHHymdUbVUo rhF5VyaKDEaiOOzQV8mcQppQA6vI0m1uaa+nvoLuWdxbSNdrKuhH84KUQwnA3Q3a7c BfK3lHQFqbJiUguudvIGWE5lz5KWNQfzGQ5BjsBtkFHOnwtuaV6CA/66ls71rMbJ3v JlmjUuccp9w//VTNI/3bj3LhvvUPAsU7DuZjSt5MVQ/2pS8oBfYwrVO3593WpId/P3 8rybaKecc+urg==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 66DAF3C0532; Thu,  6 Feb 2020 12:04:59 +0100 (CET)
Date: Thu, 6 Feb 2020 12:04:58 +0100 (CET)
From: Vittorio Bertola 
To: iab@iab.org, "architecture-discuss@ietf.org" , "last-call@ietf.org" 
Message-ID: <1446941636.8164.1580987099321@appsuite-gw2.open-xchange.com>
In-Reply-To: <052aa2af-1d52-16c3-b7b7-9d1df1a7590b@network-heretics.com>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <052aa2af-1d52-16c3-b7b7-9d1df1a7590b@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev3
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 11:05:05 -0000



  
   
 
 
  

   

  

  

   

    Il 06/02/2020 02:43 Keith Moore <moore@network-heretics.com> ha scritto:
   

   

    

   

   
   In this document, "end users," means non-technical users whose
   activities IETF standards are designed to support, sometimes
   indirectly.

   
s/non-technical users/non-technical human users/

  

  

   I'm starting from this because this is one of the comments which I have been making since -00, which was openly including commercial corporations as "end users". Definitions are really important when you adopt policy guidelines like this one, so it must be 101% clear that "end users" only includes individual human beings (though, as correctly said in the document, they can be connected to the Internet indirectly or represented by a piece of hardware or software).
   

  

  

   

  

  

   (By the way - almost 20 years ago, when I was writing a presentation for ICANN's At Large Advisory Committee, my native spellchecker Avri Doria suggested that I should always hyphenate "end-user", because my title "End user involvement in ICANN" could otherwise be interpreted in a completely different way :-) I think this is still a valid suggestion.)
   

  

  

   

  

  

   This is also why, in 3., the sentence "along with groups of them forming businesses, governments, clubs, civil society organizations, and other institutions" is problematic: what do you want to say here? If it is just that human beings form organizations, that's obvious; but if you say that all these entities are also end-users, this makes the document mostly useless, as in the end every stakeholder would be an end-user. This is why in general purpose policy systems, e.g. general elections, only individuals vote, and do so as individuals - their associations participate in other ways (i.e. specialized consultations, funding, lobbying etc.).
   

  

  

   

  

  

   A similar problematic term is "social good", used several times. The document seems to assume that "social good" is something that exists and can be defined uniquely - however, all modern Western governance systems are based on the assumption that there is not a single definition of "social good" agreed by everyone. The problem is not how to assess what the "social good" is in a given situation, but to balance multiple conflicting visions of what the "social good" would be.
  

  

   

  

  

   There are other visions; for example, the Chinese government is defining what actions are socially good or bad and giving scores to people (see 
   https://en.wikipedia.org/wiki/Social_Credit_System ). This is an attempt to define "social good" in a generally agreed, unique and objective way, and to make sure that people act "for the social good", but while this approach is culturally fit for collectivist societies like the Far Eastern ones, in individualist societies like the Western ones it horrifies people.
   

  

  

   

  

  

   So while the ambition of "doing the right thing" is of course much welcome, perhaps this point needs to be nuanced, recognizing that often there will be different visions of what is "socially good" for the end-users, and mediation will be more useful than spending months arguing against each other on what really constitutes the social good.
   

  

  

   

  

  

   This is also why I still find the start of page 6 problematic:
  

  

   

    Government representatives sometimes participate in the IETF community. While this is welcome, it should not be taken as automatically representative of end users elsewhere, or even all end users in the relevant jurisdiction. Furthermore, what is desirable in one jurisdiction (or at least to its administrators) might be detrimental in others (see Section 4.4).
   

   

    

   

   

    While some civil society organisations specialise in technology and Internet policy, they typically do not have the capacity to participate broadly, nor are they necessarily representative of the larger Internet community. Nevertheless, their understanding of end user needs is often profound, and they are in many ways the most representative advocates for end user concerns; they should be considered a primary channel for engaging the broader Internet community.
   

   

    

   

   

    A promising approach to help fill these gaps is to identify and engage with specifically affected communities; for example, one or more industry associations, user groups, or a set of individuals, though we can't of course formally ensure that they are appropriately representative.
   

  

  

   

  

  

   You are welcome to say that governments should not be the only ones to decide - indeed, that is the result of 20 years of conceptualization around multistakeholderism. However, we have now moved into the "digital sovereignty" age and many, outside of the US and China, are encouraging their governments to step back in and defend the rights of their citizens against the increasing centralization, commercialization and "surveillance-ization" of the Internet, and against its use as a global trade war instrument. Anything the IAB says on this will be taken as a position in this geopolitical debate.
   

  

  

   

  

  

   In this context, the repeated use of the word "representative" throughout the section is highly problematic, as representing people is the government's job, not civil society's job, and even multistakeholderism does not say that the roles have to be mixed or changed, only that multiple stakeholders should participate in the debate and that the debate should aim to promote rough consensus among stakeholders so that they voluntarily implement it in their respective roles. But no one ever challenged the fact that governments are representative or that they have the last word when it comes to law and public policy, much like corporations have the last word when it comes to their actions and so on. 
  

  

   

  

  

   So the IAB should just align with the existing framework and say the same thing (i.e., we must listen to all stakeholders and not only governments) without challenging the role of governments and without ranking which stakeholder is more important (so no "primary channel" please).
   

  

  

   

  

  

   Similarly, again (it must be the third time I say this), the "web browsers" paragraph in 4.2 is undemonstrated and inappropriate.
  

  

   

    For example, one of the most successful Internet applications is the Web. One of its key implementation roles is that of the Web browser - called the User Agent in [RFC7230] and other specifications. Because there are multiple interoperable implementations, users can switch with relatively low costs, and as a result there is a natural tendency to more carefully consider the user's needs as an agent. This leads to Web browsers' interests being better aligned with those of their users, creating an ecosystem that is more user-focused (even if there are serious challenges in it regarding the balance of power between implementations and the barrier to entry for new implementations).
   

  

  

   It is the legitimate perception of the author that web browser makers represent user interests well, but it is not that of many others, and I do not know of any objective analysis or data around this statement (nor one is provided in the text). Many would rather say that browsers are one of the applications where users have less choice and less controlling power, since you can switch between different implementations but there are very few of them and all are very similar. You have much more choice and variety in terms of email clients, but does this really mean that email client makers are great at representing the users?
  

  

   

  

  

   So this paragraph sounds to me like gratuitous flattering of a part of the IETF community, and implicitly also gratuitous disapproval towards other parts of the IETF community that in the author's opinion have not been as good as browsers towards the users. 
  

  

   

  

  

   If the point is that open interoperable standards (and open source implementations, I'd add) are in favour of users, let's make that one, though a mention of the phenomenon of open standards being used to implement walled gardens would also make sense, to note that open standards alone are not enough. But let's not single out anyone.
   

  

  

   

  

  

   Also, regarding the "body of guidance":
  

  

   

  

  

   

    The IAB and IETF have already established a body of guidance for situations where this sort of conflict is common, including (but not limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding privacy considerations.
   

  

  

   

  

  

   There is a contradiction in saying that the IETF has to take steps to involve more stakeholders than in the past, and yet say that things developed in the past without these stakeholders are already there and should constrain the result of future discussions. It is exactly the opposite - the IETF should have a broader discussion with non-technical stakeholders around these guidelines and see whether they really meet the needs of non-technical stakeholders.
  

  

   

  

  

   Also something that the IETF seems to be really bad at is revising its past consensus when circumstances change - it often happens that you point out a current issue and you are told "yes but this document from 15 years ago says it's not important so shut up" (I can tell you, this is very frustrating for new participants). End-users are very volatile in their opinions and requests, as public debates often show. Part of the work that needs to be done is to understand how to evolve past policy positions to meet new requests as new stakeholders join the debate and as the situation evolves.
   

  

  

   

  

  

   In the end, I see the merits of a statement in favour of individual end-users, as I have been one of the main advocates for their recognition in Internet governance venues for a long time. At the same time, this document seems to redefine multistakeholderism from "let's listen to all stakeholders and build consensus" (which, by the way, was entirely inspired by the IETF's rough consensus approach) to "let's prioritize one stakeholder over the others, and then let's see who can speak for it". This is an untested conceptual approach which is much more prone to capture or allegations thereof, and will raise eyebrows elsewhere in policy circles.
   

  

  

   

  

  

    However, the actionable recommendations in this document seem to be "make proactive efforts to involve more stakeholders" and "think in terms of end-user and social impact and document your thinking", and these are very reasonable, so perhaps the document could just focus on them.
   

  

  

   

  

  

   (I am wondering if I should propose text for some of the above observations, but I am not an IAB member so I do not know whether this would be appropriate.)
   

  

  

   
-- 

   
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

  
 
 



From nobody Thu Feb  6 06:23:37 2020
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 5E8C91208A4; Thu,  6 Feb 2020 06:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qAZFUHp3B-bA; Thu,  6 Feb 2020 06:23:28 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 3E76212092C; Thu,  6 Feb 2020 06:23:28 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id t13so4600656qto.3; Thu, 06 Feb 2020 06:23:28 -0800 (PST)
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=WU0cpws4mFPff/2AXuRV4WAS7WvITMqWnW57CeoBDBY=; b=si2cCilqlR3ywTd8/Kt6N95AcRSyjojqbC0v+eW8QyiaOLsd8z5huY3aqkk8m+kGq0 77BVmPIvDsZhtZfq9BlC5qjhMHcHS3hPQSq75VuzYCuIi7+LUydFgNa/Aa9wfHuWOPwd 8/7w/B75Y+O6Bdh/2HxPL2d0p1xb7WoajNCkP2xhbLKXcYDFbGzizululY6/m7v6zPx+ eBeYcYoatAKvVLdmOpeD1MJO2q9u66GV4OAGalZPxLxoJkf7CAPQbZ88Xn0k2CVABp+q Db5c4UxCT5WjbVJVCGOyADvZmJJgA3WkhUuZMfiQA+FkgMRNjua8fU/+UiaU/U/08CuY UMtw==
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=WU0cpws4mFPff/2AXuRV4WAS7WvITMqWnW57CeoBDBY=; b=T6mEKplizMqRId7lptsLfFCEFQFB285J+qAUoouJ0f+sYCcEnhOMnB7oEoEIw1ztRG twYpLUh/YAiYdNBb+Vr9OPiI9xZ6nbrljNG8+w/52Ow1mC6e/ra2o6DlrJIRlUlcgPBi XRy7Qz9vxSFbcIQOoGxIPE8qbHZUOrMQIu5FMLXzH9tKNsOg3rAyi2JhkjDVbKBlHEL8 DKs8Nw0e5XZRWDeeHotqIWDHNWifmKIlIGtlk0vwIMRtXd0kWf4EIlOqfh7PB7YYBeeg dpFo8IhcthgZnLQ8JseS8c7RbnvM6UxmVuQB+hm5lKvsVkNx7gmtMSOrkN80Pqbe7MUY URhA==
X-Gm-Message-State: APjAAAVS+pxMuYQKq+nfKOtQdMvrmSJ7fSna65XFv/MY5Vvu8mhpdMxJ nRc2MN/XB0oCT1DT+J1A7rqxoE63
X-Google-Smtp-Source: APXvYqx1z9i1HfzAa+Ivbh5L+TCBHZCFiOZwSfPJcKSRxnjW903olbm+yolqtTAeG9hpvICxFYIx0Q==
X-Received: by 2002:ac8:4446:: with SMTP id m6mr2894434qtn.159.1580999007000;  Thu, 06 Feb 2020 06:23:27 -0800 (PST)
Received: from ?IPv6:2607:fea8:6a0:1a5a:25c8:2911:e3e3:2aa2? ([2607:fea8:6a0:1a5a:25c8:2911:e3e3:2aa2]) by smtp.gmail.com with ESMTPSA id p135sm1496613qke.2.2020.02.06.06.23.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Feb 2020 06:23:26 -0800 (PST)
To: Vittorio Bertola , iab@iab.org, "architecture-discuss@ietf.org" , "last-call@ietf.org" 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <052aa2af-1d52-16c3-b7b7-9d1df1a7590b@network-heretics.com> <1446941636.8164.1580987099321@appsuite-gw2.open-xchange.com>
From: Rene Struik 
Message-ID: <295baf67-4be4-4ca1-c740-821e5180967b@gmail.com>
Date: Thu, 6 Feb 2020 09:23:23 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <1446941636.8164.1580987099321@appsuite-gw2.open-xchange.com>
Content-Type: multipart/alternative; boundary="------------A6472F957DF914BBA5EBAAC9"
Content-Language: en-US
Archived-At: 
Subject: Re: [arch-d] [Last-Call] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 14:23:32 -0000

This is a multi-part message in MIME format.
--------------A6472F957DF914BBA5EBAAC9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear colleagues:

Lots of points Vittorio Bertola made below resonate with me.

The presentation on the "Next Generation Internet" at CFRG [1] at the 
March 2019 meeting has useful pointers to "what the internet should be" 
vs. "what it has become". Another useful read is the "Weapons of Math 
Destruction" book [2]. Perhaps, one should indeed redesign the Internet 
from scratch to have a chance of benefiting the end-user (as defined by 
Vittorio), rather than entities where the user's data or mind control is 
the product.

Rene

Ref:
[1] 
https://datatracker.ietf.org/doc/slides-104-cfrg-next-generation-internet-open-calls/
[2] https://weaponsofmathdestructionbook.com/


On 2/6/2020 6:04 AM, Vittorio Bertola wrote:
>
>> Il 06/02/2020 02:43 Keith Moore  ha scritto:
>>
>>     In this document, "end users," means non-technical users whose
>>     activities IETF standards are designed to support, sometimes
>>     indirectly.
>>
>> s/non-technical users/non-technical human users/
>>
> I'm starting from this because this is one of the comments which I 
> have been making since -00, which was openly including commercial 
> corporations as "end users". Definitions are really important when you 
> adopt policy guidelines like this one, so it must be 101% clear that 
> "end users" only includes individual human beings (though, as 
> correctly said in the document, they can be connected to the Internet 
> indirectly or represented by a piece of hardware or software).
>
> (By the way - almost 20 years ago, when I was writing a presentation 
> for ICANN's At Large Advisory Committee, my native spellchecker Avri 
> Doria suggested that I should always hyphenate "end-user", because my 
> title "End user involvement in ICANN" could otherwise be interpreted 
> in a completely different way :-) I think this is still a valid 
> suggestion.)
>
> This is also why, in 3., the sentence "along with groups of them 
> forming businesses, governments, clubs, civil society organizations, 
> and other institutions" is problematic: what do you want to say here? 
> If it is just that human beings form organizations, that's obvious; 
> but if you say that all these entities are also end-users, this makes 
> the document mostly useless, as in the end every stakeholder would be 
> an end-user. This is why in general purpose policy systems, e.g. 
> general elections, only individuals vote, and do so as individuals - 
> their associations participate in other ways (i.e. specialized 
> consultations, funding, lobbying etc.).
>
> A similar problematic term is "social good", used several times. The 
> document seems to assume that "social good" is something that exists 
> and can be defined uniquely - however, all modern Western governance 
> systems are based on the assumption that there is not a single 
> definition of "social good" agreed by everyone. The problem is not how 
> to assess what the "social good" is in a given situation, but to 
> balance multiple conflicting visions of what the "social good" would be.
>
> There are other visions; for example, the Chinese government is 
> defining what actions are socially good or bad and giving scores to 
> people (see https://en.wikipedia.org/wiki/Social_Credit_System ). This 
> is an attempt to define "social good" in a generally agreed, unique 
> and objective way, and to make sure that people act "for the social 
> good", but while this approach is culturally fit for collectivist 
> societies like the Far Eastern ones, in individualist societies like 
> the Western ones it horrifies people.
>
> So while the ambition of "doing the right thing" is of course much 
> welcome, perhaps this point needs to be nuanced, recognizing that 
> often there will be different visions of what is "socially good" for 
> the end-users, and mediation will be more useful than spending months 
> arguing against each other on what really constitutes the social good.
>
> This is also why I still find the start of page 6 problematic:
>
>     Government representatives sometimes participate in the IETF
>     community. While this is welcome, it should not be taken as
>     automatically representative of end users elsewhere, or even all
>     end users in the relevant jurisdiction. Furthermore, what is
>     desirable in one jurisdiction (or at least to its administrators)
>     might be detrimental in others (see Section 4.4).
>
>     While some civil society organisations specialise in technology
>     and Internet policy, they typically do not have the capacity to
>     participate broadly, nor are they necessarily representative of
>     the larger Internet community. Nevertheless, their understanding
>     of end user needs is often profound, and they are in many ways the
>     most representative advocates for end user concerns; they should
>     be considered a primary channel for engaging the broader Internet
>     community.
>
>     A promising approach to help fill these gaps is to identify and
>     engage with specifically affected communities; for example, one or
>     more industry associations, user groups, or a set of individuals,
>     though we can't of course formally ensure that they are
>     appropriately representative.
>
>
> You are welcome to say that governments should not be the only ones to 
> decide - indeed, that is the result of 20 years of conceptualization 
> around multistakeholderism. However, we have now moved into the 
> "digital sovereignty" age and many, outside of the US and China, are 
> encouraging their governments to step back in and defend the rights of 
> their citizens against the increasing centralization, 
> commercialization and "surveillance-ization" of the Internet, and 
> against its use as a global trade war instrument. Anything the IAB 
> says on this will be taken as a position in this geopolitical debate.
>
> In this context, the repeated use of the word "representative" 
> throughout the section is highly problematic, as representing people 
> is the government's job, not civil society's job, and even 
> multistakeholderism does not say that the roles have to be mixed or 
> changed, only that multiple stakeholders should participate in the 
> debate and that the debate should aim to promote rough consensus among 
> stakeholders so that they voluntarily implement it in their respective 
> roles. But no one ever challenged the fact that governments are 
> representative or that they have the last word when it comes to law 
> and public policy, much like corporations have the last word when it 
> comes to their actions and so on.
>
> So the IAB should just align with the existing framework and say the 
> same thing (i.e., we must listen to all stakeholders and not only 
> governments) without challenging the role of governments and without 
> ranking which stakeholder is more important (so no "primary channel" 
> please).
>
> Similarly, again (it must be the third time I say this), the "web 
> browsers" paragraph in 4.2 is undemonstrated and inappropriate.
>
>     For example, one of the most successful Internet applications is
>     the Web. One of its key implementation roles is that of the Web
>     browser - called the User Agent in [RFC7230] and other
>     specifications. Because there are multiple interoperable
>     implementations, users can switch with relatively low costs, and
>     as a result there is a natural tendency to more carefully consider
>     the user's needs as an agent. This leads to Web browsers'
>     interests being better aligned with those of their users, creating
>     an ecosystem that is more user-focused (even if there are serious
>     challenges in it regarding the balance of power between
>     implementations and the barrier to entry for new implementations).
>
> It is the legitimate perception of the author that web browser makers 
> represent user interests well, but it is not that of many others, and 
> I do not know of any objective analysis or data around this statement 
> (nor one is provided in the text). Many would rather say that browsers 
> are one of the applications where users have less choice and less 
> controlling power, since you can switch between different 
> implementations but there are very few of them and all are very 
> similar. You have much more choice and variety in terms of email 
> clients, but does this really mean that email client makers are great 
> at representing the users?
>
> So this paragraph sounds to me like gratuitous flattering of a part of 
> the IETF community, and implicitly also gratuitous disapproval towards 
> other parts of the IETF community that in the author's opinion have 
> not been as good as browsers towards the users.
>
> If the point is that open interoperable standards (and open source 
> implementations, I'd add) are in favour of users, let's make that one, 
> though a mention of the phenomenon of open standards being used to 
> implement walled gardens would also make sense, to note that open 
> standards alone are not enough. But let's not single out anyone.
>
> Also, regarding the "body of guidance":
>
>     The IAB and IETF have already established a body of guidance for
>     situations where this sort of conflict is common, including (but
>     not limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on
>     pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973]
>     regarding privacy considerations.
>
>
> There is a contradiction in saying that the IETF has to take steps to 
> involve more stakeholders than in the past, and yet say that things 
> developed in the past without these stakeholders are already there and 
> should constrain the result of future discussions. It is exactly the 
> opposite - the IETF should have a broader discussion with 
> non-technical stakeholders around these guidelines and see whether 
> they really meet the needs of non-technical stakeholders.
>
> Also something that the IETF seems to be really bad at is revising its 
> past consensus when circumstances change - it often happens that you 
> point out a current issue and you are told "yes but this document from 
> 15 years ago says it's not important so shut up" (I can tell you, this 
> is very frustrating for new participants). End-users are very volatile 
> in their opinions and requests, as public debates often show. Part of 
> the work that needs to be done is to understand how to evolve past 
> policy positions to meet new requests as new stakeholders join the 
> debate and as the situation evolves.
>
> In the end, I see the merits of a statement in favour of individual 
> end-users, as I have been one of the main advocates for their 
> recognition in Internet governance venues for a long time. At the same 
> time, this document seems to redefine multistakeholderism from "let's 
> listen to all stakeholders and build consensus" (which, by the way, 
> was entirely inspired by the IETF's rough consensus approach) to 
> "let's prioritize one stakeholder over the others, and then let's see 
> who can speak for it". This is an untested conceptual approach which 
> is much more prone to capture or allegations thereof, and will raise 
> eyebrows elsewhere in policy circles.
>
> However, the actionable recommendations in this document seem to be 
> "make proactive efforts to involve more stakeholders" and "think in 
> terms of end-user and social impact and document your thinking", and 
> these are very reasonable, so perhaps the document could just focus on 
> them.
>
> (I am wondering if I should propose text for some of the above 
> observations, but I am not an IAB member so I do not know whether this 
> would be appropriate.)
>
> -- 
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com    
> Office @ Via Treviso 12, 10144 Torino, Italy
>

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867


--------------A6472F957DF914BBA5EBAAC9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Dear colleagues:

    


    

    
Lots of points Vittorio Bertola made
      below resonate with me. 

    

    


    

    
The presentation on the "Next
      Generation Internet" at CFRG [1] at the March 2019 meeting has
      useful pointers to "what the internet should be" vs. "what it has
      become". Another useful read is the "Weapons of Math Destruction"
      book [2]. Perhaps, one should indeed redesign the Internet from
      scratch to have a chance of benefiting the end-user (as defined by
      Vittorio), rather than entities where the user's data or mind
      control is the product.

    

    


    

    
Rene

    

    


    

    
Ref:

    
[1] https://datatracker.ietf.org/doc/slides-104-cfrg-next-generation-internet-open-calls/

    
[2] https://weaponsofmathdestructionbook.com/

    


    

    


    

    
On 2/6/2020 6:04 AM, Vittorio Bertola
      wrote:

    

    

      
      
      
 

      

      

        
 Il 06/02/2020 02:43 Keith Moore
          <moore@network-heretics.com> ha scritto: 

        
 

        

        
   In this document, "end users," means non-technical users whose
   activities IETF standards are designed to support, sometimes
   indirectly.

        
s/non-technical users/non-technical human users/

      

      
 I'm starting from this because this is one of the comments
        which I have been making since -00, which was openly including
        commercial corporations as "end users". Definitions are really
        important when you adopt policy guidelines like this one, so it
        must be 101% clear that "end users" only includes individual
        human beings (though, as correctly said in the document, they
        can be connected to the Internet indirectly or represented by a
        piece of hardware or software). 

      

      
 

      

      
 (By the way - almost 20 years ago, when I was writing a
        presentation for ICANN's At Large Advisory Committee, my native
        spellchecker Avri Doria suggested that I should always hyphenate
        "end-user", because my title "End user involvement in ICANN"
        could otherwise be interpreted in a completely different way :-)
        I think this is still a valid suggestion.) 

      

      
 

      

      
 This is also why, in 3., the sentence "along with groups of
        them forming businesses, governments, clubs, civil society
        organizations, and other institutions" is problematic: what do
        you want to say here? If it is just that human beings form
        organizations, that's obvious; but if you say that all these
        entities are also end-users, this makes the document mostly
        useless, as in the end every stakeholder would be an end-user.
        This is why in general purpose policy systems, e.g. general
        elections, only individuals vote, and do so as individuals -
        their associations participate in other ways (i.e. specialized
        consultations, funding, lobbying etc.). 

      

      
 

      

      
 A similar problematic term is "social good", used several
        times. The document seems to assume that "social good" is
        something that exists and can be defined uniquely - however, all
        modern Western governance systems are based on the assumption
        that there is not a single definition of "social good" agreed by
        everyone. The problem is not how to assess what the "social
        good" is in a given situation, but to balance multiple
        conflicting visions of what the "social good" would be. 

      
 

      

      
 There are other visions; for example, the Chinese government
        is defining what actions are socially good or bad and giving
        scores to people (see https://en.wikipedia.org/wiki/Social_Credit_System
        ). This is an attempt to define "social good" in a generally
        agreed, unique and objective way, and to make sure that people
        act "for the social good", but while this approach is culturally
        fit for collectivist societies like the Far Eastern ones, in
        individualist societies like the Western ones it horrifies
        people. 

      

      
 

      

      
 So while the ambition of "doing the right thing" is of
        course much welcome, perhaps this point needs to be nuanced,
        recognizing that often there will be different visions of what
        is "socially good" for the end-users, and mediation will be more
        useful than spending months arguing against each other on what
        really constitutes the social good. 

      

      
 

      

      
 This is also why I still find the start of page 6
        problematic: 

      

        
 Government representatives sometimes participate in the
          IETF community. While this is welcome, it should not be taken
          as automatically representative of end users elsewhere, or
          even all end users in the relevant jurisdiction. Furthermore,
          what is desirable in one jurisdiction (or at least to its
          administrators) might be detrimental in others (see Section
          4.4). 

        
 

        

        
 While some civil society organisations specialise in
          technology and Internet policy, they typically do not have the
          capacity to participate broadly, nor are they necessarily
          representative of the larger Internet community. Nevertheless,
          their understanding of end user needs is often profound, and
          they are in many ways the most representative advocates for
          end user concerns; they should be considered a primary channel
          for engaging the broader Internet community. 

        
 

        

        
 A promising approach to help fill these gaps is to
          identify and engage with specifically affected communities;
          for example, one or more industry associations, user groups,
          or a set of individuals, though we can't of course formally
          ensure that they are appropriately representative. 

      

      
 

      

      
 You are welcome to say that governments should not be the
        only ones to decide - indeed, that is the result of 20 years of
        conceptualization around multistakeholderism. However, we have
        now moved into the "digital sovereignty" age and many, outside
        of the US and China, are encouraging their governments to step
        back in and defend the rights of their citizens against the
        increasing centralization, commercialization and
        "surveillance-ization" of the Internet, and against its use as a
        global trade war instrument. Anything the IAB says on this will
        be taken as a position in this geopolitical debate. 

      

      
 

      

      
 In this context, the repeated use of the word
        "representative" throughout the section is highly problematic,
        as representing people is the government's job, not civil
        society's job, and even multistakeholderism does not say that
        the roles have to be mixed or changed, only that multiple
        stakeholders should participate in the debate and that the
        debate should aim to promote rough consensus among stakeholders
        so that they voluntarily implement it in their respective roles.
        But no one ever challenged the fact that governments are
        representative or that they have the last word when it comes to
        law and public policy, much like corporations have the last word
        when it comes to their actions and so on. 

      
 

      

      
 So the IAB should just align with the existing framework and
        say the same thing (i.e., we must listen to all stakeholders and
        not only governments) without challenging the role of
        governments and without ranking which stakeholder is more
        important (so no "primary channel" please). 

      

      
 

      

      
 Similarly, again (it must be the third time I say this), the
        "web browsers" paragraph in 4.2 is undemonstrated and
        inappropriate. 

      

        
 For example, one of the most
          successful Internet applications is the Web. One of its key
          implementation roles is that of the Web browser - called the
          User Agent in [RFC7230] and other specifications. Because
          there are multiple interoperable implementations, users can
          switch with relatively low costs, and as a result there is a
          natural tendency to more carefully consider the user's needs
          as an agent. This leads to Web browsers' interests being
          better aligned with those of their users, creating an
          ecosystem that is more user-focused (even if there are serious
          challenges in it regarding the balance of power between
          implementations and the barrier to entry for new
          implementations). 

      

      
 It is the legitimate perception of the author that web
        browser makers represent user interests well, but it is not that
        of many others, and I do not know of any objective analysis or
        data around this statement (nor one is provided in the text).
        Many would rather say that browsers are one of the applications
        where users have less choice and less controlling power, since
        you can switch between different implementations but there are
        very few of them and all are very similar. You have much more
        choice and variety in terms of email clients, but does this
        really mean that email client makers are great at representing
        the users? 

      
 

      

      
 So this paragraph sounds to me like gratuitous flattering of
        a part of the IETF community, and implicitly also gratuitous
        disapproval towards other parts of the IETF community that in
        the author's opinion have not been as good as browsers towards
        the users. 

      
 

      

      
 If the point is that open interoperable standards (and open
        source implementations, I'd add) are in favour of users, let's
        make that one, though a mention of the phenomenon of open
        standards being used to implement walled gardens would also make
        sense, to note that open standards alone are not enough. But
        let's not single out anyone. 

      

      
 

      

      
 Also, regarding the "body of guidance": 

      
 

      

      

        
 The IAB and IETF have already established a body of
          guidance for situations where this sort of conflict is common,
          including (but not limited to) [RFC7754] on filtering,
          [RFC7258] and [RFC7624] on pervasive surveillance, [RFC7288]
          on host firewalls, and [RFC6973] regarding privacy
          considerations. 

      

      
 

      

      
 There is a contradiction in saying that the IETF has to take
        steps to involve more stakeholders than in the past, and yet say
        that things developed in the past without these stakeholders are
        already there and should constrain the result of future
        discussions. It is exactly the opposite - the IETF should have a
        broader discussion with non-technical stakeholders around these
        guidelines and see whether they really meet the needs of
        non-technical stakeholders. 

      
 

      

      
 Also something that the IETF seems to be really bad at is
        revising its past consensus when circumstances change - it often
        happens that you point out a current issue and you are told "yes
        but this document from 15 years ago says it's not important so
        shut up" (I can tell you, this is very frustrating for new
        participants). End-users are very volatile in their opinions and
        requests, as public debates often show. Part of the work that
        needs to be done is to understand how to evolve past policy
        positions to meet new requests as new stakeholders join the
        debate and as the situation evolves. 

      

      
 

      

      
 In the end, I see the merits of a statement in favour of
        individual end-users, as I have been one of the main advocates
        for their recognition in Internet governance venues for a long
        time. At the same time, this document seems to redefine
        multistakeholderism from "let's listen to all stakeholders and
        build consensus" (which, by the way, was entirely inspired by
        the IETF's rough consensus approach) to "let's prioritize one
        stakeholder over the others, and then let's see who can speak
        for it". This is an untested conceptual approach which is much
        more prone to capture or allegations thereof, and will raise
        eyebrows elsewhere in policy circles. 

      

      
 

      

      
 However, the actionable recommendations in this document
        seem to be "make proactive efforts to involve more stakeholders"
        and "think in terms of end-user and social impact and document
        your thinking", and these are very reasonable, so perhaps the
        document could just focus on them. 

      

      
 

      

      
 (I am wondering if I should propose text for some of the
        above observations, but I am not an IAB member so I do not know
        whether this would be appropriate.) 

      

      

        
-- 

        

        
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

      

      

      

    

    


    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

  


--------------A6472F957DF914BBA5EBAAC9--


From nobody Thu Feb  6 06:29:00 2020
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 2C364120889 for ; Thu,  6 Feb 2020 06:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=k0+GDSDJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j7YpBbJP
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 iXo3DVNBIWmD for ; Thu,  6 Feb 2020 06:28:55 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF012080C for ; Thu,  6 Feb 2020 06:28:55 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AFB25478; Thu,  6 Feb 2020 09:28:53 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 06 Feb 2020 09:28:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8YXnKgoA6WmZIhs9dJpPsGdQgjl5khN gEd+w9/TdkAE=; b=k0+GDSDJixIQpZLzRM6k8bTbJ6etW0C3IKtS6iFIe2kL0Fp oLanm/bUSsJAkXR3vn1cQkyJ/Ld6Gujqyf8P/2uq3Cm11AK40XyhPhvbpoPNLMNI LPJ+a+xEnG0v70NRVgqy0kwDITgX/pHkvk8Hwa/gkpafHC0U8vYK7xMfqlZ4ZhIL qig7AD9jfcrrKTfDd+OKwd4RGKS4fs2JVInf3dJevlSNS7WCOsCa6ovIXHtO6wTk aATZXop1M/H/j0HrQ/fld8Tmxyc5JG1GEIs8uKi70TkVSmAqOlU4uVn7zahoSbmh gO6vC7s6FSov3oPQ5fCwym4dRXfMbO+qU5mAraQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8YXnKg oA6WmZIhs9dJpPsGdQgjl5khNgEd+w9/TdkAE=; b=j7YpBbJPtdJujcYbEZJlOv iKr3LF1vGxV9qxaX/Ie4guvYBOT4fET2wFP9IYKygvf6e0wIwSSiOOPHhn4K5sS9 L8PSxsCIWJ1VnvEMAbgjurRToZ1pUmZgKTTpwrIx7HAbLEU+tJBW30w9UGevYvJ3 TncMYm5D/LtpZZ2Uh7yGPCE0LtJ5N1hdLvd1GJ751BxBilnKQN1ijd9zTp63aw48 IVPMTIEEvLHV9kpVV/vPSLx3WJU3kOK62ElacADTH6jW0Rfhi7wiE4OCuejsjMMZ krTGWWl4UMtIAu0R3fjBhqnAGS9ukL7Xo/JhUaSFPXIDVfGAjtJIlizYubkSzp1Q ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpeiffedrohhrghdpfihikhhiphgvug hirgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E174FE00AF; Thu,  6 Feb 2020 09:28:52 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-Id: <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>
In-Reply-To: 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> 
Date: Thu, 06 Feb 2020 15:28:31 +0100
From: "Martin Thomson" 
To: "Joel M. Halpern" , architecture-discuss@ietf.org, iab@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [arch-d]  =?utf-8?q?=5BIAB=5D_Call_for_Comment=3A_=3Cdraft-iab-fo?= =?utf-8?q?r-the-users-02=3E_=28The_Internet_is_for_End_Users=29?=
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, 06 Feb 2020 14:28:58 -0000

Hi Joel,

On Thu, Feb 6, 2020, at 01:24, Joel M. Halpern wrote:
> But the underlying tone that the End User concerns should take 
> precedence over everything else seems to be incorrect.

Are you suggesting that it is incorrect in that it is not a provable statement in a mathematical sense and more a value judgment?

>From my perspective, that value judgment is right (in the moral sense) and that we should be saying this.  Having the IAB say this is also important, though I would of course be happier if the IETF said the same.  This statement is consistent with similar statements from the IETF (as referenced, RFC 3935), and other organizations (see for example the W3C position ).

As a letter to the IETF, I hope that it has weight, but it does not set out to have any sort of normative force.  Choosing a different basis from which to design a protocol would not automatically disqualify it from consideration for publication on the IETF stream, though I hope that people would be motivated to ask pointed questions or contest something that, for instance, might favour operations to the detriment of individual interests.  Arguably, we already do that; see RFCs 7871 and 7974 for published cases of where that happened with different results.

You cite some examples that seem to imply that you think that this general assertion is wrong in general, namely connected "stuff" and people who operate the network (though not those who build and design it, curiously).  Both of those concerns are addressed in the draft.  To sharpen those points: network operations exist to serve the network, which exists to serve the users of that network; devices exist to serve a range of use cases, which generally ultimately have users also.  Draw a longer chain and the value to people becomes more diffuse and abstract; see also .  But the draft also recognizes the potential for instances where the balance of interests might end up favouring other entities.

I do see this as a partial refutation of the tussle theory, to Bernard's point, but I don't see a need to address that more directly.

It's true that we cannot always predict the effect of our choices, but it seems to me that there is a prevailing attitude that says we MUST NOT consider things like social implications.  That to me is where we go wrong.  Good engineering considers all the requirements, not just the convenient ones.

Cheers,
Martin


From nobody Thu Feb  6 06:47:44 2020
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 02E57120930 for ; Thu,  6 Feb 2020 06:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=joelhalpern.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 74Nq42JUzKvn for ; Thu,  6 Feb 2020 06:47:34 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 85B2E120910 for ; Thu,  6 Feb 2020 06:47:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48D1Vt2VGqz6GD5P; Thu,  6 Feb 2020 06:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1581000454; bh=wvGPWmuXiZw8OfVu0eC9nKkh7ygmCk/OeuC3xB11R60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=S5DO0NctmiazSV8xOnCLUcmEMFbGAZ4km1EDz97Og/K+qtdagZEv8zoK65QbD4G6o 3W4heUpPjaNQXYdCuvvin5O/bUp+yMaDCxdd8tfvSM4IobXry3WLuwW3ZtE6H6kQlz gnVmNv/ehW7nrMpp0Bp36N42kH3KpZPizDY57ORE=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48D1Vs5WB8z6G8qB; Thu,  6 Feb 2020 06:47:33 -0800 (PST)
To: Martin Thomson , architecture-discuss@ietf.org, iab@iab.org
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>
From: Joel Halpern Direct 
Message-ID: 
Date: Thu, 6 Feb 2020 09:47:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [IAB] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 14:47:42 -0000

Yes, put simply, I think that declaring that the user's interest takes 
precedence over everything else is wrong.  You or the IAB as a whole are 
of course free to come to different conclusions, but I think it is 
actually very helpful to view it as a tussle with a veriety of itnerests 
that need to be respected.

If the IAB really wants to say that they think the tussle is over, I 
would expect to see the names of approving IAB members at the end of the 
document when this is done.  If, on the other hand the IAB considers 
this a useful perspective but not necessarily one they all agree with, 
then I would expect that to be clearly stated.

Personally, if the IAB takes the stance that this is a done deal, and 
the tussle is over, that will decrease the likelihood of my bothering to 
pay attention to the specifics (to the extent they exist) in the 
document.  Your choice.

Yours,
Joel

On 2/6/2020 9:28 AM, Martin Thomson wrote:
> Hi Joel,
> 
> On Thu, Feb 6, 2020, at 01:24, Joel M. Halpern wrote:
>> But the underlying tone that the End User concerns should take
>> precedence over everything else seems to be incorrect.
> 
> Are you suggesting that it is incorrect in that it is not a provable statement in a mathematical sense and more a value judgment?
> 
>  From my perspective, that value judgment is right (in the moral sense) and that we should be saying this.  Having the IAB say this is also important, though I would of course be happier if the IETF said the same.  This statement is consistent with similar statements from the IETF (as referenced, RFC 3935), and other organizations (see for example the W3C position ).
> 
> As a letter to the IETF, I hope that it has weight, but it does not set out to have any sort of normative force.  Choosing a different basis from which to design a protocol would not automatically disqualify it from consideration for publication on the IETF stream, though I hope that people would be motivated to ask pointed questions or contest something that, for instance, might favour operations to the detriment of individual interests.  Arguably, we already do that; see RFCs 7871 and 7974 for published cases of where that happened with different results.
> 
> You cite some examples that seem to imply that you think that this general assertion is wrong in general, namely connected "stuff" and people who operate the network (though not those who build and design it, curiously).  Both of those concerns are addressed in the draft.  To sharpen those points: network operations exist to serve the network, which exists to serve the users of that network; devices exist to serve a range of use cases, which generally ultimately have users also.  Draw a longer chain and the value to people becomes more diffuse and abstract; see also .  But the draft also recognizes the potential for instances where the balance of interests might end up favouring other entities.
> 
> I do see this as a partial refutation of the tussle theory, to Bernard's point, but I don't see a need to address that more directly.
> 
> It's true that we cannot always predict the effect of our choices, but it seems to me that there is a prevailing attitude that says we MUST NOT consider things like social implications.  That to me is where we go wrong.  Good engineering considers all the requirements, not just the convenient ones.
> 
> Cheers,
> Martin
> 


From nobody Thu Feb  6 06:50:22 2020
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 63BDF12094A for ; Thu,  6 Feb 2020 06:50:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGjw-gnBtomU for ; Thu,  6 Feb 2020 06:50:15 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A5912093F for ; Thu,  6 Feb 2020 06:50:15 -0800 (PST)
Received: from g2001-4878-a048-3000-5863-d58d-08b3-1347.deploy.static.akamaitechnologies.com (unknown [IPv6:2001:4878:a048:3000:5863:d58d:8b3:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id CD5805400D4; Thu,  6 Feb 2020 09:50:13 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Jared Mauch 
In-Reply-To: 
Date: Thu, 6 Feb 2020 09:50:12 -0500
Cc: Martin Thomson , architecture-discuss@ietf.org, iab@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <603EB83A-9FA0-4324-A3F7-AB893B52B823@puck.nether.net>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com> 
To: Joel Halpern Direct 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [arch-d] [IAB] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 14:50:21 -0000

> On Feb 6, 2020, at 9:47 AM, Joel Halpern Direct =
 wrote:
>=20
> Yes, put simply, I think that declaring that the user's interest takes =
precedence over everything else is wrong.  You or the IAB as a whole are =
of course free to come to different conclusions, but I think it is =
actually very helpful to view it as a tussle with a veriety of itnerests =
that need to be respected.

I would agree with your assertion that the internet is a multiple =
stakeholder environment.  Saying something is for the end-users when =
it=E2=80=99s a technology that is used by many people to build both =
public and private networks (which) could be a bold statement for those =
of us who operate large (private) networks.

- Jared=


From nobody Thu Feb  6 07:04:40 2020
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 5DFFA1208AF; Thu,  6 Feb 2020 07:04:37 -0800 (PST)
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,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 nGnm-uvMqNqb; Thu,  6 Feb 2020 07:04:35 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 341721200CC; Thu,  6 Feb 2020 07:04:34 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 016F21Xa026714; Thu, 6 Feb 2020 15:04:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ImjW0it7+4ITj2wdzNzUdM9tVskexM+TGrrNzRskIiA=; b=W4hUax2+mnuElmLLxjDLqO5Z54MLV3gd1yV9WDsJZWkJhMq+Xe1jyEcippvhZ1pT/FRG RwwImTX5DGjM+n0F7Db3PxVXoFxrCuqiFfEwMTrD9lcUBjIF9y6fFjYctY3IYp/9B38n 31R8ioE4/8h/Rq+fqpfhVzHm/YcJRWVPBM6tr67hHniyrfdSRDfp+PdcLnmixJJ7t6MP npo6Cdj/hpLpyIEvExT259jUQTe7FaIKftG8n+eoIc+GeLQe88VVGU9kCeVhCyEQ9gve gufieutjgg+tXaXaE5LdEcnZGM/ZCO1GVVDz9bjjRGa9+kdYYICwvXNCDeqiU/RpynZz cQ== 
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2xyhn5qrkk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 15:04:32 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 016F2BOL028892; Thu, 6 Feb 2020 10:04:32 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint8.akamai.com with ESMTP id 2xykfwd6xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 10:04:31 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 10:04:24 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 6 Feb 2020 10:04:24 -0500
From: "Salz, Rich" 
To: "architecture-discuss@ietf.org" , "iab@iab.org" 
Thread-Topic: Call for Comment:  (The Internet is for End Users)
Thread-Index: AQHV3HZ/I0DaxXiXykeehCHVI1JCW6gORIGA
Date: Thu, 6 Feb 2020 15:04:23 +0000
Message-ID: 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>
In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.22.0.200203
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.116.207]
Content-Type: text/plain; charset="utf-8"
Content-ID: <42AB02C76FC971498F597D08B15FFAB9@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-06_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=734 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002060115
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-06_01:2020-02-06, 2020-02-06 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 mlxlogscore=721 malwarescore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002060114
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 15:04:37 -0000

PiAgICBUaGUgZG9jdW1lbnQgaXMgYmVpbmcgY29uc2lkZXJlZCBmb3IgcHVibGljYXRpb24gYXMg
YW4gSW5mb3JtYXRpb25hbCBSRkMgDQogICAgd2l0aGluIHRoZSBJQUIgc3RyZWFtLCBhbmQgaXMg
YXZhaWxhYmxlIGZvciBpbnNwZWN0aW9uIGF0Og0KICAgIDxodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pYWItZm9yLXRoZS11c2Vycy8+DQogIA0KVGhlIHNlY29uZCBwYXJh
Z3JhcGggb2Ygc2VjdGlvbiA0LjIgaXMgZmF0YWxseSBmbGF3ZWQuICBJIHJhaXNlZCB0aGlzIGFz
IGFuIGlzc3VlIG9uIEdpdEh1YiB3ZWVrcyBhZ28uDQoNCgkiVGhpcyBsZWFkcyB0byBXZWIgYnJv
d3NlcnMnIGludGVyZXN0IGJlaW5nIGJldHRlciBhbGlnbiB3aXRoIHRob3NlIG9mIHRoZWlyIHVz
ZXINCg0KQmFsb25leS4gIEZvciBzb21lLCBtYXliZS4gQnV0IHRvIGdpdmUgYWxsIG9mIHRoZW0g
Y292ZXJhZ2UgYXMgYW4gb2ZmaWNpYWwgSUVURiBkb2N1bWVudD8gIE5vIHdheS4NCg0KDQo=


From nobody Thu Feb  6 07:06:54 2020
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 86A821208AF for ; Thu,  6 Feb 2020 07:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YF+yDTtn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QzPvM2iv
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 Cd363HySaEZM for ; Thu,  6 Feb 2020 07:06:48 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D2F1208AE for ; Thu,  6 Feb 2020 07:06:48 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0287E310; Thu,  6 Feb 2020 10:06:47 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 06 Feb 2020 10:06:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=BU4/lHSr4kkCdbCYiZJA6F0kNvvldCo SJ6Dla6DP7u4=; b=YF+yDTtng3LRdrVFpdhiQaVD53VJLCReB0kJnoxFds+QoqT xIoTt15WCsfXQSg2gcAsagFauXwec3+oWn7Cemus9QeeUEhYXMH5esWm/kDCkYZq 8+ZkltOq1xtmgm6asIpw+CBRWvTX6DJNQBWiP1WqB9cU0RKroC0L2Nd/Tb6KALU4 9Z2Jnx+tSCLMkX1X4aqNXX568iwEaZyJl7AKxD6BR2oSVC47eev4FJo99y4qUuvg 8YVBqb3P9w3EfCOVSB6Sb39eP4d4kD3oZnSsevtROgrOWwMt+k+d4hQg/DIlArcg UUGP8PpZZdtxblh0wSB1xk4DrwlA4gra7NNYHtg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BU4/lH Sr4kkCdbCYiZJA6F0kNvvldCoSJ6Dla6DP7u4=; b=QzPvM2ivM2APEw44mfuffg LniREJxE1PatyBKAH1/cO3TEVsR2RJVqIvVdmA+QbuPHPZGtKHwvzVcBhOBd/WFS Ex4Kdb3lzN7tc6l2PDcd+UqoO4mbZ67E5rGVP+xMaEiToihONzFcHN11BqaVQdcw ScSX4YbNukkUG9oLFCYwj3soJb1WNed0eG5AgX3+dIunn0dsq3f+ZE6T1tXiNwQq 6dqgZRXQX86/deZr+xtbaBky3vX9KoHKJXmqk3uuITsW7jaB5QNvYLz/NAtowVFz FxKZBwRoguF/i43TqUgVZVCLujsp89WR6IGEFxhOM7tecEvhInOQ2PbXqikZlnBg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 97096E00AF; Thu,  6 Feb 2020 10:06:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com> 
Date: Thu, 06 Feb 2020 16:06:25 +0100
From: "Martin Thomson" 
To: "Joel Halpern Direct" , architecture-discuss@ietf.org, iab@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [arch-d]  =?utf-8?q?=5BIAB=5D_Call_for_Comment=3A_=3Cdraft-iab-fo?= =?utf-8?q?r-the-users-02=3E_=28The_Internet_is_for_End_Users=29?=
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, 06 Feb 2020 15:06:50 -0000

On Thu, Feb 6, 2020, at 15:47, Joel Halpern Direct wrote:
> Yes, put simply, I think that declaring that the user's interest takes 
> precedence over everything else is wrong.

This statement implies that the draft is somewhat more absolutist than it is.  This recognizes the equities of over stakeholders and expresses an intent to *bias* toward end-user interests over those of others.  That doesn't invalidate the tussle, it just places a thumb on the scale; something Dave Clark suggested in his recent plenary talk (apologies for the appeal to authority there).

I infer from this that you also object to that notion also.  If so, then maybe we will just have to agree to disagree.


From nobody Thu Feb  6 07:12:04 2020
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 A7F0D1208AF for ; Thu,  6 Feb 2020 07:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 tHy6WUwDuRGa for ; Thu,  6 Feb 2020 07:12:01 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 5F4F3120288 for ; Thu,  6 Feb 2020 07:12:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48D2350xlpz6GD4v; Thu,  6 Feb 2020 07:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1581001921; bh=IBDImC1F+pc5mX/glSlE4RZoHATbFFElLN3IA3uYf70=; h=Subject:To:References:From:Date:In-Reply-To:From; b=e1rw0gnFaAGrZ+Oayd0cCgQnf9UpTuz38Q6oo9Ri/c1aErod+WJdjtipH6bxXNdb3 nTQXt0ZxB7AbQc2hnsq2FzuX/gfpu9SC7fqfQt6ZCa8z2CYkt8o5lz5AbTXmBMXOsd nRACBYfHlsZufg+7Fm2qNM81rB5phuMU9c3cMbts=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48D2343qkHz6GD4l; Thu,  6 Feb 2020 07:12:00 -0800 (PST)
To: Martin Thomson , architecture-discuss@ietf.org, iab@iab.org
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>  
From: Joel Halpern Direct 
Message-ID: 
Date: Thu, 6 Feb 2020 10:11:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [IAB] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 15:12:03 -0000

I do not object to a bias towards the user.  I would probably even agree 
with an assertion that the IETF in its designs has tended to place 
insufficient weight on the interests of the end users.
If that is your intent, you need to make significant adjustments in the 
wording.  Personally, I expect that would result in a better and more 
useful document.

Yours,
Joel

On 2/6/2020 10:06 AM, Martin Thomson wrote:
> On Thu, Feb 6, 2020, at 15:47, Joel Halpern Direct wrote:
>> Yes, put simply, I think that declaring that the user's interest takes
>> precedence over everything else is wrong.
> 
> This statement implies that the draft is somewhat more absolutist than it is.  This recognizes the equities of over stakeholders and expresses an intent to *bias* toward end-user interests over those of others.  That doesn't invalidate the tussle, it just places a thumb on the scale; something Dave Clark suggested in his recent plenary talk (apologies for the appeal to authority there).
> 
> I infer from this that you also object to that notion also.  If so, then maybe we will just have to agree to disagree.
> 


From nobody Thu Feb  6 07:35:08 2020
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 DB0941209A9 for ; Thu,  6 Feb 2020 07:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 XaOWLG49HvJK for ; Thu,  6 Feb 2020 07:35:05 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A412099F for ; Thu,  6 Feb 2020 07:35:03 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.79.123]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 016FYhMV028312 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Feb 2020 07:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1581003295; x=1581089695; i=@elandsys.com; bh=F+ZSRB+LBO3aVudSL0Y7yAB0nD7e3UAhVWrV7sT2lpc=; h=Date:To:From:Subject:In-Reply-To:References; b=UZHkVR/R3+20lZCAo+Oi70ARG5iQke+4MuaAmLqpMM7d2qx4+rDvBf7mMf6gMC2XV a/OajIapVctG7PSHZ+m7GLn++0JXnnwhijX7GxzZUw4B7wZKr+3rfzgGIw3JyNf3a1 ISmi1gOWrY2DIiwknheYghOAErcRsdtkJ9P+6nm8=
Message-Id: <6.2.5.6.2.20200206063251.12c5dc78@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 06 Feb 2020 07:23:54 -0800
To: Stephen Farrell , Martin Thomson , architecture-discuss@ietf.org
From: S Moonesamy 
In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl .com>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 15:35:06 -0000

Hi Stephen, Martin,
At 02:48 PM 05-02-2020, IAB Executive Administrative Manager wrote:
>This is an announcement of an IETF-wide Call for Comment on
>draft-iab-for-the-users-02.

This is the second request for comments issued by the Internet 
Architecture Board on a document which is intended to be a request 
for comments.  The first question could be whether there is any 
rationality in that.

Martin commented about predicting the effect of our choices.  How can 
the Internet Architecture Board provide long-range technical 
direction for Internet development if it cannot assess the potential 
consequences of its choices?

Regards,
S. Moonesamy 


From nobody Thu Feb  6 11:06:45 2020
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 966971200B2 for ; Thu,  6 Feb 2020 11:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nKKZHsxVtoxT for ; Thu,  6 Feb 2020 11:06:41 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C141200D8 for ; Thu,  6 Feb 2020 11:06:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=536; q=dns/txt; s=iport; t=1581016001; x=1582225601; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bKe/U/33yc3NLlqDILiDqmUmQhBpqeMV38+SQkKvuh8=; b=VIwFnjjQ0LZeV2Yz9jHENq5KJvv7Ssc6EtQEucILCq/avwoEs90M2ZVr bfuko9TWSgOia+i+1fj6AlV1+ERvNcNwrn8nTlWmwiDxP39r5ECPn3LN7 AzamunMvXaWjclxpJw8zJPcSrH6U/EBrPnU8tkF6ThFOVakuXXe0jEQkn M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAQAhYzxe/xbLJq1mHQEBAQkBEQU?= =?us-ascii?q?FAYFqBQELAYNpIBKEP4kDo14JAQEBDAEBLwEBhEACgmE3Bg4CAw0BAQQBAQE?= =?us-ascii?q?CAQUEbYVDhWcGHQZWEAsaAiYCAlcGgzmCfKxgdYEyhUqFEIEOKgGMPIIAgTg?= =?us-ascii?q?gghc1PoRLgxAygiwEr2uCRIJOk3gbgjiYU6ZWgy8CBAYFAhWBaCM+gRozGgg?= =?us-ascii?q?bFWUBgVlpPRIYDY5Vjg9AA456AQE?=
X-IronPort-AV: E=Sophos;i="5.70,410,1574121600"; d="scan'208";a="23039808"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Feb 2020 19:06:38 +0000
Received: from ams3-vpn-dhcp5100.cisco.com (ams3-vpn-dhcp5100.cisco.com [10.61.83.235]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 016J6cDm021373 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Feb 2020 19:06:38 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Eliot Lear 
In-Reply-To: 
Date: Thu, 6 Feb 2020 20:06:37 +0100
Cc: Martin Thomson , architecture-discuss@ietf.org, iab@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <237AAA98-D69A-49CD-895A-88F0C68F9AB4@cisco.com>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>   
To: Joel Halpern Direct 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-Outbound-SMTP-Client: 10.61.83.235, ams3-vpn-dhcp5100.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [arch-d] [IAB] Call for Comment:  (The Internet is for End Users)
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, 06 Feb 2020 19:06:43 -0000

At this point I find myself reasonably satisfied with where the document =
is going, and it has come a long way.  I like the broad description of =
users, and I think that=E2=80=99s quite appropriate.

I would only ask that the IAB do one more thing, which would be to take =
the opportunity to highlight cases where the advice would be actionable. =
 That has the added benefit of maybe identifying different user groups =
who should be brought into a conversation, a role to which the board =
should be well suited.

Eliot


From nobody Thu Feb  6 17:13:58 2020
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 1A996120130 for ; Thu,  6 Feb 2020 17:13:56 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 sz_Iev9Xy9II for ; Thu,  6 Feb 2020 17:13:53 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 A905912013B for ; Thu,  6 Feb 2020 17:13:53 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id l3so225895pgi.8 for ; Thu, 06 Feb 2020 17:13:53 -0800 (PST)
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:content-transfer-encoding; bh=MEnMFJMMijFlEGrwT8IqCOrb4LtegNP11wmzXtmuHSk=; b=R6eBS6PHHRFqpDDvcDGWwQJzIm4hF5e6yXnzQDniTMjXkILkKqfqn3ZTJGzjiI/tYY yV8tPIWk+puruB0KUmDZ0Z7jYzww7B2vYfpYALciiM7cw8qwpEECLZ0Tnqyfsv2r2A4W lCVsfxOuY+UqvATpUzcDbIPgwUAJRFfQwDDaEO0sXq6QNJVxvLpcxmV7BZefs/iGJoZ4 mjIk6YL5fPxUiM9/fbWWoNHLYN4FREe0QbyGUpbysp2QcC0z8LA85Io0oO7HwrZC2ywf NgpLwFMZaXpGa9hhyuPMFZF6cNb7R8gTUmia2tyil5k2udALrvK5qyzGE8Xn4w1l85mW N1oA==
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 :content-transfer-encoding; bh=MEnMFJMMijFlEGrwT8IqCOrb4LtegNP11wmzXtmuHSk=; b=I81F71D5QyoB8CHihLgIKR4iZ224L/o6BjrcHGqUGsHbYgzwsYiVuG9LRmL6t0wvxD QD7iOSuzVN6ZfJrvofyYfJ/0uux8JgZpM4xLtfqrF+W1v9M+TSUY6NQRr7BaQDUGUhzz 6MXmtF05lLSgBOgxo4vhi1uIqBqZCAgLxXhyNIW2Jjj8zTTqyLx48P6/GNDxrcXmIQAi 0uKYb1ODmNYQwQPIvAhszr1Hfk0TB4o2UzFDFtxwyACG/4BtAMPbjFzGqcSXhwrXt/vA NCqkKA4QrnZ87VnkhuawgGCbw+mdIy0YLOj4uwJYYDfXvsCPxTYjl6gZjsZ3j3w2Mub3 jVTg==
X-Gm-Message-State: APjAAAX9L9T6KNGxdfnz71vhWM1xLlnqtkHGpN+mJtPhLj/8qGuQ8lEk WMzLKgx4OUTlhep0zm8JmZ8=
X-Google-Smtp-Source: APXvYqxUJ0RH0RY3RWBwtGzzrsVfMc4PsFpR9+rFfcs5gS1QAKjaBrYopI14st4iepXQGiCafQrlpg==
X-Received: by 2002:a63:cc4a:: with SMTP id q10mr6678859pgi.241.1581038032932;  Thu, 06 Feb 2020 17:13:52 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id y18sm395641pfe.19.2020.02.06.17.13.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 17:13:52 -0800 (PST)
To: architecture-discuss@ietf.org, iab@iab.org
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>
From: Brian E Carpenter 
Message-ID: <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com>
Date: Fri, 7 Feb 2020 14:13:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 01:13:56 -0000

The Abstract makes it clear that this is an opinion piece:

> This document explains why the IAB believes ...

I think the document needs to state more clearly that it isn't prescriptive,
but is just the (current) IAB's opinion. This is subtle, but for example:

>    Beyond fulfilling the IETF's mission, prioritising end users also
>    helps to ensure the long-term health of the Internet and the IETF's
>    relevance to it.

would be better slightly rephrased as

   Beyond fulfilling the IETF's mission, prioritising end users would also
   help to ensure the long-term health of the Internet and the IETF's
   relevance to it.

and so on, wherever prescriptive language is used.

> 2.  What Are "End Users"?
> 
>    In this document, "end users," means non-technical users whose
>    activities IETF standards are designed to support, sometimes
>    indirectly.  

I don't like the unconditional "non-technical". Some users are very technical,
they're just not protocol experts. Some are highly educated, some are not.
Some may not even know they are Internet users, because they're just using
an app on their phone, or in the surveillance state they are just walking
past a camera.

>    Merely advancing the measurable success of the Internet (e.g.,
>    deployment size, bandwidth, latency, number of users) is not an
>    adequate goal; doing so ignores how technology is so often used as a
>    lever to assert power over users, rather than empower them.

I think that gets us into murky waters. Surely we aren't going to make
judgment calls in this area? Which of POP3 and IMAP allows more power
over users?

> 4.1.  Engaging the Internet Community...
>    Therefore, we have not only a responsibility to analyse and consider
>    the impacts of the IETF's work, but also a responsibility to consult
>    with that greater Internet community.  We should enter into a
>    dialogue about not only the technical concerns that are well-
>    represented in the IETF but also the political, social and economic
>    concerns that it engenders, and that are better represented
>    elsewhere.

I think the second sentence is a highly debatable assertion. Apart from
anything else, I thought it was the ISOC's job, in the accepted division
of labour according to BCP11.: https://tools.ietf.org/html/rfc2028#section-3.4
But equally important, I think we have good reason to believe that the
people who typically participate in the IETF are not the right sort of
people to engage usefully in dialogue about "political, social and economic
concerns". I think we will only burn our fingers.

I don't mean that the dialogue is unimportant. But I strongly believe that
we (the active participants in the IETF) are not the right people for the
job. This work should IMNSHO be left to ISOC.

A little bit later we find:

>    While some civil society organisations specialise in technology and
>    Internet policy, they typically do not have the capacity to
>    participate broadly, nor are they necessarily representative of the
>    larger Internet community.

Indeed. Except for ISOC.

I find this whole section "4.1.  Engaging the Internet Community" off track.
Instead, I believe it should recommend improved IETF engagement *with ISOC*,
with the objective of helping ISOC do this part of its job even better,
and giving the IETF substantive feedback as a result.

...
>    This leads to Web browsers' interests being better aligned with those
>    of their users, 

Really? In my experience browsers have become increasingly aligned with the
interests of advertisers. In any case, it's not much of an example since
the IETF doesn't control much of anything in browser space these days.

Regards
   Brian Carpenter

On 06-Feb-20 11:48, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on 
> draft-iab-for-the-users-02.
> 
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> 
> 
> The Call for Comment will last until 2020-03-04. Please send comments to
> architecture-discuss@ietf.org and iab@iab.org.
> 
> Abstract:
> 
>    This document explains why the IAB believes the IETF should consider
>    end users as its highest priority concern, and how that can be done.
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 


From nobody Fri Feb  7 01:01:37 2020
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 1D2AE12018D for ; Fri,  7 Feb 2020 01:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 n4MOAQwgkoph for ; Fri,  7 Feb 2020 01:01:34 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE6C120170 for ; Fri,  7 Feb 2020 01:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8757; q=dns/txt; s=iport; t=1581066094; x=1582275694; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=j1TH/0ups5YGZhEqm6P/I8GQ7OQgWSsXrstFV1YywRs=; b=RgPxlByOqJEnZ2WaAb1+saeqzBDGu7htCakXK1Qk63XCC3WQ/mgdjXCm aSfG7PtGJZ7rm9SA8axLxfvPTOzatslX3zVvqFTiRFMxZojTjB1qy7meU CA2nXJad+kbC2gj22amAQoEzqnnpIJcYVXtdtYWAwNHylYQTnwsXamDWb E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAABLJj1e/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYEkU4EdVCESKo0Yh38liWKJTogLCQEBAQw?= =?us-ascii?q?BASMMAQGEQAKCZDcGDgIDDQEBBAEBAQIBBQRthTcMhWYBAQEBAgEdXAULCxg?= =?us-ascii?q?uITYGE4MmAYJKAw4gD61ZgieFSoJvDYIaBoE4AYw8ggCBEScMFIJMPoIbSQE?= =?us-ascii?q?BAgGFJIIsBK8nRIJEgk6EfIpRhCsbmwuXToIojGCDLwIEBgUCFYFoIz6BGjM?= =?us-ascii?q?aCBsVZQGBWWg+EhgNjlWIT4VAQAMwAo5PAQE?=
X-IronPort-AV: E=Sophos; i="5.70,412,1574121600"; d="scan'208,217"; a="23063631"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Feb 2020 09:01:32 +0000
Received: from ams3-vpn-dhcp5100.cisco.com (ams3-vpn-dhcp5100.cisco.com [10.61.83.235]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 01791Vw5002971 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Feb 2020 09:01:31 GMT
From: Eliot Lear 
Message-Id: <70F445A3-CECF-4696-990D-0EA804BF962C@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_546AB957-36BE-4227-A0C9-945F87555E39"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Fri, 7 Feb 2020 10:01:31 +0100
In-Reply-To: <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com>
Cc: architecture-discuss@ietf.org, iab@iab.org
To: Brian E Carpenter 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-Outbound-SMTP-Client: 10.61.83.235, ams3-vpn-dhcp5100.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 09:01:36 -0000

--Apple-Mail=_546AB957-36BE-4227-A0C9-945F87555E39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Brian,

> On 7 Feb 2020, at 02:13, Brian E Carpenter =
 wrote:
>=20
> I think the second sentence is a highly debatable assertion. Apart =
from
> anything else, I thought it was the ISOC's job, in the accepted =
division
> of labour according to BCP11.: =
https://tools.ietf.org/html/rfc2028#section-3.4 =

> But equally important, I think we have good reason to believe that the
> people who typically participate in the IETF are not the right sort of
> people to engage usefully in dialogue about "political, social and =
economic
> concerns". I think we will only burn our fingers.


While that may be true, the IETF cannot just stuff this stuff off to the =
ISOC.  If work being taken on has societal consequences, the IETF should =
be aware of them, and better to have the impacted people represent their =
concerns themselves through direct participation in IETF processes, =
rather than ISOC attempting to proxy for them.

Eliot=

--Apple-Mail=_546AB957-36BE-4227-A0C9-945F87555E39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Brian,

On 7 Feb 2020, at 02:13, Brian E Carpenter =
<brian.e.carpenter@gmail.com> wrote:

I think the second sentence is a =
highly debatable assertion. Apart from
anything else, I thought it was the ISOC's job, in the =
accepted division
of labour according to BCP11.: https://tools.ietf.org/html/rfc2028#section-3.4
But equally important, I think =
we have good reason to believe that the
people who typically participate in the IETF are not the =
right sort of
people to =
engage usefully in dialogue about "political, social and =
economic
concerns". I =
think we will only burn our fingers.

While that may be true, =
the IETF cannot just stuff this stuff off to the ISOC.  If work =
being taken on has societal consequences, the IETF should be aware of =
them, and better to have the impacted people represent their concerns =
themselves through direct participation in IETF processes, rather than =
ISOC attempting to proxy for them.

Eliot
=

--Apple-Mail=_546AB957-36BE-4227-A0C9-945F87555E39--


From nobody Fri Feb  7 02:21:57 2020
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 00EE7120241 for ; Fri,  7 Feb 2020 02:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_HELO_NONE=0.001, SPF_PASS=-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 IqtpGbkCXJ2I for ; Fri,  7 Feb 2020 02:21:53 -0800 (PST)
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 C49C112022E for ; Fri,  7 Feb 2020 02:21:52 -0800 (PST)
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 249D16A272; Fri,  7 Feb 2020 11:21:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1581070908; bh=tR5Cpl+l8o8f2HygvPT4AE7lGEscQvPntU1vazowNUk=; h=Date:From:To:In-Reply-To:References:Subject:From; b=YTTkIhrEQ5eXNYyhgyxJKvWGwD+JZnONClfiVGa2ZxqhQWo63AlF7Dct+YSczhtye 6QtDGihDE+qqIursvadiUvT5PNCpz/GJtr2kdoCfYSkVnmTNfDtp9Dbq7siFRD8Yx2 u7iNQSEMOc6OONrgdLzjdCkVj1eUUVit8WB0nie6ET6u4zIt2LMqTpOzWZ9CtsN1U8 F7wR+7oL8ibsdKU1tipQv9FCvzNPLi3IuKKGE1Z+HcUlpe8ybvwKDAIsNz2duADU6C wJ0MoxgUJUh2K81ZP7fCl17rJDjUkH5iY8mQNsDWhpMCzFP5eftB8pUNtlAv15mMQ9 fZBzLwNq0P7rA==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 16F793C0158; Fri,  7 Feb 2020 11:21:48 +0100 (CET)
Date: Fri, 7 Feb 2020 11:21:47 +0100 (CET)
From: Vittorio Bertola 
To: Brian E Carpenter , architecture-discuss@ietf.org, iab@iab.org
Message-ID: <597042151.11351.1581070907998@appsuite-gw2.open-xchange.com>
In-Reply-To: <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev3
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 10:21:55 -0000

> Il 07/02/2020 02:13 Brian E Carpenter  ha scritto:
> 
> >    While some civil society organisations specialise in technology and
> >    Internet policy, they typically do not have the capacity to
> >    participate broadly, nor are they necessarily representative of the
> >    larger Internet community.
> 
> Indeed. Except for ISOC.
> 
> I find this whole section "4.1.  Engaging the Internet Community" off track.
> Instead, I believe it should recommend improved IETF engagement *with ISOC*,
> with the objective of helping ISOC do this part of its job even better,
> and giving the IETF substantive feedback as a result.

While parsing your comment, it occurred to me that perhaps we are thinking at two different definitions of "the Internet Community" (as used, but not defined, in the document). I understood "the Internet community" to include any individual that uses the Internet, i.e. several billion people. But perhaps you are thinking only of the technical community?

Otherwise, even in specialised Internet policy venues such as the IGF, you will find very few non-technical individuals and organizations that feel represented by ISOC. It is usually considered as an organization strictly for the Internet industry, an old engineers club focused on the promotion of those specific views and interests. In a way, the IETF speaking with ISOC would be perceived like the IETF speaking with itself.

(Actually, thinking at it, the outrage sparked among many NGOs by ISOC's actions on dot org is good evidence that the two sets of interests are at odds.)

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy


From nobody Fri Feb  7 07:54:17 2020
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 96A57120970 for ; Fri,  7 Feb 2020 07:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=cNI44Rpa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xTUuHKI2
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 LbkVVQ4BCi83 for ; Fri,  7 Feb 2020 07:54:12 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D236120914 for ; Fri,  7 Feb 2020 07:54:12 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 92E29483; Fri,  7 Feb 2020 10:54:11 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 07 Feb 2020 10:54:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=H p8p5kYNekXo5asoLFVw2ObDNJhqM3Qqzls/JEJ1YNA=; b=cNI44RpaHdiGKzWPZ jTXorTRSaXJFJMny3fpEvKdBIHH8lTWLBiGx2B+jrDyR3e8TlrPq4uV2rPT4xKFK 9uozU9W+WWPAG3PQn36YLyCif8FRq5dxLV0phVAzzJkkYbXO2utYyHo8WMVlqFeD iimfj0SQk/+/uI9N9aeWjDENljJ2MxEJyVGJVxP+QeMfv81NqopdFXKOYa9VnKtb pFVAjqKe8KuyS64ti6zsoOk3sC7nzsWl/0Mnm2yWzeH6mKnEsMnUQVPqblX/0clC 92OYBLuF13bKkBGeFqFa+QhN+taYNixLk7FBaM8KFN99OzoYAQN4lOnQPFyvON9w 94qhQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Hp8p5kYNekXo5asoLFVw2ObDNJhqM3Qqzls/JEJ1Y NA=; b=xTUuHKI2kcl7Qqonmalj1XofiLDa6tOlOlY1+opigqrZfLv9m7qVl9NAe 4Cms92kC9uuH9j5NXEQMxgyVxfF+qAYwYqHDzu+DHUFq5KJV50w8nqcuEUNtbL4a iVTJp6Es5827U/IPWRhpXpWPJePFcTPSlt51Q0eVv2WwWb3/u9UAohsV23EOZuR/ Htfg1zSd/oViqc331H0nQrzS69YPYj2Qhs/eBvHt9zHBCk8VWYWyRXmL7D3JD69M +Jh/nwYg5ghzFiHJtMbG9A6VrhzIeLpwj/zutzVYEuM175U6WXvjSeW9s1LEwB8M 8WAwlhK9W2r0BMBg0WpLHwBlKPL6w==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppeegiedrudegtddruddviedrudek necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnoh htsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from surfer-172-29-7-241-hotspot.internet-for-guests.com (unknown [46.140.126.18]) by mail.messagingengine.com (Postfix) with ESMTPA id A7E0B3060701; Fri,  7 Feb 2020 10:54:08 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Mark Nottingham 
In-Reply-To: 
Date: Fri, 7 Feb 2020 16:54:06 +0100
Cc: Martin Thomson , architecture-discuss@ietf.org, iab@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com>  <17b0861f-079f-4a12-914b-d88a9056ccd2@www.fastmail.com>   
To: Joel Halpern Direct 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [arch-d] [IAB] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 15:54:15 -0000

Hi Joel,

Just my personal .02 -- I think there are some adjustments we can make =
to parts of the document -- in particular, the abstract -- to avoid the =
impression that it's a declaration of the tussle being over. That having =
been said, I very much agree with Martin's characterisation here =
regarding "thumbs on scales".=20

Cheers,



> On 6 Feb 2020, at 4:11 pm, Joel Halpern Direct =
 wrote:
>=20
> I do not object to a bias towards the user.  I would probably even =
agree with an assertion that the IETF in its designs has tended to place =
insufficient weight on the interests of the end users.
> If that is your intent, you need to make significant adjustments in =
the wording.  Personally, I expect that would result in a better and =
more useful document.
>=20
> Yours,
> Joel
>=20
> On 2/6/2020 10:06 AM, Martin Thomson wrote:
>> On Thu, Feb 6, 2020, at 15:47, Joel Halpern Direct wrote:
>>> Yes, put simply, I think that declaring that the user's interest =
takes
>>> precedence over everything else is wrong.
>> This statement implies that the draft is somewhat more absolutist =
than it is.  This recognizes the equities of over stakeholders and =
expresses an intent to *bias* toward end-user interests over those of =
others.  That doesn't invalidate the tussle, it just places a thumb on =
the scale; something Dave Clark suggested in his recent plenary talk =
(apologies for the appeal to authority there).
>> I infer from this that you also object to that notion also.  If so, =
then maybe we will just have to agree to disagree.
>=20
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

--
Mark Nottingham   https://www.mnot.net/


From nobody Fri Feb  7 11:35:01 2020
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 BB9A112011C for ; Fri,  7 Feb 2020 11:34:59 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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 WgXgcZkMcg0c for ; Fri,  7 Feb 2020 11:34:58 -0800 (PST)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 6A8841200FE for ; Fri,  7 Feb 2020 11:34:58 -0800 (PST)
Received: by mail-pj1-x102e.google.com with SMTP id r67so1335849pjb.0 for ; Fri, 07 Feb 2020 11:34:58 -0800 (PST)
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:content-transfer-encoding; bh=iICLVw5GVrH353cMKlM8gxneF6JOE6pNZZ+W8M8n1c8=; b=mvKZGEfkadH2xOHCMxs0heslsXDgZ/upnrSubiXKJMGFRQriQ8US0X3ajAklYirCvr yddF/wVY+0cyJx75IukGFhDHqVeuSddUE9kKeUYGZpV5gF11BTRAznJOq8QyM0ndhd9g 781l6OlqJT9hBTcxfMPUGIOeh0ntHGdepWdWsMK8DCqPln5mMBHFK/qTI1g5x18V7IEq Xt5faZLlfvNyalazqj5JvxzkWLaugP4VRHNHQQrSJPgQl5U/JtAsuMMI4MA4i3qAAgTA YddfbFIGsINaGve9TRccDpN+Ts+b92rqrDQ1u0GGPeFGkk31aYBTyNkZVVi0pHYvcqji DWNw==
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 :content-transfer-encoding; bh=iICLVw5GVrH353cMKlM8gxneF6JOE6pNZZ+W8M8n1c8=; b=SO5EWHIZGkBtJnculMy8iXSyAPQ7vlwUex7AbgRbf1jRbib9xcBs4zYVATfnpYpyP/ V2C683foW0AQX8rQKMjlJ7mIU3J8FSB9zOoJ23rI+Cgios/B7AflKTVcG69aMGQ/rARP Bv7uh5/OM5e5S3TGjrZBxaCl8vSkH/S0Q7RRcShCU5rLuLCRwmJrWOwIq06ShNNRNaDi 0qfJla1K/JB0ccaT5ECvrMUFIKqYOTUJWGuzdViIYRUjhW1LpURk/ibDxGz8IdHgkad3 fEyoohB1usAP2w4ksVhhniQfpKzTuAYeRDP5r8JoIAkdekfHjry6pA3DY5gn4LJvDKhy WK5w==
X-Gm-Message-State: APjAAAVGB536LQn9WwL2xXpspCUrz6nAicZOQLNTKh7OQJD1CdV0f2uJ E/o4DpXNoZM/EMeamXwLSsEZ63r5
X-Google-Smtp-Source: APXvYqwiwFS2CGcwznGaGw/s/AhbcpJBjPUWrsI432BYgtSge5uKrJf+UeYc1pIgTGVtJx7QLC0H/g==
X-Received: by 2002:a17:90a:cb11:: with SMTP id z17mr5641733pjt.122.1581104097828;  Fri, 07 Feb 2020 11:34:57 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id b3sm3487539pjo.30.2020.02.07.11.34.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 11:34:57 -0800 (PST)
To: Vittorio Bertola , architecture-discuss@ietf.org, iab@iab.org
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com> <597042151.11351.1581070907998@appsuite-gw2.open-xchange.com>
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 8 Feb 2020 08:34:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <597042151.11351.1581070907998@appsuite-gw2.open-xchange.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 19:35:00 -0000

Hi Vittorio,
On 07-Feb-20 23:21, Vittorio Bertola wrote:
> 
>> Il 07/02/2020 02:13 Brian E Carpenter  ha scritto:
>>
>>>    While some civil society organisations specialise in technology and
>>>    Internet policy, they typically do not have the capacity to
>>>    participate broadly, nor are they necessarily representative of the
>>>    larger Internet community.
>>
>> Indeed. Except for ISOC.
>>
>> I find this whole section "4.1.  Engaging the Internet Community" off track.
>> Instead, I believe it should recommend improved IETF engagement *with ISOC*,
>> with the objective of helping ISOC do this part of its job even better,
>> and giving the IETF substantive feedback as a result.
> 
> While parsing your comment, it occurred to me that perhaps we are thinking at two different definitions of "the Internet Community" (as used, but not defined, in the document). I understood "the Internet community" to include any individual that uses the Internet, i.e. several billion people. But perhaps you are thinking only of the technical community?

Well, as Christian Huitema pointed out in a different context (RFC Editor discussion), the notion of the technical community has very fuzzy boundaries. However, I was indeed thinking of the wider community, not the technical community. Holding a dialogue with the wider community is immensely difficult, and we've known that for 25 years. I'll come back to that in a moment when I reply to Eliot.
 
> Otherwise, even in specialised Internet policy venues such as the IGF, you will find very few non-technical individuals and organizations that feel represented by ISOC. It is usually considered as an organization strictly for the Internet industry, an old engineers club focused on the promotion of those specific views and interests. In a way, the IETF speaking with ISOC would be perceived like the IETF speaking with itself.

I think that's a profound misunderstanding of ISOC, but it illustrates *exactly* why the IETF would do an even worse job of talking to 8 billion people than ISOC does. I have no concept at all of what the IETF could do to even attempt such a dialogue. If after 28 years the ISOC hasn't found out how to do it, we certainly can't.
 
> (Actually, thinking at it, the outrage sparked among many NGOs by ISOC's actions on dot org is good evidence that the two sets of interests are at odds.)

The big problem is the profound differences of understanding. I won't say more since that would send us wildly off topic.

Regards
    Brian


From nobody Fri Feb  7 11:51:32 2020
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 0544C120862 for ; Fri,  7 Feb 2020 11:51:31 -0800 (PST)
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_HELO_NONE=0.001, 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 ROrm2ATj8Ac3 for ; Fri,  7 Feb 2020 11:51:29 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 0885B12011C for ; Fri,  7 Feb 2020 11:51:29 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id b9so290372pgk.12 for ; Fri, 07 Feb 2020 11:51:29 -0800 (PST)
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=Iln0L90XiHgluYLFaqF2DttjlpojkQJdvacNfLVzCi4=; b=EU99TLVXrWexoydQGbnXWCgsySgTxexe6F3x3dkup5663VXa3z9MnwRxPnJWYA8iwN PrqkqMvjzr+TO+ITD/yB/0nu/yzLcxsJPW7vDgUU8B57EHtw11QymF1IRBnGHHc0G9la YreYRf2nKIDptGLbugN6p98fD3KrsbrxeEcZdsK05qfy5nJLF49AWw+8uVkhvMlx1nY1 rckQ3RLSrX/N736u33XsIZ08rrvpwUB553+67//CWVFN3bEbpD/Ga1+s17YqAg0SSlFT zZmyerSsNSLzpgYsJKGN7RCnlLQDLZpGHzwGj9Um5uadJBBZzZWpLq9bS1phRonSEkgU IKzA==
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=Iln0L90XiHgluYLFaqF2DttjlpojkQJdvacNfLVzCi4=; b=OCdFnHjjzyNKcV8uqWdpN0UPacm27uhOl+H6L8UuRYEW8DRgGRn9ITGnNdaXmliXxx WYpg2Qc/vVX+fciS8ibtHaqlJGaCNVZaipB0UmcreCJh4r4BdocfDMbXJhk5qi3S2S7J UJ/cF3O8F5uNlVDsM58k60VY09+TNBgTW5g0+3DXeAHGjCOeZezyHfgBje2hncc7lKR/ pPD111PIGSwGZbP8WbLkDFwx1PBn2z4kfqrnjatKo1wvw1bbnXjhRkzfHkTPWN6lLWLP lngDJED6pAUek6oYFRVn9isd789Jc1W0/3wch6Lt0QYDd6DzLZifU5TeRU761aoiSFx8 bIWg==
X-Gm-Message-State: APjAAAXXg3B8PnyS9rXbFSAazcrAKCSv7WiP6rjP9PSfcAbzOGj2/9Fj t29zx+GTbf2sg+D/pYuhpxRKN/NT
X-Google-Smtp-Source: APXvYqy5PaOw76z/brAXmceFy5WdNA5IiMNf3gkBxnkUr7+jHf0omCc0ZKyVpokYqEPrfajuPgtSdA==
X-Received: by 2002:a63:5508:: with SMTP id j8mr838555pgb.170.1581105088492; Fri, 07 Feb 2020 11:51:28 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id d3sm3417954pjx.10.2020.02.07.11.51.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 11:51:27 -0800 (PST)
To: Eliot Lear 
Cc: architecture-discuss@ietf.org, iab@iab.org
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com> <70F445A3-CECF-4696-990D-0EA804BF962C@cisco.com>
From: Brian E Carpenter 
Message-ID: <724115e2-345c-db3d-2190-6cd7ef9dce82@gmail.com>
Date: Sat, 8 Feb 2020 08:51:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <70F445A3-CECF-4696-990D-0EA804BF962C@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 07 Feb 2020 19:51:31 -0000

Hi Eliot,

On 07-Feb-20 22:01, Eliot Lear wrote:
> Hi Brian,
>=20
>> On 7 Feb 2020, at 02:13, Brian E Carpenter > wrote:
>>
>> I think the second sentence is a highly debatable assertion. Apart fro=
m
>> anything else, I thought it was the ISOC's job, in the accepted divisi=
on
>> of labour according to BCP11.:=C2=A0https://tools.ietf.org/html/rfc202=
8#section-3.4
>> But equally important, I think we have good reason to believe that the=

>> people who typically participate in the IETF are not the right sort of=

>> people to engage usefully in dialogue about "political, social and eco=
nomic
>> concerns". I think we will only burn our fingers.
>=20
> While that may be true, the IETF cannot just stuff this stuff off to th=
e ISOC. =C2=A0If work being taken on has societal consequences, the IETF =
should be aware of them, and better to have the impacted people represent=
 their concerns themselves through direct participation in IETF processes=
, rather than ISOC attempting to proxy for them.

The IETF being open to all, yes, of course direct participation is availa=
ble and welcome. But that doesn't mean that the IETF can itself engage wi=
th civil society, lobbying groups, special interest groups, governments, =
and whatever, which the draft seems to suggest:

> 4.1.  Engaging the Internet Community
=2E..
>    Therefore, we have not only a responsibility to analyse and consider=

>    the impacts of the IETF's work, but also a responsibility to consult=

>    with that greater Internet community.=20

That ("consult with that greater Internet community") seems infeasible.

>    We should enter into a
>    dialogue about not only the technical concerns that are well-
>    represented in the IETF but also the political, social and economic
>    concerns that it engenders, and that are better represented
>    elsewhere.

That is very obscurely phrased. Does it mean that in addition to our exis=
ting channel of communication with ISOC, we should have channels of commu=
nication with other organisations? If so, which ones, and who is the arbi=
ter when they disagree? When the EFF says one thing, and the IAB (I mean =
iab.com) says another thing, who do we listen to?

I just don't find this section of the draft realistic at all.

Note, I am not saying that the "political, social and economic concerns" =
don't matter. They do matter. I'm just not seeing the mechanism for takin=
g them into account.

Regards
    Brian



From nobody Sat Feb  8 06:45:33 2020
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 01541120074 for ; Sat,  8 Feb 2020 06:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.003
X-Spam-Level: ****
X-Spam-Status: No, score=4.003 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, FREEMAIL_REPLY=1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rTzOrrOBTMwe for ; Sat,  8 Feb 2020 06:45:28 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 883E712006F for ; Sat,  8 Feb 2020 06:45:28 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id p8so2099676oth.10 for ; Sat, 08 Feb 2020 06:45:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b1q26iKenDU0ea/XIv4A5MG0TF2moAeT0AOqaKBlalA=; b=eWclkGPr6F4+DKjezwt3Q7mO2OV/b/4h7maklxHQvpF1Ng3hOD0lUB1vf0z86PdV6c zahn2c/gNPEhvgIF28Sd5tMNEinlaO53aymMbczo4Gjl5wvFTv931kWL4EJDNwz1e4Iz Cx/9d1eWsU5UaIE8URRMF/X39Kf0mPBIdJB0vlHIcp25LIaV0SWeWI9kvOrFRkYI8Xle cpyqWGjd7oAwyXygsdvSMYmgkODnmqwnBrTUJvRvuoHv+8CNgGLT783eMHnEyis+YiDT OfXLzCQgJlZ5EY5xPVr8b5QJYqVf6GvrbvrOK/51mh4QhYXAqc6xYjVwryYFStzz5A6J Xxjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b1q26iKenDU0ea/XIv4A5MG0TF2moAeT0AOqaKBlalA=; b=t5O6z3lKWwVS+T+vvTSNcjYPo8luiuzn8puhgO2hWwF8TjQ1QbUWBajgAUhqYVZy/Z ZssTj6Lh+nXWGLQtiDd/vssvjOMrRoGjjqc//YhdCaFXNYRczbCswjYdB+qAQP0okQ7i xwm+LiLXDfkGQeBap+Yj9e7iIBwi3aqZF34RLSlvDnARIf35Lcw56BfC0Q8HaZjldoDZ 6cwQSs0oTeDlE6ujSN7/9VxnDEvJ4RsUPLjo5B8qfVKMb9W7dow6ys1D9BvrTC2IpQg/ RhUC0BGvRBMJAk/m+9KvDazcS0dy0QFbQeAIQWIv3wzZ+vzMOMXWd69FYKlixStHUsKu Nh2Q==
X-Gm-Message-State: APjAAAVWcE//7ywosrRRqq8fAX2aLjLYPZnMf4glfPbFwcIQ3TXYO3Kv IuMAdqtIOiD8ny3uOMpLdFFdxRJXVdT+56+KEEo=
X-Google-Smtp-Source: APXvYqyogUeOizVtMVaZUSrPBYknttBwegaGXClT2zEdQ+DnXWys8z2APbzgxz7JTNPDvQDEpI5qod5Bau3/zEYtG/s=
X-Received: by 2002:a9d:831:: with SMTP id 46mr3723321oty.295.1581173127763; Sat, 08 Feb 2020 06:45:27 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 8 Feb 2020 06:45:27 -0800 (PST)
In-Reply-To: <724115e2-345c-db3d-2190-6cd7ef9dce82@gmail.com>
References: <158094293707.31222.730373457433066701.idtracker@ietfa.amsl.com> <1c0861ff-cd59-1c43-6aa9-76e369128115@gmail.com> <70F445A3-CECF-4696-990D-0EA804BF962C@cisco.com> <724115e2-345c-db3d-2190-6cd7ef9dce82@gmail.com>
From: Guntur Wiseno Putra 
Date: Sat, 8 Feb 2020 21:45:27 +0700
Message-ID: 
To: Brian E Carpenter 
Cc: Eliot Lear , "iab@iab.org" ,  "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000009bdb0d059e118e10"
Archived-At: 
Subject: Re: [arch-d] Call for Comment:  (The Internet is for End Users)
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, 08 Feb 2020 14:45:31 -0000

--0000000000009bdb0d059e118e10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,


Section 4.1 Engaging the Internet Community of the IAB draft on "User"
which is especially in relation with IETF"s Internet Standad Process and
other key organizations involved:



"... to consult with that greater Internet community.  We should enter into=
 a
   dialogue about not only the technical concerns that are well-
   represented in the IETF but also the political, social and economic
   concerns that it engenders, and that are better represented
   elsewhere.

...".




The paragraph above represents what is worked on by "2019 ISOC GIR --
Consolidation in the Internet Economy" which is about programming for users
a way how to see the Internet's meanings and values:


"... we identify the important properties that make the Internet such a
powerful platform and describe what this means for the users of the
Internet. This framework will help to guide us in considering the questions
of consolidation in the Internet economy.

* Fundamental properties of the Internet
(: Internet Invariants =E2=80=93 what really matters about the Internet3): =
1.
global reach and integrity, 2. general purpose, 3. supports innovation
without requiring permission, 4. accesible, 5. based on interoperability
and mutual agreement, 6. collaboration, 7. technology, reusable building
blocks, 8. no permanent favourits

"The Internet Society believes that the Internet based on these invariants
empowers users with certain abilities. These abilities stem from the
invariants and underpin the social and economic value that the Internet
provides to people. As we look to the future, these abilities must remain
at the heart of the Internet experience for everyone, everywhere:.

They are the abilities to connect, to speak, to innovate, to share, to
choose, to trust.


"* The Internet in society
The Internet Invariants provide a guide to what really matters about the
Internet in terms of its architecture and technological properties. The
abilities highlight the different ways in which the Internet affects human
societies and supports us in understanding why people care so much about
this technological artefact that is much more than the sum of its parts.
Both notions will help guide us as we consider the issues of consolidation
in the Internet economy".


(4. How We See the Internet, pp. 12-14)

https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/=
InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf


Those are in accordance with what are mentioned in RFC 2026 which is
especially about the ISOC having important role in "Internet Standard
Process" together with other organizations involved in in the Internet
standard process mentioned in RFC 2028 (IETF, IETF WG, IETF Sec, ISOC, IAB,
IESG, IANA, IRTF)



"...The Internet Standards process is an activity of the Internet Society
that is organized and managed on behalf of the Internet community by the
Internet Architecture Board (IAB) and the Internet Engineering Steering
Group (IESG)".



(RFC 2026 -- Internet Standard Process
sec. 1. Introduction p. 3)

https://www.ietf.org/rfc/rfc2026.txt


"The Internet Society (ISOC) is an international organization concerned
with the growth and evolution of the worldwide Internet and with the
social, political, and technical issues that arise from its use...

Internet standardization is an organized activity of the ISOC, with the
Board of Trustees being responsible for ratifying the procedures and rules
of the Internet standards process [B]".


(RFC 2028 sec. 3 "Key organization involved in the process" p. 4)

https://tools.ietf.org/html/rfc2028#section-3.4

Regard,
Guntur Wiseno Putra

Pada Sabtu, 08 Februari 2020, Brian E Carpenter 
menulis:

> Hi Eliot,
>
> On 07-Feb-20 22:01, Eliot Lear wrote:
> > Hi Brian,
> >
> >> On 7 Feb 2020, at 02:13, Brian E Carpenter  > wrote:
> >>
> >> I think the second sentence is a highly debatable assertion. Apart fro=
m
> >> anything else, I thought it was the ISOC's job, in the accepted divisi=
on
> >> of labour according to BCP11.: https://tools.ietf.org
> /html/rfc2028#section-3.4
> >> But equally important, I think we have good reason to believe that the
> >> people who typically participate in the IETF are not the right sort of
> >> people to engage usefully in dialogue about "political, social and
> economic
> >> concerns". I think we will only burn our fingers.
> >
> > While that may be true, the IETF cannot just stuff this stuff off to th=
e
> ISOC.  If work being taken on has societal consequences, the IETF should =
be
> aware of them, and better to have the impacted people represent their
> concerns themselves through direct participation in IETF processes, rathe=
r
> than ISOC attempting to proxy for them.
>
> The IETF being open to all, yes, of course direct participation is
> available and welcome. But that doesn't mean that the IETF can itself
> engage with civil society, lobbying groups, special interest groups,
> governments, and whatever, which the draft seems to suggest:
>
> > 4.1.  Engaging the Internet Community
> ...
> >    Therefore, we have not only a responsibility to analyse and consider
> >    the impacts of the IETF's work, but also a responsibility to consult
> >    with that greater Internet community.
>
> That ("consult with that greater Internet community") seems infeasible.
>
> >    We should enter into a
> >    dialogue about not only the technical concerns that are well-
> >    represented in the IETF but also the political, social and economic
> >    concerns that it engenders, and that are better represented
> >    elsewhere.
>
> That is very obscurely phrased. Does it mean that in addition to our
> existing channel of communication with ISOC, we should have channels of
> communication with other organisations? If so, which ones, and who is the
> arbiter when they disagree? When the EFF says one thing, and the IAB (I
> mean iab.com) says another thing, who do we listen to?
>
> I just don't find this section of the draft realistic at all.
>
> Note, I am not saying that the "political, social and economic concerns"
> don't matter. They do matter. I'm just not seeing the mechanism for takin=
g
> them into account.
>
> Regards
>     Brian
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

--0000000000009bdb0d059e118e10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,


Section 4.1 En=
gaging the Internet Community of the IAB draft on "User" which is=
 especially in relation with IETF"s Internet Standad Process and other=
 key organizations involved:



"... to consult with that greater Internet community.  W=
e should enter into a
   dialogue about not only the technical concerns that are well-
   represented in the IETF but also the political, social and economic
   concerns that it engenders, and that are better represented
   elsewhere.
...".



The paragraph above rep=
resents what is worked on by "2019 ISOC GIR -- Consolidation in the In=
ternet Economy" which is about programming for users a way how to see =
the Internet's meanings and values:




"... we identify the important properties that make the Internet s=
uch a powerful platform and describe what this means for the users of the I=
nternet. This framework will help to guide us in considering the questions =
of consolidation in the Internet economy.


* Fundamental properties of the Internet

(: Internet Invariants =E2=80=93 what really matters about the Internet3): =
1. global reach and integrity, 2. general purpose, 3. supports innovation w=
ithout requiring permission, 4. accesible, 5. based on interoperability and=
 mutual agreement, 6. collaboration, 7. technology, reusable building block=
s, 8. no permanent favourits



"The Internet Society believes that the Internet based on these invari=
ants empowers users with certain abilities. These abilities stem from the i=
nvariants and underpin the social and economic value that the Internet prov=
ides to people. As we look to the future, these abilities must remain at th=
e heart of the Internet experience for everyone, everywhere:.

=

They are the abilities to connect, to speak, to innovate, to share, to=
 choose, to trust.




"* The Internet in society 

The Internet Invariants provide a guide to what really matters about the In=
ternet in terms of its architecture and technological properties. The abili=
ties highlight the different ways in which the Internet affects human socie=
ties and supports us in understanding why people care so much about this te=
chnological artefact that is much more than the sum of its parts. Both noti=
ons will help guide us as we consider the issues of consolidation in the In=
ternet economy".


(4. How W=
e See the Internet, pp. 12-14)



Those are in ac=
cordance with what are mentioned in RFC 2026 which is especially about the =
ISOC having important role in "Internet Standard Process" togethe=
r with other organizations involved in in the Internet standard process men=
tioned in RFC 2028 (IETF, IETF WG, IETF Sec, ISOC, IAB, IESG, IANA, IRTF)



"...The Internet=
 Standards process is an activity of the Internet Society that is organized=
 and managed on behalf of the Internet community by the Internet Architectu=
re Board (IAB) and the Internet Engineering Steering Group (IESG)".



(RFC 2026 -- =
Internet Standard Process
sec. 1. Introduction p. 3)
<=
div>


"The Internet S=
ociety (ISOC) is an international organization concerned with the growth an=
d evolution of the worldwide Internet and with the social, political, and t=
echnical issues that arise from its use...

Interne=
t standardization is an organized activity of the ISOC, with the Board of T=
rustees being responsible for ratifying the procedures and rules of the Int=
ernet standards process [B]".=C2=A0


(RFC 2028 sec. 3 "Key organization involved in the process"=
 p. 4)

https://tools.ietf.org/html/rfc2028#section-3.4

Regard,
Guntur Wiseno Putra

Pada Sa=
btu, 08 Februari 2020, Brian E Carpenter <brian.e.carpenter@gmail.com> menu=
lis:
Hi Eliot,



On 07-Feb-20 22:01, Eliot Lear wrote:

> Hi Brian,

> 

>> On 7 Feb 2020, at 02:13, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:

>>

>> I think the second sentence is a highly debatable assertion. Apart=
 from

>> anything else, I thought it was the ISOC's job, in the accepte=
d division

>> of labour according to BCP11.:=C2=A0https://tools.ietf.org=
/html/rfc2028#section-3.4

>> But equally important, I think we have good reason to believe that=
 the

>> people who typically participate in the IETF are not the right sor=
t of

>> people to engage usefully in dialogue about "political, socia=
l and economic

>> concerns". I think we will only burn our fingers.

> 

> While that may be true, the IETF cannot just stuff this stuff off to t=
he ISOC.=C2=A0 If work being taken on has societal consequences, the IETF s=
hould be aware of them, and better to have the impacted people represent th=
eir concerns themselves through direct participation in IETF processes, rat=
her than ISOC attempting to proxy for them.



The IETF being open to all, yes, of course direct participation is availabl=
e and welcome. But that doesn't mean that the IETF can itself engage wi=
th civil society, lobbying groups, special interest groups, governments, an=
d whatever, which the draft seems to suggest:



> 4.1.=C2=A0 Engaging the Internet Community

...

>=C2=A0 =C2=A0 Therefore, we have not only a responsibility to analyse a=
nd consider

>=C2=A0 =C2=A0 the impacts of the IETF's work, but also a responsibi=
lity to consult

>=C2=A0 =C2=A0 with that greater Internet community. 



That ("consult with that greater Internet community") seems infea=
sible.



>=C2=A0 =C2=A0 We should enter into a

>=C2=A0 =C2=A0 dialogue about not only the technical concerns that are w=
ell-

>=C2=A0 =C2=A0 represented in the IETF but also the political, social an=
d economic

>=C2=A0 =C2=A0 concerns that it engenders, and that are better represent=
ed

>=C2=A0 =C2=A0 elsewhere.



That is very obscurely phrased. Does it mean that in addition to our existi=
ng channel of communication with ISOC, we should have channels of communica=
tion with other organisations? If so, which ones, and who is the arbiter wh=
en they disagree? When the EFF says one thing, and the IAB (I mean iab.com) says another thing, who =
do we listen to?



I just don't find this section of the draft realistic at all.



Note, I am not saying that the "political, social and economic concern=
s" don't matter. They do matter. I'm just not seeing the mecha=
nism for taking them into account.



Regards

=C2=A0 =C2=A0 Brian





_______________________________________________

Architecture-discuss mailing list

Architec=
ture-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/architecture-discu=
ss




--0000000000009bdb0d059e118e10--


From nobody Sun Feb 16 07:33:10 2020
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 DAED6120052 for ; Sun, 16 Feb 2020 07:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zgcS64RBvQSU for ; Sun, 16 Feb 2020 07:33:07 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 5C4A6120219 for ; Sun, 16 Feb 2020 07:33:07 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id p8so13671968oth.10 for ; Sun, 16 Feb 2020 07:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=FHn606fh7vUrwHsbnyV22LYUhIzsDBk0lY3gFfEXSD4=; b=tTyJWvW7HLjw443hMmGuxEFnrM17ztv7O/Yv9ounc4n0J99HFCO5Lwysj3/THja2yX Hb9hDnLzbhNxn84F5U8ptHNPSA6NhHYCYE1s7R2NtdZay2D68zu7r3rKQw6fGdkjTsHi xHvYhza57QYbeCqa8DG/iJ7ErH8qvIphLvZ1HnHCfAzHaUuTxqlqjUcmZ/gTwojWZDvd +hqc7h1x7sEh4sIi0nCr4HP26BLCkXe7PH88cQRvu1qrFr9l/K6975Ep3MiQG6wrd33k wVIGby/6TpRGnHkL/aIyvUsF7NU9QlyI8FuJfMEbcRqFxhCe+Djk8OUXBYZSWQKX8nG+ BPdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FHn606fh7vUrwHsbnyV22LYUhIzsDBk0lY3gFfEXSD4=; b=qjQeOyTu55TRTo5JmkBIGpd8hVv7YX3M6x6FP0GX5iWLxyrjf1L3zRZaxX5gii1rMJ wDff0C8UjU6gTEeO7ZSLCbOnbb1Tjrz0+ZwWmFXXN2v7iZtIg3GyWhLyt8nEwnM+3qE0 5eCFOrXYLl5m1Jzr+9xRmGBQ3kWgVPdXyou/FZh900so/9KNpXARCOSZ5Kbuo7wfW5FD t2r1atMbK2kx0LS6Lb4UGkQrQu9z+smvMbTAsT7gjh3trWuxyBcLjK4mGqrYsq7ZSU5e FKFSzoGYa3nfA7Qpzallws8bS9YiCxykbqQc01y53gqLhadOpySSKJZidf1HgGMGXneM +OTQ==
X-Gm-Message-State: APjAAAW3FxYkqgMh8z2KQqS6Ci4/W+gwNdaU7oYFmtOqHfUvHJnG+fUw qRNoYuZshseyStmOldc7PWOth0pLy8EEGOBRwWp+6g==
X-Google-Smtp-Source: APXvYqwaruSrR2T+zkBcoqgF6AKt18m01I7E5EGzZClvkr7yAGybtYniVVq+DeRYGJMHByEYQwQ56lxjUPbOpD5amo4=
X-Received: by 2002:a05:6830:10a:: with SMTP id i10mr8870225otp.365.1581867186527;  Sun, 16 Feb 2020 07:33:06 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 16 Feb 2020 07:33:06 -0800 (PST)
From: Guntur Wiseno Putra 
Date: Sun, 16 Feb 2020 22:33:06 +0700
Message-ID: 
To: architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bc2080059eb3271e"
Archived-At: 
Subject: [arch-d] A Reading on "Cosmos", "Technics" and "Politics"
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, 16 Feb 2020 15:33:09 -0000

--000000000000bc2080059eb3271e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I finded a reading on "cosmos", "technics" and "politics" published in 2017=
:

It was said, by Yuk Sui that there were the end of unilateral globalization
and the arrival of anthropocene driving such possibillity to talk about
"cosmopolitics" as a commercial regime and as politics of nature.

Then it was said, "...    =C2=A73. Cosmotechnics as CosmopoliticsI propose =
to go
beyond the notion of cosmology; instead, it would be more productive to
address what I call cosmotechnics. Let me give you a preliminary definition
of cosmotechnics: it is the unification of the cosmos and the moral through
technical activities, whether craft-making or art-making. There hasn=E2=80=
=99t been
one or two technics, but many cosmotechnics. What kind of morality, which
and whose cosmos, and how to unite them vary from one culture to another
according to different dynamics. I am convinced that in order to confront
the crisis that is before us=E2=80=94namely, the Anthropocene, or the intru=
sion of
Gaia (Latour and Stengers), or the =E2=80=9Centropocene=E2=80=9D (Stiegler)=
, all presented
as the inevitable future of humanity=E2=80=94it is necessary to reopen the =
question
of technology, in order to envisage the bifurcation of technological
futures by conceiving different cosmotechnics. ...".

Sui, Yuk, "Cosmotechnics as Cosmopolitics", E-flux journal #86, November
2017)


https://www.e-flux.com/journal/86/161887/cosmotechnics-as-cosmopolitics

Regard,
Guntur Wiseno Putra

--000000000000bc2080059eb3271e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I finded a reading on "c=
osmos", "technics" and "politics" published in 201=
7:

It was said, by Yuk Sui that there were the end o=
f unilateral globalization and the arrival of anthropocene driving such pos=
sibillity to talk about "cosmopolitics" as a commercial regime an=
d as politics of nature.

Then it was said, ".=
.. =C2=A0 =C2=A0
=C2=A73. Cosmotechnics as Cosmopolitic=
s
I propose to go beyond =
the notion of cosmology; instead, it would be more productive to address wh=
at I call cosmotechnics. Let me give you a preliminary definition of cosmot=
echnics: it is the unification of the cosmos and the moral through technica=
l activities, whether craft-making or art-making. There hasn=E2=80=99t been=
 one or two technics, but many cosmotechnics. What kind of morality, which =
and whose cosmos, and how to unite them vary from one culture to another ac=
cording to different dynamics. I am convinced that in order to confront the=
 crisis that is before us=E2=80=94namely, the Anthropocene, or the intrusio=
n of Gaia (Latour and Stengers), or the =E2=80=9Centropocene=E2=80=9D (Stie=
gler), all presented as the inevitable future of humanity=E2=80=94it is nec=
essary to reopen the question of technology, in order to envisage the bifur=
cation of technological futures by conceiving different cosmotechnics.=C2=A0...".

Sui, Yuk, "Cosmotechnics a=
s Cosmopolitics", E-flux journal #86, November 2017)


--000000000000bc2080059eb3271e--


From nobody Mon Feb 17 18:26:30 2020
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 64F0D1200F4 for ; Sun, 16 Feb 2020 20:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 GP75xHRRgwFH for ; Sun, 16 Feb 2020 20:09:41 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 7EA5712001A for ; Sun, 16 Feb 2020 20:09:41 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id c16so15486667oic.3 for ; Sun, 16 Feb 2020 20:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=dVTKMgc6p2pG8qyzLtjzj28xe1uN8kLbqx/+rTRH/kU=; b=rEARkT7nX+FdW9W7AkyBKU0wwvzrNMI63WjuD7HXbCndJwgPaUmUjWodpzhkO7ISxl jnwIeFbBXL0if30o8HCO2LlqSFYHEBMoXq+88g+HK/RAHnArZJySIPBpYcKaOQbUTNjG FSqpSpAEfBztR3TuPx5ZvAolozthkGWW2fIlAiwkR5fyb9xKMvSPHOmetCINRELjsP3+ 5WQBBMsMe6MYCY+ToabL39H4D9y4TUmWe1Nib+ocq99eyr7XO78Ft0zlY0ESNLHjyXRF 9LLnB+wm/Uq8un9ltSVvjy96nqR2SGn93GekheFPC4Ud4aCXuL4bykXrDlp2wJPaqnuN M0aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dVTKMgc6p2pG8qyzLtjzj28xe1uN8kLbqx/+rTRH/kU=; b=GH+nYSFOPbKmeo1ayMkWWAuvluFP0cZoJ/TRQQgjF4OayvHCscO092uk/SX07D5OfB PZKE3Sos4ajtz2jZhHtG2q4ppWmtHyfnlDIZwm+MHcCkP1RSurcvvccOWvZnbqY6Gz6z rJd00XRFqlIfTSNFBbf9m45Q+RweTYTsWZC7EXsc+zR31ojmeoflF7XKN+R1cNaoJTKM eJBFrCxoqgVRxbVPznBjk3FvyKep80NgKAyvZMbILZQj7FSmJBVhIc0ZNC/9F8zT9mss /qfJk+Fu4Y2dlfftnMQw309y85u73GJNp3iDT3EKzlywZhDgf7NN0CnCV6UugCfZBWwo E9Gw==
X-Gm-Message-State: APjAAAV3aydei46EEZwXA7wfoPoDnuG8i9EYR/IFPoMfGezOn64UgN19 /9zzVjYhv1QI340LxFegUT7+MqqEVZYv3IMbrKCFIA==
X-Google-Smtp-Source: APXvYqzn762gxML/0uTx+ieNqUV871OKzL3aeOAcxPc7BA8RSZlJMjHC/OULIfw3mBP/BqJ00Q4IMTgW7lVuQQAt9cY=
X-Received: by 2002:aca:f354:: with SMTP id r81mr8502673oih.90.1581912580607;  Sun, 16 Feb 2020 20:09:40 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 16 Feb 2020 20:09:40 -0800 (PST)
In-Reply-To: 
References: 
From: Guntur Wiseno Putra 
Date: Mon, 17 Feb 2020 11:09:40 +0700
Message-ID: 
To: "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000006ed1b1059ebdb9aa"
Archived-At: 
Subject: Re: [arch-d] A Reading on "Cosmos", "Technics" and "Politics"
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, 17 Feb 2020 04:09:43 -0000

--0000000000006ed1b1059ebdb9aa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I finded also "The Genesis of Technicity" referring to (the book) "On the
Mode of Existence of Technical Objects" --both were published in 2017:


"...

This study postulates that technicity is one of the two fundamental phases
of the mode of existence of the whole constituted by man and the world.1 ..=
.

...".








https://www.e-flux.com/journal/82/133160/the-genesis-of-technicity

Simondon, Gilbert, "The Genesis of Technicity", E-Flux journal #82 - Mei
2017


Regard,
Guntur Wiseno Putra

Pada Minggu, 16 Februari 2020, Guntur Wiseno Putra 
menulis:

> Dear architecture-discuss,
>
> I finded a reading on "cosmos", "technics" and "politics" published in
> 2017:
>
> It was said, by Yuk Sui that there were the end of unilateral
> globalization and the arrival of anthropocene driving such possibillity t=
o
> talk about "cosmopolitics" as a commercial regime and as politics of natu=
re.
>
> Then it was said, "...    =C2=A73. Cosmotechnics as CosmopoliticsI propos=
e to
> go beyond the notion of cosmology; instead, it would be more productive t=
o
> address what I call cosmotechnics. Let me give you a preliminary definiti=
on
> of cosmotechnics: it is the unification of the cosmos and the moral throu=
gh
> technical activities, whether craft-making or art-making. There hasn=E2=
=80=99t been
> one or two technics, but many cosmotechnics. What kind of morality, which
> and whose cosmos, and how to unite them vary from one culture to another
> according to different dynamics. I am convinced that in order to confront
> the crisis that is before us=E2=80=94namely, the Anthropocene, or the int=
rusion of
> Gaia (Latour and Stengers), or the =E2=80=9Centropocene=E2=80=9D (Stiegle=
r), all presented
> as the inevitable future of humanity=E2=80=94it is necessary to reopen th=
e question
> of technology, in order to envisage the bifurcation of technological
> futures by conceiving different cosmotechnics. ...".
>
> Sui, Yuk, "Cosmotechnics as Cosmopolitics", E-flux journal #86, November
> 2017)
>
>
> https://www.e-flux.com/journal/86/161887/cosmotechnics-as-cosmopolitics
>
> Regard,
> Guntur Wiseno Putra
>

--0000000000006ed1b1059ebdb9aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I finded also "The Genes=
is of Technicity" referring to (the book) "On the Mode of Existen=
ce of Technical Objects" --both were published in 2017:

"...
This study postulates that technicity is one of the two=
 fundamental phases of the mode of existence of the whole constituted by ma=
n and the world.1=C2=A0...
...".








Simondon, Gilbert, "The Genesis of Technicit=
y", E-Flux journal #82 - Mei 2017


<=
div>Regard,
Guntur Wiseno Putra

Pada Minggu, 16 Februa=
ri 2020, Guntur Wiseno Putra <gseno=
pu@gmail.com> menulis:
Dear archit=
ecture-discuss,

I finded a reading on "cosmos"=
, "technics" and "politics" published in 2017:
=

It was said, by Yuk Sui that there were the end of unilatera=
l globalization and the arrival of anthropocene driving such possibillity t=
o talk about "cosmopolitics" as a commercial regime and as politi=
cs of nature.

Then it was said, "... =C2=A0 =
=C2=A0
=C2=A73. Cosmotechnics as Cosmopolitics
I propose to go beyond the notion of cosmology; inst=
ead, it would be more productive to address what I call cosmotechnics. Let =
me give you a preliminary definition of cosmotechnics: it is the unificatio=
n of the cosmos and the moral through technical activities, whether craft-m=
aking or art-making. There hasn=E2=80=99t been one or two technics, but man=
y cosmotechnics. What kind of morality, which and whose cosmos, and how to =
unite them vary from one culture to another according to different dynamics=
. I am convinced that in order to confront the crisis that is before us=E2=
=80=94namely, the Anthropocene, or the intrusion of Gaia (Latour and Stenge=
rs), or the =E2=80=9Centropocene=E2=80=9D (Stiegler), all presented as the =
inevitable future of humanity=E2=80=94it is necessary to reopen the questio=
n of technology, in order to envisage the bifurcation of technological futu=
res by conceiving different cosmotechnics.=C2=A0...".

Sui, Yuk, "Cosmotechnics as Cosmopolitics", E-flu=
x journal #86, November 2017)



Regard,
=

Guntur Wiseno Putra




--0000000000006ed1b1059ebdb9aa--


From nobody Sun Feb 23 23:09:42 2020
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 B4BFF3A0A78 for ; Sun, 23 Feb 2020 23:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.662
X-Spam-Level: *
X-Spam-Status: No, score=1.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_WP_DIRINDEX=3.499] autolearn=no 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 w9k9y1p-JzUy for ; Sun, 23 Feb 2020 23:09:38 -0800 (PST)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 7874A3A0A76 for ; Sun, 23 Feb 2020 23:09:38 -0800 (PST)
Received: by mail-oi1-x22f.google.com with SMTP id q84so8033001oic.4 for ; Sun, 23 Feb 2020 23:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F1kinKMJEOqMzOFR5pHmR51UTs4OmHO90Bvlem5nfJ0=; b=cBSV0qMxRmnqo7EuAuk7Tmmz9Bicj/BEOxTBwH62G2EKbGGKqdPKejlgNmrQ1PmQkI 3OuW+Z3RMmZRYHNlRBd9+uGndhdf3G2UFZojaHAU588jq7IY5CrCMkAzjeyEoAuez0+e hk67kwb0zBfzcBzydbOYFAbpAQMcWN45nud679Pm9Si3gxDLsoUA66vBEC/XmngW/bYG GYd+abOv27b3oey9GX1XI4Y11KCDL8+bx53QmIyAWFwF9bM8w2l/TfNvBeUpsKbDBRep TyHu3H5o2NTzPaB4L+PIhZ6C0Dxh8cFr8HUKhJ1bdJiDQ3Y/VZZTwsJaoKNvGLzc3Rwd FxEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F1kinKMJEOqMzOFR5pHmR51UTs4OmHO90Bvlem5nfJ0=; b=o0I7KlKuClslqcOWvU5yr7B383j1O+HsP7uTD/nSIPTQ1dtpDTQxcMN88CWb0ByGZ4 kTLpofF/AdLFPxwI+Fy5WcG9hgweQUxzfv+xN5MZnUquG4JF+820JD/X8e2ym50qbAc2 PLQ51abFuoM5qqayyjvs7bZ4C/1vNhJkmpMiwta4bN/wYW5zvm63qnW6qQk/XA5lp0vw AVEFA1WVPSmbWYfhx6Lc0CD/xDMA66p5bYzHWDrYxoLary7DP+wiJdGYQwdzaihok5rw RFZ5Sd50dtxWAuQIWXAlX1+qpCqwDOODTdLePcP0PZKkx2eskLSRR/uDt1hcMbsnTKiC vBqw==
X-Gm-Message-State: APjAAAWcam+sBPNiEiIw4I4lWe9nnUB+kFlCVffQ95g5eQO/tKo2QVz7 TrvgI0bvcWd5asCga09gUH2H9MUiLxVGJCJxgJKPaA==
X-Google-Smtp-Source: APXvYqzT7FtfFI9WmEUcyRIHsCqpJggC8+5C7HPS678Lht8XhIky/FJaOLSOQ6LbHTXJX3gMBXU6ZVKymiLDoOzrOCI=
X-Received: by 2002:aca:f354:: with SMTP id r81mr10950271oih.90.1582528177346;  Sun, 23 Feb 2020 23:09:37 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 23 Feb 2020 23:09:37 -0800 (PST)
In-Reply-To: 
References:  <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com>   
From: Guntur Wiseno Putra 
Date: Mon, 24 Feb 2020 14:09:37 +0700
Message-ID: 
To: Russ Housley 
Cc: "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000db9b73059f4d0d52"
Archived-At: 
Subject: Re: [arch-d] Network Architecture in the Internet Society
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, 24 Feb 2020 07:09:41 -0000

--000000000000db9b73059f4d0d52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

By opening files at www.ietfjournal.org I finded this out: Among others
this is one worked on by the IETF publication on "architecture" which
mentioned also about "architecture-discuss" in the time of its beginning
--I then made it part of the entry on "Consolidation of the Internet..." at
the Internet Society's Open Forum Library:

NETWORKING RESEARCHReflections on

ArchitectureBy: Pekka Nikander
Date:
December 2005


"I happen to have an architect=E2=80=99s mind. Looking at the network of to=
day, I
strongly feel the pain of the current architecture=E2=80=99s cracking and
squeaking. Consequently, I believe that we =E2=80=93 the wider IETF communi=
ty
responsible for Internet technology =E2=80=93 need to re-think the architec=
ture. We
need to find a way to re-create the core of the Internet in a way that
leads to a new era of innovation and intellectual prosperity. The highlight
of my IETF64 meeting in Vancouver was that I started to see signs of
interest and activity in the broader community to pursue such a goal.

...

The IAB has recently created a new mailing list, architecture-discuss [15],
for wider discussion of architectural issues, which I hope will develop
into a valuable forum over time. I hope to see you there".

https://www.ietfjournal.org/reflections-on-architecture





Regard,
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
menulis:

> Dear Russ & architecture-discuss,
>
>
> I have just added Leva. T & H. Suommi's "Framework of Analyzing
> Feasibility of Internet Protocols" to the before-mentioned list of readin=
gs
> by "Add Comment" Facility in the OPEN FORUM Community Library:
>
>
> ###
> To the list of readings above (Consolidation of the Internet: from the
> Socio-Economic to the Architectural) may I add "Framework of Analyzing
> Feasibility of Internet Potocols" (Leva, T. & H. Suommi, the IAB Workshop
> on Internet Technology Adootion and Transition 2013) which was ever to be
> part of architecture-discuss@ietf.org "Centralization or diversity?"
> January 22th 2020:
>
> https://mailarchive.ietf.org/arch/msg/architecture-discuss/
> sdTkLd7q7wXyfAnjJQlNceWPr8U
>
>
> ###
>
>
>
>
> Note:
> To clarify what I said in the previous message:
> I mean the architecture-discuss@ietf.org and the OPEN FORUM Community
> Library may be about a networked community of reading, a networked librar=
y.
>
>
>
>
>
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
> menulis:
>
>> Dear Russ and architecture-discuss,
>>
>> The post  in OPEN Forum Community Library is about those document saved
>> in the architecture-discuss mailarchive I mentioned above plus
>>
>>  Arkko, Jarri et all., "Considerations on the Internet Consolidation and
>> the Internet Architecture", Internet-Draft, IETF, Expired April 2019
>> https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00
>>
>> While, I have not included yet that of T. Leva and H. Suommi's...
>>
>> I emphasized on socio-economic and architectural learnings attempted by
>> those documents there--while the post at architecture-discuss emphazised=
 on
>> feasibility of the Internet architecture in relation with aesthetic and
>> ethic experiences.
>>
>> This is what I saved in OPEN FORUM Community Library:
>>
>> "Consolidation of the Internet: From the Socio-Economic to the
>> Architectural"
>>
>> This documents refer to "Consolidation in the Internet" which is of
>> economic and architectural approaches and perspectives:
>>
>> - ISOC Global Internet Report Consolidation in the Internet Economy
>> https://future.internetsociety.org/2019/wp-content/uploads/
>> sites/2/2019/04/InternetSociety-GlobalInternet
>> Report-ConsolidationintheInternetEconomy.pdf
>> - Arkko, Jarri et all., "Considerations on the Internet Consolidation an=
d
>> the Internet Architecture", Internet-Draft, IETF, Expired April 2019
>> https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00
>> - Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols",
>> IAB-DEDR Workshop 2019 https://www.iab.org/wp-content
>> /IAB-uploads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf
>> - Arkko, Jarri, "Centralized Architecture in Internet Architecture",
>> Internet Draft, 2019
>> https://www.ietf.org/id/draft-arkko-arch-infrastructure-cent
>> ralisation-00.txt
>> Kutscher, Dirk, "Protocol Design and Socio-economic Realities", in the
>> IAB-DEDR Workshop 2019
>> https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-
>> kutscher-internet-design-kutscher.pdf
>>
>>
>> Note: This post is related with another one in this "Open Forum":
>> Restream: Internet Consolidation: What Lies beneath the Application
>> Layer..." (December 14th 2019) https://connect.internetsociet
>> y.org/communities/community-home/digestviewer/viewthread?G
>> roupId=3D67&MessageKey=3D426220c6-e41e-45c8-8872-7f0cc455f492&
>> CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3D
>> digestviewer&ReturnUrl=3D%2fcommunities%2fcommunity-home%2fdigestviewer%
>> 3fCommunityKey%3d3a9fa082-a518-475d-9e7f-ecec4ffe56dd
>>
>>
>>
>>
>>
>>
>>
>>
>> Regard,
>> Guntur Wiseno Putra
>>
>> Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
>> menulis:
>>
>>> Dear Russ and architecture-discuss,
>>>
>>>
>>> I am new there, I have not know muc "how to": I think one needs to
>>> create an account in the Internet Society to join with OPEN FORUM Commu=
nity
>>> to access its features:
>>>
>>> https://www.internetsociety.org/become-a-member/
>>>
>>>
>>> But at this architecture-discuss, where we are now, one may simply
>>> access its mail archives for the documents on "Consolidation of the
>>> Internet" --so it is nothing new but such a networked community of read=
ing,
>>> such a networked library:
>>>
>>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/s
>>> dTkLd7q7wXyfAnjJQlNceWPr8U
>>>
>>> I find no search engine facility for documents at OPEN FORUM community
>>> Library while there is one at architecture-discuss mail archive.
>>>
>>> Regard,
>>> Guntur Wiseno Putra
>>>
>>> Pada Jumat, 31 Januari 2020, Russ Housley 
>>> menulis:
>>>
>>>> Is there a way to see the document without creating an account?
>>>>
>>>> Russ
>>>>
>>>>
>>>> On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra 
>>>> wrote:
>>>>
>>>> Dear architecture-discuss,
>>>>
>>>> Documents related with the current issues on "consolidation of the
>>>> Internet" saved in the "Open Forum" community of the Internet Society:
>>>>
>>>>
>>>> https://connect.internetsociety.org/viewdocument/consolidati
>>>> on-of-the-internet-from?CommunityKey=3D3a9fa082-a518-475d-9e7f
>>>> -ecec4ffe56dd&tab=3Dlibrarydocuments#ItemCommentPanel
>>>>
>>>> Regard,
>>>> Guntur Wiseno Putra
>>>>
>>>>
>>>>

--000000000000db9b73059f4d0d52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

By opening files at www.ietfjournal.org I finded this out: =
Among others this is one worked on by the IETF publication on "archite=
cture" which mentioned also about "architecture-discuss" in =
the time of its beginning --I then made it part of the entry on "Conso=
lidation of the Internet..." at the Internet Society's Open Forum =
Library:

NETWORKING RESEARCH
Reflections on
Architecture
By:=C2=A0Pekka Nikander
Date: De=
cember 2005


"I happen to have an architect=E2=80=99=
s mind. Looking at the network of today, I strongly feel the pain of the cu=
rrent architecture=E2=80=99s cracking and squeaking. Consequently, I believ=
e that we =E2=80=93 the wider IETF community responsible for Internet techn=
ology =E2=80=93 need to re-think the architecture. We need to find a way to=
 re-create the core of the Internet in a way that leads to a new era of inn=
ovation and intellectual prosperity. The highlight of my IETF64 meeting in =
Vancouver was that I started to see signs of interest and activity in the b=
roader community to pursue such a goal.
=

...

The IAB has recently creat=
ed a new mailing list, architecture-discuss [15], for wider discussion of a=
rchitectural issues, which I hope will develop into a valuable forum over t=
ime. I hope to see you there".

https://www.ietfjournal.org/reflections-on-archite=
cture




Regard,
Guntur Wiseno Putra

Pada Jumat, 31 Jan=
uari 2020, Guntur Wiseno Putra <gse=
nopu@gmail.com> menulis:
Dear Rus=
s & architecture-discuss,


I have just=
 added Leva. T & H. Suommi's "Framework of Analyzing Feasibili=
ty of Internet Protocols" to the before-mentioned list of readings by =
"Add Comment" Facility in the OPEN FORUM Community Library:
=



###
To the list of readings a=
bove (Consolidation of the Internet: from the Socio-Economic to the Archite=
ctural) may I add "Framework of Analyzing Feasibility of Internet Poto=
cols" (Leva, T. & H. Suommi, the IAB Workshop on Internet Technolo=
gy Adootion and Transition 2013) which was ever to be part of architecture-discuss@=
ietf.org "Centralization or diversity?" January 22th 2020:

https://mailarchive.ietf.org/<=
wbr>arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U


###




Note:=C2=A0
To clar=
ify what I said in the previous message:=C2=A0
I mean the architecture-di=
scuss@ietf.org and the OPEN FORUM Community Library may be about a netw=
orked community of reading, a networked library.

<=
br>




R=
egard,
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2020, Gu=
ntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear=
 Russ and architecture-discuss,

The post =C2=A0in OPEN F=
orum Community Library is about those document saved in the architecture-di=
scuss mailarchive I mentioned above plus=C2=A0

=C2=A0Arkko, Jarri et all., "Considerations on the I=
nternet Consolidation and the Internet Architecture", Internet-Draft, =
IETF, Expired April 2019 https://tools.ietf.org/ht=
ml/draft-arkko-iab-internet-consolidation-00=C2=A0

While, I have not included yet that of T. Leva =
and H. Suommi's...

I emphasized on soci=
o-economic and architectural learnings attempted by those documents there--=
while the post at architecture-discuss emphazised on feasibility of the Int=
ernet architecture in relation with aesthetic and ethic experiences.
<=
div>
This is what I saved in OPEN FORUM Community Library:

"Consolidation of the Internet: From the Socio-=
Economic to the Architectural"

This documents refer to "Consolidation in the =
Internet" which is of economic and architectural approaches and perspe=
ctives:

- ISOC Global Internet=
 Report Consolidation in the Internet Economy https://future.internetsociety.org/2019/wp-content/uploads/sites=
/2/2019/04/InternetSociety-GlobalInternetReport-Consolidationinth=
eInternetEconomy.pdf=C2=A0
- Arkko, Jarri et all., "Considerations on the Internet Consoli=
dation and the Internet Architecture", Internet-Draft, IETF, Expired A=
pril 2019 https://tools.ietf.org/html/draft-a=
rkko-iab-internet-consolidation-00=C2=A0
=
- Sullivan, Andrew, "Three Kinds of Concentration=
 in Open Protocols", IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-upl=
oads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf<=
/a>=C2=A0
- Arkko, Jarri, &qu=
ot;Centralized Architecture in Internet Architecture", Internet Draft,=
 2019=C2=A0
https://www.ietf.org/id/draft-arkko-arch-infrastructur=
e-centralisation-00.txt
Kutscher, Dirk, "Protocol Design and Socio-economic Realities"=
;, in the IAB-DEDR Workshop 2019
https://www.iab.org/wp-=
content/IAB-uploads/2019/05/p14-kutscher-internet-design-kutscher.pdf


Note: This post is related with another one in this =
"Open Forum": Restream: Internet Consolidation: What Lies beneath=
 the Application Layer..." (December 14th 2019) https://connect.i=
nternetsociety.org/communities/community-home/digestviewer/viewth=
read?GroupId=3D67&MessageKey=3D426220c6-e41e-45c8-8872-7f0cc4=
55f492&CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&am=
p;tab=3Ddigestviewer&ReturnUrl=3D%2fcommunities%2fcommunity-<=
wbr>home%2fdigestviewer%3fCommunityKey%3d3a9fa082-a518-475d-9e7f-=
ecec4ffe56dd








Regard,
Guntur Wiseno Putra

Pada Jumat, 31 Januari=
 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear Russ and architecture-discuss,=C2=A0


I am new there, I have not know muc "how to": I think one needs =
to create an account in the Internet Society to join with OPEN FORUM Commun=
ity to access its features:



https://www.internetsociety.org/become-a-member/




But at this architecture-discuss, where we are now, one may simply acce=
ss its mail archives for the documents on "Consolidation of the Intern=
et" --so it is nothing new but such a networked community of reading, =
such a networked library:


https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U



I find no search engine facility for documents at OPEN FORUM community Libr=
ary while there is one at architecture-discuss mail archive.
=

Regard,
Guntur Wiseno Putra

Pada Jum=
at, 31 Januari 2020, Russ Housley <housley@vigilsec.com> menulis:
Is there a way to see the document without creating an account?
Russ


=
On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra <gsenopu@gmail.com> wrote:

=

Dear architecture-discuss,

Documents related with t=
he current issues on "consolidation of the Internet" saved in the=
 "Open Forum" community of the Internet Society:










--000000000000db9b73059f4d0d52--


From nobody Mon Feb 24 14:27:29 2020
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 151333A14A5; Mon, 24 Feb 2020 14:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 nxbniFNy__OI; Mon, 24 Feb 2020 14:27:22 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46263A148A; Mon, 24 Feb 2020 14:27:21 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A3C3E548052; Mon, 24 Feb 2020 23:27:15 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 989C4440040; Mon, 24 Feb 2020 23:27:15 +0100 (CET)
Date: Mon, 24 Feb 2020 23:27:15 +0100
From: Toerless Eckert 
To: Mark Andrews 
Cc: Khaled Omar , architecture-discuss@ietf.org
Message-ID: <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>  
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 24 Feb 2020 22:27:27 -0000

[Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]

Mark: 

Funny to see how yours is the first actual answer to at least how i read
Khaleds question. I would summarize what you said with:

https://en.wikipedia.org/wiki/IPv6_transition_mechanism

(14 standardized plus a lot more. Aka: thank you, but we have enough)

Most everybody else jumps to the growth of the IPv6 Internet, which
to me is just the visible tip of the iceberg of overall IPv4 and IPv6
deployments. I think the picture changes quite a bit if we look at the
whole iceberg. 

In private / controlled networks, the choices are not only IPv4 vs.
IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet 
switching.

For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon
be software-only overlay virtual networks whereas the actual
terrabit accelerated hardware forwarding plane of future networks
maybe something else. 4G/5G "core" "network" already are such
overlay networks. 

[Rant]
I am not sure if the question, as constrained as  Khaled is asking
it will really help us to improve what we should do in the future. But
neither is the defensive reaction of IPv6 evangelists pointing at the
growth curve of the IPv6 Internet as the only relevant metric to the
success and benefits of IPv6.

I am primarily concerned that we did manage to recognize we needed
disruptive innovartion in the 90th, when we came up with IPv6, but
now the predominant religion seems to be being stuck in small
incremental enhancements of that 25 year old architecture, especially
because its bible (RFC8200) did only think of the IPv6 Internet use-case
requirements, but not those of private/controlled networks.
[/Rant]

Cheer
    Toerless

On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
> Really we do not need to be inventing anything new in this space.
> We already have too many mechanisms.  ISPs just need to DEPLOY the
> existing mechanism.
> 
> We have plain dual stack.
> 
> We have public IPv4 + 6rd for ISPs where the access network doesn???t
> support IPv6.
> 
> We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn???t
> support IPv6 and they have run out of IPv4 space.
> 
> We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when the ISP
> has run out of IPv4 and the access network supports IPv6.
> 
> We have CGN + IPv6.
> 
> Do we really need something more at the protocol level?
> 
> We do need Governments to ban the selling of new IPv4-only domestic
> devices (CPE routers, TV???s, game boxes, etc.).
> 
> Mark
> 
> > On 20 Feb 2020, at 11:32, Khaled Omar  wrote:
> > 
> > Regardless the different %s, lets take the average one, it can not make us optimistic and stop thinking about a better solution, we should learn from the long time passed without full migration occured, if we will wait till that happens, the division will occur which is not good for the internet, lets welcome new ideas and give it the space, time, and opportunity fairly, if it will be good then welcome, if not, trash is made for this. 
> > 
> > Get Outlook for Android
> > 
> > From: ietf  on behalf of JORDI PALET MARTINEZ 
> > Sent: Thursday, February 20, 2020 2:00:58 AM
> > To: IETF Rinse Repeat 
> > Subject: Re: ipv4 and ipv6 Coexistence.
> >  
> > And you're missing several points about how those stats are looked at.
> > 
> > The % in the stats shown by google/others is only what they can measure, but they can't measure *all*. There are countries (big ones) that don't allow measurements, or at least the same level of details, and however, are doing massive IPv6 deployments.
> > 
> > All the CDNs and caches have IPv6. The customers that have those caches and enable IPv6 for their subscribers, are getting ranges over 65%, sometimes even up to 85-90% of IPv6 traffic when mainly the subscribers are householders instead of big enterprises.
> > 
> > Also, the google (and others) measurements, show average worldwide, but if you look to many countries they have even surpassed the 50% or so.
> > 
> > Regards,
> > Jordi
> > @jordipalet
> >  
> >  
> > 
> > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar"  escribi:
> > 
> >     Since long time I was observing this, still almost the same, no clear progress occurred.
> >     
> >     Thanks,
> >     
> >     Khaled Omar
> >     
> >     -----Original Message-----
> >     From: Scott O. Bradner  
> >     Sent: Wednesday, February 19, 2020 8:11 PM
> >     To: Khaled Omar 
> >     Cc: IETF Rinse Repeat 
> >     Subject: Re: ipv4 and ipv6 Coexistence.
> >     
> >     Quite a few folk are already there - see https://www.google.com/intl/en/ipv6/statistics.html
> >     
> >     Scott
> >     
> >     
> > 
> > 
> > 
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> > 
> > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> > 
> > 
> > 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org


From nobody Mon Feb 24 23:47:45 2020
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 945F33A0966 for ; Mon, 24 Feb 2020 23:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HAAyJkd2QKdh for ; Mon, 24 Feb 2020 23:47:34 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 31CE63A0965 for ; Mon, 24 Feb 2020 23:47:34 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id j132so11670193oih.9 for ; Mon, 24 Feb 2020 23:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LqjIi/y6xrsjjqITi1C5QFH4bFJy2EUsRnpcIsdcRak=; b=OOa364B6epnzWejVLEtElpOIg1PB81ZlGPJnRjK0DD3dcjJaUwZt6He0L6eezEHxwN yq1exoXyaHawfY2gUp2kC180aM2rcU2CemWx/2VHfLeujK6KNAaQ485/kNkXUmaMUk/2 dDOUi5xv/w8EXlp1CavNjw9Nv4IASkU6Fb6zb4RRQNd6+wDbnT8PK5jLuHQk8sYaAlRX Oc2DucV9THt2WtyrHAvEF/oEFDUgY1GZ0g1eLdJspSjK+1AqmJcGTe5o3qIQQm+uhq+/ sJG0Gx4zl8HoXyXmIEC++J/wEfCEUI8u7dDIM8BzA8/6Mu19zXwl6Di9g5W8VjtJO3Tk JmcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LqjIi/y6xrsjjqITi1C5QFH4bFJy2EUsRnpcIsdcRak=; b=Aa4Xdt4SutsykVU5OW+Yvr6dnt2fwXqhkpdYurSTUiFQ3W/TJ3R077S8N7dbAge2sZ g1r85tOguZ+b1juZxUeZ9Kv+ZHNMIwZdS13KlgkbOwJacSV4VFluVgWgWhsQZHQHAkni pwvJXnJYKUj/WE+2PHfUsCqZMqymjoQHnVd85+kqPNb7NUvP0xQ4K86Sd2qxf66dMmk2 WOXU3NT94GA8EtGFGgFvtgk9sOOgjarQPwOYII7PaY+dd3YCcU7GSedywEJ0zfDZwa9B Wu3XZs3TwcTUZDlszzIuB+CxstDYihxzNPlUQ0A++7TcZputFBXB/rlh9UMzBihLBFgW 9pQA==
X-Gm-Message-State: APjAAAXS+zlPE+dvYA8uX9reL0OCb+H0nZajYd03WGGsvoDI78cjaT6D I2cEx5KsKf3zP6Y7bxQSD/B2TbmXMJzpi45WuZo=
X-Google-Smtp-Source: APXvYqzYIvDXx21/Ae1JAwdu/KzwohfqBapiBdR2IAWZYCAzT+fIdFKXAj5yxvYSc4/QnmpLut/vqOOuBhcD4xpvJuE=
X-Received: by 2002:aca:f354:: with SMTP id r81mr2354090oih.90.1582616853448;  Mon, 24 Feb 2020 23:47:33 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Mon, 24 Feb 2020 23:47:33 -0800 (PST)
In-Reply-To: <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
From: Guntur Wiseno Putra 
Date: Tue, 25 Feb 2020 14:47:33 +0700
Message-ID: 
To: Toerless Eckert 
Cc: Mark Andrews , Khaled Omar ,  "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005d8d7b059f61b3d2"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 25 Feb 2020 07:47:37 -0000

--0000000000005d8d7b059f61b3d2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless and
architecture-discuss,

To inform that there is a post on IPv6 yesterday at the Open Forum's
Discussion of the Internet Society:

"Adopting and Enforcing an IPv6-Only Policy: If Not Now, When"?

by Charles Sun



https://connect.internetsociety.org/communities/community-home/
digestviewer/viewthread?MessageKey=3Df2844839-3d7d-40e2-b7ab-e4b0c1562de8&
CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3D
digestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8



Regard,
Guntur Wiseno Putra

Pada Selasa, 25 Februari 2020, Toerless Eckert  menulis:

> [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
>
> Mark:
>
> Funny to see how yours is the first actual answer to at least how i read
> Khaleds question. I would summarize what you said with:
>
> https://en.wikipedia.org/wiki/IPv6_transition_mechanism
>
> (14 standardized plus a lot more. Aka: thank you, but we have enough)
>
> Most everybody else jumps to the growth of the IPv6 Internet, which
> to me is just the visible tip of the iceberg of overall IPv4 and IPv6
> deployments. I think the picture changes quite a bit if we look at the
> whole iceberg.
>
> In private / controlled networks, the choices are not only IPv4 vs.
> IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet
> switching.
>
> For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon
> be software-only overlay virtual networks whereas the actual
> terrabit accelerated hardware forwarding plane of future networks
> maybe something else. 4G/5G "core" "network" already are such
> overlay networks.
>
> [Rant]
> I am not sure if the question, as constrained as  Khaled is asking
> it will really help us to improve what we should do in the future. But
> neither is the defensive reaction of IPv6 evangelists pointing at the
> growth curve of the IPv6 Internet as the only relevant metric to the
> success and benefits of IPv6.
>
> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6, but
> now the predominant religion seems to be being stuck in small
> incremental enhancements of that 25 year old architecture, especially
> because its bible (RFC8200) did only think of the IPv6 Internet use-case
> requirements, but not those of private/controlled networks.
> [/Rant]
>
> Cheer
>     Toerless
>
> On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
> > Really we do not need to be inventing anything new in this space.
> > We already have too many mechanisms.  ISPs just need to DEPLOY the
> > existing mechanism.
> >
> > We have plain dual stack.
> >
> > We have public IPv4 + 6rd for ISPs where the access network doesn???t
> > support IPv6.
> >
> > We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn??=
?t
> > support IPv6 and they have run out of IPv4 space.
> >
> > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when the
> ISP
> > has run out of IPv4 and the access network supports IPv6.
> >
> > We have CGN + IPv6.
> >
> > Do we really need something more at the protocol level?
> >
> > We do need Governments to ban the selling of new IPv4-only domestic
> > devices (CPE routers, TV???s, game boxes, etc.).
> >
> > Mark
> >
> > > On 20 Feb 2020, at 11:32, Khaled Omar 
> wrote:
> > >
> > > Regardless the different %s, lets take the average one, it can not
> make us optimistic and stop thinking about a better solution, we should
> learn from the long time passed without full migration occured, if we wil=
l
> wait till that happens, the division will occur which is not good for the
> internet, lets welcome new ideas and give it the space, time, and
> opportunity fairly, if it will be good then welcome, if not, trash is mad=
e
> for this.
> > >
> > > Get Outlook for Android
> > >
> > > From: ietf  on behalf of JORDI PALET MARTINEZ
> 
> > > Sent: Thursday, February 20, 2020 2:00:58 AM
> > > To: IETF Rinse Repeat 
> > > Subject: Re: ipv4 and ipv6 Coexistence.
> > >
> > > And you're missing several points about how those stats are looked at=
.
> > >
> > > The % in the stats shown by google/others is only what they can
> measure, but they can't measure *all*. There are countries (big ones) tha=
t
> don't allow measurements, or at least the same level of details, and
> however, are doing massive IPv6 deployments.
> > >
> > > All the CDNs and caches have IPv6. The customers that have those
> caches and enable IPv6 for their subscribers, are getting ranges over 65%=
,
> sometimes even up to 85-90% of IPv6 traffic when mainly the subscribers a=
re
> householders instead of big enterprises.
> > >
> > > Also, the google (and others) measurements, show average worldwide,
> but if you look to many countries they have even surpassed the 50% or so.
> > >
> > > Regards,
> > > Jordi
> > > @jordipalet
> > >
> > >
> > >
> > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <
> ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com> escribi=
=C3=B3:
> > >
> > >     Since long time I was observing this, still almost the same, no
> clear progress occurred.
> > >
> > >     Thanks,
> > >
> > >     Khaled Omar
> > >
> > >     -----Original Message-----
> > >     From: Scott O. Bradner 
> > >     Sent: Wednesday, February 19, 2020 8:11 PM
> > >     To: Khaled Omar 
> > >     Cc: IETF Rinse Repeat 
> > >     Subject: Re: ipv4 and ipv6 Coexistence.
> > >
> > >     Quite a few folk are already there - see
> https://www.google.com/intl/en/ipv6/statistics.html
> > >
> > >     Scott
> > >
> > >
> > >
> > >
> > >
> > > **********************************************
> > > IPv4 is over
> > > Are you ready for the new Internet ?
> > > http://www.theipv6company.com
> > > The IPv6 Company
> > >
> > > This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the exclusive use =
of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> > >
> > >
> > >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

--0000000000005d8d7b059f61b3d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless and
architecture-discuss,

To inf=
orm that there is a post on IPv6 yesterday at the Open Forum's Discussi=
on of the Internet Society:

"Adopting and Enf=
orcing an IPv6-Only Policy: If Not Now, When"?=C2=A0
=
=

by Charles Sun






Regard,
Guntur Wiseno Putra

Pada Selasa, 25 Februari 2020, Toerless =
Eckert <tte@cs.fau.de=
> menulis:
[Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.o=
rg]



Mark: 



Funny to see how yours is the first actual answer to at least how i read
Khaleds question. I would summarize what you said with:



https://en.wikipedia.org/wiki/IPv6_transition_mechanism



(14 standardized plus a lot more. Aka: thank you, but we have enough)



Most everybody else jumps to the growth of the IPv6 Internet, which

to me is just the visible tip of the iceberg of overall IPv4 and IPv6

deployments. I think the picture changes quite a bit if we look at the

whole iceberg. 



In private / controlled networks, the choices are not only IPv4 vs.

IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet 

switching.



For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon

be software-only overlay virtual networks whereas the actual

terrabit accelerated hardware forwarding plane of future networks

maybe something else. 4G/5G "core" "network" already ar=
e such

overlay networks. 



[Rant]

I am not sure if the question, as constrained as=C2=A0 Khaled is asking

it will really help us to improve what we should do in the future. But

neither is the defensive reaction of IPv6 evangelists pointing at the

growth curve of the IPv6 Internet as the only relevant metric to the

success and benefits of IPv6.



I am primarily concerned that we did manage to recognize we needed

disruptive innovartion in the 90th, when we came up with IPv6, but

now the predominant religion seems to be being stuck in small

incremental enhancements of that 25 year old architecture, especially

because its bible (RFC8200) did only think of the IPv6 Internet use-case
requirements, but not those of private/controlled networks.

[/Rant]



Cheer

=C2=A0 =C2=A0 Toerless



On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:

> Really we do not need to be inventing anything new in this space.

> We already have too many mechanisms.=C2=A0 ISPs just need to DEPLOY th=
e

> existing mechanism.

> 

> We have plain dual stack.

> 

> We have public IPv4 + 6rd for ISPs where the access network doesn???t<=
br>
> support IPv6.

> 

> We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn?=
??t

> support IPv6 and they have run out of IPv4 space.

> 

> We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when th=
e ISP

> has run out of IPv4 and the access network supports IPv6.

> 

> We have CGN + IPv6.

> 

> Do we really need something more at the protocol level?

> 

> We do need Governments to ban the selling of new IPv4-only domestic
> devices (CPE routers, TV???s, game boxes, etc.).

> 

> Mark

> 

> > On 20 Feb 2020, at 11:32, Khaled Omar <eng.khaled.omar@outlook.com&g=
t; wrote:

> > 

> > Regardless the different %s, lets take the average one, it can no=
t make us optimistic and stop thinking about a better solution, we should l=
earn from the long time passed without full migration occured, if we will w=
ait till that happens, the division will occur which is not good for the in=
ternet, lets welcome new ideas and give it the space, time, and opportunity=
 fairly, if it will be good then welcome, if not, trash is made for this. <=
br>
> > 

> > Get Outlook for Android

> > 

> > From: ietf <ietf-bounces@ietf.org> on behalf of JORDI PALET MARTINEZ &l=
t;jordi.palet=3D40consulintel.es@dmarc.ietf.org>

> > Sent: Thursday, February 20, 2020 2:00:58 AM

> > To: IETF Rinse Repeat <ietf@ietf.org>

> > Subject: Re: ipv4 and ipv6 Coexistence.

> >=C2=A0 

> > And you're missing several points about how those stats are l=
ooked at.

> > 

> > The % in the stats shown by google/others is only what they can m=
easure, but they can't measure *all*. There are countries (big ones) th=
at don't allow measurements, or at least the same level of details, and=
 however, are doing massive IPv6 deployments.

> > 

> > All the CDNs and caches have IPv6. The customers that have those =
caches and enable IPv6 for their subscribers, are getting ranges over 65%, =
sometimes even up to 85-90% of IPv6 traffic when mainly the subscribers are=
 householders instead of big enterprises.

> > 

> > Also, the google (and others) measurements, show average worldwid=
e, but if you look to many countries they have even surpassed the 50% or so=
.

> > 

> > Regards,

> > Jordi

> > @jordipalet

> >=C2=A0 

> >=C2=A0 

> > 

> > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <=
;ietf-bounces@ie=
tf.org en nombre de eng.khaled.omar@outlook.com> escribi=C3=B3:

> > 

> >=C2=A0 =C2=A0 =C2=A0Since long time I was observing this, still al=
most the same, no clear progress occurred.

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0Thanks,

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0Khaled Omar

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0-----Original Message-----

> >=C2=A0 =C2=A0 =C2=A0From: Scott O. Bradner <sob@sobco.com> 

> >=C2=A0 =C2=A0 =C2=A0Sent: Wednesday, February 19, 2020 8:11 PM

> >=C2=A0 =C2=A0 =C2=A0To: Khaled Omar <eng.khaled.omar@outlook.com><=
br>
> >=C2=A0 =C2=A0 =C2=A0Cc: IETF Rinse Repeat <ietf@ietf.org>

> >=C2=A0 =C2=A0 =C2=A0Subject: Re: ipv4 and ipv6 Coexistence.

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0Quite a few folk are already there - see https://www.google.com/intl/en/ipv6/statistics.html

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0Scott

> >=C2=A0 =C2=A0 =C2=A0

> >=C2=A0 =C2=A0 =C2=A0

> > 

> > 

> > 

> > **********************************************

> > IPv4 is over

> > Are you ready for the new Internet ?

> > http:=
//www.theipv6company.com

> > The IPv6 Company

> > 

> > This electronic message contains information which may be privile=
ged or confidential. The information is intended to be for the exclusive us=
e of the individual(s) named above and further non-explicilty authorized di=
sclosure, copying, distribution or use of the contents of this information,=
 even if partially, including attached files, is strictly prohibited and wi=
ll be considered a criminal offense. If you are not the intended recipient =
be aware that any disclosure, copying, distribution or use of the contents =
of this information, even if partially, including attached files, is strict=
ly prohibited, will be considered a criminal offense, so you must reply to =
the original sender to inform about this communication and delete it.

> > 

> > 

> > 

> 

> -- 

> Mark Andrews, ISC

> 1 Seymour St., Dundas Valley, NSW 2117, Australia

> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 INTERNET: marka@isc.org=




_______________________________________________

Architecture-discuss mailing list

Architec=
ture-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/architecture-discu=
ss




--0000000000005d8d7b059f61b3d2--


From nobody Tue Feb 25 03:49:39 2020
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 6EAE93A0A5E for ; Tue, 25 Feb 2020 03:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KJzJqtg5izIh for ; Tue, 25 Feb 2020 03:49:33 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 8540B3A0A5B for ; Tue, 25 Feb 2020 03:49:33 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id p125so12252998oif.10 for ; Tue, 25 Feb 2020 03:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIxRBoOw44TVja0iv2FRSw06WLb4JeMCDGOLx8J4oBs=; b=SMKdGtyG2858XQ2f8+1ZIKAyjlSN+y/vYIG6bCiaa6LWGt125L594Z119tafvmtjNF IuVwuCU68fYiIX/l07hzev8nE0NGcyk5Lxr0ULMIofLmytmfTkNrpDZt5Ce7lfREEptp ps53XleQSpHEKf+AUKVyunvvkNkb6vIqHeQ8rz8FrP50BA6PhHodHqkbanExoJ8uj+Bf iGO0aIvyA6r12K+mc02BaV7+fQSi8zAip/BVoDo9feWr0JVZ62FGYiTa5VlmoX7ai7rv W3FwIz2iySk6I7XWpH1mxvY/adjGQEII/Az6pBXtpcFjBnuB8za58WWlTOo/ee3Qaimk 9WxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIxRBoOw44TVja0iv2FRSw06WLb4JeMCDGOLx8J4oBs=; b=LxaJCcMEL9OLfFlFJMIcMhRcgZLxWdsGeZAxtupX0bPwupDOXHHfYnSfj/gaZIs/9X dOsI4Kz+eVFnjfUAmAUN9GVCNwxF/GtEYzCEFyO44DLDxORDde7lfOoy9NwpGMDK0iwz lIKvaawZqJQ20qDBaLFLLMUnhd+CQIj9uwL6QNnIhodBEApWs82W7Lycbi5ksXkrgyis YZkX9YqKQl/kjI6MV4E7RIPmkdmFJ/6tdluOTaxeQ66xtzsDj5yFkd9fmS5IyW7beVre /rphc1v1hZxSy22HLz+p6m4mEys8xj+DCMv2sYLRTVl/NGsDTuw3SoxPfMXP+yOfSceU tvSA==
X-Gm-Message-State: APjAAAUSOXa7B0AulAh1yU9GZKSA9WPsLfD4hQcdxjsos+OywrYsmuzS 1gHikHqsG9oiXQxBMyaqXAvXiK9UPvaB9l1nDPh04A==
X-Google-Smtp-Source: APXvYqymiWLpXdyzcrQHa05ZbRc+CVxJ/GB7uCvwbuq1PJagMhCeefScl6feHFfKh6mo0jsODm7mp74CtmANymM9gAE=
X-Received: by 2002:aca:1a10:: with SMTP id a16mr3244438oia.9.1582631372808; Tue, 25 Feb 2020 03:49:32 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Tue, 25 Feb 2020 03:49:32 -0800 (PST)
In-Reply-To: 
References:  <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com>    
From: Guntur Wiseno Putra 
Date: Tue, 25 Feb 2020 18:49:32 +0700
Message-ID: 
To: Russ Housley 
Cc: "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c9641d059f6514e7"
Archived-At: 
Subject: Re: [arch-d] Network Architecture in the Internet Society
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, 25 Feb 2020 11:49:37 -0000

--000000000000c9641d059f6514e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

Pekka Nikander, in "Reflections on Architecture" of the previous message,
mentioned little about "economy and information (security)": by this thread
of "(Consolidation of) the Internet Economy: from the socio-economic to the
architectural", I wander would these raw materials of thought works for an
economy of the Internet:


"Goods and services: Here we are. What is it there...? What does happen
there...? What could we make there...? Would our sad heart --because of
stupidities/foolishness and failures-- be entertained...? Would our
passions -- for truth, justice and beauty -- be well served...? --including
of ourselves...?

Those people either are or were great, it is said: for what they have made
available to many others, for what they have made inspiring --saying about
acceptances and denials by-- many others: concepts and technics. Part of
those things have been being through places and times, many countries and
being made survived for decades, for centuries... Other part of those
things have been forgotten though ever enjoyed long celebrations: and, yes,
there were then revelations of what were silent before... They just took
rest while kept maintained in such simplicities until other things came to
and take them with new hopes, new happines, new plans, new games... (It is
like a story on concepts in the making: with their histories, ...)

...

Here we have more, here we lack of... There are others by whom we may talk
to and exchange with... Farewell: just take journeys... (so it is then here
we are in journeys or we may be there in journeys...)

...

"Here we have , here we lack of": does it not represent an understanding
about "justice"...? What are about "truth" and "beauty"...?

If it does refers us to a notion on "justice", or perhaps precisely
"natural justice", if it is how "justice" works, then how do we take our
journeys..?

Choices and risks, benefits and costs, gains and pains.... There are rules
of games: is it not illusive not to think/to think otherwise that profits
are just equal to costs/sacrifices, that victories are equal to
struggles...? And, there are as well the historical as the social, as well
succesive generations as consensus/collectivities/togetherness, we live in:
of rules of games, of "justice".
...

The circle, or the equation, of trust, responsibility, and facility...
People trust ones in such ways to take responsibilities to provide them
with goods or services accompanied by facilities to work on the
responsibilities...--including such physio- and psychoterapies of rest...


...".



Regard,
Guntur Wiseno Putra

Pada Senin, 24 Februari 2020, Guntur Wiseno Putra 
menulis:

> Dear architecture-discuss,
>
> By opening files at www.ietfjournal.org I finded this out: Among others
> this is one worked on by the IETF publication on "architecture" which
> mentioned also about "architecture-discuss" in the time of its beginning
> --I then made it part of the entry on "Consolidation of the Internet..." =
at
> the Internet Society's Open Forum Library:
>
> NETWORKING RESEARCHReflections on
> 
> ArchitectureBy: Pekka Nikander
> Date:
> December 2005
>
>
> "I happen to have an architect=E2=80=99s mind. Looking at the network of =
today, I
> strongly feel the pain of the current architecture=E2=80=99s cracking and
> squeaking. Consequently, I believe that we =E2=80=93 the wider IETF commu=
nity
> responsible for Internet technology =E2=80=93 need to re-think the archit=
ecture. We
> need to find a way to re-create the core of the Internet in a way that
> leads to a new era of innovation and intellectual prosperity. The highlig=
ht
> of my IETF64 meeting in Vancouver was that I started to see signs of
> interest and activity in the broader community to pursue such a goal.
>
> ...
>
> The IAB has recently created a new mailing list, architecture-discuss
> [15], for wider discussion of architectural issues, which I hope will
> develop into a valuable forum over time. I hope to see you there".
>
> https://www.ietfjournal.org/reflections-on-architecture
>
>
>
>
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
> menulis:
>
>> Dear Russ & architecture-discuss,
>>
>>
>> I have just added Leva. T & H. Suommi's "Framework of Analyzing
>> Feasibility of Internet Protocols" to the before-mentioned list of readi=
ngs
>> by "Add Comment" Facility in the OPEN FORUM Community Library:
>>
>>
>> ###
>> To the list of readings above (Consolidation of the Internet: from the
>> Socio-Economic to the Architectural) may I add "Framework of Analyzing
>> Feasibility of Internet Potocols" (Leva, T. & H. Suommi, the IAB Worksho=
p
>> on Internet Technology Adootion and Transition 2013) which was ever to b=
e
>> part of architecture-discuss@ietf.org "Centralization or diversity?"
>> January 22th 2020:
>>
>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/s
>> dTkLd7q7wXyfAnjJQlNceWPr8U
>>
>>
>> ###
>>
>>
>>
>>
>> Note:
>> To clarify what I said in the previous message:
>> I mean the architecture-discuss@ietf.org and the OPEN FORUM Community
>> Library may be about a networked community of reading, a networked libra=
ry.
>>
>>
>>
>>
>>
>>
>> Regard,
>> Guntur Wiseno Putra
>>
>> Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
>> menulis:
>>
>>> Dear Russ and architecture-discuss,
>>>
>>> The post  in OPEN Forum Community Library is about those document saved
>>> in the architecture-discuss mailarchive I mentioned above plus
>>>
>>>  Arkko, Jarri et all., "Considerations on the Internet Consolidation an=
d
>>> the Internet Architecture", Internet-Draft, IETF, Expired April 2019
>>> https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00
>>>
>>> While, I have not included yet that of T. Leva and H. Suommi's...
>>>
>>> I emphasized on socio-economic and architectural learnings attempted by
>>> those documents there--while the post at architecture-discuss emphazise=
d on
>>> feasibility of the Internet architecture in relation with aesthetic and
>>> ethic experiences.
>>>
>>> This is what I saved in OPEN FORUM Community Library:
>>>
>>> "Consolidation of the Internet: From the Socio-Economic to the
>>> Architectural"
>>>
>>> This documents refer to "Consolidation in the Internet" which is of
>>> economic and architectural approaches and perspectives:
>>>
>>> - ISOC Global Internet Report Consolidation in the Internet Economy
>>> https://future.internetsociety.org/2019/wp-content/uploads/s
>>> ites/2/2019/04/InternetSociety-GlobalInternetReport-
>>> ConsolidationintheInternetEconomy.pdf
>>> - Arkko, Jarri et all., "Considerations on the Internet Consolidation
>>> and the Internet Architecture", Internet-Draft, IETF, Expired April 201=
9
>>> https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00
>>> - Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols",
>>> IAB-DEDR Workshop 2019 https://www.iab.org/wp-content
>>> /IAB-uploads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pd=
f
>>>
>>> - Arkko, Jarri, "Centralized Architecture in Internet Architecture",
>>> Internet Draft, 2019
>>> https://www.ietf.org/id/draft-arkko-arch-infrastructure-cent
>>> ralisation-00.txt
>>> Kutscher, Dirk, "Protocol Design and Socio-economic Realities", in the
>>> IAB-DEDR Workshop 2019
>>> https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-kutsc
>>> her-internet-design-kutscher.pdf
>>>
>>>
>>> Note: This post is related with another one in this "Open Forum":
>>> Restream: Internet Consolidation: What Lies beneath the Application
>>> Layer..." (December 14th 2019) https://connect.internetsociet
>>> y.org/communities/community-home/digestviewer/viewthread?Gro
>>> upId=3D67&MessageKey=3D426220c6-e41e-45c8-8872-7f0cc455f492&Comm
>>> unityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Ddigestvi
>>> ewer&ReturnUrl=3D%2fcommunities%2fcommunity-home%
>>> 2fdigestviewer%3fCommunityKey%3d3a9fa082-a518-475d-9e7f-ecec4ffe56dd
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regard,
>>> Guntur Wiseno Putra
>>>
>>> Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra 
>>> menulis:
>>>
>>>> Dear Russ and architecture-discuss,
>>>>
>>>>
>>>> I am new there, I have not know muc "how to": I think one needs to
>>>> create an account in the Internet Society to join with OPEN FORUM Comm=
unity
>>>> to access its features:
>>>>
>>>> https://www.internetsociety.org/become-a-member/
>>>>
>>>>
>>>> But at this architecture-discuss, where we are now, one may simply
>>>> access its mail archives for the documents on "Consolidation of the
>>>> Internet" --so it is nothing new but such a networked community of rea=
ding,
>>>> such a networked library:
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/s
>>>> dTkLd7q7wXyfAnjJQlNceWPr8U
>>>>
>>>> I find no search engine facility for documents at OPEN FORUM community
>>>> Library while there is one at architecture-discuss mail archive.
>>>>
>>>> Regard,
>>>> Guntur Wiseno Putra
>>>>
>>>> Pada Jumat, 31 Januari 2020, Russ Housley 
>>>> menulis:
>>>>
>>>>> Is there a way to see the document without creating an account?
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>> On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra 
>>>>> wrote:
>>>>>
>>>>> Dear architecture-discuss,
>>>>>
>>>>> Documents related with the current issues on "consolidation of the
>>>>> Internet" saved in the "Open Forum" community of the Internet Society=
:
>>>>>
>>>>>
>>>>> https://connect.internetsociety.org/viewdocument/consolidati
>>>>> on-of-the-internet-from?CommunityKey=3D3a9fa082-a518-475d-9e7f
>>>>> -ecec4ffe56dd&tab=3Dlibrarydocuments#ItemCommentPanel
>>>>>
>>>>> Regard,
>>>>> Guntur Wiseno Putra
>>>>>
>>>>>
>>>>>

--000000000000c9641d059f6514e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

Pekka Nikander, in "Refl=
ections on Architecture" of the previous message, mentioned little abo=
ut "economy and information (security)": by this thread of "=
(Consolidation of) the Internet Economy: from the socio-economic to the arc=
hitectural", I wander would these raw materials of thought works for a=
n economy of the Internet:


"Go=
ods and services: Here we are. What is it there...? What does happen there.=
..? What could we make there...? Would our sad heart --because of stupiditi=
es/foolishness and failures-- be entertained...? Would our passions -- for =
truth, justice and beauty -- be well served...? --including of ourselves...=
?



Those people either are or were great, it is said: for what they have made =
available to many others, for what they have made inspiring --saying about =
acceptances and denials by-- many others: concepts and technics. Part of th=
ose things have been being through places and times, many countries and bei=
ng made survived for decades, for centuries... Other part of those things h=
ave been forgotten though ever enjoyed long celebrations: and, yes, there w=
ere then revelations of what were silent before... They just took rest whil=
e kept maintained in such simplicities until other things came to and take =
them with new hopes, new happines, new plans, new games... (It is like a st=
ory on concepts in the making: with their histories, ...) 



...



Here we have more, here we lack of... There are others by whom we may talk =
to and exchange with...=C2=A0Farewell: just take journeys... (so it is then=
 here we are in journeys or we may be there in journeys...)



...



"Here we have , here we lack of": does it not represent an unders=
tanding about "justice"...? What are about "truth" and =
"beauty"...? 



If it does refers us to a notion on "justice", or perhaps precise=
ly "natural justice", if it is how "justice" works, the=
n how do we take our journeys..? 

Choices and risks, benefits and co=
sts, gains and pains.... There are rules of games: is it not illusive not t=
o think/to think otherwise that profits are just equal to costs/sacrifices,=
 that victories are equal to struggles...? And, there are as well the histo=
rical as the social, as well succesive generations as consensus/collectivit=
ies/togetherness, we live in: of rules of games, of "justice".=C2=
=A0

...


The circle, or the equation, of trust, responsibility, and facility... =
People trust ones in such ways to take responsibilities to provide them wit=
h goods or services accompanied by facilities to work on the responsibiliti=
es...--including such physio- and psychoterapies of rest...=C2=A0





...".



Regard,
Guntur Wiseno Putra

Pada Senin, 24 Februari 2020, Guntur Wi=
seno Putra <gsenopu@gmail.com&g=
t; menulis:
Dear architecture-discuss,
By opening files at www.ietfjournal.org I finded this out: Among others =
this is one worked on by the IETF publication on "architecture" w=
hich mentioned also about "architecture-discuss" in the time of i=
ts beginning --I then made it part of the entry on "Consolidation of t=
he Internet..." at the Internet Society's Open Forum Library:
<=
br>
NETWORKING RESE=
ARCH
Reflections o=
n
Architecture
By:=C2=A0Pekka Nikander<=
/h4>
Date: Decem=
ber 2005


"I happen to have an architect=
=E2=80=99s mind. Looking at the network of today, I strongly feel the pain =
of the current architecture=E2=80=99s cracking and squeaking. Consequently,=
 I believe that we =E2=80=93 the wider IETF community responsible for Inter=
net technology =E2=80=93 need to re-think the architecture. We need to find=
 a way to re-create the core of the Internet in a way that leads to a new e=
ra of innovation and intellectual prosperity. The highlight of my IETF64 me=
eting in Vancouver was that I started to see signs of interest and activity=
 in the broader community to pursue such a goal.

...

<=
/span>The IAB has recen=
tly created a new mailing list, architecture-discuss [15], for wider discus=
sion of architectural issues, which I hope will develop into a valuable for=
um over time. I hope to see you there".

https://www.=
ietfjournal.org/reflections-on-architecture





Regard,
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2=
020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear Russ & architecture-discuss,


=
I have just added Leva. T & H. Suommi's "Framework of Analyzin=
g Feasibility of Internet Protocols" to the before-mentioned list of r=
eadings by "Add Comment" Facility in the OPEN FORUM Community Lib=
rary:


###
To the list of=
 readings above (Consolidation of the Internet: from the Socio-Economic to =
the Architectural) may I add "Framework of Analyzing Feasibility of In=
ternet Potocols" (Leva, T. & H. Suommi, the IAB Workshop on Intern=
et Technology Adootion and Transition 2013) which was ever to be part of architectu=
re-discuss@ietf.org "Centralization or diversity?" January 22=
th 2020:

https://mailarchive=
.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr=
8U


###



Note:=C2=A0
<=
div>To clarify what I said in the previous message:=C2=A0
I mean =
the arch=
itecture-discuss@ietf.org and the OPEN FORUM Community Library may be a=
bout a networked community of reading, a networked library.

<=
/div>





<=
/div>
Regard,
Guntur Wiseno Putra

Pada Jumat, 31 Janua=
ri 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear Russ and architecture-discuss,

The post =C2=
=A0in OPEN Forum Community Library is about those document saved in the arc=
hitecture-discuss mailarchive I mentioned above plus=C2=A0

=C2=A0Arkko, Jarri et all., "Considerati=
ons on the Internet Consolidation and the Internet Architecture", Inte=
rnet-Draft, IETF, Expired April 2019 https://tools=
.ietf.org/html/draft-arkko-iab-internet-consolidation-00=C2=A0
While, I have not included yet that=
 of T. Leva and H. Suommi's...

I emphas=
ized on socio-economic and architectural learnings attempted by those docum=
ents there--while the post at architecture-discuss emphazised on feasibilit=
y of the Internet architecture in relation with aesthetic and ethic experie=
nces.

This is what I saved in OPEN FORUM Community=
 Library:

"Consolidation of the Internet: Fro=
m the Socio-Economic to the Architectural"

This documents refer to "Consolida=
tion in the Internet" which is of economic and architectural approache=
s and perspectives:

- ISOC Glo=
bal Internet Report Consolidation in the Internet Economy https://future.internetsociety.org/2019/wp-content/upload=
s/sites/2/2019/04/InternetSociety-GlobalInternetReport-Conso=
lidationintheInternetEconomy.pdf=C2=A0
- Arkko, Jarri et all., "Considerations on the Inte=
rnet Consolidation and the Internet Architecture", Internet-Draft, IET=
F, Expired April 2019 https://tools.ietf.org/html/=
draft-arkko-iab-internet-consolidation-00=C2=A0
- Sullivan, Andrew, "Three Kinds of C=
oncentration in Open Protocols", IAB-DEDR Workshop 2019 https://www.iab.org/wp-content<=
wbr>/IAB-uploads/2019/05/p7-sulllivan-three_kinds_concentration_a=
js_dedr.pdf=C2=A0
- Arkko=
, Jarri, "Centralized Architecture in Internet Architecture", Int=
ernet Draft, 2019=C2=A0
https://www.ietf.org/id/draft-arkko-arch-i=
nfrastructure-centralisation-00.txt
Kutscher, Dirk, "Protocol Design and Socio-economic Re=
alities", in the IAB-DEDR Workshop 2019
https://www=
.iab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-des=
ign-kutscher.pdf


Note: This post is related with another =
one in this "Open Forum": Restream: Internet Consolidation: What =
Lies beneath the Application Layer..." (December 14th 2019) https=
://connect.internetsociety.org/communities/community-home/digestv=
iewer/viewthread?GroupId=3D67&MessageKey=3D426220c6-e41e-45c8=
-8872-7f0cc455f492&CommunityKey=3D3a9fa082-a518-475d-9e7f-ece=
c4ffe56dd&tab=3Ddigestviewer&ReturnUrl=3D%2fcommunities%2=
fcommunity-home%2fdigestviewer%3fCommunityKey%3d3a9fa082-a518-475=
d-9e7f-ecec4ffe56dd


=






=


Regard,
Guntur Wiseno Putra

Pada Jumat=
, 31 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear Russ and architecture-discuss,=C2=A0


I am new there, I have not know muc "how to": I think=
 one needs to create an account in the Internet Society to join with OPEN F=
ORUM Community to access its features:



https://www.internetsociety.org/become-a-member/




But at this architecture-discuss, where we are now, one may simply acce=
ss its mail archives for the documents on "Consolidation of the Intern=
et" --so it is nothing new but such a networked community of reading, =
such a networked library:


https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U



I find no search engine facility for documents at OPEN FORUM community Libr=
ary while there is one at architecture-discuss mail archive.
=

Regard,
Guntur Wiseno Putra

Pada Jum=
at, 31 Januari 2020, Russ Housley <housley@vigilsec.com> menulis:
Is there a way to see the document without creating an account?
Russ


=
On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra <gsenopu@gmail.com> wrote:

=

Dear architecture-discuss,

Documents related with t=
he current issues on "consolidation of the Internet" saved in the=
 "Open Forum" community of the Internet Society:













--000000000000c9641d059f6514e7--


From nobody Tue Feb 25 10:16:31 2020
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 254593A12A4 for ; Tue, 25 Feb 2020 10:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bWEmpeS08WKr for ; Tue, 25 Feb 2020 10:16:28 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 E56283A1294 for ; Tue, 25 Feb 2020 10:16:27 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id n96so44363pjc.3 for ; Tue, 25 Feb 2020 10:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cAVQOAyr4QtNvZZVxzuBE57GZclpJaduud8wDPVkNNM=; b=sFnuPQXPecZPYDFxwJwyscKxtNvRlG5FRFg+F6Y/ZmRONhFGGUfpjK3u+tEDuAj2F9 9eFLuFDn2B0sxxE/AYOFho6O2gH5mNeJAvhY5HbpRZI5pK7nP+eVEg7AaKkzteKfEKRK sdWiSxuGdTFpb003FxK1DrtkoP7C1GuHt/U4jCZHZv81vJAec7yautzO3gv4YZnv1pvI YWouzxOLhrxjPezNUHUu74zu+31f8USFWXsZ5di+6+I4VtvZut6cNUdZMwqLdYXdhTJe OAWKHTyPxHI1Ckjr9pVlPZ1L3SeHV3vPImS8bFt/9t8DH3VJGed5JMUFnPUdkm1g70B4 LxuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cAVQOAyr4QtNvZZVxzuBE57GZclpJaduud8wDPVkNNM=; b=lCZIIcK/HHKyCYyI9GrSKndC0VP70tud/hPSPqcTkBDVDXghiWhIsa1s1n03KFC1Rv ylbLt0gR2pdrcdEOPk6RY2XCjo+xn3CVI3vnocG/fvHNB9u4ogb1HScYXvP4Bt5xhmjQ /7Sn3BUB+alcc0nf+YdidcPF5AVYDeojw6LtzRiOvtZyZT7Lnv50azFRKA5x3OTMxoxN aL5SNMabAr/Mr5Mnte42Ol3yTfAMBo1LyIMhS3x4zSKdQwYqKAR0xjCHCGPES4BlXt/N BDjFD3nArLBXThqhZEYMznfy+61A9aF8h9qHV7TFgnE+QiLHbM0uqs0Mn7LO7B9O0zYY SBXQ==
X-Gm-Message-State: APjAAAWYtctC8tiocVKQJBTIoSMWGM07Eosr6t04PpRamASBaZ3Jj+Vv nY2CXq9qlQHo04JyUA04E+w=
X-Google-Smtp-Source: APXvYqz8kNahP+U98+2KsIZFBJrUN2cDTl9B35cGFRZIixAJWAyg349fztaPYPlmMI7vNIN8o8e53Q==
X-Received: by 2002:a17:902:7687:: with SMTP id m7mr55733653pll.136.1582654587134;  Tue, 25 Feb 2020 10:16:27 -0800 (PST)
Received: from ?IPv6:2600:8801:d004:600:5d6a:f944:7762:f7f3? ([2600:8801:d004:600:5d6a:f944:7762:f7f3]) by smtp.gmail.com with ESMTPSA id v9sm4089084pja.26.2020.02.25.10.16.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 10:16:26 -0800 (PST)
From: Fred Baker 
Message-Id: <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3C2AE762-B98C-45E2-B187-332D272F8BCF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.19\))
Date: Tue, 25 Feb 2020 10:16:24 -0800
In-Reply-To: <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
Cc: Mark Andrews , architecture-discuss@ietf.org
To: Toerless Eckert 
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3608.80.19)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 25 Feb 2020 18:16:29 -0000

--Apple-Mail=_3C2AE762-B98C-45E2-B187-332D272F8BCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 24, 2020, at 2:27 PM, Toerless Eckert  wrote:
>=20
> In private / controlled networks, the choices are not only IPv4 vs.
> IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet
> switching.

You make some important points, but...

We have had several countries discuss pulling off the Internet or doing =
something pretty disruptive, such as unilaterally changing from DNS to =
something else or imposing government-controlled firewalls. My point to =
them - and I have spoken with more than one - is that disrupting =
Internet communications affects the flow of international commerce, and =
therefore money, into their countries.

The same point applies in this case. If a company wants to internally =
only use  as a link layer protocol, that's their choice, but =
if they step very far away from IPv4 and IPv6, it means that they can't =
do business with their vendors and their customers - they have to in =
some way translate or overlay at that boundary. What has been beneficial =
with Internet technologies since they were invented was that one no =
longer had to think about global deployments of BBN 1822, X.25, =
Ethernet, or any of a long list of other things; they became carriers =
for a common architecture enabling global communications.

--Apple-Mail=_3C2AE762-B98C-45E2-B187-332D272F8BCF
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-----

iQIzBAEBCgAdFiEENpw36LrlpbGsJvlBQTRsYxfuthwFAl5VZHgACgkQQTRsYxfu
thzttg//ctmFElnl5gTrOp8COhT+Vea1E4PHatUE7uZ3mzPKx+rbzYkapVTBZnQt
1ueaN18+BIOzTgrgG8sP+BHAN9h0HlIgkiSCIvzH5nH2ueYK+0pPjL0pkY8ofXmH
fwRfWCWEqIU3aGRtw3u3ii/IYykO7uEPX2xQ003LcblP7wbzXQULE69+Fs6JE60d
elRQtWJ1xAV4ufQrHDpbzw4zJJVTATcr6DY2TLuBWnNei0nMK7YZj+EpkV1ha06V
a2epAmfBcqSNSMO0+pnBV00Af19qbxZSfWTug//H842VzBqL+QNaFJydT3phsVhY
NlQYgMl+NsKjuUGdpfT2jHu4c8NrYn5fnyMFwlunUB/twlDAa35ZKCo75SV5P7LF
J/7Dk01oqHvT9gA8xLEbCkfXBj0OL9jsKUFAtMAzA9wLIN8A3NE/raA1Ml/YdgI2
5Cnb98WnuRVYkzKX9vkVCIfyHQOQAo+MnE67LOIC8M4t7rqeaDzg8DHfKWAhXuMA
wrP42/HsAZ84Go+e1yyUt2++kgt32WeOX0YNf0gGOifJiq+llkaemHUtBZTMg2mP
k5KAhXtIRwsh6kHFJUvZhCQb1TB0r3X5BnpX0OcMtUJXFyH2aFLwHzxooVVC9mXb
urcwYeXr7S+D1nLHKChVILuJvX9UMCcmlm0x1aTBdOaIzWOfJl0=
=0uNB
-----END PGP SIGNATURE-----

--Apple-Mail=_3C2AE762-B98C-45E2-B187-332D272F8BCF--


From nobody Tue Feb 25 11:16:57 2020
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 C66443A1440 for ; Tue, 25 Feb 2020 11:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AxkAv8POozcl for ; Tue, 25 Feb 2020 11:16:53 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 B17F93A143F for ; Tue, 25 Feb 2020 11:16:52 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id 185so54531pfv.3 for ; Tue, 25 Feb 2020 11:16:52 -0800 (PST)
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=HNhkNywkE6F49I12eqnMztSu0fe2h5ATt3rsLXxZbLw=; b=TpB1Mhefo+JB0pVD/np0ppvSyqziJ8VWY3R8TA6wbRKvYEkb44orfKBHDjH7dBlPjM ofOzUbUe5R6OYcUyp6eOR7qD/X96Ocbas74QNEEKxPB747aoLhXdEts2HARKO/NgUAzg KWg/YjovlTxJm6aVAb6OZhQVafyUBpXtth/rW1z+CCBq/wDVZflz1pcNZQwyfp6px/uS 0wUeWdfawfZYLIvtRWfLJ0Xz4fb4N2ENr+5hvAIoPZJvx8eKKsZq+Ir6A1oBL+XNoynR klj5kHzfbK2rZS2Yjwy0C/oYOKrb4m0ckKSCh+oAl0440pg6hLXn/qM9TGf5qy8zfpJ2 9wKg==
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=HNhkNywkE6F49I12eqnMztSu0fe2h5ATt3rsLXxZbLw=; b=dXt45CyIKwgkgALoEpFM+MF7/p8b3y/Wpq/SRAwFBOLHi+ID2q/2XJn67zeOy6hdgW Mol9/18Qxye2/+T04/q1BNLxS/0qDAzkpiAWov3tIGqjFcc8pdEbkjVb6acJScKQQGNG drkCC7kSugAeVcCd0zSeYZ5jOrECfh2tGel6bVKKAfVjemOO7Nid12WEt0XXx1iQ9o7D 194pkeRMtorWSMOb5NR/lNnqqkL9aQgc4O4OyEaSOsTE7CjnixTGwT1d/F+FnRodYHGo ra5/txyG3i9TitzJpPq9tKHs1/yph5UVCK4brEmJ0hcOI0ugUhHo2xem8XrUVAap+6RG qwGw==
X-Gm-Message-State: APjAAAVbW+yVnjWmC6Dtj65Q8/7Pj3tX3n/gJxajKR79e8QZ/Pzykp5w ZdZMAYVbmrOoMPBYHNZPTehv8l/m
X-Google-Smtp-Source: APXvYqyJquuPB6D1uAfqAfMva+gKPdQHN33eOJpwAMBH+uwJy0WVdrXxuDvyypHqawFkJzA8ZfYxEg==
X-Received: by 2002:a62:1b4f:: with SMTP id b76mr198749pfb.163.1582658211607;  Tue, 25 Feb 2020 11:16:51 -0800 (PST)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id e18sm18489110pfm.24.2020.02.25.11.16.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 11:16:50 -0800 (PST)
To: Toerless Eckert , Mark Andrews 
Cc: architecture-discuss@ietf.org
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
From: Brian E Carpenter 
Message-ID: <31bc85a7-7ae5-1f7a-826d-9ea27865c6f3@gmail.com>
Date: Wed, 26 Feb 2020 08:16:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 25 Feb 2020 19:16:55 -0000

Hi Toerless,

> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6,=20

I'm not at all sure we intended to be disruptive. In fact, the word
"coexistence" was there from before the start (I put it there, in
RFC1671) and to a considerable extent the IPv6 design tried to adopt
current best practice and was in fact a very conservative design; some
said it was too conservative.

As you can easily see, my foresight in that RFC was far from perfect
but the emphasis on coexistence and interworking was something that
every operator required from the start. If not, we wouldn't have got very=

far.

Regards
   Brian

On 25-Feb-20 11:27, Toerless Eckert wrote:
> [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
>=20
> Mark:=20
>=20
> Funny to see how yours is the first actual answer to at least how i rea=
d
> Khaleds question. I would summarize what you said with:
>=20
> https://en.wikipedia.org/wiki/IPv6_transition_mechanism
>=20
> (14 standardized plus a lot more. Aka: thank you, but we have enough)
>=20
> Most everybody else jumps to the growth of the IPv6 Internet, which
> to me is just the visible tip of the iceberg of overall IPv4 and IPv6
> deployments. I think the picture changes quite a bit if we look at the
> whole iceberg.=20
>=20
> In private / controlled networks, the choices are not only IPv4 vs.
> IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet =

> switching.
>=20
> For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon
> be software-only overlay virtual networks whereas the actual
> terrabit accelerated hardware forwarding plane of future networks
> maybe something else. 4G/5G "core" "network" already are such
> overlay networks.=20
>=20
> [Rant]
> I am not sure if the question, as constrained as  Khaled is asking
> it will really help us to improve what we should do in the future. But
> neither is the defensive reaction of IPv6 evangelists pointing at the
> growth curve of the IPv6 Internet as the only relevant metric to the
> success and benefits of IPv6.
>=20
> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6, but
> now the predominant religion seems to be being stuck in small
> incremental enhancements of that 25 year old architecture, especially
> because its bible (RFC8200) did only think of the IPv6 Internet use-cas=
e
> requirements, but not those of private/controlled networks.
> [/Rant]
>=20
> Cheer
>     Toerless
>=20
> On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
>> Really we do not need to be inventing anything new in this space.
>> We already have too many mechanisms.  ISPs just need to DEPLOY the
>> existing mechanism.
>>
>> We have plain dual stack.
>>
>> We have public IPv4 + 6rd for ISPs where the access network doesn???t
>> support IPv6.
>>
>> We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn?=
??t
>> support IPv6 and they have run out of IPv4 space.
>>
>> We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when th=
e ISP
>> has run out of IPv4 and the access network supports IPv6.
>>
>> We have CGN + IPv6.
>>
>> Do we really need something more at the protocol level?
>>
>> We do need Governments to ban the selling of new IPv4-only domestic
>> devices (CPE routers, TV???s, game boxes, etc.).
>>
>> Mark
>>
>>> On 20 Feb 2020, at 11:32, Khaled Omar  w=
rote:
>>>
>>> Regardless the different %s, lets take the average one, it can not ma=
ke us optimistic and stop thinking about a better solution, we should lea=
rn from the long time passed without full migration occured, if we will w=
ait till that happens, the division will occur which is not good for the =
internet, lets welcome new ideas and give it the space, time, and opportu=
nity fairly, if it will be good then welcome, if not, trash is made for t=
his.=20
>>>
>>> Get Outlook for Android
>>>
>>> From: ietf  on behalf of JORDI PALET MARTINEZ =

>>> Sent: Thursday, February 20, 2020 2:00:58 AM
>>> To: IETF Rinse Repeat 
>>> Subject: Re: ipv4 and ipv6 Coexistence.
>>> =20
>>> And you're missing several points about how those stats are looked at=
=2E
>>>
>>> The % in the stats shown by google/others is only what they can measu=
re, but they can't measure *all*. There are countries (big ones) that don=
't allow measurements, or at least the same level of details, and however=
, are doing massive IPv6 deployments.
>>>
>>> All the CDNs and caches have IPv6. The customers that have those cach=
es and enable IPv6 for their subscribers, are getting ranges over 65%, so=
metimes even up to 85-90% of IPv6 traffic when mainly the subscribers are=
 householders instead of big enterprises.
>>>
>>> Also, the google (and others) measurements, show average worldwide, b=
ut if you look to many countries they have even surpassed the 50% or so.
>>>
>>> Regards,
>>> Jordi
>>> @jordipalet
>>> =20
>>> =20
>>>
>>> ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar"  escribi=C3=B3:
>>>
>>>     Since long time I was observing this, still almost the same, no c=
lear progress occurred.
>>>    =20
>>>     Thanks,
>>>    =20
>>>     Khaled Omar
>>>    =20
>>>     -----Original Message-----
>>>     From: Scott O. Bradner =20
>>>     Sent: Wednesday, February 19, 2020 8:11 PM
>>>     To: Khaled Omar 
>>>     Cc: IETF Rinse Repeat 
>>>     Subject: Re: ipv4 and ipv6 Coexistence.
>>>    =20
>>>     Quite a few folk are already there - see https://www.google.com/i=
ntl/en/ipv6/statistics.html
>>>    =20
>>>     Scott
>>>    =20
>>>    =20
>>>
>>>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged =
or confidential. The information is intended to be for the exclusive use =
of the individual(s) named above and further non-explicilty authorized di=
sclosure, copying, distribution or use of the contents of this informatio=
n, even if partially, including attached files, is strictly prohibited an=
d will be considered a criminal offense. If you are not the intended reci=
pient be aware that any disclosure, copying, distribution or use of the c=
ontents of this information, even if partially, including attached files,=
 is strictly prohibited, will be considered a criminal offense, so you mu=
st reply to the original sender to inform about this communication and de=
lete it.
>>>
>>>
>>>
>>
>> --=20
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>=20
>=20


From nobody Tue Feb 25 12:24:12 2020
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 B7ACD3A1532 for ; Tue, 25 Feb 2020 12:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y0EmWfCjDQHp for ; Tue, 25 Feb 2020 12:24:09 -0800 (PST)
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 052043A1533 for ; Tue, 25 Feb 2020 12:24:08 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D2424548005; Tue, 25 Feb 2020 21:24:03 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C6B34440040; Tue, 25 Feb 2020 21:24:03 +0100 (CET)
Date: Tue, 25 Feb 2020 21:24:03 +0100
From: Toerless Eckert 
To: Fred Baker 
Cc: Mark Andrews , architecture-discuss@ietf.org
Message-ID: <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 25 Feb 2020 20:24:11 -0000

Thanks, Fred, inline

On Tue, Feb 25, 2020 at 10:16:24AM -0800, Fred Baker wrote:
> On Feb 24, 2020, at 2:27 PM, Toerless Eckert  wrote:
> > 
> > In private / controlled networks, the choices are not only IPv4 vs.
> > IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet
> > switching.
> 
> You make some important points, but...

> We have had several countries discuss pulling off the Internet or doing something pretty disruptive, such as unilaterally changing from DNS to something else or imposing government-controlled firewalls. My point to them - and I have spoken with more than one - is that disrupting Internet communications affects the flow of international commerce, and therefore money, into their countries.

Let me answer this further below.

> The same point applies in this case. If a company wants to internally only use  as a link layer protocol, that's their choice, but if they step very far away from IPv4 and IPv6, it means that they can't do business with their vendors and their customers - they have to in some way translate or overlay at that boundary. What has been beneficial with Internet technologies since they were invented was that one no longer had to think about global deployments of BBN 1822, X.25, Ethernet, or any of a long list of other things; they became carriers for a common architecture enabling global communications.

I think its dismissive to call private or controlled networks
"link layers".  They include global enterprise, service provider, defense,
federal and other federated networks, manufacturing and the like. 

The Internet already is an overlay of sorts and the heavy lifting is
done below it by those private/controlled network re-using IETF TCP/IP
technologies, and a lot more than "The Internet".  Including the likes
of MPLS, SRv6, DiffServ, heck even IntServ or *yikes* IP multicast. And
parts of the IETF are still treating innovation to improve those type of
networks as tangential or subordinated to comply with policies really only
built just with "The Internet" use-case in mind.

Making future IETF technologies better support where the heavy lifting
is done is what i think would serve the IETF well.

[rant]
About your first point: I think that additional entities like
governments "breaking" the Internet is a completely separate point,
from the one i made and argued above.

The vision of the transparent global Internet was a great vision to
me until 1995 when the Internet population exploded and IMHO the 
model started to fail. Since then, the mayority of TCP/IP hosts
connects to the internet through some type of policy filtering,
and the IETF has architecturally not really acknowledged
that reality or the need for it. How are countries policing the
Internet for their constituencies now any different from enterprises
having done the same for decades for their constituencies ? What
else but closing its eyes to the issue did the IETF do in the last 25
years ?

And now its easy to see how a limited number of regulated
"WWW service conglomerates" will happily claim to solve all policy
requirements at their application/gateway level. Because IETF
networking architecture has failed to evolve the "Internet" model to
something a little more based on reality of human society than the
original Internet garden of Eden model that is still canon.
[/rant]

Cheers
    Toerless


From nobody Tue Feb 25 12:46:24 2020
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 106183A157F for ; Tue, 25 Feb 2020 12:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FAR4CFpioQCk for ; Tue, 25 Feb 2020 12:46:13 -0800 (PST)
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 9E9983A15AC for ; Tue, 25 Feb 2020 12:46:13 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 207D4548048; Tue, 25 Feb 2020 21:46:08 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1A483440040; Tue, 25 Feb 2020 21:46:08 +0100 (CET)
Date: Tue, 25 Feb 2020 21:46:08 +0100
From: Toerless Eckert 
To: Guntur Wiseno Putra 
Cc: Khaled Omar , Mark Andrews , "architecture-discuss@ietf.org" 
Message-ID: <20200225204608.GI39574@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 25 Feb 2020 20:46:22 -0000

Guntur:

That URL takes me to an SSO login on internetsociety.org.
Is that correct ? Internetsociety hosts walled garden content ?
I am puzzled.

With the title i found this:
https://www.hstoday.us/subject-matter-areas/cybersecurity/adopting-and-enforcing-an-ipv6-only-policy-if-not-now-when/

Is that what you wanted to point to ?

Cheers
    Toerless

On Tue, Feb 25, 2020 at 02:47:33PM +0700, Guntur Wiseno Putra wrote:
> Dear Toerless and
> architecture-discuss,
> 
> To inform that there is a post on IPv6 yesterday at the Open Forum's
> Discussion of the Internet Society:
> 
> "Adopting and Enforcing an IPv6-Only Policy: If Not Now, When"?
> 
> by Charles Sun
> 
> 
> 
> https://connect.internetsociety.org/communities/community-home/digestviewer/viewthread?MessageKey=f2844839-3d7d-40e2-b7ab-e4b0c1562de8&CommunityKey=3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=digestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8
> 
> 
> 
> Regard,
> Guntur Wiseno Putra
> 
> Pada Selasa, 25 Februari 2020, Toerless Eckert  menulis:
> 
> > [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
> >
> > Mark:
> >
> > Funny to see how yours is the first actual answer to at least how i read
> > Khaleds question. I would summarize what you said with:
> >
> > https://en.wikipedia.org/wiki/IPv6_transition_mechanism
> >
> > (14 standardized plus a lot more. Aka: thank you, but we have enough)
> >
> > Most everybody else jumps to the growth of the IPv6 Internet, which
> > to me is just the visible tip of the iceberg of overall IPv4 and IPv6
> > deployments. I think the picture changes quite a bit if we look at the
> > whole iceberg.
> >
> > In private / controlled networks, the choices are not only IPv4 vs.
> > IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet
> > switching.
> >
> > For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon
> > be software-only overlay virtual networks whereas the actual
> > terrabit accelerated hardware forwarding plane of future networks
> > maybe something else. 4G/5G "core" "network" already are such
> > overlay networks.
> >
> > [Rant]
> > I am not sure if the question, as constrained as  Khaled is asking
> > it will really help us to improve what we should do in the future. But
> > neither is the defensive reaction of IPv6 evangelists pointing at the
> > growth curve of the IPv6 Internet as the only relevant metric to the
> > success and benefits of IPv6.
> >
> > I am primarily concerned that we did manage to recognize we needed
> > disruptive innovartion in the 90th, when we came up with IPv6, but
> > now the predominant religion seems to be being stuck in small
> > incremental enhancements of that 25 year old architecture, especially
> > because its bible (RFC8200) did only think of the IPv6 Internet use-case
> > requirements, but not those of private/controlled networks.
> > [/Rant]
> >
> > Cheer
> >     Toerless
> >
> > On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
> > > Really we do not need to be inventing anything new in this space.
> > > We already have too many mechanisms.  ISPs just need to DEPLOY the
> > > existing mechanism.
> > >
> > > We have plain dual stack.
> > >
> > > We have public IPv4 + 6rd for ISPs where the access network doesn???t
> > > support IPv6.
> > >
> > > We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn???t
> > > support IPv6 and they have run out of IPv4 space.
> > >
> > > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when the
> > ISP
> > > has run out of IPv4 and the access network supports IPv6.
> > >
> > > We have CGN + IPv6.
> > >
> > > Do we really need something more at the protocol level?
> > >
> > > We do need Governments to ban the selling of new IPv4-only domestic
> > > devices (CPE routers, TV???s, game boxes, etc.).
> > >
> > > Mark
> > >
> > > > On 20 Feb 2020, at 11:32, Khaled Omar 
> > wrote:
> > > >
> > > > Regardless the different %s, lets take the average one, it can not
> > make us optimistic and stop thinking about a better solution, we should
> > learn from the long time passed without full migration occured, if we will
> > wait till that happens, the division will occur which is not good for the
> > internet, lets welcome new ideas and give it the space, time, and
> > opportunity fairly, if it will be good then welcome, if not, trash is made
> > for this.
> > > >
> > > > Get Outlook for Android
> > > >
> > > > From: ietf  on behalf of JORDI PALET MARTINEZ
> > 
> > > > Sent: Thursday, February 20, 2020 2:00:58 AM
> > > > To: IETF Rinse Repeat 
> > > > Subject: Re: ipv4 and ipv6 Coexistence.
> > > >
> > > > And you're missing several points about how those stats are looked at..
> > > >
> > > > The % in the stats shown by google/others is only what they can
> > measure, but they can't measure *all*. There are countries (big ones) that
> > don't allow measurements, or at least the same level of details, and
> > however, are doing massive IPv6 deployments.
> > > >
> > > > All the CDNs and caches have IPv6. The customers that have those
> > caches and enable IPv6 for their subscribers, are getting ranges over 65%,
> > sometimes even up to 85-90% of IPv6 traffic when mainly the subscribers are
> > householders instead of big enterprises.
> > > >
> > > > Also, the google (and others) measurements, show average worldwide,
> > but if you look to many countries they have even surpassed the 50% or so.
> > > >
> > > > Regards,
> > > > Jordi
> > > > @jordipalet
> > > >
> > > >
> > > >
> > > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <
> > ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com> escribi:
> > > >
> > > >     Since long time I was observing this, still almost the same, no
> > clear progress occurred.
> > > >
> > > >     Thanks,
> > > >
> > > >     Khaled Omar
> > > >
> > > >     -----Original Message-----
> > > >     From: Scott O. Bradner 
> > > >     Sent: Wednesday, February 19, 2020 8:11 PM
> > > >     To: Khaled Omar 
> > > >     Cc: IETF Rinse Repeat 
> > > >     Subject: Re: ipv4 and ipv6 Coexistence.
> > > >
> > > >     Quite a few folk are already there - see
> > https://www.google.com/intl/en/ipv6/statistics.html
> > > >
> > > >     Scott
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > **********************************************
> > > > IPv4 is over
> > > > Are you ready for the new Internet ?
> > > > http://www.theipv6company.com
> > > > The IPv6 Company
> > > >
> > > > This electronic message contains information which may be privileged
> > or confidential. The information is intended to be for the exclusive use of
> > the individual(s) named above and further non-explicilty authorized
> > disclosure, copying, distribution or use of the contents of this
> > information, even if partially, including attached files, is strictly
> > prohibited and will be considered a criminal offense. If you are not the
> > intended recipient be aware that any disclosure, copying, distribution or
> > use of the contents of this information, even if partially, including
> > attached files, is strictly prohibited, will be considered a criminal
> > offense, so you must reply to the original sender to inform about this
> > communication and delete it.
> > > >
> > > >
> > > >
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >

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


-- 
---
tte@cs.fau.de


From nobody Tue Feb 25 18:03:22 2020
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 8C50F3A08E3 for ; Tue, 25 Feb 2020 18:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mdesuqb87y18 for ; Tue, 25 Feb 2020 18:03:18 -0800 (PST)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 CDC913A08E0 for ; Tue, 25 Feb 2020 18:03:17 -0800 (PST)
Received: by mail-ot1-x342.google.com with SMTP id h9so1474278otj.11 for ; Tue, 25 Feb 2020 18:03:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sUYLVKy4NOpIqonQulroXezkrCriUTvSdgKcxuD+tN0=; b=WF5xNeovPPyVhtb6HS698ikgqJ8Y7vzkDEeKc60yaAkQ+95b3qGYdEH9t44Y+1+O3D BFelRb5qug68+p2bZjjLNZRcD+hLF33sWXqxI2NUA4XkLCUp/W846xRWQCiXEP4XUxPm HazayQ17t0fZrGImd32EZ0T6CZLfTBf+Iqvg7isEjOTcCUr0nMkk320WR2yqZpQPYaEE P3IxkSffPSDV+3JUEGuVRQJ0dH2iOmUa2DcNJBzUjWV6PpFgBfePU+Y2Y82CgClR3R2b PIgsGprzNF0NaOqYluTofFZImfpOPJrG7MJo4IdgBvm5lSPOLUXFe02Am6PN4QxASIxA I8og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sUYLVKy4NOpIqonQulroXezkrCriUTvSdgKcxuD+tN0=; b=IrjZGlEai+7bHKDOBQwprvok+GPZk9S2KvBWvbZvZLgEEbim1eS4Pg0NhpiCfDfHQJ 4erEvNq+hlaT6mG0zhfRl6YD+wr5BT870tRXYJjN7Eon2jGgHDRPB0JCyxSApnn/kWDN Ocpgl438AiXmKP3WNTwQ+k8TrudK3tj4Zck2nNyNLGlIfIYuKtNTZh5wtbmlw5yOpxVQ 2uJ3kKrqMej1iuBrYu6rXscBvYI4PdHS74pReapLMZhz7NQzR3iecoCATxon7fpl7wVZ e9ovdBJzxZ0ZYvo9Q8LXkvdFNHslCfYSdV59gbAt/j7QGezhpCjyQWaGmzGocsL4+7dL dr0w==
X-Gm-Message-State: APjAAAVsGBMh/bq/B4JkbRydUrcZpX33/MWuaJ71c1LJPn5LmG3fouqF odwE4sNEz1RTdERq8bJCL8oehXRsBdm3L9v3jAM=
X-Google-Smtp-Source: APXvYqw1A0+09rP87qnUa7mtc0dTrVWck+q/05tjB5rge/XTv5RlvxAzdVdE2sIHsiA3LAlBLnhI5nC4kMeZqVzwkG8=
X-Received: by 2002:a9d:65da:: with SMTP id z26mr1215844oth.197.1582682596825;  Tue, 25 Feb 2020 18:03:16 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Tue, 25 Feb 2020 18:03:16 -0800 (PST)
In-Reply-To: <20200225204608.GI39574@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>  <20200225204608.GI39574@faui48f.informatik.uni-erlangen.de>
From: Guntur Wiseno Putra 
Date: Wed, 26 Feb 2020 09:03:16 +0700
Message-ID: 
To: Toerless Eckert 
Cc: Khaled Omar , Mark Andrews ,  "architecture-discuss@ietf.org" , forcharles@gmail.com
Content-Type: multipart/alternative; boundary="000000000000f9ddf8059f710107"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 02:03:21 -0000

--000000000000f9ddf8059f710107
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless,
architecture-discuss &
Mr. Charles Sun,


I wish Mr. Charles Sun does not mind if I share his post (originally sent
to the Open Forum's discussion of the Internet Society) to
architecture-discuss:


Adopting and Enforcing an IPv6-Only Policy: If Not Now, When?
Follow

   - 1.
   0 Recommend
   Charles Sun
   
   Posted 2 days ago
   ReplyOptions Dropdown

   Adopting and enforcing the IPv6-only policy worldwide by securely
   deploying the single stack of IPv6, turning off IPv4, and setting a
   specific deadline to sunset IPv4 completely will dramatically reduce the
   overall cybersecurity threats and attacks based on IPv4.

   It is not a question as to whether or not we should adopt and enforce an
   IPv6-only policy by turning off and sunsetting IPv4, but rather a questi=
on
   that we all must ask: If not now, when?!

   Here is the link to the full text of my latest opinion article:
   https://tinyurl.com/yxx386fd


* #**cybersecurity*
   
    #IPv6Only
   
    #IPv6
   

   *Disclaimer: The views presented are only personal opinions and they do
   not necessarily represent those of the U.S. Government.*
   =E2=80=8B=E2=80=8B=E2=80=8B

   ------------------------------
   ForCharles@gmail.com
   IPv6 Expert, Speaker, Columnist, Board Member, IT Executive.

   Note: replies will be sent to the full discussion group.
   ------------------------------




Regard,
Guntur Wiseno Putra

Pada Rabu, 26 Februari 2020, Toerless Eckert  menulis:

> Guntur:
>
> That URL takes me to an SSO login on internetsociety.org.
> Is that correct ? Internetsociety hosts walled garden content ?
> I am puzzled.
>
> With the title i found this:
> https://www.hstoday.us/subject-matter-areas/cybersecurity/adopting-and-
> enforcing-an-ipv6-only-policy-if-not-now-when/
>
> Is that what you wanted to point to ?
>
> Cheers
>     Toerless
>
> On Tue, Feb 25, 2020 at 02:47:33PM +0700, Guntur Wiseno Putra wrote:
> > Dear Toerless and
> > architecture-discuss,
> >
> > To inform that there is a post on IPv6 yesterday at the Open Forum's
> > Discussion of the Internet Society:
> >
> > "Adopting and Enforcing an IPv6-Only Policy: If Not Now, When"?
> >
> > by Charles Sun
> >
> >
> >
> > https://connect.internetsociety.org/communities/community-home/
> digestviewer/viewthread?MessageKey=3Df2844839-3d7d-40e2-b7ab-e4b0c1562de8=
&
> CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3D
> digestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8
> >
> >
> >
> > Regard,
> > Guntur Wiseno Putra
> >
> > Pada Selasa, 25 Februari 2020, Toerless Eckert  menulis:
> >
> > > [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
> > >
> > > Mark:
> > >
> > > Funny to see how yours is the first actual answer to at least how i
> read
> > > Khaleds question. I would summarize what you said with:
> > >
> > > https://en.wikipedia.org/wiki/IPv6_transition_mechanism
> > >
> > > (14 standardized plus a lot more. Aka: thank you, but we have enough)
> > >
> > > Most everybody else jumps to the growth of the IPv6 Internet, which
> > > to me is just the visible tip of the iceberg of overall IPv4 and IPv6
> > > deployments. I think the picture changes quite a bit if we look at th=
e
> > > whole iceberg.
> > >
> > > In private / controlled networks, the choices are not only IPv4 vs.
> > > IPv6 or their interop, but also (SR-)MPLS and even more so L2 etherne=
t
> > > switching.
> > >
> > > For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soo=
n
> > > be software-only overlay virtual networks whereas the actual
> > > terrabit accelerated hardware forwarding plane of future networks
> > > maybe something else. 4G/5G "core" "network" already are such
> > > overlay networks.
> > >
> > > [Rant]
> > > I am not sure if the question, as constrained as  Khaled is asking
> > > it will really help us to improve what we should do in the future. Bu=
t
> > > neither is the defensive reaction of IPv6 evangelists pointing at the
> > > growth curve of the IPv6 Internet as the only relevant metric to the
> > > success and benefits of IPv6.
> > >
> > > I am primarily concerned that we did manage to recognize we needed
> > > disruptive innovartion in the 90th, when we came up with IPv6, but
> > > now the predominant religion seems to be being stuck in small
> > > incremental enhancements of that 25 year old architecture, especially
> > > because its bible (RFC8200) did only think of the IPv6 Internet
> use-case
> > > requirements, but not those of private/controlled networks.
> > > [/Rant]
> > >
> > > Cheer
> > >     Toerless
> > >
> > > On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
> > > > Really we do not need to be inventing anything new in this space.
> > > > We already have too many mechanisms.  ISPs just need to DEPLOY the
> > > > existing mechanism.
> > > >
> > > > We have plain dual stack.
> > > >
> > > > We have public IPv4 + 6rd for ISPs where the access network doesn??=
?t
> > > > support IPv6.
> > > >
> > > > We have CGN + 6RD + 100.64/10 for ISPs where the access network
> doesn???t
> > > > support IPv6 and they have run out of IPv4 space.
> > > >
> > > > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when
> the
> > > ISP
> > > > has run out of IPv4 and the access network supports IPv6.
> > > >
> > > > We have CGN + IPv6.
> > > >
> > > > Do we really need something more at the protocol level?
> > > >
> > > > We do need Governments to ban the selling of new IPv4-only domestic
> > > > devices (CPE routers, TV???s, game boxes, etc.).
> > > >
> > > > Mark
> > > >
> > > > > On 20 Feb 2020, at 11:32, Khaled Omar  >
> > > wrote:
> > > > >
> > > > > Regardless the different %s, lets take the average one, it can no=
t
> > > make us optimistic and stop thinking about a better solution, we shou=
ld
> > > learn from the long time passed without full migration occured, if we
> will
> > > wait till that happens, the division will occur which is not good for
> the
> > > internet, lets welcome new ideas and give it the space, time, and
> > > opportunity fairly, if it will be good then welcome, if not, trash is
> made
> > > for this.
> > > > >
> > > > > Get Outlook for Android
> > > > >
> > > > > From: ietf  on behalf of JORDI PALET
> MARTINEZ
> > > 
> > > > > Sent: Thursday, February 20, 2020 2:00:58 AM
> > > > > To: IETF Rinse Repeat 
> > > > > Subject: Re: ipv4 and ipv6 Coexistence.
> > > > >
> > > > > And you're missing several points about how those stats are looke=
d
> at..
> > > > >
> > > > > The % in the stats shown by google/others is only what they can
> > > measure, but they can't measure *all*. There are countries (big ones)
> that
> > > don't allow measurements, or at least the same level of details, and
> > > however, are doing massive IPv6 deployments.
> > > > >
> > > > > All the CDNs and caches have IPv6. The customers that have those
> > > caches and enable IPv6 for their subscribers, are getting ranges over
> 65%,
> > > sometimes even up to 85-90% of IPv6 traffic when mainly the
> subscribers are
> > > householders instead of big enterprises.
> > > > >
> > > > > Also, the google (and others) measurements, show average worldwid=
e,
> > > but if you look to many countries they have even surpassed the 50% or
> so.
> > > > >
> > > > > Regards,
> > > > > Jordi
> > > > > @jordipalet
> > > > >
> > > > >
> > > > >
> > > > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <
> > > ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com>
> escribi=C3=B3:
> > > > >
> > > > >     Since long time I was observing this, still almost the same, =
no
> > > clear progress occurred.
> > > > >
> > > > >     Thanks,
> > > > >
> > > > >     Khaled Omar
> > > > >
> > > > >     -----Original Message-----
> > > > >     From: Scott O. Bradner 
> > > > >     Sent: Wednesday, February 19, 2020 8:11 PM
> > > > >     To: Khaled Omar 
> > > > >     Cc: IETF Rinse Repeat 
> > > > >     Subject: Re: ipv4 and ipv6 Coexistence.
> > > > >
> > > > >     Quite a few folk are already there - see
> > > https://www.google.com/intl/en/ipv6/statistics.html
> > > > >
> > > > >     Scott
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > **********************************************
> > > > > IPv4 is over
> > > > > Are you ready for the new Internet ?
> > > > > http://www.theipv6company.com
> > > > > The IPv6 Company
> > > > >
> > > > > This electronic message contains information which may be
> privileged
> > > or confidential. The information is intended to be for the exclusive
> use of
> > > the individual(s) named above and further non-explicilty authorized
> > > disclosure, copying, distribution or use of the contents of this
> > > information, even if partially, including attached files, is strictly
> > > prohibited and will be considered a criminal offense. If you are not
> the
> > > intended recipient be aware that any disclosure, copying, distributio=
n
> or
> > > use of the contents of this information, even if partially, including
> > > attached files, is strictly prohibited, will be considered a criminal
> > > offense, so you must reply to the original sender to inform about thi=
s
> > > communication and delete it.
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> > >
> > > _______________________________________________
> > > Architecture-discuss mailing list
> > > Architecture-discuss@ietf.org
> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > >
>
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> --
> ---
> tte@cs.fau.de
>

--000000000000f9ddf8059f710107
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless,=C2=A0
architecture-discuss &
Mr. Charles Sun=
,=C2=A0


I wish Mr. Charles Sun does not m=
ind if I share his post (originally sent to the Open Forum's discussion=
 of the Internet Society) to architecture-discuss:


<=
/div>
Adopting and Enforcing an IPv6-Only Policy: If Not =
Now, When?
Follow=C2=A0
  • 1.=C2=A0
    =
Posted 2 days ago
    ReplyOptions Dropdown
    =
Adopting and enforcing the IPv6-only policy worldwide by securely deploying=
 the single stack of IPv6, turning off IPv4, and setting a specific deadlin=
e to sunset IPv4 completely will dramatically reduce the overall cybersecur=
ity threats and attacks based on IPv4.
    It is not a question as to whether or not we should a=
dopt and enforce an IPv6-only policy by turning off and sunsetting IPv4, bu=
t rather a question that we all must ask: If not now, when?!
    Here is the link to the full te=
xt of my latest=C2=A0opinion article:=C2=A0https://tinyurl.com/yxx386fd<=
/a>=C2=A0

    #    cybersecurity    =C2=A0#IPv6Only=C2=A0#IPv6

    Disclaimer:=
 The views presented are only personal opinions and they do not necessarily=
 represent those of the U.S. Government.
    =E2=80=8B=E2=80=
=8B=E2=80=8B

    ------------------------------
    =
ForCharles@gmail.com
    IPv6 Expert, Speaker, Columnist, Board Member, I=
T Executive.

    Note: replies will be sent to the full discussion group.
    ------------------------------



Regard,
Guntur Wiseno Putra

Pada Rabu, 26 =
Februari 2020, Toerless Eckert <tte@cs.=
fau.de> menulis:
Guntur:



That URL takes me to an SSO login on internetsociety.org.

Is that correct ? Internetsociety hosts walled garden content ?

I am puzzled.



With the title i found this:

ht=
tps://www.hstoday.us/subject-matter-areas/cybersecurity/adopting-=
and-enforcing-an-ipv6-only-policy-if-not-now-when/



Is that what you wanted to point to ?



Cheers

=C2=A0 =C2=A0 Toerless



On Tue, Feb 25, 2020 at 02:47:33PM +0700, Guntur Wiseno Putra wrote:

> Dear Toerless and

> architecture-discuss,

> 

> To inform that there is a post on IPv6 yesterday at the Open Forum'=
;s

> Discussion of the Internet Society:

> 

> "Adopting and Enforcing an IPv6-Only Policy: If Not Now, When&quo=
t;?

> 

> by Charles Sun

> 

> 

> 

> https://co=
nnect.internetsociety.org/communities/community-home/digestv=
iewer/viewthread?MessageKey=3Df2844839-3d7d-40e2-b7ab-e4b0c1562de=
8&CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=
=3Ddigestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8

> 

> 

> 

> Regard,

> Guntur Wiseno Putra

> 

> Pada Selasa, 25 Februari 2020, Toerless Eckert <tte@cs.fau.de> menulis:

> 

> > [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org<=
/a>]

> >

> > Mark:

> >

> > Funny to see how yours is the first actual answer to at least how=
 i read

> > Khaleds question. I would summarize what you said with:

> >

> > https://en.wikipedia.org/wiki/IPv6_transition_mec=
hanism

> >

> > (14 standardized plus a lot more. Aka: thank you, but we have eno=
ugh)

> >

> > Most everybody else jumps to the growth of the IPv6 Internet, whi=
ch

> > to me is just the visible tip of the iceberg of overall IPv4 and =
IPv6

> > deployments. I think the picture changes quite a bit if we look a=
t the

> > whole iceberg.

> >

> > In private / controlled networks, the choices are not only IPv4 v=
s.

> > IPv6 or their interop, but also (SR-)MPLS and even more so L2 eth=
ernet

> > switching.

> >

> > For all intent and purpose, Internet IPv6 vs. Internet IPv4 could=
 soon

> > be software-only overlay virtual networks whereas the actual

> > terrabit accelerated hardware forwarding plane of future networks=


> > maybe something else. 4G/5G "core" "network" =
already are such

> > overlay networks.

> >

> > [Rant]

> > I am not sure if the question, as constrained as=C2=A0 Khaled is =
asking

> > it will really help us to improve what we should do in the future=
. But

> > neither is the defensive reaction of IPv6 evangelists pointing at=
 the

> > growth curve of the IPv6 Internet as the only relevant metric to =
the

> > success and benefits of IPv6.

> >

> > I am primarily concerned that we did manage to recognize we neede=
d

> > disruptive innovartion in the 90th, when we came up with IPv6, bu=
t

> > now the predominant religion seems to be being stuck in small

> > incremental enhancements of that 25 year old architecture, especi=
ally

> > because its bible (RFC8200) did only think of the IPv6 Internet u=
se-case

> > requirements, but not those of private/controlled networks.

> > [/Rant]

> >

> > Cheer

> >=C2=A0 =C2=A0 =C2=A0Toerless

> >

> > On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:

> > > Really we do not need to be inventing anything new in this s=
pace.

> > > We already have too many mechanisms.=C2=A0 ISPs just need to=
 DEPLOY the

> > > existing mechanism.

> > >

> > > We have plain dual stack.

> > >

> > > We have public IPv4 + 6rd for ISPs where the access network =
doesn???t

> > > support IPv6.

> > >

> > > We have CGN + 6RD + 100.64/10 for ISPs where the access netw=
ork doesn???t

> > > support IPv6 and they have run out of IPv4 space.

> > >

> > > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS f=
or when the

> > ISP

> > > has run out of IPv4 and the access network supports IPv6.
> > >

> > > We have CGN + IPv6.

> > >

> > > Do we really need something more at the protocol level?

> > >

> > > We do need Governments to ban the selling of new IPv4-only d=
omestic

> > > devices (CPE routers, TV???s, game boxes, etc.).

> > >

> > > Mark

> > >

> > > > On 20 Feb 2020, at 11:32, Khaled Omar <eng.khaled.omar@outlook.com>

> > wrote:

> > > >

> > > > Regardless the different %s, lets take the average one,=
 it can not

> > make us optimistic and stop thinking about a better solution, we =
should

> > learn from the long time passed without full migration occured, i=
f we will

> > wait till that happens, the division will occur which is not good=
 for the

> > internet, lets welcome new ideas and give it the space, time, and=


> > opportunity fairly, if it will be good then welcome, if not, tras=
h is made

> > for this.

> > > >

> > > > Get Outlook for Android

> > > >

> > > > From: ietf <ietf-bounces@ietf.org> on behalf of JORDI PALET MARTINEZ

> > <jordi.palet=3D40consulintel.es@dmarc.ietf.org>

> > > > Sent: Thursday, February 20, 2020 2:00:58 AM

> > > > To: IETF Rinse Repeat <ietf@ietf.org>

> > > > Subject: Re: ipv4 and ipv6 Coexistence.

> > > >

> > > > And you're missing several points about how those s=
tats are looked at..

> > > >

> > > > The % in the stats shown by google/others is only what =
they can

> > measure, but they can't measure *all*. There are countries (b=
ig ones) that

> > don't allow measurements, or at least the same level of detai=
ls, and

> > however, are doing massive IPv6 deployments.

> > > >

> > > > All the CDNs and caches have IPv6. The customers that h=
ave those

> > caches and enable IPv6 for their subscribers, are getting ranges =
over 65%,

> > sometimes even up to 85-90% of IPv6 traffic when mainly the subsc=
ribers are

> > householders instead of big enterprises.

> > > >

> > > > Also, the google (and others) measurements, show averag=
e worldwide,

> > but if you look to many countries they have even surpassed the 50=
% or so.

> > > >

> > > > Regards,

> > > > Jordi

> > > > @jordipalet

> > > >

> > > >

> > > >

> > > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar=
" <

> > ietf-bounces@ietf.org en nombre de eng.khaled.om=
ar@outlook.com> escribi=C3=B3:

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Since long time I was observing this=
, still almost the same, no

> > clear progress occurred.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Thanks,

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Khaled Omar

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0-----Original Message-----

> > > >=C2=A0 =C2=A0 =C2=A0From: Scott O. Bradner <sob@sobco.com>

> > > >=C2=A0 =C2=A0 =C2=A0Sent: Wednesday, February 19, 2020 8=
:11 PM

> > > >=C2=A0 =C2=A0 =C2=A0To: Khaled Omar <eng.khaled.omar@outlook.com>

> > > >=C2=A0 =C2=A0 =C2=A0Cc: IETF Rinse Repeat <ietf@ietf.org>

> > > >=C2=A0 =C2=A0 =C2=A0Subject: Re: ipv4 and ipv6 Coexisten=
ce.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Quite a few folk are already there -=
 see

> > https://www.google.com/intl/en/ipv6/statistics.html

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Scott

> > > >

> > > >

> > > >

> > > >

> > > >

> > > > **********************************************

> > > > IPv4 is over

> > > > Are you ready for the new Internet ?

> > > > http://www.theipv6company.com

> > > > The IPv6 Company

> > > >

> > > > This electronic message contains information which may =
be privileged

> > or confidential. The information is intended to be for the exclus=
ive use of

> > the individual(s) named above and further non-explicilty authoriz=
ed

> > disclosure, copying, distribution or use of the contents of this<=
br>
> > information, even if partially, including attached files, is stri=
ctly

> > prohibited and will be considered a criminal offense. If you are =
not the

> > intended recipient be aware that any disclosure, copying, distrib=
ution or

> > use of the contents of this information, even if partially, inclu=
ding

> > attached files, is strictly prohibited, will be considered a crim=
inal

> > offense, so you must reply to the original sender to inform about=
 this

> > communication and delete it.

> > > >

> > > >

> > > >

> > >

> > > --

> > > Mark Andrews, ISC

> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia

> > > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 INTERNET: marka@isc.org

> >

> > _______________________________________________

> > Architecture-discuss mailing list

> > Architecture-dis=
cuss@ietf.org

> > https://www.ietf.org/mailman/listinfo/architec=
ture-discuss

> >



> _______________________________________________

> Architecture-discuss mailing list

> Architecture-discuss@=
ietf.org

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss





-- 

---

tte@cs.fau.de




--000000000000f9ddf8059f710107--


From nobody Tue Feb 25 18:14:32 2020
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 797953A094C for ; Tue, 25 Feb 2020 18:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LL8C0-9CVvu5 for ; Tue, 25 Feb 2020 18:14:26 -0800 (PST)
Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 D9B6D3A090F for ; Tue, 25 Feb 2020 18:14:25 -0800 (PST)
Received: by mail-oi1-x241.google.com with SMTP id a142so1459900oii.7 for ; Tue, 25 Feb 2020 18:14:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wQci0wsJtS/tE86jLrcJ2LUhLASywu4Hb02C6YZZ8Y0=; b=JWBS2jV3tnfXalTt7gTPXktmccnyg9/Le2KWo45mPVBMPgd5DpOq80Tyj9NRsVSRgz Q1piJsjhnNOeCQ4/TKqQJn1UfH0NJcaIc1FyiEFhbervIZnfweps7B60iUTO6ijb7NL0 y+hd6jWNsVMA/LUx1DJyl+9uSVPqeAXMe6eGeFuAXVM0qEqI4XQ0KYoRD/PbxZN/iM0/ 4bv/viEcxZ7vBk7HpFOkyiWY01hDQ9BQYKL2k4pbMWxw2Elxfv2j6mCaI4/4Qybi3pcI A3wqhk/VQeUZJL5K1fbRwI09wxYWKv48wN+gc1tSk+MmloJN82jQNneNNDXUmrCTTux5 aXhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wQci0wsJtS/tE86jLrcJ2LUhLASywu4Hb02C6YZZ8Y0=; b=QIRozUMx1gBh2DPWk3AejB18ittQjpNKBb+n78Yz9zoy3VxEQuoBLp+NniaK/6WFNS cCjBCqyePgQh9z80etnSUmDmo7NBedj9FGkZA0lFIazQ3SUJVlBQEybV00Suftqk+eoi iQ/yhrj++NW6P6DO/p/a+jvV1OqTDpxer+q+AXSYGaICb3yuyRoE40898iOOVpImKUZ0 KVnBKY+BBSZxwtHM90W30qsLuLl83eJguO2pVbti7qK2oMEnD28hQBSN5m18U/BwGwQX XrVP0KuF15b8nz3XqX/XbvIY0GuhOBFNQsHfNa2iaJOJd/W2tvwsH3PgSMGD+71BLJzq 7bbw==
X-Gm-Message-State: APjAAAWt1gvwyylUpF9vKXyoUc3JBD99TbXLnUfgnBhFYGaIloakiCQe MSPaBuRIYE+FC12NHpuOAQRQ/m4D15hOhR7XEmLtPw==
X-Google-Smtp-Source: APXvYqyoHl8KtKHEiz6c56gUTpxt8MFnba2vSOQ1iwSOWWJz7GtRgv0BLZhyajIRnukT/UD5K96uSa1zXiS/ArUkAtY=
X-Received: by 2002:aca:f587:: with SMTP id t129mr1323619oih.143.1582683265077;  Tue, 25 Feb 2020 18:14:25 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Tue, 25 Feb 2020 18:14:24 -0800 (PST)
In-Reply-To: 
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>  <20200225204608.GI39574@faui48f.informatik.uni-erlangen.de> 
From: Guntur Wiseno Putra 
Date: Wed, 26 Feb 2020 09:14:24 +0700
Message-ID: 
To: Toerless Eckert 
Cc: Khaled Omar , Mark Andrews ,  "architecture-discuss@ietf.org" ,  "forcharles@gmail.com" 
Content-Type: multipart/alternative; boundary="000000000000ce9798059f712929"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 02:14:30 -0000

--000000000000ce9798059f712929
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless &
architecture-discuss,

I finded a 2011 article in the IETF Journal with the same title plus:

"IPv4, IPv6 Coexistence Challenges Network Operators" (Carolyn Duffy
Marsan, March 6th 2016)


https://www.ietfjournal.org/ipv4-ipv6-coexistence-challenges-network-operat=
ors/

Regard,
Guntur Wiseno Putra

Pada Rabu, 26 Februari 2020, Guntur Wiseno Putra 
menulis:

> Dear Toerless,
> architecture-discuss &
> Mr. Charles Sun,
>
>
> I wish Mr. Charles Sun does not mind if I share his post (originally sent
> to the Open Forum's discussion of the Internet Society) to
> architecture-discuss:
>
>
> Adopting and Enforcing an IPv6-Only Policy: If Not Now, When?
> Follow
>
>    - 1.
>    0 Recommend
>    Charles Sun
>    
>    Posted 2 days ago
>    ReplyOptions Dropdown
>
>    Adopting and enforcing the IPv6-only policy worldwide by securely
>    deploying the single stack of IPv6, turning off IPv4, and setting a
>    specific deadline to sunset IPv4 completely will dramatically reduce t=
he
>    overall cybersecurity threats and attacks based on IPv4.
>
>    It is not a question as to whether or not we should adopt and enforce
>    an IPv6-only policy by turning off and sunsetting IPv4, but rather a
>    question that we all must ask: If not now, when?!
>
>    Here is the link to the full text of my latest opinion article:
>    https://tinyurl.com/yxx386fd 
>
>
> * #**cybersecurity*
>    
>     #IPv6Only
>    
>     #IPv6
>    
>
>    *Disclaimer: The views presented are only personal opinions and they
>    do not necessarily represent those of the U.S. Government.*
>    =E2=80=8B=E2=80=8B=E2=80=8B
>
>    ------------------------------
>    ForCharles@gmail.com
>    IPv6 Expert, Speaker, Columnist, Board Member, IT Executive.
>
>    Note: replies will be sent to the full discussion group.
>    ------------------------------
>
>
>
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Rabu, 26 Februari 2020, Toerless Eckert  menulis:
>
>> Guntur:
>>
>> That URL takes me to an SSO login on internetsociety.org.
>> Is that correct ? Internetsociety hosts walled garden content ?
>> I am puzzled.
>>
>> With the title i found this:
>> https://www.hstoday.us/subject-matter-areas/cybersecurity/ad
>> opting-and-enforcing-an-ipv6-only-policy-if-not-now-when/
>>
>> Is that what you wanted to point to ?
>>
>> Cheers
>>     Toerless
>>
>> On Tue, Feb 25, 2020 at 02:47:33PM +0700, Guntur Wiseno Putra wrote:
>> > Dear Toerless and
>> > architecture-discuss,
>> >
>> > To inform that there is a post on IPv6 yesterday at the Open Forum's
>> > Discussion of the Internet Society:
>> >
>> > "Adopting and Enforcing an IPv6-Only Policy: If Not Now, When"?
>> >
>> > by Charles Sun
>> >
>> >
>> >
>> > https://connect.internetsociety.org/communities/community-ho
>> me/digestviewer/viewthread?MessageKey=3Df2844839-3d7d-40e2-b7a
>> b-e4b0c1562de8&CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe
>> 56dd&tab=3Ddigestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8
>> >
>> >
>> >
>> > Regard,
>> > Guntur Wiseno Putra
>> >
>> > Pada Selasa, 25 Februari 2020, Toerless Eckert  menulis=
:
>> >
>> > > [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
>> > >
>> > > Mark:
>> > >
>> > > Funny to see how yours is the first actual answer to at least how i
>> read
>> > > Khaleds question. I would summarize what you said with:
>> > >
>> > > https://en.wikipedia.org/wiki/IPv6_transition_mechanism
>> > >
>> > > (14 standardized plus a lot more. Aka: thank you, but we have enough=
)
>> > >
>> > > Most everybody else jumps to the growth of the IPv6 Internet, which
>> > > to me is just the visible tip of the iceberg of overall IPv4 and IPv=
6
>> > > deployments. I think the picture changes quite a bit if we look at t=
he
>> > > whole iceberg.
>> > >
>> > > In private / controlled networks, the choices are not only IPv4 vs.
>> > > IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethern=
et
>> > > switching.
>> > >
>> > > For all intent and purpose, Internet IPv6 vs. Internet IPv4 could so=
on
>> > > be software-only overlay virtual networks whereas the actual
>> > > terrabit accelerated hardware forwarding plane of future networks
>> > > maybe something else. 4G/5G "core" "network" already are such
>> > > overlay networks.
>> > >
>> > > [Rant]
>> > > I am not sure if the question, as constrained as  Khaled is asking
>> > > it will really help us to improve what we should do in the future. B=
ut
>> > > neither is the defensive reaction of IPv6 evangelists pointing at th=
e
>> > > growth curve of the IPv6 Internet as the only relevant metric to the
>> > > success and benefits of IPv6.
>> > >
>> > > I am primarily concerned that we did manage to recognize we needed
>> > > disruptive innovartion in the 90th, when we came up with IPv6, but
>> > > now the predominant religion seems to be being stuck in small
>> > > incremental enhancements of that 25 year old architecture, especiall=
y
>> > > because its bible (RFC8200) did only think of the IPv6 Internet
>> use-case
>> > > requirements, but not those of private/controlled networks.
>> > > [/Rant]
>> > >
>> > > Cheer
>> > >     Toerless
>> > >
>> > > On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
>> > > > Really we do not need to be inventing anything new in this space.
>> > > > We already have too many mechanisms.  ISPs just need to DEPLOY the
>> > > > existing mechanism.
>> > > >
>> > > > We have plain dual stack.
>> > > >
>> > > > We have public IPv4 + 6rd for ISPs where the access network
>> doesn???t
>> > > > support IPv6.
>> > > >
>> > > > We have CGN + 6RD + 100.64/10 for ISPs where the access network
>> doesn???t
>> > > > support IPv6 and they have run out of IPv4 space.
>> > > >
>> > > > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for whe=
n
>> the
>> > > ISP
>> > > > has run out of IPv4 and the access network supports IPv6.
>> > > >
>> > > > We have CGN + IPv6.
>> > > >
>> > > > Do we really need something more at the protocol level?
>> > > >
>> > > > We do need Governments to ban the selling of new IPv4-only domesti=
c
>> > > > devices (CPE routers, TV???s, game boxes, etc.).
>> > > >
>> > > > Mark
>> > > >
>> > > > > On 20 Feb 2020, at 11:32, Khaled Omar <
>> eng.khaled.omar@outlook.com>
>> > > wrote:
>> > > > >
>> > > > > Regardless the different %s, lets take the average one, it can n=
ot
>> > > make us optimistic and stop thinking about a better solution, we
>> should
>> > > learn from the long time passed without full migration occured, if w=
e
>> will
>> > > wait till that happens, the division will occur which is not good fo=
r
>> the
>> > > internet, lets welcome new ideas and give it the space, time, and
>> > > opportunity fairly, if it will be good then welcome, if not, trash i=
s
>> made
>> > > for this.
>> > > > >
>> > > > > Get Outlook for Android
>> > > > >
>> > > > > From: ietf  on behalf of JORDI PALET
>> MARTINEZ
>> > > 
>> > > > > Sent: Thursday, February 20, 2020 2:00:58 AM
>> > > > > To: IETF Rinse Repeat 
>> > > > > Subject: Re: ipv4 and ipv6 Coexistence.
>> > > > >
>> > > > > And you're missing several points about how those stats are
>> looked at..
>> > > > >
>> > > > > The % in the stats shown by google/others is only what they can
>> > > measure, but they can't measure *all*. There are countries (big ones=
)
>> that
>> > > don't allow measurements, or at least the same level of details, and
>> > > however, are doing massive IPv6 deployments.
>> > > > >
>> > > > > All the CDNs and caches have IPv6. The customers that have those
>> > > caches and enable IPv6 for their subscribers, are getting ranges ove=
r
>> 65%,
>> > > sometimes even up to 85-90% of IPv6 traffic when mainly the
>> subscribers are
>> > > householders instead of big enterprises.
>> > > > >
>> > > > > Also, the google (and others) measurements, show average
>> worldwide,
>> > > but if you look to many countries they have even surpassed the 50% o=
r
>> so.
>> > > > >
>> > > > > Regards,
>> > > > > Jordi
>> > > > > @jordipalet
>> > > > >
>> > > > >
>> > > > >
>> > > > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <
>> > > ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com>
>> escribi=C3=B3:
>> > > > >
>> > > > >     Since long time I was observing this, still almost the same,
>> no
>> > > clear progress occurred.
>> > > > >
>> > > > >     Thanks,
>> > > > >
>> > > > >     Khaled Omar
>> > > > >
>> > > > >     -----Original Message-----
>> > > > >     From: Scott O. Bradner 
>> > > > >     Sent: Wednesday, February 19, 2020 8:11 PM
>> > > > >     To: Khaled Omar 
>> > > > >     Cc: IETF Rinse Repeat 
>> > > > >     Subject: Re: ipv4 and ipv6 Coexistence.
>> > > > >
>> > > > >     Quite a few folk are already there - see
>> > > https://www.google.com/intl/en/ipv6/statistics.html
>> > > > >
>> > > > >     Scott
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > **********************************************
>> > > > > IPv4 is over
>> > > > > Are you ready for the new Internet ?
>> > > > > http://www.theipv6company.com
>> > > > > The IPv6 Company
>> > > > >
>> > > > > This electronic message contains information which may be
>> privileged
>> > > or confidential. The information is intended to be for the exclusive
>> use of
>> > > the individual(s) named above and further non-explicilty authorized
>> > > disclosure, copying, distribution or use of the contents of this
>> > > information, even if partially, including attached files, is strictl=
y
>> > > prohibited and will be considered a criminal offense. If you are not
>> the
>> > > intended recipient be aware that any disclosure, copying,
>> distribution or
>> > > use of the contents of this information, even if partially, includin=
g
>> > > attached files, is strictly prohibited, will be considered a crimina=
l
>> > > offense, so you must reply to the original sender to inform about th=
is
>> > > communication and delete it.
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > > --
>> > > > Mark Andrews, ISC
>> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> > > > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> > >
>> > > _______________________________________________
>> > > Architecture-discuss mailing list
>> > > Architecture-discuss@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
>> > >
>>
>> > _______________________________________________
>> > Architecture-discuss mailing list
>> > Architecture-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>>
>> --
>> ---
>> tte@cs.fau.de
>>
>

--000000000000ce9798059f712929
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Toerless &
architecture-discuss,

I find=
ed a 2011 article in the IETF Journal with the same title plus:
<=
br>
"IPv4, IPv6 Coexistence Challenges Network Operators" (Carolyn =
Duffy Marsan, March 6th 2016)


Regard,
Gu=
ntur Wiseno Putra

Pada Rabu, 26 Februari 2020, Guntur Wiseno Putra &=
lt;gsenopu@gmail.com=
> menulis:
Dear Toerless,=C2=A0architecture-discuss &
Mr. Charles Sun,=C2=A0

<=
div>
I wish Mr. Charles Sun does not mind if I share his post=
 (originally sent to the Open Forum's discussion of the Internet Societ=
y) to architecture-discuss:


Adopting and Enforcing an IPv=
6-Only Policy: If Not Now, When?
  • 1.=C2=A0
    Poste=
d 2 days ago
    Reply
    Adopti=
ng and enforcing the IPv6-only policy worldwide by securely deploying the s=
ingle stack of IPv6, turning off IPv4, and setting a specific deadline to s=
unset IPv4 completely will dramatically reduce the overall cybersecurity th=
reats and attacks based on IPv4.
    It is =
not a question as to whether or not we should adopt and enforce an IPv6-onl=
y policy by turning off and sunsetting IPv4, but rather a question that we =
all must ask: If not now, when?!
    Here i=
s the link to the full text of my latest=C2=A0opinion article:=C2=A0https://tinyurl.com/y=
xx386fd=C2=A0

    #cybersecurity    =C2=A0#IPv6Only=C2=A0#IPv6

    <=
em>Disclaimer: The views presented are only personal opinions and t=
hey do not necessarily represent those of the U.S. Government.
    =E2=80=8B=E2=80=8B=E2=80=8B

    ------------------------------
    <=
a href=3D"mailto:ForCharles@gmail.com" style=3D"color:rgb(58,130,228);backg=
round:transparent" target=3D"_blank">ForCharles@gmail.com
    IPv6 Exper=
t, Speaker, Columnist, Board Member, IT Executive.

    Note: replies wil=
l be sent to the full discussion group.
    ------------------------------

=


Regard,
Guntur Wiseno Putra

=
Pada Rabu, 26 Februari 2020, Toerless Eckert <tte@cs.fau.de> menulis:
Guntur:



That URL takes me to an SSO login on internetsociety.org.

Is that correct ? Internetsociety hosts walled garden content ?

I am puzzled.



With the title i found this:

ht=
tps://www.hstoday.us/subject-matter-areas/cybersecurity/adopting-=
and-enforcing-an-ipv6-only-policy-if-not-now-when/



Is that what you wanted to point to ?



Cheers

=C2=A0 =C2=A0 Toerless



On Tue, Feb 25, 2020 at 02:47:33PM +0700, Guntur Wiseno Putra wrote:

> Dear Toerless and

> architecture-discuss,

> 

> To inform that there is a post on IPv6 yesterday at the Open Forum'=
;s

> Discussion of the Internet Society:

> 

> "Adopting and Enforcing an IPv6-Only Policy: If Not Now, When&quo=
t;?

> 

> by Charles Sun

> 

> 

> 

> https://co=
nnect.internetsociety.org/communities/community-home/digestviewer=
/viewthread?MessageKey=3Df2844839-3d7d-40e2-b7ab-e4b0c1562de8&=
;CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Ddi=
gestviewer#bmf2844839-3d7d-40e2-b7ab-e4b0c1562de8

> 

> 

> 

> Regard,

> Guntur Wiseno Putra

> 

> Pada Selasa, 25 Februari 2020, Toerless Eckert <tte@cs.fau.de> menulis:

> 

> > [Bcc ietf@ietf=
.org, Cc: architecture-discuss@ietf.org]

> >

> > Mark:

> >

> > Funny to see how yours is the first actual answer to at least how=
 i read

> > Khaleds question. I would summarize what you said with:

> >

> > https://en.wikipedia.org/wiki/IPv6_transition_mec=
hanism

> >

> > (14 standardized plus a lot more. Aka: thank you, but we have eno=
ugh)

> >

> > Most everybody else jumps to the growth of the IPv6 Internet, whi=
ch

> > to me is just the visible tip of the iceberg of overall IPv4 and =
IPv6

> > deployments. I think the picture changes quite a bit if we look a=
t the

> > whole iceberg.

> >

> > In private / controlled networks, the choices are not only IPv4 v=
s.

> > IPv6 or their interop, but also (SR-)MPLS and even more so L2 eth=
ernet

> > switching.

> >

> > For all intent and purpose, Internet IPv6 vs. Internet IPv4 could=
 soon

> > be software-only overlay virtual networks whereas the actual

> > terrabit accelerated hardware forwarding plane of future networks=


> > maybe something else. 4G/5G "core" "network" =
already are such

> > overlay networks.

> >

> > [Rant]

> > I am not sure if the question, as constrained as=C2=A0 Khaled is =
asking

> > it will really help us to improve what we should do in the future=
. But

> > neither is the defensive reaction of IPv6 evangelists pointing at=
 the

> > growth curve of the IPv6 Internet as the only relevant metric to =
the

> > success and benefits of IPv6.

> >

> > I am primarily concerned that we did manage to recognize we neede=
d

> > disruptive innovartion in the 90th, when we came up with IPv6, bu=
t

> > now the predominant religion seems to be being stuck in small

> > incremental enhancements of that 25 year old architecture, especi=
ally

> > because its bible (RFC8200) did only think of the IPv6 Internet u=
se-case

> > requirements, but not those of private/controlled networks.

> > [/Rant]

> >

> > Cheer

> >=C2=A0 =C2=A0 =C2=A0Toerless

> >

> > On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:

> > > Really we do not need to be inventing anything new in this s=
pace.

> > > We already have too many mechanisms.=C2=A0 ISPs just need to=
 DEPLOY the

> > > existing mechanism.

> > >

> > > We have plain dual stack.

> > >

> > > We have public IPv4 + 6rd for ISPs where the access network =
doesn???t

> > > support IPv6.

> > >

> > > We have CGN + 6RD + 100.64/10 for ISPs where the access netw=
ork doesn???t

> > > support IPv6 and they have run out of IPv4 space.

> > >

> > > We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS f=
or when the

> > ISP

> > > has run out of IPv4 and the access network supports IPv6.
> > >

> > > We have CGN + IPv6.

> > >

> > > Do we really need something more at the protocol level?

> > >

> > > We do need Governments to ban the selling of new IPv4-only d=
omestic

> > > devices (CPE routers, TV???s, game boxes, etc.).

> > >

> > > Mark

> > >

> > > > On 20 Feb 2020, at 11:32, Khaled Omar <eng.khaled.omar@outlook=
.com>

> > wrote:

> > > >

> > > > Regardless the different %s, lets take the average one,=
 it can not

> > make us optimistic and stop thinking about a better solution, we =
should

> > learn from the long time passed without full migration occured, i=
f we will

> > wait till that happens, the division will occur which is not good=
 for the

> > internet, lets welcome new ideas and give it the space, time, and=


> > opportunity fairly, if it will be good then welcome, if not, tras=
h is made

> > for this.

> > > >

> > > > Get Outlook for Android

> > > >

> > > > From: ietf <ietf-bounces@ietf.org> on behalf of JORDI PALET M=
ARTINEZ

> > <jordi.palet=3D40consulintel.es@dmarc.ietf.org>

> > > > Sent: Thursday, February 20, 2020 2:00:58 AM

> > > > To: IETF Rinse Repeat <ietf@ietf.org>

> > > > Subject: Re: ipv4 and ipv6 Coexistence.

> > > >

> > > > And you're missing several points about how those s=
tats are looked at..

> > > >

> > > > The % in the stats shown by google/others is only what =
they can

> > measure, but they can't measure *all*. There are countries (b=
ig ones) that

> > don't allow measurements, or at least the same level of detai=
ls, and

> > however, are doing massive IPv6 deployments.

> > > >

> > > > All the CDNs and caches have IPv6. The customers that h=
ave those

> > caches and enable IPv6 for their subscribers, are getting ranges =
over 65%,

> > sometimes even up to 85-90% of IPv6 traffic when mainly the subsc=
ribers are

> > householders instead of big enterprises.

> > > >

> > > > Also, the google (and others) measurements, show averag=
e worldwide,

> > but if you look to many countries they have even surpassed the 50=
% or so.

> > > >

> > > > Regards,

> > > > Jordi

> > > > @jordipalet

> > > >

> > > >

> > > >

> > > > ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar=
" <

> > ietf-b=
ounces@ietf.org en nombre de eng.khaled.omar@outlook.com> escribi=C3=B3:
> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Since long time I was observing this=
, still almost the same, no

> > clear progress occurred.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Thanks,

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Khaled Omar

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0-----Original Message-----

> > > >=C2=A0 =C2=A0 =C2=A0From: Scott O. Bradner <sob@sobco.com>

> > > >=C2=A0 =C2=A0 =C2=A0Sent: Wednesday, February 19, 2020 8=
:11 PM

> > > >=C2=A0 =C2=A0 =C2=A0To: Khaled Omar <eng.khaled.omar@outlook.co=
m>

> > > >=C2=A0 =C2=A0 =C2=A0Cc: IETF Rinse Repeat <ietf@ietf.org>

> > > >=C2=A0 =C2=A0 =C2=A0Subject: Re: ipv4 and ipv6 Coexisten=
ce.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Quite a few folk are already there -=
 see

> > https://www.google.com/intl/en/ipv6/statistics.html

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Scott

> > > >

> > > >

> > > >

> > > >

> > > >

> > > > **********************************************

> > > > IPv4 is over

> > > > Are you ready for the new Internet ?

> > > > http://www.theipv6company.com

> > > > The IPv6 Company

> > > >

> > > > This electronic message contains information which may =
be privileged

> > or confidential. The information is intended to be for the exclus=
ive use of

> > the individual(s) named above and further non-explicilty authoriz=
ed

> > disclosure, copying, distribution or use of the contents of this<=
br>
> > information, even if partially, including attached files, is stri=
ctly

> > prohibited and will be considered a criminal offense. If you are =
not the

> > intended recipient be aware that any disclosure, copying, distrib=
ution or

> > use of the contents of this information, even if partially, inclu=
ding

> > attached files, is strictly prohibited, will be considered a crim=
inal

> > offense, so you must reply to the original sender to inform about=
 this

> > communication and delete it.

> > > >

> > > >

> > > >

> > >

> > > --

> > > Mark Andrews, ISC

> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia

> > > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 INTERNET: mar=
ka@isc.org

> >

> > _______________________________________________

> > Architecture-discuss mailing list

> > Architecture-discuss@ietf.org

> > https://www.ietf.org/mailman/listinfo/architec=
ture-discuss

> >



> _______________________________________________

> Architecture-discuss mailing list

> Arc=
hitecture-discuss@ietf.org

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss





-- 

---

tte@cs.fau.de






--000000000000ce9798059f712929--


From nobody Wed Feb 26 01:00:08 2020
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 38CC03A10FB for ; Wed, 26 Feb 2020 01:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 34M29vM71seB for ; Wed, 26 Feb 2020 01:00:03 -0800 (PST)
Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 791DB3A10FA for ; Wed, 26 Feb 2020 01:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1582707602; bh=TUORAInajf6W/W05o4kMiPA6j+/29/gTRhqT+OqHtxE=; h=Date:From:To:Subject:References:From:Subject; b=Ohc8gHmmfndP0NDKPgcyEnmfHml6UFRu8sGXZIKLsRFFtkhnRMZKigyJTAPoW2ZsQEqw3ek7n/4sfspoNb6mpAwVxiZTL/4UgfEIjFCaQuOvARlardxiVh87wo08/GzmWZ9uroTn0YmmGlK9av97XkcwvAx2mfZ6AmSM0IFaddX+rgWhWEBPne/wPcclRZFM+fte72gFFhYGMj5uxI2Yj/JGofUYLnzoZaFRGrqVIALLlXzjez5nvQ20YRqBqKhPgJdSVZL31KmzRWhtBNsuFweQyYbnx6SIGH/iZarrl3o/mErEQqmXb7df3/p6Cl9+kel2FYAmOkPSFa9YfE9IGA==
X-YMail-OSG: wYfNQAEVM1kU7K0GFAzmrr0CZvnaKH4KUvUvPQjcbbUB.jkeXji79kn2OGnJhBr 2pIwhQ0XD1KY6R3T0D3A7UU4OVdFFD_Vgj9SL5TdBFPX65oPWvyhTq.xfngPpijiZv.ENSUSY7hN i3klqAvityxXDD6YPfgHpbv85KaUwI3zLDC8n5l4A4VbVBqKr_ScmilESpGIoNMQQhJ1e1LCGlrK h1EvjSyJQ1gwEnxyKxV1FIlcF.rQz9DZjvRP3JH62MPrs06fKzg5FnKwDPYuO.hnDqkeMr4ov6Y4 .8C3KtSZvar0cdTXicf4Fbwc_KUu6WPS7wBWQtYvacbRtmIo6EOlnwwaG2d00J6sUa2jSAoYi1iA 0SfzyeFNtJKyQ903OR5rFm2UUvAqVRxtVCO0RK_mG5hJy63kDB3.KE4GzzOFIsg_LOxj.MlWSvD3 LtFztAfiTFaQjj6sdwvwb9AXrJZRzzyGAvkbtlZVyp8FHozyq4h0fJHJjqHkxRIGR3EyfHFWM49H .0_s7iLOVn.kjy2W9gABV5Q0q3L3pmKYRLD5FDpnoOlaFC6n4jpEtThSmHguWPetzxnU6LIW_JlI etzcHSfgGAK6xMSPm7wwoO.p0rfZmlHqsbRT5cp27bvmu7qYo6V7sIlY92bRaLH3_S3StJxWtZK4 97WSPYh6rlHC.gxFFru4aszmzeHcKCb9VUIQEL_1su9KseaPgp7D2DomRalsqYjGNu1dlrrRnUlh yckN0GUG3A6jHYecoaXZ7.GrLAl7DqFnY8EndfVGMX31pfPxgDX_PzPDDwmvvm8IcxYtXMSd047L fWzGURwhuZnmGhhowa5fV9Qp.IUWiQPeYDzEZOGzX90hdw5YoyaLQl.FkVKZCsFU47bnr77DJb_w KIQ9TPjYnAPYBAqAv0QPtQqP2CAQuVQHWiVHbarSwjC01yXPL3b7CLBF_30IkYHzILmNSRowWSQt 7xc.SpI3jFrjcmk.EaHPj_60ovVz_GcWRZIlgoIFn5qzdoD5JZDSD5Rs75fuKRFS6KYId1N7hjiO Ltx3gkk8GRkK7G_AKB6k.W3NSKJdP6NjfD76m3Mfa7mgIyfYfy8cwkGOW8roVkAGCkaW7osEr5qJ aJZX84E9EmOrkNPnfeQVeS5n75xKI06PaiMIASvP0ZR2kMR8Lp.mPhHJ_wTpPOtALVzqgqQc8l1G SS93EqTS6CWyNldttOrcosBHMFiRpS2h7wJVLjcFIq_VMimmwHEBiqHxTzm5StorlSRRakh5dbbx 0gkEpGG1m4ZdlrEi4YI8Gt8PRTy1T3jNrQTJ6xFRU4SDYWSbZPYaFhP5elG2x
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 09:00:02 +0000
Date: Wed, 26 Feb 2020 09:00:01 +0000 (UTC)
From: heinerhummel@aol.com
To: architecture-discuss@ietf.org
Message-ID: <1269431243.458183.1582707601351@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_458182_312777755.1582707601350"
References: <1269431243.458183.1582707601351.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.15302 aolwebmail Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:48.0) Gecko/20100101 Firefox/48.0
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 09:00:07 -0000

------=_Part_458182_312777755.1582707601350
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 Imho, ipv6 is just like ipv4. It does not dispatch the old errors:
Unicast, multicast,anycast are different services and needs to be addressed=
 by differentiating service bits in the header =E2=80=93 and not by differe=
nt address ranges! Also: Traffic congestion is a problem inmidst the networ=
k and needs to be solved by partial detouring. More than a decade ago, I el=
aborated algorithm+protocol how to utilize ALL adjacent links for forwardin=
g:=C2=A0 to ALL those neighbor-s(!) closer=C2=A0 to the destination,=C2=A0 =
to equally-distant neighbors,=C2=A0 to 1-hop-more-remote neighbors and for =
the worst case by means of 2 encapsulations to a far more distant(also rela=
tively to the destination) intermediate node, followed to=C2=A0 some remote=
 but closer-to-the-destination intermediate node. Included IP header info h=
ereby would haved avoided any endless looping.=C2=A0 That was for OSPF netw=
orks. With respect to interdomain, I elaborated TARA whose concept is well-=
known because applied by Google-map-routing: All nodes participate to enabl=
e the view of several zooming levels with accordingly skimmed topologies. T=
he next-hop was looked-up from 1, respective 3 offset-tables rather than by=
 binary search from a 850 000 entries-sized BGP table.

Invain. So I still think IPv6 will never fly.

Heiner
=20
=20
-----Urspr=C3=BCngliche Mitteilung-----
Von: Fred Baker 
An: Toerless Eckert 
Cc: architecture-discuss ; Mark Andrews 
Verschickt: Di, 25. Feb. 2020 19:16
Betreff: Re: [arch-d] ipv4 and ipv6 Coexistence.

On Feb 24, 2020, at 2:27 PM, Toerless Eckert  wrote:
>=20
> In private / controlled networks, the choices are not only IPv4 vs.
> IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet
> switching.

You make some important points, but...

We have had several countries discuss pulling off the Internet or doing som=
ething pretty disruptive, such as unilaterally changing from DNS to somethi=
ng else or imposing government-controlled firewalls. My point to them - and=
 I have spoken with more than one - is that disrupting Internet communicati=
ons affects the flow of international commerce, and therefore money, into t=
heir countries.

The same point applies in this case. If a company wants to internally only =
use  as a link layer protocol, that's their choice, but if they =
step very far away from IPv4 and IPv6, it means that they can't do business=
 with their vendors and their customers - they have to in some way translat=
e or overlay at that boundary. What has been beneficial with Internet techn=
ologies since they were invented was that one no longer had to think about =
global deployments of BBN 1822, X.25, Ethernet, or any of a long list of ot=
her things; they became carriers for a common architecture enabling global =
communications._______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss

------=_Part_458182_312777755.1582707601350
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





 Imho, ipv6 is just like ipv4. It does not dispatch t=
he old errors:

Unicast, multicast,anycast are different services and needs to be addressed=
 by differentiating service bits in the header =E2=80=93 and not by differe=
nt address ranges! Also: Traffic congestion is a problem inmidst the networ=
k and needs to be solved by partial detouring. More than a decade ago, I el=
aborated algorithm+protocol how to utilize ALL adjacent links for forwardin=
g:  to ALL those neighbor-s(!) closer  to the destination,  =
to equally-distant neighbors,  to 1-hop-more-remote neighbors and for =
the worst case by means of 2 encapsulations to a far more distant(also rela=
tively to the destination) intermediate node, followed to  some remote=
 but closer-to-the-destination intermediate node. Included IP header info h=
ereby would haved avoided any endless looping.  That was for OSPF netw=
orks. With respect to interdomain, I elaborated TARA whose concept is well-=
known because applied by Google-map-routing: All nodes participate to enabl=
e the view of several zooming levels with accordingly skimmed topologies. T=
he next-hop was looked-up from 1, respective 3 offset-tables rather than by=
 binary search from a 850 000 entries-sized BGP table.



Invain. So I still think IPv6 will never fly.



Heiner





 





 





-----=
Urspr=C3=BCngliche Mitteilung-----

Von: Fred Baker <fredbakersba@gmail.com>

An: Toerless Eckert <tte@cs.fau.de>

Cc: architecture-discuss <architecture-discuss@ietf.org>; Mark Andrew=
s <marka@isc.org>

Verschickt: Di, 25. Feb. 2020 19:16

Betreff: Re: [arch-d] ipv4 and ipv6 Coexistence.





On Feb 24, 2020, at 2:27 PM, Toerless Eckert <tte@cs.fau.de> wrote:


> 
> In private / controlled networks, the choices are not o=
nly IPv4 vs.
> IPv6 or their interop, but also (SR-)MP=
LS and even more so L2 ethernet
> switching.



You make some important points, but..=
.

We have had several countries discus=
s pulling off the Internet or doing something pretty disruptive, such as un=
ilaterally changing from DNS to something else or imposing government-contr=
olled firewalls. My point to them - and I have spoken with more than one - =
is that disrupting Internet communications affects the flow of internationa=
l commerce, and therefore money, into their countries.
The same point applies in this case. If a company wants to=
 internally only use <something> as a link layer protocol, that's the=
ir choice, but if they step very far away from IPv4 and IPv6, it means that=
 they can't do business with their vendors and their customers - they have =
to in some way translate or overlay at that boundary. What has been benefic=
ial with Internet technologies since they were invented was that one no lon=
ger had to think about global deployments of BBN 1822, X.25, Ethernet, or a=
ny of a long list of other things; they became carriers for a common archit=
ecture enabling global communications.



____________________________=
___________________
Architecture-discuss mailing list
Architecture-discu=
ss@ietf.org
https:=
//www.ietf.org/mailman/listinfo/architecture-discuss
=







------=_Part_458182_312777755.1582707601350--


From nobody Wed Feb 26 01:04:13 2020
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 683B83A1104 for ; Wed, 26 Feb 2020 01:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 uaVQlSuq71mM for ; Wed, 26 Feb 2020 01:04:07 -0800 (PST)
Received: from sonic304-35.consmr.mail.bf2.yahoo.com (sonic304-35.consmr.mail.bf2.yahoo.com [74.6.128.58]) (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 792403A110A for ; Wed, 26 Feb 2020 01:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1582707846; bh=usSt7b1L+CV/YE9V0s6WXLKnUJsHQaA9qTQwe8fYpl8=; h=Date:From:To:Subject:References:From:Subject; b=bA90VBlUydb7ZnFMzuz2c5jMN0j7t/9PMIIEPl95kcMZufgzK1PLIw85NaQ6xxj7/YRsUWWC2dhx/pPZgBH1NAiBp78DwFvkIrLh4YcKI1gBTaR73SFV+ZXzSSCNYiwQ2uySoXlV6EmHh3fvW35tfMtdDpvJ21Zd9Byn93DN9wt+NGgi6QJfQywrxOpeY84oXOQRp3XZcxLqo1QLViL3eJKGcCTmmAnhLqv+5vqZZL2DCepG1E+w89NtHDRKGx2mLNvCJwi1XDhekpZaAC7HZQYg8hp4pALlpC6IqdkW4qxjGigFDWhaO36gHBIUSe13U2Hj7+e4wyMvXCudI7r/bA==
X-YMail-OSG: N_6BpMEVRDvd.miR6A7lED5GPdAEx7ojsA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 09:04:06 +0000
Date: Wed, 26 Feb 2020 09:02:05 +0000 (UTC)
From: heinerhummel@aol.com
To: architecture-discuss@ietf.org
Message-ID: <1841465135.468499.1582707725166@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_468498_1108220186.1582707725163"
References: <1841465135.468499.1582707725166.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.15302 aolwebmail Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:48.0) Gecko/20100101 Firefox/48.0
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 09:04:11 -0000

------=_Part_468498_1108220186.1582707725163
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 Imho, ipv6 is just like ipv4. It does not dispatch the old errors:
Unicast, multicast,anycast are different services and needs to be addressed=
 by differentiating service bits in the header =E2=80=93 and not by differe=
nt address ranges! Also: Traffic congestion is a problem inmidst the networ=
k and needs to be solved by partial detouring. More than a decade ago, I el=
aborated algorithm+protocol how to utilize ALL adjacent links for forwardin=
g:=C2=A0 to ALL those neighbor-s(!) closer=C2=A0 to the destination,=C2=A0 =
to equally-distant neighbors,=C2=A0 to 1-hop-more-remote neighbors and for =
the worst case by means of 2 encapsulations to a far more distant(also rela=
tively to the destination) intermediate node, followed to=C2=A0 some remote=
 but closer-to-the-destination intermediate node. Included IP header info h=
ereby would haved avoided any endless looping.=C2=A0 That was for OSPF netw=
orks. With respect to interdomain, I elaborated TARA whose concept is well-=
known because applied by Google-map-routing: All nodes participate to enabl=
e the view of several zooming levels with accordingly skimmed topologies. T=
he next-hop was looked-up from 1, respective 3 offset-tables rather than by=
 binary search from a 850 000 entries-sized BGP table.

Invain. So I still think IPv6 will never fly.

Heiner=20
=20
-----Urspr=C3=BCngliche Mitteilung-----
Von: Brian E Carpenter 
An: Toerless Eckert ; Mark Andrews 
Cc: architecture-discuss 
Verschickt: Di, 25. Feb. 2020 20:17
Betreff: Re: [arch-d] ipv4 and ipv6 Coexistence.

Hi Toerless,

> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6,=20

I'm not at all sure we intended to be disruptive. In fact, the word
"coexistence" was there from before the start (I put it there, in
RFC1671) and to a considerable extent the IPv6 design tried to adopt
current best practice and was in fact a very conservative design; some
said it was too conservative.

As you can easily see, my foresight in that RFC was far from perfect
but the emphasis on coexistence and interworking was something that
every operator required from the start. If not, we wouldn't have got very
far.

Regards
=C2=A0 Brian

On 25-Feb-20 11:27, Toerless Eckert wrote:
> [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
>=20
> Mark:=20
>=20
> Funny to see how yours is the first actual answer to at least how i read
> Khaleds question. I would summarize what you said with:
>=20
> https://en.wikipedia.org/wiki/IPv6_transition_mechanism
>=20
> (14 standardized plus a lot more. Aka: thank you, but we have enough)
>=20
> Most everybody else jumps to the growth of the IPv6 Internet, which
> to me is just the visible tip of the iceberg of overall IPv4 and IPv6
> deployments. I think the picture changes quite a bit if we look at the
> whole iceberg.=20
>=20
> In private / controlled networks, the choices are not only IPv4 vs.
> IPv6 or their interop, but also (SR-)MPLS and even more so L2 ethernet=20
> switching.
>=20
> For all intent and purpose, Internet IPv6 vs. Internet IPv4 could soon
> be software-only overlay virtual networks whereas the actual
> terrabit accelerated hardware forwarding plane of future networks
> maybe something else. 4G/5G "core" "network" already are such
> overlay networks.=20
>=20
> [Rant]
> I am not sure if the question, as constrained as=C2=A0 Khaled is asking
> it will really help us to improve what we should do in the future. But
> neither is the defensive reaction of IPv6 evangelists pointing at the
> growth curve of the IPv6 Internet as the only relevant metric to the
> success and benefits of IPv6.
>=20
> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6, but
> now the predominant religion seems to be being stuck in small
> incremental enhancements of that 25 year old architecture, especially
> because its bible (RFC8200) did only think of the IPv6 Internet use-case
> requirements, but not those of private/controlled networks.
> [/Rant]
>=20
> Cheer
>=C2=A0 =C2=A0 Toerless
>=20
> On Thu, Feb 20, 2020 at 12:26:28PM +1100, Mark Andrews wrote:
>> Really we do not need to be inventing anything new in this space.
>> We already have too many mechanisms.=C2=A0 ISPs just need to DEPLOY the
>> existing mechanism.
>>
>> We have plain dual stack.
>>
>> We have public IPv4 + 6rd for ISPs where the access network doesn???t
>> support IPv6.
>>
>> We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn???=
t
>> support IPv6 and they have run out of IPv4 space.
>>
>> We have DS-Lite, MAP-E, MAP-T, NAT64 ??? providing IPV4AAS for when the =
ISP
>> has run out of IPv4 and the access network supports IPv6.
>>
>> We have CGN + IPv6.
>>
>> Do we really need something more at the protocol level?
>>
>> We do need Governments to ban the selling of new IPv4-only domestic
>> devices (CPE routers, TV???s, game boxes, etc.).
>>
>> Mark
>>
>>> On 20 Feb 2020, at 11:32, Khaled Omar  wro=
te:
>>>
>>> Regardless the different %s, lets take the average one, it can not make=
 us optimistic and stop thinking about a better solution, we should learn f=
rom the long time passed without full migration occured, if we will wait ti=
ll that happens, the division will occur which is not good for the internet=
, lets welcome new ideas and give it the space, time, and opportunity fairl=
y, if it will be good then welcome, if not, trash is made for this.=20
>>>
>>> Get Outlook for Android
>>>
>>> From: ietf  on behalf of JORDI PALET MARTINEZ 
>>> Sent: Thursday, February 20, 2020 2:00:58 AM
>>> To: IETF Rinse Repeat 
>>> Subject: Re: ipv4 and ipv6 Coexistence.
>>>=C2=A0=20
>>> And you're missing several points about how those stats are looked at.
>>>
>>> The % in the stats shown by google/others is only what they can measure=
, but they can't measure *all*. There are countries (big ones) that don't a=
llow measurements, or at least the same level of details, and however, are =
doing massive IPv6 deployments.
>>>
>>> All the CDNs and caches have IPv6. The customers that have those caches=
 and enable IPv6 for their subscribers, are getting ranges over 65%, someti=
mes even up to 85-90% of IPv6 traffic when mainly the subscribers are house=
holders instead of big enterprises.
>>>
>>> Also, the google (and others) measurements, show average worldwide, but=
 if you look to many countries they have even surpassed the 50% or so.
>>>
>>> Regards,
>>> Jordi
>>> @jordipalet
>>>=C2=A0=20
>>>=C2=A0=20
>>>
>>> ???El 20/2/20 5:38, "ietf en nombre de Khaled Omar"  escribi=C3=B3:
>>>
>>>=C2=A0 =C2=A0 Since long time I was observing this, still almost the sam=
e, no clear progress occurred.
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0 Thanks,
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0 Khaled Omar
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0 -----Original Message-----
>>>=C2=A0 =C2=A0 From: Scott O. Bradner =20
>>>=C2=A0 =C2=A0 Sent: Wednesday, February 19, 2020 8:11 PM
>>>=C2=A0 =C2=A0 To: Khaled Omar 
>>>=C2=A0 =C2=A0 Cc: IETF Rinse Repeat 
>>>=C2=A0 =C2=A0 Subject: Re: ipv4 and ipv6 Coexistence.
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0 Quite a few folk are already there - see https://www.googl=
e.com/intl/en/ipv6/statistics.html
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0 Scott
>>>=C2=A0 =C2=A0=20
>>>=C2=A0 =C2=A0=20
>>>
>>>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the exclusive use of t=
he individual(s) named above and further non-explicilty authorized disclosu=
re, copying, distribution or use of the contents of this information, even =
if partially, including attached files, is strictly prohibited and will be =
considered a criminal offense. If you are not the intended recipient be awa=
re that any disclosure, copying, distribution or use of the contents of thi=
s information, even if partially, including attached files, is strictly pro=
hibited, will be considered a criminal offense, so you must reply to the or=
iginal sender to inform about this communication and delete it.
>>>
>>>
>>>
>>
>> --=20
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I=
NTERNET: marka@isc.org
>=20
>=20

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

------=_Part_468498_1108220186.1582707725163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





 Imho, ipv6 is just like ipv4. It does not dispatch t=
he old errors:

Unicast,
 multicast,anycast are different services and needs to be addressed by=20
differentiating service bits in the header =E2=80=93 and not by different=
=20
address ranges! Also: Traffic congestion is a problem inmidst the=20
network and needs to be solved by partial detouring. More than a decade=20
ago, I elaborated algorithm+protocol how to utilize ALL adjacent links=20
for forwarding:  to ALL those neighbor-s(!) closer  to the destin=
ation, 
 to equally-distant neighbors,  to 1-hop-more-remote neighbors and for=
=20
the worst case by means of 2 encapsulations to a far more distant(also=20
relatively to the destination) intermediate node, followed to  some=20
remote but closer-to-the-destination intermediate node. Included IP=20
header info hereby would haved avoided any endless looping.  That was=
=20
for OSPF networks. With respect to interdomain, I elaborated TARA whose=20
concept is well-known because applied by Google-map-routing: All nodes=20
participate to enable the view of several zooming levels with=20
accordingly skimmed topologies. The next-hop was looked-up from 1,=20
respective 3 offset-tables rather than by binary search from a 850 000=20
entries-sized BGP table.



Invain. So I still think IPv6 will never fly.



Heiner



 





 





-----=
Urspr=C3=BCngliche Mitteilung-----

Von: Brian E Carpenter <brian.e.carpenter@gmail.com>

An: Toerless Eckert <tte@cs.fau.de>; Mark Andrews <marka@isc.org&g=
t;

Cc: architecture-discuss <architecture-discuss@ietf.org>

Verschickt: Di, 25. Feb. 2020 20:17

Betreff: Re: [arch-d] ipv4 and ipv6 Coexistence.





Hi Toerless,

> I a=
m primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6, =


I'm not at all sure we intended to be=
 disruptive. In fact, the word
"coexistence" was there fr=
om before the start (I put it there, in
RFC1671) and to a=
 considerable extent the IPv6 design tried to adopt
curre=
nt best practice and was in fact a very conservative design; some
said it was too conservative.

As you can easily see, my foresight in that RFC was far from perfect
but the emphasis on coexistence and interworking was somethin=
g that
every operator required from the start. If not, we=
 wouldn't have got very
far.

Regards
   Brian



On 25-Feb=
-20 11:27, Toerless Eckert wrote:
> [Bcc ietf@ietf.org, Cc: architecture-discuss@ietf.org]
> 
> Mark: 
> > Funny to see how yours is the first actual answer to a=
t least how i read
> Khaleds question. I would summari=
ze what you said with:
> 
> https://en.wikipedia.org/w=
iki/IPv6_transition_mechanism
> 
> (14 standardized plus a lot more. Aka: thank you, but we have enough)=

> 
> Most everybody else jumps t=
o the growth of the IPv6 Internet, which
> to me is ju=
st the visible tip of the iceberg of overall IPv4 and IPv6
> deployments. I think the picture changes quite a bit if we look at t=
he
> whole iceberg. 
> 
> In private / controlled networks, the choices are not only I=
Pv4 vs.
> IPv6 or their interop, but also (SR-)MPLS an=
d even more so L2 ethernet 
> switching.
> 
> For all intent and purpose, Internet IPv6=
 vs. Internet IPv4 could soon
> be software-only overl=
ay virtual networks whereas the actual
> terrabit acce=
lerated hardware forwarding plane of future networks
>=
 maybe something else. 4G/5G "core" "network" already are such
> overlay networks. 
> 
>=
; [Rant]
> I am not sure if the question, as constrain=
ed as  Khaled is asking
> it will really help us =
to improve what we should do in the future. But
> neit=
her is the defensive reaction of IPv6 evangelists pointing at the
> growth curve of the IPv6 Internet as the only relevant metri=
c to the
> success and benefits of IPv6.
> 
> I am primarily concerned that we did mana=
ge to recognize we needed
> disruptive innovartion in =
the 90th, when we came up with IPv6, but
> now the pre=
dominant religion seems to be being stuck in small
> i=
ncremental enhancements of that 25 year old architecture, especially
> because its bible (RFC8200) did only think of the IPv6 Int=
ernet use-case
> requirements, but not those of privat=
e/controlled networks.
> [/Rant]
>=
; 
> Cheer
>     Toerle=
ss
> 
> On Thu, Feb 20, 2020 at 1=
2:26:28PM +1100, Mark Andrews wrote:
>> Really we d=
o not need to be inventing anything new in this space.
&g=
t;> We already have too many mechanisms.  ISPs just need to DEPLOY =
the
>> existing mechanism.
>&g=
t;
>> We have plain dual stack.
&=
gt;>
>> We have public IPv4 + 6rd for ISPs where=
 the access network doesn???t
>> support IPv6.
>>
>> We have CGN + 6RD + 100.6=
4/10 for ISPs where the access network doesn???t
>>=
 support IPv6 and they have run out of IPv4 space.
>&g=
t;
>> We have DS-Lite, MAP-E, MAP-T, NAT64 ??? prov=
iding IPV4AAS for when the ISP
>> has run out of IP=
v4 and the access network supports IPv6.
>>
>> We have CGN + IPv6.
>>
>> Do we really need something more at the protocol level?<=
br clear=3D"none">>>
>> We do need Government=
s to ban the selling of new IPv4-only domestic
>> d=
evices (CPE routers, TV???s, game boxes, etc.).
>><=
br clear=3D"none">>> Mark
>>
>>> On 20 Feb 2020, at 11:32, Khaled Omar <eng.khaled.omar@outlook.com=
> wrote:
>>>
>>> R=
egardless the different %s, lets take the average one, it can not make us o=
ptimistic and stop thinking about a better solution, we should learn from t=
he long time passed without full migration occured, if we will wait till th=
at happens, the division will occur which is not good for the internet, let=
s welcome new ideas and give it the space, time, and opportunity fairly, if=
 it will be good then welcome, if not, trash is made for this. 
>>>
>>> Get Outlook for Android<=
br clear=3D"none">>>>
>>> From: ietf &l=
t;ietf-bounces@ietf.org> on behalf of JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmar=
c.ietf.org>
>>> Sent: Thursday, February =
20, 2020 2:00:58 AM
>>> To: IETF Rinse Repeat &l=
t;ietf@ietf.org>
>>> Subject: Re: ipv4 and ipv6 Coexistence.
>=
;>>  
>>> And you're missing several =
points about how those stats are looked at.
>>><=
br clear=3D"none">>>> The % in the stats shown by google/others is=
 only what they can measure, but they can't measure *all*. There are countr=
ies (big ones) that don't allow measurements, or at least the same level of=
 details, and however, are doing massive IPv6 deployments.
>>>
>>> All the CDNs and caches have =
IPv6. The customers that have those caches and enable IPv6 for their subscr=
ibers, are getting ranges over 65%, sometimes even up to 85-90% of IPv6 tra=
ffic when mainly the subscribers are householders instead of big enterprise=
s.
>>>
>>> Also, the =
google (and others) measurements, show average worldwide, but if you look t=
o many countries they have even surpassed the 50% or so.
=
>>>
>>> Regards,
>=
>> Jordi
>>> @jordipalet
>>>  
>>>  
>>>
>>> ???El 20/2/20 5:38, "ietf en =
nombre de Khaled Omar" <ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com> escribi=C3=
=B3:
>>>
>>>  &n=
bsp;  Since long time I was observing this, still almost the same, no clear=
 progress occurred.
>>>     
>>>     Thanks,
>>>=
     
>>>     Khaled Omar>>>     
>>>&=
nbsp;    -----Original Message-----
>>>&nbs=
p;    From: Scott O. Bradner <sob=
@sobco.com> 
>>>     Sent: Wedn=
esday, February 19, 2020 8:11 PM
>>>   =
;  To: Khaled Omar <eng.khaled.omar@outlook.com>
>>>=
;     Cc: IETF Rinse Repeat <ietf@ietf.org>
>>>     Subject=
: Re: ipv4 and ipv6 Coexistence.
>>>   =
;  
>>>     Quite a few folk are alrea=
dy there - see https://ww=
w.google.com/intl/en/ipv6/statistics.html
>>>=
;     
>>>     Scott
>>>     
>>> =
    
>>>
>>>
>>>
>>> ****************=
******************************
>>> IPv4 is over<=
br clear=3D"none">>>> Are you ready for the new Internet ?
>>> http://www.theipv6compa=
ny.com
>>> The IPv6 Company
>>>
>>> This electronic message conta=
ins information which may be privileged or confidential. The information is=
 intended to be for the exclusive use of the individual(s) named above and =
further non-explicilty authorized disclosure, copying, distribution or use =
of the contents of this information, even if partially, including attached =
files, is strictly prohibited and will be considered a criminal offense. If=
 you are not the intended recipient be aware that any disclosure, copying, =
distribution or use of the contents of this information, even if partially,=
 including attached files, is strictly prohibited, will be considered a cri=
minal offense, so you must reply to the original sender to inform about thi=
s communication and delete it.
>>>
>>>
>>>
>>=

>> -- 
>> Mark Andrews, IS=
C
>> 1 Seymour St., Dundas Valley, NSW 2117, Austra=
lia
>> PHONE: +61 2 9871 4742      &=
nbsp;       INTERNET: mark=
a@isc.org
> 
> 

_______________________________________________
Architecture-discuss mailing list
Architecture-disc=
uss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discus=
s








------=_Part_468498_1108220186.1582707725163--


From nobody Wed Feb 26 01:45:40 2020
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 B25443A11A7 for ; Wed, 26 Feb 2020 01:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NVZO8u0uehVD for ; Wed, 26 Feb 2020 01:45:34 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 7B59C3A11A6 for ; Wed, 26 Feb 2020 01:45:34 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id t23so2208875wmi.1 for ; Wed, 26 Feb 2020 01:45:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TyNblg2HrfFbeCK0H0iVm9uKHW7WROyNbrQfv8omP5E=; b=pr424T2yt7GRCZZLc0DhWvihBLOm+C/OoCtU0jFIVS8ku8NAeZ7bqiqF7Id6dszi5p APOwJhTtsTDyq4CAuY08nOPddNqoKuw/oJxQ925QyNmMWpZthcxbmYoyHgiRbJBMXbf7 c6yWpw9XF7CJDQTQdTYtnIYQ64S3KPfIGrg9I3bIXOhYFrb+7iX5vsz3vpClRMhNbNIu p7+VrPflnfuh6hGvpc3lRg8cXG4kekxMQDL4+XYvfzksDFyXx/oJ7H6aKlODPBVmNKbO SoAS1IK3bhn/XFN/q9CVJ8NAZDRMQ3aWwn5pMJ5AJxDd2BJH7bJNzQdRDgvIvFbkNYC0 TOYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TyNblg2HrfFbeCK0H0iVm9uKHW7WROyNbrQfv8omP5E=; b=CE1xPOmJ8ZFWNcBIA+npLNwK3X9FhRuW1lkyyMZvgtOLsxKhT72SI9pwfFte/NusTS Rm7+aqtN3LOSrVll299q8EeSM0SS5WakzfSFAbHcEZBOe+pvQFcGGzmJnAhO3BKXOxrR w51i6IboRFtcof8TD6hpTS5D/Xk/SlTgaOEgxMuDZ2ig9vG26XzCLIeu9hOhrXkY3CPB QhNOJfuyrY9vB+N6IfpYXWFw4u384ZpCsltL0yfJyERSFKY9lYxxVHhK0YbRJkrCvucs v+LZD92fpmbLPdr6kNkHrknSEaBcaekw12k/kWGuSsHBPPJohw7efRykFvgNKyWpocZ8 6IcA==
X-Gm-Message-State: APjAAAUmkTKcQjsQs33EhLYGw+6Ogzc5H/YB1RBEACmJQ7EfjnHa2jP+ ZuTNlJbTG55/wzrAFWTcWac=
X-Google-Smtp-Source: APXvYqybxwPSpTi2FfDoFSZFKjjUs+VwG7NCaDjTqwyS6uxorrRFJA4LPyDP+aMuoQV5qLHq/uh1dw==
X-Received: by 2002:a1c:7dd4:: with SMTP id y203mr4597373wmc.67.1582710333038;  Wed, 26 Feb 2020 01:45:33 -0800 (PST)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id q1sm2437655wrw.5.2020.02.26.01.45.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 01:45:32 -0800 (PST)
From: Stewart Bryant 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_14D04969-DB4F-43D6-9065-6B92D52F5CA1"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 26 Feb 2020 09:45:32 +0000
In-Reply-To: <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
Cc: Stewart Bryant , Mark Andrews , Khaled Omar , architecture-discuss@ietf.org
To: Toerless Eckert 
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 09:45:39 -0000

--Apple-Mail=_14D04969-DB4F-43D6-9065-6B92D52F5CA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 24 Feb 2020, at 22:27, Toerless Eckert  wrote:
>=20
> I am primarily concerned that we did manage to recognize we needed
> disruptive innovartion in the 90th, when we came up with IPv6, but
> now the predominant religion seems to be being stuck in small
> incremental enhancements of that 25 year old architecture, especially
> because its bible (RFC8200) did only think of the IPv6 Internet =
use-case
> requirements, but not those of private/controlled networks.

I agree.

It is more that just the issue of private/controlled networks, the =
Internet itself is changing and the end to end model as we espouse is =
breaking is becoming a minority activity.

Anyone that has not done so already should read

target: =
https://hknog.net/wp-content/uploads/2018/03/01_GeoffHuston_TheDeath_of_Tr=
ansit_and_Beyond.pdf
title: The Death of Transit and Beyond
author:
      name: Geoff Huston

It took us forever to recognise the reality of NATs, and I fear that we =
are failing to recognise the opportunities,  weaknesses and threats that =
the edge server and app centric model present.

- Stewart



--Apple-Mail=_14D04969-DB4F-43D6-9065-6B92D52F5CA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On 24 Feb 2020, at 22:27, Toerless Eckert <tte@cs.fau.de> =
wrote:

I am =
primarily concerned that we did manage to recognize we needed
disruptive =
innovartion in the 90th, when we came up with IPv6, but
now the =
predominant religion seems to be being stuck in small
incremental =
enhancements of that 25 year old architecture, especially
because its =
bible (RFC8200) did only think of the IPv6 Internet use-case
requirements, =
but not those of private/controlled =
networks.

I =
agree.

It is =
more that just the issue of private/controlled networks, the Internet =
itself is changing and the end to end model as we espouse is breaking is =
becoming a minority activity.

Anyone that has not done so already =
should read

target: https://hknog.net/wp-content/uploads/2018/03/01_GeoffHuston_The=
Death_of_Transit_and_Beyond.pdf
title: The Death of Transit and Beyond
author:
      name: Geoff =
Huston

It =
took us forever to recognise the reality of NATs, and I fear that we are =
failing to recognise the opportunities,  weaknesses and threats =
that the edge server and app centric model present.

- Stewart


=

--Apple-Mail=_14D04969-DB4F-43D6-9065-6B92D52F5CA1--


From nobody Wed Feb 26 01:59:18 2020
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 494273A11E9 for ; Wed, 26 Feb 2020 01:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 BwwEGfRO3x3o for ; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 727693A11E8 for ; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a9so2308489wmj.3 for ; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=W2yqQohlNVvYtMsY5cxNvdUPFT41KNTNE+CgdhnsxEw=; b=Q+ZhYyFEwO5HXpptwJiGnp4UXnBrsre6vwF7nDQnITfYAeRrwtYh6g62ZYFmxQOxNc NZCc0ezpT+mcyGOtLA7Egu5mbd0ZwxeGzTJXyVWEl+RS81Oy7t1CMpskSA0qorc98DrT sEkwU/I0Jw4chnkmyMdiJ9mqJUUOOF7QDB7/8RSiJCeglq81o14+UQ2AOe5Gki7NyRpk 4jvGHeNj1biBuLBp2aMQOtUx8qWyMBS5/9Tck/Q1IuAeVysTWbOc1VvmuQ1D8TMPiRay y8VXdLCGi/PBotxL9X3LOqBhSazmEYxWE482vjFFH/mQNIFK6wXXQq4l+vd42TkdSahj Kd8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=W2yqQohlNVvYtMsY5cxNvdUPFT41KNTNE+CgdhnsxEw=; b=cRJs8eMHlwLLp5sLKcYJ4JpKf/Qh45kU8Q6kn4t4W+ytLbD9f82Yl9qqRNaK+nmGki Fn1SRySgYbJYOs4XAFjOhIZVxxwx+YOaag/0fXNk6Ca1iLdvd7Qga4w5ZLQKYFDzxLiJ HCdKH/MEz/UlnoAaU6TQUvbLUtQzb5w5X2TRHf1BTHsxmbfBhPtbZdBUHGUv9FTTY3nq zvYFZofKwqQKXG23aYug3Ja+8ay1/I+0J4zFaq9dqejH+stO6x/ghoXrlJuseABSsOrU W0cJQXrx1hjIuvlQsAewprP3N1Bs/4Gtc1e2Z8XkUxTdBBcSILaGt9krIMbgblarh0Qt Vp3A==
X-Gm-Message-State: APjAAAWM7oHfIsPjQfAWxdI3588uw8H30D0YtMO/oeZ/ZoN0pFwQQMrS 0Tq16QutINB4Cl2saaiahmI=
X-Google-Smtp-Source: APXvYqxhkVk3cZM3w/METuQTyGNkB+NiuO22THqLx6zZN3QZTIurg6UiMqK3KValF1SklgsglOkJXQ==
X-Received: by 2002:a1c:238d:: with SMTP id j135mr4678963wmj.165.1582711153734;  Wed, 26 Feb 2020 01:59:13 -0800 (PST)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id k16sm2591519wrd.17.2020.02.26.01.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 01:59:13 -0800 (PST)
From: Stewart Bryant 
Message-Id: <5BF40034-E920-484B-AC6A-9071BC1E86B7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1167D3A8-DB74-4FF5-AD20-B9ADCCFAA715"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 26 Feb 2020 09:59:12 +0000
In-Reply-To: <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
Cc: Stewart Bryant , Toerless Eckert , architecture-discuss@ietf.org, Mark Andrews 
To: Fred Baker 
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 09:59:17 -0000

--Apple-Mail=_1167D3A8-DB74-4FF5-AD20-B9ADCCFAA715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 25 Feb 2020, at 18:16, Fred Baker  wrote:
>=20
> The same point applies in this case. If a company wants to internally =
only use  as a link layer protocol, that's their choice, but =
if they step very far away from IPv4 and IPv6, it means that they can't =
do business with their vendors and their customers - they have to in =
some way translate or overlay at that boundary. What has been beneficial =
with Internet technologies since they were invented was that one no =
longer had to think about global deployments of BBN 1822, X.25, =
Ethernet, or any of a long list of other things; they became carriers =
for a common architecture enabling global communications.

I think that we have to distinguish between packet exchange and =
information exchange.

For the applications that are of commercial significance HTTP(S) seems =
to be becoming the new waist.

Furthermore for most of those applications the entry point into the =
commercial domain is moving quite close to the user giving greater scope =
for migration to an alternative than we have in a model where most =
traffic transits an IXP.

The trend is towards app to commercial server connected via an encrypted =
UDP/IP tunnel. Where the app can be a web browser.=20

I am sure that we will retain IPv4/6 as a connection of last resort for =
the foreseeable future, but it is by no means clear that it (or indeed =
any single replacement) will remain the protocol of first choice.

- Stewart





--Apple-Mail=_1167D3A8-DB74-4FF5-AD20-B9ADCCFAA715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On 25 Feb 2020, at 18:16, Fred Baker <fredbakersba@gmail.com> wrote:

The same =
point applies in this case. If a company wants to internally only use =
<something> as a link layer protocol, that's their choice, but if =
they step very far away from IPv4 and IPv6, it means that they can't do =
business with their vendors and their customers - they have to in some =
way translate or overlay at that boundary. What has been beneficial with =
Internet technologies since they were invented was that one no longer =
had to think about global deployments of BBN 1822, X.25, Ethernet, or =
any of a long list of other things; they became carriers for a common =
architecture enabling global =
communications.

I think that we have to distinguish between packet exchange =
and information exchange.

For the applications that are of commercial significance =
HTTP(S) seems to be becoming the new waist.

Furthermore for most of those =
applications the entry point into the commercial domain is moving quite =
close to the user giving greater scope for migration to an alternative =
than we have in a model where most traffic transits an IXP.

The trend is towards app =
to commercial server connected via an encrypted UDP/IP tunnel. Where the =
app can be a web browser. 

I am sure that we will retain IPv4/6 as =
a connection of last resort for the foreseeable future, but it is by no =
means clear that it (or indeed any single replacement) will remain the =
protocol of first choice.

- Stewart




=

--Apple-Mail=_1167D3A8-DB74-4FF5-AD20-B9ADCCFAA715--


From nobody Wed Feb 26 02:22:08 2020
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 0EED83A12FB for ; Wed, 26 Feb 2020 02:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 9V_mA6Lye35B for ; Wed, 26 Feb 2020 02:22:03 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 E86B03A1279 for ; Wed, 26 Feb 2020 02:22:01 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id t14so2389922wmi.5 for ; Wed, 26 Feb 2020 02:22:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wHxpUqbUCLbu0xM/V0agqcBBg1KzJpqzwxlMHuZYNFc=; b=u9GFC340hkmBMRHn5LPwH5ffxRmlz+inALnYDK9LRmHXMzzy9PfTU6/VtZmAQqiMMI HySPPh6AEnTGrlT/WNl/RPyJNodHrST/xyfxrmHUBQKPYt/VE7ZtV/rEHfa79tLaLwmz 4tnl2v4w5yxm+0Hdy9lKpeDa3HEQzUuH00dIp+iSJ9PpR6SqFQb1MOx/m85O+q3e9mvU bkXkn9+DR3vfbT85f8yKQLiQpNzvbYZ1LKX7oIChLGUlv1++waHqiyVvJniKDe5IQWIr 7IWmXe6yqDtebDNwP3fXFAsY9NL2bpVXlZH3Aew70/GITMTKpL08A7iIZdXjVsFQ0G5r xTZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wHxpUqbUCLbu0xM/V0agqcBBg1KzJpqzwxlMHuZYNFc=; b=qqTpUPIOq6O58pm3F3ew/XTScFQnD9BC+T/XK5S2u5gT+W1NDyVyl/yYxQaWDilQVM 2ooDNhd2sTlIYdPm547IYr1MIgh0vFxoOrxY3JFk2P7htpew9R4JT4vpE9rlBZlAuHLf 5GBc4i21YUIvOh162ypSDqdfMYrJUSroq+rrem0Yrsw/2oCvrJ7F5s6JqqhOkZbEMOca OOzmyNrcH8ZRILJMKksCVEK3Tpb6XlxLFMxHJcq5mq7klk4fjs7GG2xzw0whWx2wmjSf fMMuXZtxO3szcOuM+s6UFhL57uJPR21jPwEhJHqFiEHVhrD6K3Wa0QGaV9xHwJD320+r YDIA==
X-Gm-Message-State: APjAAAVMxOEYJTQAVV5nEtuZOH4oaW1E5B+LNObhQQVOdjL+m4iwHMbF tyNi6b4BsD6dBqN7dtksMn4=
X-Google-Smtp-Source: APXvYqxhG0zZnp/DHo8QVYKortByyGt2UYejwi0tQpy4q2GNUBg9pkPwMnFmaSdSkmzzwimvct2wtw==
X-Received: by 2002:a7b:cb42:: with SMTP id v2mr4825936wmj.170.1582712520304;  Wed, 26 Feb 2020 02:22:00 -0800 (PST)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id j11sm2343937wmi.3.2020.02.26.02.21.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 02:21:59 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Stewart Bryant 
In-Reply-To: <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
Date: Wed, 26 Feb 2020 10:21:58 +0000
Cc: Stewart Bryant , Fred Baker , architecture-discuss@ietf.org, Mark Andrews 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 10:22:07 -0000

>=20
> The vision of the transparent global Internet was a great vision to
> me until 1995 when the Internet population exploded and IMHO the=20
> model started to fail. Since then, the mayority of TCP/IP hosts
> connects to the internet through some type of policy filtering,
> and the IETF has architecturally not really acknowledged
> that reality or the need for it. How are countries policing the
> Internet for their constituencies now any different from enterprises
> having done the same for decades for their constituencies ? What
> else but closing its eyes to the issue did the IETF do in the last 25
> years ?
>=20
> And now its easy to see how a limited number of regulated
> "WWW service conglomerates" will happily claim to solve all policy
> requirements at their application/gateway level. Because IETF
> networking architecture has failed to evolve the "Internet" model to
> something a little more based on reality of human society than the
> original Internet garden of Eden model that is still canon.
> [/rant]

The following is a quote from the London Times newspaper today and is a =
statement by someone who=E2=80=99s prime mission these days is to =
prevent the British public being murdered by terrorists.=20

"The head of MI5 has urged technology companies to give the security =
services =E2=80=9Cexceptional=E2=80=9D access to encrypted messages to =
tackle the =E2=80=9Cwild west=E2=80=9D of the internet.

"Sir Andrew Parker, 58, said that cyberspace needed to be policed in the =
same way as the physical world, where crimes had consequences. It was =
=E2=80=9Cincreasingly mystifying=E2=80=9D that intelligence officials =
were barred from reading secret messages shared between terrorist =
suspects, he told ITV News.



"Challenging the notion that Britons were content to allow the =
cybersphere to be an =E2=80=9Cunregulated, inaccessible-to-authorities =
space=E2=80=9D, he said that urgent change was needed.=E2=80=9D

Now we can argue about the technology issues, but fundamentally we (the =
IETF) have washed our hands of need to transition the  Internet from a =
meeting point of fundamentally good people, to an environment in which =
all have accesses and the social norms are maintained through government =
action via the judicial system, i.e. the real world.

- Stewart



From nobody Wed Feb 26 02:45:39 2020
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 79A183A0101 for ; Wed, 26 Feb 2020 02:45:37 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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=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 uKKR-Xf2-31q for ; Wed, 26 Feb 2020 02:45:33 -0800 (PST)
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 523363A00B0 for ; Wed, 26 Feb 2020 02:45:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 22DA6BE4D; Wed, 26 Feb 2020 10:45:31 +0000 (GMT)
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 UwRsJhUJU2Yb; Wed, 26 Feb 2020 10:45:30 +0000 (GMT)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5A21BE39; Wed, 26 Feb 2020 10:45:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582713930; bh=t3U/aKileKMxzIq5seVMDFz340ipfROFAFwWUaPS24Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=H7bdBR56DpB55KjmjwBQWP+kIIf4kEjiuZwXYejn/wfjDA8fX+V/GPTVLvKVxJ3Gb Ir1wDfyBheeA28nb8fEX7k/DOn0aRBOWKyURb2TmOrSKaLn0I25w9LL5vtJG3XJkus tNZUmp3bGYXAe8Y2T6m3kzIMBsdmIRgABE4wic9s=
To: Stewart Bryant 
Cc: architecture-discuss@ietf.org
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com>
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
Date: Wed, 26 Feb 2020 10:45:29 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pZOJ90Udp9QL5lvD8T2O2602qi6Bnxc8Y"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 10:45:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pZOJ90Udp9QL5lvD8T2O2602qi6Bnxc8Y
Content-Type: multipart/mixed; boundary="QRgh0xUwbMfxksSGA7dpoa0FGac5OkFxz";
 protected-headers="v1"
From: Stephen Farrell 
To: Stewart Bryant 
Cc: architecture-discuss@ietf.org
Message-ID: <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
References: 
 
 
 <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>
 
 
 <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de>
 <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
 <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
 <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com>
In-Reply-To: <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com>

--QRgh0xUwbMfxksSGA7dpoa0FGac5OkFxz
Content-Type: multipart/mixed;
 boundary="------------EA1481012FA2FB8FD83D87D7"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------EA1481012FA2FB8FD83D87D7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Stewart,

On 26/02/2020 10:21, Stewart Bryant wrote:
> "The head of MI5 has urged technology companies to give the security
> services =C3=A2=E2=82=AC=C5=93exceptional=C3=A2=E2=82=AC=C2=9D access t=
o encrypted messages=20

And in other, equally shocking, news: the sun will rise
tomorrow;-)

If you do want to rehash the cryptowars debate again,
maybe at least change the subject line? If doing so,
and I hope you decide not to, because there's no gain,
please recognise that there are many (me included) who
do not share the views you quoted for sound technical
reasons (e.g. [1] is perhaps the most-cited recent
paper on that) that have garnered rough consensus in
the IETF every time we've done that rehashing.

S.

[1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
by requiring government access to all data and communications." Journal
of Cybersecurity 1.1 (2015): 69-79.
https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf






--------------EA1481012FA2FB8FD83D87D7
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
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------EA1481012FA2FB8FD83D87D7--

--QRgh0xUwbMfxksSGA7dpoa0FGac5OkFxz--

--pZOJ90Udp9QL5lvD8T2O2602qi6Bnxc8Y
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5WTEkACgkQWrL68XsX
K+pGABAAyva0aLinfk6IJ8B/CE2/3NgCwhgo1EGGwFVwv275c2mrPauPi3YOvHUV
QnLd0fd6P+Vax+/pYA+hyZjNS3Xikf6cTKhAGXip+Wgp1IH9QrVWlxlmCFJR2Sqh
OHmS+HYZ3AVk4SD+zJfqQ8Xop/bT/qwPZdKhArIsktqgJXAcD3sMAISqFK3m8nxS
2Nh54nOBsUPUBxNbSwxxqslBylZQYW5/++py78QiRMPO5s+W+Y3AjDZTuiZy+2vK
CoRJ/USx1RDsE84F8Curk/C2px+9VzjVEUbg99xOXoPQxe9DK1bEcw0VA/ea12z9
rZxM+VcSenOKIiVnPe0s0pyBDryDRQ8D6kswGoakIXMvdIxKIK41BDsacvAx6TJh
ggUILArhcfX+dYmm8Ls/1sO99hAp5pVU/Ocon+CLa+00QTZhhwDODivAIAs+EQ0N
esfx2xCZ0mj63f/k8SiH9HEe7s/HHPin4cpOQQdVF1lQyL8MPiVkNETVZimZ+N2C
OGTNHURGyyo+o/O09j1HACPdzpld1avXs2BOqXs0C5odQb5qn0Qfb9hN8baTBVBO
PkSffUNO0HObNLY3d5uyrOYDwsmUv4fqaC+QgaYxERtOumuh092VZvEupgaMLS5V
iG4TauLmtBZBR5XpOiQRCldkXCG49YBqW+E2cSXmx3XAMJ/g/UE=
=RXOm
-----END PGP SIGNATURE-----

--pZOJ90Udp9QL5lvD8T2O2602qi6Bnxc8Y--


From nobody Wed Feb 26 03:53:01 2020
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 9A7183A0896 for ; Wed, 26 Feb 2020 03:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=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 i2OuA3KqGVDr for ; Wed, 26 Feb 2020 03:52:56 -0800 (PST)
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 362B03A0891 for ; Wed, 26 Feb 2020 03:52:55 -0800 (PST)
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 7669F6A275; Wed, 26 Feb 2020 12:52:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1582717971; bh=psXJkKYE5yqffghLY8okrTwsBWtjYItOLfvD2XGHZJo=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=rP1Wtl6ygELPTttdAxNWWVFUNkK6ENaUhCEOTJ+81ZYezqdgdhlOjV2fpep4Ygi/l GYvwV5S+Nkqrdbi60BpPU4cmT0wJARmLlI1RdNrwkhg5rw/snmEEXTslmRV8R29Sga DnbWqg9MJTnzWi7lf6Keu2ZBu82nMD61ZHfqmrFRZFNmOmPR7l0FqD+s7STAj6qpBO b8Tmva+AVI6rxwT+fkcweJGOXVtGt1Rs13uoOgJCT+gOws4kNwOE6ubSz2Z/UesDNd 8cSR1jNh2sAZQ0OWilx/b/t6klvR6DpPsFriHd+WnAXumn6WIN4+tpDu09RB0zILi0 SSvOSCAnDvf6A==
Received: from appsuite-gw1.open-xchange.com (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 699853C04CD; Wed, 26 Feb 2020 12:52:51 +0100 (CET)
Date: Wed, 26 Feb 2020 12:52:51 +0100 (CET)
From: Vittorio Bertola 
To: Stephen Farrell 
Cc: architecture-discuss@ietf.org
Message-ID: <1050951832.15584.1582717971339@appsuite-gw1.open-xchange.com>
In-Reply-To: <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev5
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 11:53:00 -0000

> Il 26/02/2020 11:45 Stephen Farrell  ha scritto:
> 
> If you do want to rehash the cryptowars debate again,
> maybe at least change the subject line? If doing so,
> and I hope you decide not to, because there's no gain,
> please recognise that there are many (me included) who
> do not share the views you quoted for sound technical
> reasons (e.g. [1] is perhaps the most-cited recent
> paper on that) that have garnered rough consensus in
> the IETF every time we've done that rehashing.

I think that no one here wants to reopen that discussion - we all agree that, from a technical standpoint, putting backdoors in cryptography is a bad idea. However, I wholeheartedly share the rant that Toerless posted; the problem is that, outside of the IETF, there are real public order issues that the IETF refuses to address, just continuing to deny their relevance or to suggest that they are technically impossible to solve. 

This behaviour will not make the issues disappear, nor the push by non-technical stakeholders to get them addressed, so either the IETF can come up with a workable technical reply to "what should we do then to enforce the law on a fully encrypted Internet?", or the push will simply break the Internet as we know it, and then you will have more countries building great firewalls, or mandating really bad technical solutions by law, because no one built a good one for them.

There could be solutions to the above question that impact the architecture of the Internet without breaking the communication protocols - for example, related to where the endpoints are located and who runs/gets access to them. Can this be done securely, with a reasonable compromise between privacy and access, etc.? I don't know, but AFAIK the IETF until now has refused to even discuss the issue - and even if it is mostly a policy issue, sound technical know-how and possibly bits of specific protocol development are likely to be part of any good solution. (Think of the RDAP protocol designed to handle global tiered access to domain registrant information, though it's not really working yet because the policy part has not been agreed - still, without building the appropriate technical tool there would be no way to address the policy issue.)

I understand that this is hard because it is not something that technologists can do alone; it requires interdisciplinary cooperation among many open minded people (open minded in the sense that they have to listen to and acknowledge very different views on what the Internet should be and do). But I see this as the big architectural challenge in the near future.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy


From nobody Wed Feb 26 08:58:13 2020
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 9873E3A0C37 for ; Wed, 26 Feb 2020 08:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.385
X-Spam-Level: 
X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no 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 eUCeSbmK8Lyj for ; Wed, 26 Feb 2020 08:58:09 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5533A0C31 for ; Wed, 26 Feb 2020 08:58:08 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2408886B8C; Wed, 26 Feb 2020 17:58:05 +0100 (CET)
From: Fernando Gont 
To: architecture-discuss@ietf.org
Cc: Internet Architecture Board 
References: 
Message-ID: <3c860fa5-af2d-272b-1d3a-2a740c9fe8a1@si6networks.com>
Date: Wed, 26 Feb 2020 13:57:51 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [arch-d] IPv6 header insertion/removal (Fwd: Re: [spring] Is srv6 PSP a good idea)
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, 26 Feb 2020 16:58:11 -0000

Folks,

This has been going on for at least months now.

So... IPv6 is not end to end?



-------- Forwarded Message --------
Subject: Re: [spring] Is srv6 PSP a good idea
Date: Wed, 26 Feb 2020 13:54:44 -0300
From: Fernando Gont 
To: Dirk Steinberg 
CC: Pablo Camarillo (pcamaril) , 
Mark Smith , SPRING WG 

On 26/2/20 12:57, Dirk Steinberg wrote:
> Hi Fernando,
> 
> adding to my own comment and to be more specific:
> 
> The existing RFCs are very clear in their wording that
> the node identified in the Destination Address field of
> the  IPv6 header is free to do whatever it desires with
> the packet it just received. After all, the packet was
> addressed specifically to that node.
> 
> These nodes are called segment endpoint nodes in SRv6.
> 
> Only nodes that are *NOT* identified in the DA are
> prohibited from making any changes.
> This should be very clear, even if you seem to
> wish that IPv6 had been defined differently.

Are you saying that IPv6 allows for in the network header insertion/removal?

If so, please tell me how AH, Path-MTU Discovery, and ICMPv6 error 
reporting works -- all very basic functions of IPv6.

IPv6 is an end to end protocol. With RH you change the DA on the flight, 
because routing only works based on the DA -- there's no other way to 
specify waypoints.

If you claim otherwise, that can be, at best, a major misunderstanding 
of how IPv6 works.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Feb 26 09:13:52 2020
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 4A6D43A0CFF for ; Wed, 26 Feb 2020 09:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lnxe9rgMS1Ld for ; Wed, 26 Feb 2020 09:13:48 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D3F733A0CFA for ; Wed, 26 Feb 2020 09:13:48 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id a6so1536250plm.3 for ; Wed, 26 Feb 2020 09:13:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7QRFGIsDkxVZ2nP0BHJ9mcwj1RQvAF6+uWGnKDCPvHU=; b=ukz+3d5bictNO+8l5OYhFSTYfb8Q1o0A3Rexyk0hmLTTNFqfVE+TWPwWMnRktdQQfB iA6M4G7/ShuoCOi0K932/T609bO8BvQ1/0ASTYxlw0Vmhjz6GF9jnOFB6vUArMEhTL5M wAIME802+qFNhGmWy1rPlhPwQtt996RBniA6m57gU3KYd/R03vuTSxS+mEqH97+WlivE PvpPQqBJD/RSDp/2ZotbksCPyQDlwAHb7JWAJNguWfCKD7wN/KRyzln7U/P8qiOt60U9 x4sw4ic7J2kctJKP5y3IXCV1v6Glsm3XoVw9j/M1jeFAlcezhCUKQT5OTy3PlZwaY9/O AAfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7QRFGIsDkxVZ2nP0BHJ9mcwj1RQvAF6+uWGnKDCPvHU=; b=IqlWr/9DTtedBD4gmILraDzgsSQrFYahQs6NZl5T1MTnkJ7Nf+wJzlrT298Tp/g+9b XSb8JRF+yk7M+4Y5CQt+cGvl/hDkelI8gv/u5mfHzSgL+W5Hxpnk6tZdW+XkRa2Ess8x dILtiw5WEjHJfZu8ib/K/R9H+Nl8sxb0+Ok+pcbOiiFBrLlMqvVRUVcRDiVQSH0tHUKg iFLb2n3mrilTxhYlIs+GxhyerT0884Ps459ctWA/f//YKKRs4NFaAgCoSsiBFY6L+ANN UCGVaEJwbMl8eJ2Cy5ZWtC/GQY0dP4y1v6e1sj08uJktXP0biY/p2f05DJGtMjcS4iE+ mwuA==
X-Gm-Message-State: APjAAAU8yHHOapKU60O3mGTTN22Wio3QqCKTphvHPXx4l3yeUdLbFaGR FD3O2kDZhAKGLzHh4dTeeJk=
X-Google-Smtp-Source: APXvYqz6OByLX2yyfh6uM6v6/0CbLUf16EuPNrHQ4HG4AHK2jh2nruJqojop/OGcjYliEqE0TXynsQ==
X-Received: by 2002:a17:902:8bc3:: with SMTP id r3mr302296plo.220.1582737228235;  Wed, 26 Feb 2020 09:13:48 -0800 (PST)
Received: from ?IPv6:2600:8801:d004:600:5d6a:f944:7762:f7f3? ([2600:8801:d004:600:5d6a:f944:7762:f7f3]) by smtp.gmail.com with ESMTPSA id b133sm3320051pga.43.2020.02.26.09.13.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 09:13:47 -0800 (PST)
From: FREDERICK BAKER 
Message-Id: <9B568BC7-9A2F-434D-8F92-C85420B40935@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_B34F0915-34FB-4256-8E5A-21A8F2A9F979"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.19\))
Date: Wed, 26 Feb 2020 09:13:45 -0800
In-Reply-To: <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
Cc: Mark Andrews , architecture-discuss@ietf.org
To: Toerless Eckert 
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3608.80.19)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 17:13:50 -0000

--Apple-Mail=_B34F0915-34FB-4256-8E5A-21A8F2A9F979
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Feb 25, 2020, at 12:24 PM, Toerless Eckert  wrote:
>=20
> Thanks, Fred, inline
>=20
> On Tue, Feb 25, 2020 at 10:16:24AM -0800, Fred Baker wrote:
>> On Feb 24, 2020, at 2:27 PM, Toerless Eckert  wrote:
>>>=20
>>> In private / controlled networks, the choices are not only IPv4 vs.
>>> IPv6 or their interop, but also (SR-)MPLS and even more so L2 =
ethernet
>>> switching.
>>=20
>> You make some important points, but...
>=20
>> We have had several countries discuss pulling off the Internet or =
doing something pretty disruptive, such as unilaterally changing from =
DNS to something else or imposing government-controlled firewalls. My =
point to them - and I have spoken with more than one - is that =
disrupting Internet communications affects the flow of international =
commerce, and therefore money, into their countries.
>=20
> Let me answer this further below.
>=20
>> The same point applies in this case. If a company wants to internally =
only use  as a link layer protocol, that's their choice, but =
if they step very far away from IPv4 and IPv6, it means that they can't =
do business with their vendors and their customers - they have to in =
some way translate or overlay at that boundary. What has been beneficial =
with Internet technologies since they were invented was that one no =
longer had to think about global deployments of BBN 1822, X.25, =
Ethernet, or any of a long list of other things; they became carriers =
for a common architecture enabling global communications.
>=20
> I think its dismissive to call private or controlled networks
> "link layers".  They include global enterprise, service provider, =
defense,
> federal and other federated networks, manufacturing and the like.

I'm not calling private or controlled networks link layers. I'm calling =
"(SR-)MPLS and even more so L2 ethernet switching" Link layers. You call =
a large part of what follows a "rant". I'll agree with you that it's a =
rant - and not respond.

> The Internet already is an overlay of sorts and the heavy lifting is
> done below it by those private/controlled network re-using IETF TCP/IP
> technologies, and a lot more than "The Internet".  Including the likes
> of MPLS, SRv6, DiffServ, heck even IntServ or *yikes* IP multicast. =
And
> parts of the IETF are still treating innovation to improve those type =
of
> networks as tangential or subordinated to comply with policies really =
only
> built just with "The Internet" use-case in mind.
>=20
> Making future IETF technologies better support where the heavy lifting
> is done is what i think would serve the IETF well.
>=20
> [rant]
> About your first point: I think that additional entities like
> governments "breaking" the Internet is a completely separate point,
> from the one i made and argued above.
>=20
> The vision of the transparent global Internet was a great vision to
> me until 1995 when the Internet population exploded and IMHO the
> model started to fail. Since then, the mayority of TCP/IP hosts
> connects to the internet through some type of policy filtering,
> and the IETF has architecturally not really acknowledged
> that reality or the need for it. How are countries policing the
> Internet for their constituencies now any different from enterprises
> having done the same for decades for their constituencies ? What
> else but closing its eyes to the issue did the IETF do in the last 25
> years ?
>=20
> And now its easy to see how a limited number of regulated
> "WWW service conglomerates" will happily claim to solve all policy
> requirements at their application/gateway level. Because IETF
> networking architecture has failed to evolve the "Internet" model to
> something a little more based on reality of human society than the
> original Internet garden of Eden model that is still canon.
> [/rant]
>=20
> Cheers
>    Toerless


--Apple-Mail=_B34F0915-34FB-4256-8E5A-21A8F2A9F979
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-----

iQIzBAEBCgAdFiEENpw36LrlpbGsJvlBQTRsYxfuthwFAl5Wp0kACgkQQTRsYxfu
thzd5hAAjSNzEcTFIxV8XOOFyaUI5qNiJHWw3Tn8BjqAOktnQ/PMIN7Nefx6OP0f
+z58ZUSTxhGbkGBH6XfBji1Myj0y21EBTYtnTD2T/offoB/Gi7c+qDf45bCSKs3A
IoYuhMjSpghnVRLCXX1NtlDdRSoX1TCNSl3g4L6lKAQUf594+Ti9mCVniM59G+FJ
d8MOirgJpYAu/vZy1LgfxjEH6HRbvJ6RQcRNxqvcg+oAhAf496+MvMynRfg7HN5u
CoQaZGY5wJ6YGUkg5XoS95fbhoJMaycjEy/1DAzdlgTboWIYbVBzyvO8J9nwim/1
i5NmlhHTxlS85cRL0t9oEbU1Ue3QWVr84WaLX/xVmAsVSzqCAthXJQO0XCwrHShK
pBGXSiJbo7mHoJwbj06rJevx6AiNyUDDiDANcJ1v9jORfoTg7tu1cThMi+k76AMX
M/EQSpJJeHUzM8VdZIJlbn49USRsJBqGL5TrYenZ3xz5lkCezzFyWbMro0zlbd3M
tYTHELsTZK04zaQ4VdhTV3fHdhtn0LckGPal/hUMd4fOiGIKqJO/miMwY08m/1As
yPNyhmOObkDVehNF8Y2Pk7WNkLSncMPqGSOqyDByW2fpg4CIzP7I1DYmdtuOTgD1
M58IwABBklIOqgDK6BNyvTEGNRytc/uqzopPqurZaFvq6ROwhMY=
=4AzD
-----END PGP SIGNATURE-----

--Apple-Mail=_B34F0915-34FB-4256-8E5A-21A8F2A9F979--


From nobody Wed Feb 26 12:00:55 2020
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 CBCA13A13BB for ; Wed, 26 Feb 2020 12:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 PQQ5dGvp5I9o for ; Wed, 26 Feb 2020 12:00:43 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB423A13C6 for ; Wed, 26 Feb 2020 12:00:42 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C2C43548005; Wed, 26 Feb 2020 21:00:35 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BCCD4440040; Wed, 26 Feb 2020 21:00:35 +0100 (CET)
Date: Wed, 26 Feb 2020 21:00:35 +0100
From: Toerless Eckert 
To: FREDERICK BAKER 
Cc: architecture-discuss@ietf.org, Mark Andrews 
Message-ID: <20200226200035.GK39574@faui48f.informatik.uni-erlangen.de>
References:    <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <9B568BC7-9A2F-434D-8F92-C85420B40935@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9B568BC7-9A2F-434D-8F92-C85420B40935@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 20:00:53 -0000

On Wed, Feb 26, 2020 at 09:13:45AM -0800, FREDERICK BAKER wrote:
> I'm not calling private or controlled networks link layers. I'm calling "(SR-)MPLS and even more so L2 ethernet switching" Link layers.

Thanks, that was not quite clear to me from your first statement.

> You call a large part of what follows a "rant". I'll agree with you that it's a rant - and not respond.

Sure. Let me know if you are interested in any actual technical
discussion without rants abou the technical points i raised.

Cheers
    Toerless

> > The Internet already is an overlay of sorts and the heavy lifting is
> > done below it by those private/controlled network re-using IETF TCP/IP
> > technologies, and a lot more than "The Internet".  Including the likes
> > of MPLS, SRv6, DiffServ, heck even IntServ or *yikes* IP multicast. And
> > parts of the IETF are still treating innovation to improve those type of
> > networks as tangential or subordinated to comply with policies really only
> > built just with "The Internet" use-case in mind.
> > 
> > Making future IETF technologies better support where the heavy lifting
> > is done is what i think would serve the IETF well.
> > 
> > [rant]
> > About your first point: I think that additional entities like
> > governments "breaking" the Internet is a completely separate point,
> > from the one i made and argued above.
> > 
> > The vision of the transparent global Internet was a great vision to
> > me until 1995 when the Internet population exploded and IMHO the
> > model started to fail. Since then, the mayority of TCP/IP hosts
> > connects to the internet through some type of policy filtering,
> > and the IETF has architecturally not really acknowledged
> > that reality or the need for it. How are countries policing the
> > Internet for their constituencies now any different from enterprises
> > having done the same for decades for their constituencies ? What
> > else but closing its eyes to the issue did the IETF do in the last 25
> > years ?
> > 
> > And now its easy to see how a limited number of regulated
> > "WWW service conglomerates" will happily claim to solve all policy
> > requirements at their application/gateway level. Because IETF
> > networking architecture has failed to evolve the "Internet" model to
> > something a little more based on reality of human society than the
> > original Internet garden of Eden model that is still canon.
> > [/rant]
> > 
> > Cheers
> >    Toerless
> 



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


-- 
---
tte@cs.fau.de


From nobody Wed Feb 26 13:01:06 2020
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 52D063A14A4 for ; Wed, 26 Feb 2020 13:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 gj7_aqMQNCOG for ; Wed, 26 Feb 2020 13:00:54 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872153A1498 for ; Wed, 26 Feb 2020 13:00:54 -0800 (PST)
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 61EB8548048; Wed, 26 Feb 2020 22:00:48 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5CC61440040; Wed, 26 Feb 2020 22:00:48 +0100 (CET)
Date: Wed, 26 Feb 2020 22:00:48 +0100
From: Toerless Eckert 
To: Stephen Farrell 
Cc: Stewart Bryant , architecture-discuss@ietf.org
Message-ID: <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
References:   <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 26 Feb 2020 21:01:04 -0000

On Wed, Feb 26, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:
> On 26/02/2020 10:21, Stewart Bryant wrote:
> > "The head of MI5 has urged technology companies to give the security
> > services ?????exceptional??? access to encrypted messages 
> 
> And in other, equally shocking, news: the sun will rise tomorrow;-)

https://en.wikipedia.org/wiki/The_empire_on_which_the_sun_never_sets
;-))

> If you do want to rehash the cryptowars debate again,

Not at all. But for example enterprises often use HTTPs proxies
for firewalling, intrusion detection, proprietary data leakage
prevention and the like. I am not aware we have stablished standards
for such desirable behavior. In fact there are issues with the expected
end-to-end krypto security when you bring in such trusted middle-men.
(e.g.: undesirable cert spoofing). There are no browser standards
for a three party trust-model AFAIK.

Right now, we have only those global commercial players positioning
them as trusted third parties. Even DoH IMHO falls into this play.
And then selling customer data collected, at least when they have
some entity operating outside europe (GDPR data leakage prevention).

All those IoT devices that export unbeknownst do the user all type
of collected user data to a cloud. We could come up with mandatory
published data models, force the connection through a trusted third
party device that can then do semantic filtering. Aka: i rather
want to be able to control than just trust GDPR statements.

Likewise i think we could define better behaving firewall policies
in the fashion did it for NAT with BEHAVE, e.g.: more visibility
of policy for better diagnostics.

Etc. pp. Just brainstorm what positive evolution we could promote
through IETF work for more security. The IETF end-to-end encryption
laurels nice but not enough.

> maybe at least change the subject line? If doing so,
> and I hope you decide not to, because there's no gain,
> please recognise that there are many (me included) who
> do not share the views you quoted for sound technical
> reasons (e.g. [1] is perhaps the most-cited recent
> paper on that) that have garnered rough consensus in
> the IETF every time we've done that rehashing.

Stating that we would like to see IETF solve problems doesnt
mean we agree to those regurgitated security agency memes.
Instead, i see these memes as the real risks, because the
public has shown to give in to the ongoing "tough on crime"
pounding with really bad outcomes. So we really need better,
alternative models for more security in addition to the
ongoing push back against that type of nonsense.

Cheers
    Toerless

> S.
> 
> [1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
> by requiring government access to all data and communications." Journal
> of Cybersecurity 1.1 (2015): 69-79.
> https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf
> 
> 
> 
> 
> 

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) 
> sub   RSA 4096/36CB8BB6 2017-12-22
> 




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


-- 
---
tte@cs.fau.de


From nobody Wed Feb 26 21:19:21 2020
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 6A51D3A0CB1 for ; Wed, 26 Feb 2020 21:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1Q2ieJNWekcf for ; Wed, 26 Feb 2020 21:19:15 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 D01F83A11C0 for ; Wed, 26 Feb 2020 21:19:14 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id r16so1814873otd.2 for ; Wed, 26 Feb 2020 21:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RPZwtFwYs4cmmI+XoiEo+1FM2L5he++RcUM1X9ETgfY=; b=eB1XzibiTroLPlo7jALFA4S3mn2QsLE+mHESK1+Yr6PJNcyIsLRCIsg+aC6C3QPdbs 7U8QCV4XZEl0A9Om7v0SQONZzY2+vKE84rEWUBCrBBd9Wnj5cbcquwEY+JsBZ25RoeEO +IxvJ86znpdgB0agqXU3y90Y/bKygTtEA4PiEuHOLHrH/P4JWzza4GJBO5GWPV4NIcCp 7N6bz9LFPf0p5C3LXcsE/9E/BaNQnE5JmeipETMOC3VyCnsPxdOCO/xnCEaGlZpBxC1O av8MyvVRLtFpRaJbqIgyQGLI6snI5htoMqRwj5yrG83QagMe+EbF+hqAqsqdur714Tsu TsuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPZwtFwYs4cmmI+XoiEo+1FM2L5he++RcUM1X9ETgfY=; b=R/+yf3zuelnO7ZafUiUcATuZmanyvfjPPvbM/uH3aRSC1xibnSW1YqG58F52rap5sH Ivmiqz+FREcC11t+cpW26HmeGUIiNoTGzUZeWodu7qagO/nchf7RcfrU3+nppNNmV1ba f2Go+aDLKjuzegmJ5wmiMflcypk4xdSmikCYujeOd6lrSPKVD5QwfVteWZ4gqGc0UVpS TTFxjagxpZuRsv1x/t0Dg0Nkxzwsu/H6ytCbzb535AbNH+Bfakf3D26L53u3683q6KoM pab+QbUth0J/huAMPq5KDDHYC1b7KShyPwCO6iucNHl2Q6AhjFapP9+Ld50MNg/qAJ7F l7Uw==
X-Gm-Message-State: APjAAAWklOQMPjIIpLA5MBfNPJU6QV8qoEmEVDBklg3DQvNgpMuRGO1k zbQ77LCnZ6WnB4NcBH5Qpeypc9LaP2Pm9EeQ2hM=
X-Google-Smtp-Source: APXvYqx7hrEF7ZEd7po0TuRfaytaZCSdMTUsXm0PBv9OgLlqmABrXS3YtujLSOrnvo/fa4yAj6F+sRDzNGACc3AkjbA=
X-Received: by 2002:a05:6830:1e76:: with SMTP id m22mr1974290otr.295.1582780752969;  Wed, 26 Feb 2020 21:19:12 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 26 Feb 2020 21:19:12 -0800 (PST)
In-Reply-To: <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
References:   <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie> <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
From: Guntur Wiseno Putra 
Date: Thu, 27 Feb 2020 12:19:12 +0700
Message-ID: 
To: Toerless Eckert 
Cc: Stephen Farrell ,  "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000089c1aa059f87dc39"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 27 Feb 2020 05:19:19 -0000

--00000000000089c1aa059f87dc39
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I am struggling to read on what Pekka Nikkander made about "IPv4 & IPv6" in
"Reflection on Architecture" (2005) where he mentioned about the time of
architecture-discuss' beginning:


(P. Nikander:)

"...Looking at the network of today, I strongly feel the pain of the
current architecture=E2=80=99s cracking and squeaking. Consequently, I beli=
eve that
we =E2=80=93 the wider IETF community responsible for Internet technology =
=E2=80=93 need to
re-think the architecture. We need to find a way to re-create the core of
the Internet in a way that leads to a new era of innovation and
intellectual prosperity....

... ( What we perhaps don=E2=80=99t consider very often is the fact that th=
ere are
huge asset values embedded in various parts of the network.)As the
slower-than-expected migration to IPv6 has amply demonstrated, some parts
of the current Internet are painfully hard to change. This makes any
long-term architectural thinking and planning difficult.

(While we can at most work towards understanding emergent complexity in the
first place, there is a great deal we can do about architectural
complexity... )

... We need some kind of an architectural vision and a related transition
path; an idea of where we are heading and perhaps how we could get there.

My vision includes peaceful co-existence of both IPv4 and IPv6 for a fairly
long time to come. While I would like to see a day when the last IPv4 node
is shut down, it is more likely that only future generations will see that
happening. In my vision it is possible to use any application I want
wherever I am and whatever kind of connection I may have. Indeed, I imagine
being able to use multiple wireless networks most of the time, and at least
one almost always. I dream of once more being able to communicate with
anyone, anywhere on the Internet, independent of the application we want to
use, not artificially hindered by NATs or other non-premeditated middle
boxes. Finally, in my vision we have baseline security as a built-in
feature of the architecture, providing cryptographically strong end-to-end
security and sufficient hooks for attaching different kinds of security
infrastructures, some based on organisational management and some based on
grassroots attempts to model interpersonal human trust relationships with
decentralised authorisation systems.

It looks very likely that fulfilling my vision requires adding a new layer,
a new =E2=80=9Cwaist=E2=80=9D, to the architecture [7]. We have to implemen=
t mobility,
multi-homing, and the envisioned baseline security somewhere in the stack.
If we want connectivity to span the partition between IPv4 and IPv6
networks, it looks necessary to build the functionality on the top of the
existing hop-by-hop functionality of the IP layer....

(Once we start to consider how to introduce the changes needed to progress
towards any vision, it becomes apparent that the two hardest-to-change
assets are the existing routing infrastructure and the set of all existing
applications. But network transparency is exactly what we should
re-establish...)

Using a term that Brian Carpenter recently coined, I propose that we aim at
providing new Architected Network Transparency (ANT). There seem to be
three or four potential migration paths towards ANT. One possibility is to
utilise a Cryptographically Generated Addresses (CGA) [8] based security
model in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to
provide end-to-end security and mobility even when IPv6 traffic is
shimmed....

... (Toward the ANT) One possible means might be Keyed Hash Identifiers
(KHI, pronounced as the Greek letter ?) [14], currently subject to heated
debate in the int-area and ipv6 mailing lists. Whether KHIs should be
considered as an important but transitory stepping stone or as despicable
opening of the flood gates to occupy the IPv6 address space with varmints
remains to be seen.

...".







Regard,
Guntur Wiseno Putra

Pada Kamis, 27 Februari 2020, Toerless Eckert  menulis:

> On Wed, Feb 26, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:
> > On 26/02/2020 10:21, Stewart Bryant wrote:
> > > "The head of MI5 has urged technology companies to give the security
> > > services =C3=A2?????exceptional=C3=A2???  access to encrypted message=
s
> >
> > And in other, equally shocking, news: the sun will rise tomorrow;-)
>
> https://en.wikipedia.org/wiki/The_empire_on_which_the_sun_never_sets
> ;-))
>
> > If you do want to rehash the cryptowars debate again,
>
> Not at all. But for example enterprises often use HTTPs proxies
> for firewalling, intrusion detection, proprietary data leakage
> prevention and the like. I am not aware we have stablished standards
> for such desirable behavior. In fact there are issues with the expected
> end-to-end krypto security when you bring in such trusted middle-men.
> (e.g.: undesirable cert spoofing). There are no browser standards
> for a three party trust-model AFAIK.
>
> Right now, we have only those global commercial players positioning
> them as trusted third parties. Even DoH IMHO falls into this play.
> And then selling customer data collected, at least when they have
> some entity operating outside europe (GDPR data leakage prevention).
>
> All those IoT devices that export unbeknownst do the user all type
> of collected user data to a cloud. We could come up with mandatory
> published data models, force the connection through a trusted third
> party device that can then do semantic filtering. Aka: i rather
> want to be able to control than just trust GDPR statements.
>
> Likewise i think we could define better behaving firewall policies
> in the fashion did it for NAT with BEHAVE, e.g.: more visibility
> of policy for better diagnostics.
>
> Etc. pp. Just brainstorm what positive evolution we could promote
> through IETF work for more security. The IETF end-to-end encryption
> laurels nice but not enough.
>
> > maybe at least change the subject line? If doing so,
> > and I hope you decide not to, because there's no gain,
> > please recognise that there are many (me included) who
> > do not share the views you quoted for sound technical
> > reasons (e.g. [1] is perhaps the most-cited recent
> > paper on that) that have garnered rough consensus in
> > the IETF every time we've done that rehashing.
>
> Stating that we would like to see IETF solve problems doesnt
> mean we agree to those regurgitated security agency memes.
> Instead, i see these memes as the real risks, because the
> public has shown to give in to the ongoing "tough on crime"
> pounding with really bad outcomes. So we really need better,
> alternative models for more security in addition to the
> ongoing push back against that type of nonsense.
>
> Cheers
>     Toerless
>
> > S.
> >
> > [1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
> > by requiring government access to all data and communications." Journal
> > of Cybersecurity 1.1 (2015): 69-79.
> > https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf
> >
> >
> >
> >
> >
>
> pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <
> stephen.farrell@cs.tcd.ie>
> > sub   RSA 4096/36CB8BB6 2017-12-22
> >
>
>
>
>
> > _______________________________________________
> > 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
>

--00000000000089c1aa059f87dc39
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

I am struggling to read on wh=
at Pekka Nikkander made about "IPv4 & IPv6" in "Reflecti=
on on Architecture" (2005) where he mentioned about the time of archit=
ecture-discuss' beginning:


(P. =
Nikander:)


"...Looking at the network of today, I strongly feel the pain of t=
he current architecture=E2=80=99s cracking and squeaking. Consequently, I b=
elieve that we =E2=80=93 the wider IETF community responsible for Internet =
technology =E2=80=93 need to re-think the architecture. We need to find a w=
ay to re-create the core of the Internet in a way that leads to a new era o=
f innovation and intellectual prosperity....



... ( What we perhaps don=E2=80=99t consider very often is the fact that th=
ere are huge asset values embedded in various parts of the network.)As the =
slower-than-expected migration to IPv6 has amply demonstrated, some parts o=
f the current Internet are painfully hard to change. This makes any long-te=
rm architectural thinking and planning difficult.



(While we can at most work towards understanding emergent complexity in the=
 first place, there is a great deal we can do about architectural complexit=
y... )



... We need some kind of an architectural vision and a related transition p=
ath; an idea of where we are heading and perhaps how we could get there.


My vision includes peaceful co-existence of both IPv4 and IPv6 for a fairly=
 long time to come. While I would like to see a day when the last IPv4 node=
 is shut down, it is more likely that only future generations will see that=
 happening. In my vision it is possible to use any application I want where=
ver I am and whatever kind of connection I may have. Indeed, I imagine bein=
g able to use multiple wireless networks most of the time, and at least one=
 almost always. I dream of once more being able to communicate with anyone,=
 anywhere on the Internet, independent of the application we want to use, n=
ot artificially hindered by NATs or other non-premeditated middle boxes. Fi=
nally, in my vision we have baseline security as a built-in feature of the =
architecture, providing cryptographically strong end-to-end security and su=
fficient hooks for attaching different kinds of security infrastructures, s=
ome based on organisational management and some based on grassroots attempt=
s to model interpersonal human trust relationships with decentralised autho=
risation systems.



It looks very likely that fulfilling my vision requires adding a new layer,=
 a new =E2=80=9Cwaist=E2=80=9D, to the architecture [7]. We have to impleme=
nt mobility, multi-homing, and the envisioned baseline security somewhere i=
n the stack. If we want connectivity to span the partition between IPv4 and=
 IPv6 networks, it looks necessary to build the functionality on the top of=
 the existing hop-by-hop functionality of the IP layer....



(Once we start to consider how to introduce the changes needed to progress =
towards any vision, it becomes apparent that the two hardest-to-change asse=
ts are the existing routing infrastructure and the set of all existing appl=
ications. But network transparency is exactly what we should re-establish..=
.)



Using a term that Brian Carpenter recently coined, I propose that we aim at=
 providing new Architected Network Transparency (ANT). There seem to be thr=
ee or four potential migration paths towards ANT. One possibility is to uti=
lise a Cryptographically Generated Addresses (CGA) [8] based security model=
 in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to provide en=
d-to-end security and mobility even when IPv6 traffic is shimmed....



... (Toward the ANT) One possible means might be Keyed Hash Identifiers (KH=
I, pronounced as the Greek letter ?) [14], currently subject to heated deba=
te in the int-area and ipv6 mailing lists. Whether KHIs should be considere=
d as an important but transitory stepping stone or as despicable opening of=
 the flood gates to occupy the IPv6 address space with varmints remains to =
be seen.



...".










=
Regard,
Guntur Wiseno Putra

Pada Kamis, 27 Februari 2020, =
Toerless Eckert <tte@cs.fau.de> =
menulis:
On Wed, Feb 26, 2020 at 10:45:29=
AM +0000, Stephen Farrell wrote:

> On 26/02/2020 10:21, Stewart Bryant wrote:

> > "The head of MI5 has urged technology companies to give the =
security

> > services =C3=A2?????exceptional=C3=A2???=C2=A0 access to encrypte=
d messages 

> 

> And in other, equally shocking, news: the sun will rise tomorrow;-)


https://en.wikipedia.org/wiki/The_empire_on_wh=
ich_the_sun_never_sets

;-))



> If you do want to rehash the cryptowars debate again,



Not at all. But for example enterprises often use HTTPs proxies

for firewalling, intrusion detection, proprietary data leakage

prevention and the like. I am not aware we have stablished standards

for such desirable behavior. In fact there are issues with the expected

end-to-end krypto security when you bring in such trusted middle-men.

(e.g.: undesirable cert spoofing). There are no browser standards

for a three party trust-model AFAIK.



Right now, we have only those global commercial players positioning

them as trusted third parties. Even DoH IMHO falls into this play.

And then selling customer data collected, at least when they have

some entity operating outside europe (GDPR data leakage prevention).



All those IoT devices that export unbeknownst do the user all type

of collected user data to a cloud. We could come up with mandatory

published data models, force the connection through a trusted third

party device that can then do semantic filtering. Aka: i rather

want to be able to control than just trust GDPR statements.



Likewise i think we could define better behaving firewall policies

in the fashion did it for NAT with BEHAVE, e.g.: more visibility

of policy for better diagnostics.



Etc. pp. Just brainstorm what positive evolution we could promote

through IETF work for more security. The IETF end-to-end encryption

laurels nice but not enough.



> maybe at least change the subject line? If doing so,

> and I hope you decide not to, because there's no gain,

> please recognise that there are many (me included) who

> do not share the views you quoted for sound technical

> reasons (e.g. [1] is perhaps the most-cited recent

> paper on that) that have garnered rough consensus in

> the IETF every time we've done that rehashing.



Stating that we would like to see IETF solve problems doesnt

mean we agree to those regurgitated security agency memes.

Instead, i see these memes as the real risks, because the

public has shown to give in to the ongoing "tough on crime"

pounding with really bad outcomes. So we really need better,

alternative models for more security in addition to the

ongoing push back against that type of nonsense.



Cheers

=C2=A0 =C2=A0 Toerless



> S.

> 

> [1] Abelson, Harold, et al. "Keys under doormats: mandating insec=
urity

> by requiring government access to all data and communications." J=
ournal

> of Cybersecurity 1.1 (2015): 69-79.

> https://www.cs.yale.edu/homes/jf/paper-ke=
ys-under-doormats-CSAIL.pdf

> 

> 

> 

> 

> 



pub=C2=A0 =C2=A0RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie>=


> sub=C2=A0 =C2=A0RSA 4096/36CB8BB6 2017-12-22

> 









> _______________________________________________

> 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-discu=
ss




--00000000000089c1aa059f87dc39--


From nobody Wed Feb 26 21:26:05 2020
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 B224B3A11ED for ; Wed, 26 Feb 2020 21:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iPnsou4DpAVp for ; Wed, 26 Feb 2020 21:26:00 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 977133A11E9 for ; Wed, 26 Feb 2020 21:26:00 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id b18so2120876oie.2 for ; Wed, 26 Feb 2020 21:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GYfOc2fGWHM5Et3gMmGw7ar8XrkAS9ioEAPCjd2d0EE=; b=Tr7sPHIVMHqSIrH8PTZV4XjPGRWy9lH1fWM3RvmNembpCtA+agZq2fuyUzsWx4o5vG mhah+fKlWDBD6bAIN4b8ce0fxsbrz94PCHievbyA8H00PzAeI2KmOgj1cFanKp2XEHbf hcpiilm7gYWx0Z81NsLcwx+W/A84DLrZblGgrU7uQHyJF8/bx2xInR/kJ/HXwSELvfQ7 1xCY0qZKPTcnatcoTPInC5MjhHaphR1a9T7rgT7TuvhCgyUMXAHvIpwkSeKdSi4nF8O7 IncB++pNA69QJJ3sWSCtoWpZvmc5enAc/MCtmL0aa2H2wjduhC97vVofFSEugPoIHqf3 ASHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GYfOc2fGWHM5Et3gMmGw7ar8XrkAS9ioEAPCjd2d0EE=; b=iJ3jBqnB9bPgKjx7P7fnvBvkrBkVxJPocbPlBmYcruYQgMp5D0VOcwXVtAkpNJKVry CdLlSsSsjOUMcFD6qhSOqnj4muvMsUuxzw82oNzJQIpuSPB0h4kRfhF5iacBrf/YmSNn 8vivMQmdpRm4AsoPgDzUZUcKjtLGymd36m/LGRJ/dN650HMAYGqcZK5WzcSaHQPIXsOD cxR3R7wK0xR8n+po6FYAz663okFvbEPLorWLjbs6GDigFu3IyTHskyR9BmhIyR4uaQyu gkz2B6KhkSOZjHuwDKVZuKs6KBqzpMX8EP3MMa0QxmX75DQOUMx6r3KaUYsYg9aIDTEp HgTQ==
X-Gm-Message-State: APjAAAUe9joHwq1wYv71kZKQg07dfciVdEMatRJR6cRQZv5sG6hfMy8J TTUQ9SSWIBktIemgV94vuDq9b/ncePn3YslgZcf7SA==
X-Google-Smtp-Source: APXvYqxqiw27kFgoagngQNisrnNUrYVdmWSz3tk8al/fO9PeLIPsB9V7F8PFBmnjTwZpzXAJvWBenNFnwqMtoF7BCcA=
X-Received: by 2002:a54:4396:: with SMTP id u22mr2070793oiv.128.1582781159723;  Wed, 26 Feb 2020 21:25:59 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 26 Feb 2020 21:25:59 -0800 (PST)
In-Reply-To: 
References:   <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es>   <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie> <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de> 
From: Guntur Wiseno Putra 
Date: Thu, 27 Feb 2020 12:25:59 +0700
Message-ID: 
To: Toerless Eckert 
Cc: Stephen Farrell ,  "architecture-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c8573e059f87f438"
Archived-At: 
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
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, 27 Feb 2020 05:26:04 -0000

--000000000000c8573e059f87f438
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

This is the address for Pekka Nikander's "Reflections on Architecture" I
mentioned above:

https://www.ietfjournal.org/reflections-on-architecture/


Regard,
Guntur Wiseno Putra

Pada Kamis, 27 Februari 2020, Guntur Wiseno Putra 
menulis:

> Dear architecture-discuss,
>
> I am struggling to read on what Pekka Nikkander made about "IPv4 & IPv6"
> in "Reflection on Architecture" (2005) where he mentioned about the time =
of
> architecture-discuss' beginning:
>
>
> (P. Nikander:)
>
> "...Looking at the network of today, I strongly feel the pain of the
> current architecture=E2=80=99s cracking and squeaking. Consequently, I be=
lieve that
> we =E2=80=93 the wider IETF community responsible for Internet technology=
 =E2=80=93 need to
> re-think the architecture. We need to find a way to re-create the core of
> the Internet in a way that leads to a new era of innovation and
> intellectual prosperity....
>
> ... ( What we perhaps don=E2=80=99t consider very often is the fact that =
there are
> huge asset values embedded in various parts of the network.)As the
> slower-than-expected migration to IPv6 has amply demonstrated, some parts
> of the current Internet are painfully hard to change. This makes any
> long-term architectural thinking and planning difficult.
>
> (While we can at most work towards understanding emergent complexity in
> the first place, there is a great deal we can do about architectural
> complexity... )
>
> ... We need some kind of an architectural vision and a related transition
> path; an idea of where we are heading and perhaps how we could get there.
>
> My vision includes peaceful co-existence of both IPv4 and IPv6 for a
> fairly long time to come. While I would like to see a day when the last
> IPv4 node is shut down, it is more likely that only future generations wi=
ll
> see that happening. In my vision it is possible to use any application I
> want wherever I am and whatever kind of connection I may have. Indeed, I
> imagine being able to use multiple wireless networks most of the time, an=
d
> at least one almost always. I dream of once more being able to communicat=
e
> with anyone, anywhere on the Internet, independent of the application we
> want to use, not artificially hindered by NATs or other non-premeditated
> middle boxes. Finally, in my vision we have baseline security as a built-=
in
> feature of the architecture, providing cryptographically strong end-to-en=
d
> security and sufficient hooks for attaching different kinds of security
> infrastructures, some based on organisational management and some based o=
n
> grassroots attempts to model interpersonal human trust relationships with
> decentralised authorisation systems.
>
> It looks very likely that fulfilling my vision requires adding a new
> layer, a new =E2=80=9Cwaist=E2=80=9D, to the architecture [7]. We have to=
 implement
> mobility, multi-homing, and the envisioned baseline security somewhere in
> the stack. If we want connectivity to span the partition between IPv4 and
> IPv6 networks, it looks necessary to build the functionality on the top o=
f
> the existing hop-by-hop functionality of the IP layer....
>
> (Once we start to consider how to introduce the changes needed to progres=
s
> towards any vision, it becomes apparent that the two hardest-to-change
> assets are the existing routing infrastructure and the set of all existin=
g
> applications. But network transparency is exactly what we should
> re-establish...)
>
> Using a term that Brian Carpenter recently coined, I propose that we aim
> at providing new Architected Network Transparency (ANT). There seem to be
> three or four potential migration paths towards ANT. One possibility is t=
o
> utilise a Cryptographically Generated Addresses (CGA) [8] based security
> model in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to
> provide end-to-end security and mobility even when IPv6 traffic is
> shimmed....
>
> ... (Toward the ANT) One possible means might be Keyed Hash Identifiers
> (KHI, pronounced as the Greek letter ?) [14], currently subject to heated
> debate in the int-area and ipv6 mailing lists. Whether KHIs should be
> considered as an important but transitory stepping stone or as despicable
> opening of the flood gates to occupy the IPv6 address space with varmints
> remains to be seen.
>
> ...".
>
>
>
>
>
>
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Kamis, 27 Februari 2020, Toerless Eckert  menulis:
>
>> On Wed, Feb 26, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:
>> > On 26/02/2020 10:21, Stewart Bryant wrote:
>> > > "The head of MI5 has urged technology companies to give the security
>> > > services =C3=A2?????exceptional=C3=A2???  access to encrypted messag=
es
>> >
>> > And in other, equally shocking, news: the sun will rise tomorrow;-)
>>
>> https://en.wikipedia.org/wiki/The_empire_on_which_the_sun_never_sets
>> ;-))
>>
>> > If you do want to rehash the cryptowars debate again,
>>
>> Not at all. But for example enterprises often use HTTPs proxies
>> for firewalling, intrusion detection, proprietary data leakage
>> prevention and the like. I am not aware we have stablished standards
>> for such desirable behavior. In fact there are issues with the expected
>> end-to-end krypto security when you bring in such trusted middle-men.
>> (e.g.: undesirable cert spoofing). There are no browser standards
>> for a three party trust-model AFAIK.
>>
>> Right now, we have only those global commercial players positioning
>> them as trusted third parties. Even DoH IMHO falls into this play.
>> And then selling customer data collected, at least when they have
>> some entity operating outside europe (GDPR data leakage prevention).
>>
>> All those IoT devices that export unbeknownst do the user all type
>> of collected user data to a cloud. We could come up with mandatory
>> published data models, force the connection through a trusted third
>> party device that can then do semantic filtering. Aka: i rather
>> want to be able to control than just trust GDPR statements.
>>
>> Likewise i think we could define better behaving firewall policies
>> in the fashion did it for NAT with BEHAVE, e.g.: more visibility
>> of policy for better diagnostics.
>>
>> Etc. pp. Just brainstorm what positive evolution we could promote
>> through IETF work for more security. The IETF end-to-end encryption
>> laurels nice but not enough.
>>
>> > maybe at least change the subject line? If doing so,
>> > and I hope you decide not to, because there's no gain,
>> > please recognise that there are many (me included) who
>> > do not share the views you quoted for sound technical
>> > reasons (e.g. [1] is perhaps the most-cited recent
>> > paper on that) that have garnered rough consensus in
>> > the IETF every time we've done that rehashing.
>>
>> Stating that we would like to see IETF solve problems doesnt
>> mean we agree to those regurgitated security agency memes.
>> Instead, i see these memes as the real risks, because the
>> public has shown to give in to the ongoing "tough on crime"
>> pounding with really bad outcomes. So we really need better,
>> alternative models for more security in addition to the
>> ongoing push back against that type of nonsense.
>>
>> Cheers
>>     Toerless
>>
>> > S.
>> >
>> > [1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
>> > by requiring government access to all data and communications." Journa=
l
>> > of Cybersecurity 1.1 (2015): 69-79.
>> > https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf
>> >
>> >
>> >
>> >
>> >
>>
>> pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <
>> stephen.farrell@cs.tcd.ie>
>> > sub   RSA 4096/36CB8BB6 2017-12-22
>> >
>>
>>
>>
>>
>> > _______________________________________________
>> > 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
>>
>

--000000000000c8573e059f87f438
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

This is the address for Pekka=
 Nikander's "Reflections on Architecture" I mentioned above:<=
/div>



Regard,
Gun=
tur Wiseno Putra

Pada Kamis, 27 Februari 2020, Guntur Wiseno Putra &=
lt;gsenopu@gmail.com> menulis:<=
br>
Dear architecture-discuss,

=

I am struggling to read on what Pekka Nikkander made about "IPv4 =
& IPv6" in "Reflection on Architecture" (2005) where he =
mentioned about the time of architecture-discuss' beginning:
=


(P. Nikander:)


"...Looking at the network of today, I strongly feel the pain of t=
he current architecture=E2=80=99s cracking and squeaking. Consequently, I b=
elieve that we =E2=80=93 the wider IETF community responsible for Internet =
technology =E2=80=93 need to re-think the architecture. We need to find a w=
ay to re-create the core of the Internet in a way that leads to a new era o=
f innovation and intellectual prosperity....



... ( What we perhaps don=E2=80=99t consider very often is the fact that th=
ere are huge asset values embedded in various parts of the network.)As the =
slower-than-expected migration to IPv6 has amply demonstrated, some parts o=
f the current Internet are painfully hard to change. This makes any long-te=
rm architectural thinking and planning difficult.



(While we can at most work towards understanding emergent complexity in the=
 first place, there is a great deal we can do about architectural complexit=
y... )



... We need some kind of an architectural vision and a related transition p=
ath; an idea of where we are heading and perhaps how we could get there.


My vision includes peaceful co-existence of both IPv4 and IPv6 for a fairly=
 long time to come. While I would like to see a day when the last IPv4 node=
 is shut down, it is more likely that only future generations will see that=
 happening. In my vision it is possible to use any application I want where=
ver I am and whatever kind of connection I may have. Indeed, I imagine bein=
g able to use multiple wireless networks most of the time, and at least one=
 almost always. I dream of once more being able to communicate with anyone,=
 anywhere on the Internet, independent of the application we want to use, n=
ot artificially hindered by NATs or other non-premeditated middle boxes. Fi=
nally, in my vision we have baseline security as a built-in feature of the =
architecture, providing cryptographically strong end-to-end security and su=
fficient hooks for attaching different kinds of security infrastructures, s=
ome based on organisational management and some based on grassroots attempt=
s to model interpersonal human trust relationships with decentralised autho=
risation systems.



It looks very likely that fulfilling my vision requires adding a new layer,=
 a new =E2=80=9Cwaist=E2=80=9D, to the architecture [7]. We have to impleme=
nt mobility, multi-homing, and the envisioned baseline security somewhere i=
n the stack. If we want connectivity to span the partition between IPv4 and=
 IPv6 networks, it looks necessary to build the functionality on the top of=
 the existing hop-by-hop functionality of the IP layer....



(Once we start to consider how to introduce the changes needed to progress =
towards any vision, it becomes apparent that the two hardest-to-change asse=
ts are the existing routing infrastructure and the set of all existing appl=
ications. But network transparency is exactly what we should re-establish..=
.)



Using a term that Brian Carpenter recently coined, I propose that we aim at=
 providing new Architected Network Transparency (ANT). There seem to be thr=
ee or four potential migration paths towards ANT. One possibility is to uti=
lise a Cryptographically Generated Addresses (CGA) [8] based security model=
 in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to provide en=
d-to-end security and mobility even when IPv6 traffic is shimmed....



... (Toward the ANT) One possible means might be Keyed Hash Identifiers (KH=
I, pronounced as the Greek letter ?) [14], currently subject to heated deba=
te in the int-area and ipv6 mailing lists. Whether KHIs should be considere=
d as an important but transitory stepping stone or as despicable opening of=
 the flood gates to occupy the IPv6 address space with varmints remains to =
be seen.



...".










=
Regard,
Guntur Wiseno Putra

Pada Kamis, 27 Februari 2020, =
Toerless Eckert <tte@=
cs.fau.de> menulis:
On Wed, Feb 26=
, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:

> On 26/02/2020 10:21, Stewart Bryant wrote:

> > "The head of MI5 has urged technology companies to give the =
security

> > services =C3=A2?????exceptional=C3=A2???=C2=A0 access to encrypte=
d messages 

> 

> And in other, equally shocking, news: the sun will rise tomorrow;-)


https://en.wikipedia.org/wiki/The_empire_on_wh=
ich_the_sun_never_sets

;-))



> If you do want to rehash the cryptowars debate again,



Not at all. But for example enterprises often use HTTPs proxies

for firewalling, intrusion detection, proprietary data leakage

prevention and the like. I am not aware we have stablished standards

for such desirable behavior. In fact there are issues with the expected

end-to-end krypto security when you bring in such trusted middle-men.

(e.g.: undesirable cert spoofing). There are no browser standards

for a three party trust-model AFAIK.



Right now, we have only those global commercial players positioning

them as trusted third parties. Even DoH IMHO falls into this play.

And then selling customer data collected, at least when they have

some entity operating outside europe (GDPR data leakage prevention).



All those IoT devices that export unbeknownst do the user all type

of collected user data to a cloud. We could come up with mandatory

published data models, force the connection through a trusted third

party device that can then do semantic filtering. Aka: i rather

want to be able to control than just trust GDPR statements.



Likewise i think we could define better behaving firewall policies

in the fashion did it for NAT with BEHAVE, e.g.: more visibility

of policy for better diagnostics.



Etc. pp. Just brainstorm what positive evolution we could promote

through IETF work for more security. The IETF end-to-end encryption

laurels nice but not enough.



> maybe at least change the subject line? If doing so,

> and I hope you decide not to, because there's no gain,

> please recognise that there are many (me included) who

> do not share the views you quoted for sound technical

> reasons (e.g. [1] is perhaps the most-cited recent

> paper on that) that have garnered rough consensus in

> the IETF every time we've done that rehashing.



Stating that we would like to see IETF solve problems doesnt

mean we agree to those regurgitated security agency memes.

Instead, i see these memes as the real risks, because the

public has shown to give in to the ongoing "tough on crime"

pounding with really bad outcomes. So we really need better,

alternative models for more security in addition to the

ongoing push back against that type of nonsense.



Cheers

=C2=A0 =C2=A0 Toerless



> S.

> 

> [1] Abelson, Harold, et al. "Keys under doormats: mandating insec=
urity

> by requiring government access to all data and communications." J=
ournal

> of Cybersecurity 1.1 (2015): 69-79.

> https://www.cs.yale.edu/homes/jf/paper-ke=
ys-under-doormats-CSAIL.pdf

> 

> 

> 

> 

> 



pub=C2=A0 =C2=A0RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell=
@cs.tcd.ie>

> sub=C2=A0 =C2=A0RSA 4096/36CB8BB6 2017-12-22

> 









> _______________________________________________

> Architecture-discuss mailing list

> Arc=
hitecture-discuss@ietf.org

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss





-- 

---

tte@cs.fau.de



_______________________________________________

Architecture-discuss mailing list

Architec=
ture-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/architecture-discu=
ss






--000000000000c8573e059f87f438--


From nobody Thu Feb 27 13:42:59 2020
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 8E3313A0C94; Thu, 27 Feb 2020 13:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA98Lh4dU2uf; Thu, 27 Feb 2020 13:42:55 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6213A0C95; Thu, 27 Feb 2020 13:42:54 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CE95180BF1; Thu, 27 Feb 2020 22:42:50 +0100 (CET)
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
To: "'ietf@ietf.org'" , Internet Architecture Board , Internet Area 
Cc: Suresh Krishnan , architecture-discuss@iab.org
From: Fernando Gont 
X-Forwarded-Message-Id: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
Message-ID: <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
Date: Thu, 27 Feb 2020 18:42:42 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 21:42:58 -0000

Folks,

If you haven't been following recent developments in the Spring WG, you 
may be surprised about some of the work that is being pursued (or was 
being pursued)-

Such work has included proposing that some IPv6 routers insert and 
remove routing headers en-route to the final destination.

After many very heated and lengthy debates, some of this work was 
dropped, but other remains (e.g. routers removing IPv6 EHs from packets 
en-route to their final destination, part of what they call "PSP"). For 
the most part, the proponents have argued that "we have implemented it, 
and the industry wants it" -- as if we just have to rubberstamp what 
they have done.

On the technical side, the proponents have argued that:

     If a packet employs source routing (and hence its Destination
     Address is modified en-route to direct the packet through each
     of these "waypoints"), then any of such "waypoint" routers are
     free to add or remove IPv6 extension headers at will. (No, not
     encap/decap, but rather add/remove EHs from the IPv6 header
     chain).

That seems to me like a very major deviation from what's supposed to be 
our current "architecture", where IPv6 is an end to end protocol. 
Besides, it should be obvious that removal/insertion of EHs en-route 
error reporting (since host typically check that the ICMP errors they 
receive correspond to something that they actually sent).


A number of us have raised this a number of times, and at least some of 
us feel that our concerns are being ignored.

It would seem to me that these documents and decisions have a concrete 
impact on our architecture, and that they are being pursued without any 
proper oversight. There is also a widespread feeling that having one or 
a few big vendors pushing these ideas might be playing a role here.

(See, for instance:

* https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/

* https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
)

What I would expect is that all thes major changes to our existing 
architecture and protocols would only done by formally updating existing 
standards *if* deemed appropriate, as opposed to just trying to sneak 
changes "when nobody is watching", or by having very curious 
interpretations of our protocols and standards.

I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d 
list before, but so far haven't been lucky or seen anything meaningful 
happen in this area.

I have also submitted an errata to make RFC8200 even more clear on the 
topic, but it remains unprocessed.

So my questions are:

* On the technical area:

  + Is IPv6 an End To End protocol?  Or is the IETF's stance that 
routers are free to mangle with the packet structure as they please?

  + Was IPv6 designed that way? And if it wasn't, when/how was the 
architecture changed?


* On the procedural area:

   + Where/how should IETF WGs seek for architecture-related advice?

   + What do do in situations like the above?  Wait and see how things
     evolve, and upon any formal decisions, just submit formal Appeals
     if deemed necessary?  (and after way too much energy consumed from
     everyone)

     I would have expected that as soon as these issues were raised,
     the offending text would be removed rightaway. But that wasn't
     the case. And when the changes did happen, it wasn't without
     an extraordinary waste of time and energy from all of us.
     For instance, any work on IPv6 header insertion/deletion wouldn't
     seem to fit within the charters of the 6man or spring wgs.


     FWIW, this is not the first instance of issues surrounding the same
     topic. It goes back to the rfc2460bis effort, when a similar set of
     folks (too many from one big vendor) got to have 6man ship
     what became RFC8200 with a noted "ambiguity", just to be able
     to have some playground for EH insertion/deletion. And we only got
     to improve on that during IETF LC:

    (see: 
https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)


Thoughts or advice on the technical and/or procedural aspects will be 
appreciated.

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: Errata #5933 for RFC8200
Date: Thu, 27 Feb 2020 17:07:36 -0300
From: Fernando Gont 
To: Suresh Krishnan 
CC: 6man@ietf.org <6man@ietf.org>

Suresh,

Two months ago I filled an errata on RFC8200 regarding the processing of 
IPv6 extension headers. The errata is available here: 
https://www.rfc-editor.org/errata/eid5933

While I believe that folks with a knowledge of Internet Protocols would 
be able to interpret what is in RFC8200, given recent discussions on the 
topic, and upon a re-read of the text, I believe a clarification is 
warranted, such that we allow all sorts of curious interpretations of 
the text.

I send a heads-up on the 6man mailing list 
(https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), 
and the proposed text received the review of at least Brian Carpenter, 
Ron Bonica, and Mark Smith. Their reviews are available on such thread.

In the light that some folks seem to be pretending to leverage "the lack 
of clarify" in RFC8200 (an Internet Standard) to violate it, I'd 
appreciate that the reported errata be processed.

Processing the aforementioned errata is key to many of the discussions 
this and other WGs are having.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 14:07:51 2020
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 0C32A3A0D60 for ; Thu, 27 Feb 2020 14:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.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 zqND5l8GEpvo for ; Thu, 27 Feb 2020 14:07:47 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 0EB453A0D5D for ; Thu, 27 Feb 2020 14:07:47 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id t7so926197edr.4 for ; Thu, 27 Feb 2020 14:07:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gtaCzPNatFatNGHtsYfFZYlBn7leRTn7/ueo3rL75aY=; b=eNB7IMlgdv+a9c/Q61OOnTUBHiF+wn2K+09q9tipWQ+nuDYpFUgJOVXOW/eT5IWKLN bl6+8TXd99/5g+kzFgBOGdof6CKI0zHOCJ0OBpEeJl8solw01jwdRMndEzmpVW/Jkc1N Qz3hZu1+LpxZYjZnxu/sQ94LEHhj6QLESNLPbPRd0UiiDpLEecWau1sTmMwols7dnW+R W5N50Me/z4Elkk/TWy3l5Go8QvwuXPQzQ8SEvaiC/3QCCmytckubAnFFe7qXf+ecuuwL o6DhO9jbkg5wGk87QWT63kH3vxJ4a7UjIchBJUokPgbHldfgX3bZ4xvWiJiG6Wxe4pzX QaAQ==
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=gtaCzPNatFatNGHtsYfFZYlBn7leRTn7/ueo3rL75aY=; b=tMnkjxBjqrqLG+8nrp0BpaLltQITUJItEjFbuOrcDRjvPWLST2HLXOS+pvYhD48n2+ NxajRUvyKYIVkmtXNWbCGRAc2m2dv2FqnpPwhW84tQ1VJjpsf/+2Zzj2ZMq8qvUtj6ur Pdd8G2Q6r9l9O9W2NZclEP/tBODAp7kXtfekAqjIkKqSv/f+H5ikwPA16qpICLfoEFyL FpGquVaqh9FequRrxACR/BbRtzPNnf5sk0jdwyhUpNFYMaNgtiqChqGB2c7UD98ZIV8T foHkmecLswwMzkVPXwJHRWTMB8kXRloj9iZaM1goVF6BAZYoJLOXEvtgobQPJkOBSQmy FAJg==
X-Gm-Message-State: APjAAAWe9J+6RJw9/dxMgkDH5oKodRXk8hGMfi48U87zR5ymOmCe2dEE Qqv2kcCHNbjUKoOMKQwyofJ3W1IoqTTvBxXLRxSRQQ==
X-Google-Smtp-Source: APXvYqw1WBrsgdCUzoDt9RClPlKtOlzkEg0VekjqRvuv+jC8U015UnBEnCWX+a6pzHyqeB2B4mbIwWUuITwXOWVNNe4=
X-Received: by 2002:a17:906:4b10:: with SMTP id y16mr1080440eju.304.1582841265095;  Thu, 27 Feb 2020 14:07:45 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
In-Reply-To: <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
From: Tom Herbert 
Date: Thu, 27 Feb 2020 14:07:33 -0800
Message-ID: 
To: Fernando Gont 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:07:49 -0000

Fernando,

I think we need to be careful that IETF is labeled as a collection of
inflexible architectural purists. We know that standards conformance
is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own
purposes. IMO extension header insertion is a great example of that.
On one hand we have people quoting IPv6 saying that it isn't allowed
per RFC8200-- period! And on other side there are proponents that see
a real need for it and believe they have clear use case-- at one
presentation in IETF a proponent bluntly stated that regardless of any
discussion in IETF they're going to do it! IMO, what we haven't seen,
was a real attempt to resolve and work out the engineering issues.
That's not for lack of trying-- for instance I proposed a direction to
try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
but saw little discussion on that.

Tom

On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote:
>
> Folks,
>
> If you haven't been following recent developments in the Spring WG, you
> may be surprised about some of the work that is being pursued (or was
> being pursued)-
>
> Such work has included proposing that some IPv6 routers insert and
> remove routing headers en-route to the final destination.
>
> After many very heated and lengthy debates, some of this work was
> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
> en-route to their final destination, part of what they call "PSP"). For
> the most part, the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done.
>
> On the technical side, the proponents have argued that:
>
>      If a packet employs source routing (and hence its Destination
>      Address is modified en-route to direct the packet through each
>      of these "waypoints"), then any of such "waypoint" routers are
>      free to add or remove IPv6 extension headers at will. (No, not
>      encap/decap, but rather add/remove EHs from the IPv6 header
>      chain).
>
> That seems to me like a very major deviation from what's supposed to be
> our current "architecture", where IPv6 is an end to end protocol.
> Besides, it should be obvious that removal/insertion of EHs en-route
> error reporting (since host typically check that the ICMP errors they
> receive correspond to something that they actually sent).
>
>
> A number of us have raised this a number of times, and at least some of
> us feel that our concerns are being ignored.
>
> It would seem to me that these documents and decisions have a concrete
> impact on our architecture, and that they are being pursued without any
> proper oversight. There is also a widespread feeling that having one or
> a few big vendors pushing these ideas might be playing a role here.
>
> (See, for instance:
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
> )
>
> What I would expect is that all thes major changes to our existing
> architecture and protocols would only done by formally updating existing
> standards *if* deemed appropriate, as opposed to just trying to sneak
> changes "when nobody is watching", or by having very curious
> interpretations of our protocols and standards.
>
> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
> list before, but so far haven't been lucky or seen anything meaningful
> happen in this area.
>
> I have also submitted an errata to make RFC8200 even more clear on the
> topic, but it remains unprocessed.
>
> So my questions are:
>
> * On the technical area:
>
>   + Is IPv6 an End To End protocol?  Or is the IETF's stance that
> routers are free to mangle with the packet structure as they please?
>
>   + Was IPv6 designed that way? And if it wasn't, when/how was the
> architecture changed?
>
>
> * On the procedural area:
>
>    + Where/how should IETF WGs seek for architecture-related advice?
>
>    + What do do in situations like the above?  Wait and see how things
>      evolve, and upon any formal decisions, just submit formal Appeals
>      if deemed necessary?  (and after way too much energy consumed from
>      everyone)
>
>      I would have expected that as soon as these issues were raised,
>      the offending text would be removed rightaway. But that wasn't
>      the case. And when the changes did happen, it wasn't without
>      an extraordinary waste of time and energy from all of us.
>      For instance, any work on IPv6 header insertion/deletion wouldn't
>      seem to fit within the charters of the 6man or spring wgs.
>
>
>      FWIW, this is not the first instance of issues surrounding the same
>      topic. It goes back to the rfc2460bis effort, when a similar set of
>      folks (too many from one big vendor) got to have 6man ship
>      what became RFC8200 with a noted "ambiguity", just to be able
>      to have some playground for EH insertion/deletion. And we only got
>      to improve on that during IETF LC:
>
>     (see:
> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>
>
> Thoughts or advice on the technical and/or procedural aspects will be
> appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: Errata #5933 for RFC8200
> Date: Thu, 27 Feb 2020 17:07:36 -0300
> From: Fernando Gont 
> To: Suresh Krishnan 
> CC: 6man@ietf.org <6man@ietf.org>
>
> Suresh,
>
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> https://www.rfc-editor.org/errata/eid5933
>
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
>
> I send a heads-up on the 6man mailing list
> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
>
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area


From nobody Thu Feb 27 14:15:57 2020
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 486643A0D77; Thu, 27 Feb 2020 14:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIdb92QNG4CY; Thu, 27 Feb 2020 14:15:53 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41A43A0D7D; Thu, 27 Feb 2020 14:15:52 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AAB9182D4D; Thu, 27 Feb 2020 23:15:49 +0100 (CET)
To: Tom Herbert 
Cc: architecture-discuss@iab.org, Internet Architecture Board , Internet Area , "ietf@ietf.org" 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> 
From: Fernando Gont 
Message-ID: <236c3aa7-71c1-ae96-3063-991d55d65d34@si6networks.com>
Date: Thu, 27 Feb 2020 19:15:42 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:15:55 -0000

Tom,

If you read my email carefully, I said:

    What I would expect is that all these major changes to our existing
    architecture and protocols would only done by formally updating
    existing standards *if* deemed appropriate, as opposed to just trying
    to sneak changes "when nobody is watching", or by having very curious
    interpretations of our protocols and standards.

That's not an argument against formally changing a spec.

But it *is* an argument against:

   * Violating specs at ill

   * Changing specs while pretending you don't

   * Applying major changes to the architecture without proper oversight.

Thanks,
Fernando




On 27/2/20 19:07, Tom Herbert wrote:
> Fernando,
> 
> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists. We know that standards conformance
> is voluntary and we haven't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes. IMO extension header insertion is a great example of that.
> On one hand we have people quoting IPv6 saying that it isn't allowed
> per RFC8200-- period! And on other side there are proponents that see
> a real need for it and believe they have clear use case-- at one
> presentation in IETF a proponent bluntly stated that regardless of any
> discussion in IETF they're going to do it! IMO, what we haven't seen,
> was a real attempt to resolve and work out the engineering issues.
> That's not for lack of trying-- for instance I proposed a direction to
> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
> but saw little discussion on that.
> 
> Tom
> 
> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote:
>>
>> Folks,
>>
>> If you haven't been following recent developments in the Spring WG, you
>> may be surprised about some of the work that is being pursued (or was
>> being pursued)-
>>
>> Such work has included proposing that some IPv6 routers insert and
>> remove routing headers en-route to the final destination.
>>
>> After many very heated and lengthy debates, some of this work was
>> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
>> en-route to their final destination, part of what they call "PSP"). For
>> the most part, the proponents have argued that "we have implemented it,
>> and the industry wants it" -- as if we just have to rubberstamp what
>> they have done.
>>
>> On the technical side, the proponents have argued that:
>>
>>       If a packet employs source routing (and hence its Destination
>>       Address is modified en-route to direct the packet through each
>>       of these "waypoints"), then any of such "waypoint" routers are
>>       free to add or remove IPv6 extension headers at will. (No, not
>>       encap/decap, but rather add/remove EHs from the IPv6 header
>>       chain).
>>
>> That seems to me like a very major deviation from what's supposed to be
>> our current "architecture", where IPv6 is an end to end protocol.
>> Besides, it should be obvious that removal/insertion of EHs en-route
>> error reporting (since host typically check that the ICMP errors they
>> receive correspond to something that they actually sent).
>>
>>
>> A number of us have raised this a number of times, and at least some of
>> us feel that our concerns are being ignored.
>>
>> It would seem to me that these documents and decisions have a concrete
>> impact on our architecture, and that they are being pursued without any
>> proper oversight. There is also a widespread feeling that having one or
>> a few big vendors pushing these ideas might be playing a role here.
>>
>> (See, for instance:
>>
>> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>>
>> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
>> )
>>
>> What I would expect is that all thes major changes to our existing
>> architecture and protocols would only done by formally updating existing
>> standards *if* deemed appropriate, as opposed to just trying to sneak
>> changes "when nobody is watching", or by having very curious
>> interpretations of our protocols and standards.
>>
>> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
>> list before, but so far haven't been lucky or seen anything meaningful
>> happen in this area.
>>
>> I have also submitted an errata to make RFC8200 even more clear on the
>> topic, but it remains unprocessed.
>>
>> So my questions are:
>>
>> * On the technical area:
>>
>>    + Is IPv6 an End To End protocol?  Or is the IETF's stance that
>> routers are free to mangle with the packet structure as they please?
>>
>>    + Was IPv6 designed that way? And if it wasn't, when/how was the
>> architecture changed?
>>
>>
>> * On the procedural area:
>>
>>     + Where/how should IETF WGs seek for architecture-related advice?
>>
>>     + What do do in situations like the above?  Wait and see how things
>>       evolve, and upon any formal decisions, just submit formal Appeals
>>       if deemed necessary?  (and after way too much energy consumed from
>>       everyone)
>>
>>       I would have expected that as soon as these issues were raised,
>>       the offending text would be removed rightaway. But that wasn't
>>       the case. And when the changes did happen, it wasn't without
>>       an extraordinary waste of time and energy from all of us.
>>       For instance, any work on IPv6 header insertion/deletion wouldn't
>>       seem to fit within the charters of the 6man or spring wgs.
>>
>>
>>       FWIW, this is not the first instance of issues surrounding the same
>>       topic. It goes back to the rfc2460bis effort, when a similar set of
>>       folks (too many from one big vendor) got to have 6man ship
>>       what became RFC8200 with a noted "ambiguity", just to be able
>>       to have some playground for EH insertion/deletion. And we only got
>>       to improve on that during IETF LC:
>>
>>      (see:
>> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>>
>>
>> Thoughts or advice on the technical and/or procedural aspects will be
>> appreciated.
>>
>> Thanks!
>>
>> Cheers,
>> Fernando
>>
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: Errata #5933 for RFC8200
>> Date: Thu, 27 Feb 2020 17:07:36 -0300
>> From: Fernando Gont 
>> To: Suresh Krishnan 
>> CC: 6man@ietf.org <6man@ietf.org>
>>
>> Suresh,
>>
>> Two months ago I filled an errata on RFC8200 regarding the processing of
>> IPv6 extension headers. The errata is available here:
>> https://www.rfc-editor.org/errata/eid5933
>>
>> While I believe that folks with a knowledge of Internet Protocols would
>> be able to interpret what is in RFC8200, given recent discussions on the
>> topic, and upon a re-read of the text, I believe a clarification is
>> warranted, such that we allow all sorts of curious interpretations of
>> the text.
>>
>> I send a heads-up on the 6man mailing list
>> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
>> and the proposed text received the review of at least Brian Carpenter,
>> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>>
>> In the light that some folks seem to be pretending to leverage "the lack
>> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
>> appreciate that the reported errata be processed.
>>
>> Processing the aforementioned errata is key to many of the discussions
>> this and other WGs are having.
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 14:26:50 2020
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 417493A0DB9; Thu, 27 Feb 2020 14:26:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GEvSH2u1dKTi; Thu, 27 Feb 2020 14:26:40 -0800 (PST)
Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 E931C3A0DA8; Thu, 27 Feb 2020 14:26:39 -0800 (PST)
Received: by mail-oi1-f175.google.com with SMTP id a22so857261oid.13; Thu, 27 Feb 2020 14:26:39 -0800 (PST)
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=9h7/lIhhMUv046gjtf7O1EogUgXcI6IToxDY6cEU0CM=; b=SwNFQbh1rs72PIDUT9mwsSOcpz/x6M685L36APQVWeDABYnYmNp1F3k/5/1170Pt3P 5LaNaIkQ1HZWVxjDOYTqgBgGTMZv3LeV8Y9O0VcvMD0CAiGfLSPGUyvN374yXRR/vmib aQsxv9z0evhPwAe/qRYXSDW265UmTZuy2ow/Nggy/rnf0GuEeR3yAytCup7PAbeWkjZJ wdI3KzwoZq9G+WZ5yN9P+dObjjQPlUOs1h2vpaJLPey/McY4MThp9+5tSEYxF9WMMFV9 QlvDyCKk/iGZLwVSdXnK60/KIF0XW8UaFMeglBWdcWV5YB73DELPRYLDjT/HQ+hf/umU dCxw==
X-Gm-Message-State: APjAAAUu62tRAhPWhRDXQ4ZsvX5rVRjnriqJO+AUo0r5+6/iSVoljgHk tHejEiN2gkHYaC32zAytt8wA3fv/iGmbJBUOLHE=
X-Google-Smtp-Source: APXvYqyfBgmk4vkP/QeV7MzebaEzntssxEe/37jiLwxJSi4Xf8IhsMfs1CE8qHOV8X/OssRFAvBe1+ZxP+nhcdnmVvI=
X-Received: by 2002:aca:5646:: with SMTP id k67mr976977oib.166.1582842399252;  Thu, 27 Feb 2020 14:26:39 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> 
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Thu, 27 Feb 2020 17:26:28 -0500
Message-ID: 
To: Tom Herbert 
Cc: Fernando Gont , architecture-discuss@iab.org,  Internet Architecture Board , Internet Area ,  "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000f16749059f963642"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:26:42 -0000

--000000000000f16749059f963642
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:

> Fernando,
>
> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists. We know that standards conformance
> is voluntary and we haven't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes.
>

IP end to end does not mean the IP address is constant end to end. It never
has meant that and never will. An IP address is merely a piece of data that
allows a packet to reach its destination. There is no reason to insist on
it remaining constant along the path.

The sooner people get over that fact the better.

If an IPv4 device interacts with an IPv6 device, there will be address
translation going on somewhere along the path. That is inevitable.

We discovered that there were good reasons for NATing IPv4 besides address
multiplexing. The topology of my network is none of your business.

More generally, Internet standards only apply to the Inter-net, the network
of networks. What happens inside the networks at either end is for the
owners of those networks to decide. If we go back to the original Internet
design, they didn't even need to run IP. IP end to end come later.

So let us stop being dogmatic about things that don't actually matter. The
only job of the network layer is to get packets from one end to another.
The only job of the transport layer is to provide reliable streams. An
application protocol that depends on the IP address remaining constant end
to end is a bad protocol and should be rejected.

--000000000000f16749059f963642
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <tom@herbertland.com> wrote:
Fernando,



I think we need to be careful that IETF is labeled as a collection of

inflexible architectural purists. We know that standards conformance

is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own

purposes.

IP end to end does not mean the IP address is constant=
 end to end. It never has meant that and never will. An IP address is merel=
y a piece of data that allows a packet to reach=C2=A0its destination. There=
 is no reason to insist on it remaining constant along the path.=C2=A0

The sooner people get over th=
at fact the better.

If an=
 IPv4 device interacts with an IPv6 device, there will be address translati=
on going on somewhere along the path. That is inevitable.

We discovered that there were good reaso=
ns for NATing IPv4 besides address multiplexing. The topology of my network=
 is none of your business.

More generally, Internet standards only apply to the Inter-net, the netwo=
rk of networks. What happens inside the networks at either end is for the o=
wners of those networks to decide. If we go back to the original Internet d=
esign, they didn't even need to run IP. IP end to end come later.
=


So let us stop being dogmatic =
about things that don't actually matter. The only job of the network la=
yer is to get packets from one end to another. The only job of the transpor=
t layer is to provide reliable streams. An application protocol that depend=
s on the IP address remaining constant end to end is a bad protocol and sho=
uld be rejected.=C2=A0


--000000000000f16749059f963642--


From nobody Thu Feb 27 14:39:14 2020
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 732093A0E03 for ; Thu, 27 Feb 2020 14:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 gIk7yvL89ufT for ; Thu, 27 Feb 2020 14:39:01 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 87D613A0DF8 for ; Thu, 27 Feb 2020 14:39:01 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id z9so805561oth.5 for ; Thu, 27 Feb 2020 14:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SmUTW7Z2h3ARbhYjGHJAEQc60+9tHYMMvHeofwXPJCA=; b=COcD6ymZ7EYy3We62TG6KAs9G7VdoIikOdSo1XDKhxLZTrBLq6LuWkRxgz76Biw6Cj GCNvXnTn9jigtZl9TuOmWG+TUF5quY/qxSbGVOMLTy7h4ZbqaJyiNhQGZ/hRdG9/Q/QE NBCoKcagkRusWjmKZj8V8hXyD6eVWOsSYeqH0+3j+KGr7fb7ra5S1GHGn3n5aXGrjd4d H7ZlzWYJ78kKFddwCYt4K9LUV/nmvtL6GExR4VcOQOMsBIkvUNsUCickzEUSd3ACzn4l xynSn4MHJe5dBsntVvYxdULcuOlU6BaeWe33wk2WvWMTFJi4PnwkYWr0KvTq5SSXh3lS CsgQ==
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=SmUTW7Z2h3ARbhYjGHJAEQc60+9tHYMMvHeofwXPJCA=; b=V0nue8AOEB5OrqR1owKVrjUuRiHxaQ86Fe8qW9lKb/lF1LwITAmemfA/iDimoE4gHn E0lJVfWdIr9InQtO9YoXuhw0tDaOPduG6KytiS1dS+jyu7HmzKyONUdX4ncOi+ebOBG8 wB1nOBZYRkDu/l9LlHDJ6BszExFq5HDA0ACB0JrXL3Prmb//hOLEebG41Ra0MjKAA2UL xTxdmpba2HyPf0U+ZhKuVL7vYxXa/hQZ8eBg9jw/lsk+nJIHGI8Se+TT5jFKEnFccEFt kN9rnF0cP22sjji2lMKHv4cfqXdP1ES4LN+l0lBMcP4TCEGxbfUyBbCJ+27tJBUDyFcs DBnQ==
X-Gm-Message-State: APjAAAWtDpfP4tF2GQ51z59fhmFWUTkJ/pHxE9wpTtW7kOHeGdK8PfbN 0en4qBxXy6uzRODsFGfZ7p1u2vs+fR+m6c52ByIU/g==
X-Google-Smtp-Source: APXvYqw7UhcIWE5g+da/lKL6D8daxOk4BmcrrtciEcUVvJTqmXqPnlG3bzxc+vRG14hFMPTFOUsDrBte9xdo/4rKEvg=
X-Received: by 2002:a9d:6a4f:: with SMTP id h15mr971985otn.86.1582843140870; Thu, 27 Feb 2020 14:39:00 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
In-Reply-To: 
From: Robert Raszuk 
Date: Thu, 27 Feb 2020 23:38:50 +0100
Message-ID: 
To: Phillip Hallam-Baker 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000025a5f9059f96639a"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:39:05 -0000

--00000000000025a5f9059f96639a
Content-Type: text/plain; charset="UTF-8"

This below note deserves to be printed and framed ! Spot on.



On Thu, Feb 27, 2020 at 11:26 PM Phillip Hallam-Baker 
wrote:

> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:
>
>> Fernando,
>>
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
>>
>
> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will. An IP address is merely a piece of
> data that allows a packet to reach its destination. There is no reason to
> insist on it remaining constant along the path.
>
> The sooner people get over that fact the better.
>
> If an IPv4 device interacts with an IPv6 device, there will be address
> translation going on somewhere along the path. That is inevitable.
>
> We discovered that there were good reasons for NATing IPv4 besides address
> multiplexing. The topology of my network is none of your business.
>
> More generally, Internet standards only apply to the Inter-net, the
> network of networks. What happens inside the networks at either end is for
> the owners of those networks to decide. If we go back to the original
> Internet design, they didn't even need to run IP. IP end to end come later.
>
> So let us stop being dogmatic about things that don't actually matter. The
> only job of the network layer is to get packets from one end to another.
> The only job of the transport layer is to provide reliable streams. An
> application protocol that depends on the IP address remaining constant end
> to end is a bad protocol and should be rejected.
>

--00000000000025a5f9059f96639a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This below note deserves to be printed and framed ! Spot o=
n.=C2=A0



=

On Thu, Feb 27, 2020 at 11:26 PM Phil=
lip Hallam-Baker <phill@hallamb=
aker.com> wrote:
On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <tom@herbertland.com=
> wrote:
Fernando,



I think we need to be careful that IETF is labeled as a collection of

inflexible architectural purists. We know that standards conformance

is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own

purposes.

IP end to end does not mean the IP address is constant=
 end to end. It never has meant that and never will. An IP address is merel=
y a piece of data that allows a packet to reach=C2=A0its destination. There=
 is no reason to insist on it remaining constant along the path.=C2=A0

The sooner people get over th=
at fact the better.

If an=
 IPv4 device interacts with an IPv6 device, there will be address translati=
on going on somewhere along the path. That is inevitable.

We discovered that there were good reaso=
ns for NATing IPv4 besides address multiplexing. The topology of my network=
 is none of your business.

More generally, Internet standards only apply to the Inter-net, the netwo=
rk of networks. What happens inside the networks at either end is for the o=
wners of those networks to decide. If we go back to the original Internet d=
esign, they didn't even need to run IP. IP end to end come later.
=


So let us stop being dogmatic =
about things that don't actually matter. The only job of the network la=
yer is to get packets from one end to another. The only job of the transpor=
t layer is to provide reliable streams. An application protocol that depend=
s on the IP address remaining constant end to end is a bad protocol and sho=
uld be rejected.=C2=A0




--00000000000025a5f9059f96639a--


From nobody Thu Feb 27 14:43:36 2020
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 DEB763A0E1E; Thu, 27 Feb 2020 14:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 cDTG9qcTjhLb; Thu, 27 Feb 2020 14:43:23 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 4D70C3A0E13; Thu, 27 Feb 2020 14:43:23 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id l6so272282uap.13; Thu, 27 Feb 2020 14:43:23 -0800 (PST)
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=4UWsU51O8TShrz2ebd28SjFROF/LPOVigmattsWqhCE=; b=mA5Rn4x8swCLe0asV/ioL2SHl1Fi7s0/6jp9JTHYIYfDHzco1Oqyjt+EnqaIpyMmM5 wL4MPgOPnVaIRBKjS0UoFLKtG7s6N3k/5H79yBGH5e75tfozFi48X5Tn1V3Gyslcb2KN RRKPwwQDJD2UkfQAJfXSuVvYTmCgLIGD0T0/52fser8F/G/NJHTOGjthRE90wPl+HByy HtZPAKzfciAd+whz0jm3ogcecft0Ivcid0mUxyFJoD+kEJQCs9bDPUD+VykQzOsiNH74 vTcp4B+ogJaYCbkePVA+H/b7arD4Uk+oNCCq+OGQP+BKOVgZRHYuhoEp/OcehoowVuZc AQ+g==
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=4UWsU51O8TShrz2ebd28SjFROF/LPOVigmattsWqhCE=; b=AYENU0WV1VisVrS2AEsX4K6b1SsQFqW35fBiXBFyMSieA0sVwi00aUVLWwUOSNgtP0 7cPk0BPufvXNT96lIHSuFIp+wuYJG5D2rPAW6Xhfi6FDg+dRe980FUBedKAbj7EeBdMo NwiN+dNUmnC9/QRoU3QJ9+fbiuLBOyAFCd8uZMNnP4QHf0MQATFPg/x0u1PpoVxmlA50 UNFv0CPtwQS2mJBMipDsayqXTSZWSzhpc0e/f88sqvHW+57cJb1aXzXRMzzNY+2YKQJk PS2eUNZDgjl46ypeqdQFiXTPhYs60Qb+swocru1/5gNmK2VTWbg+dldUe/qv4cvcOGkN HDxg==
X-Gm-Message-State: ANhLgQ0tHpOQIkpJ8GMSnYGc/UqK/k90y9oEWRijukJAxl+6uA8uJinu RBXBCI3n5dDPx6wx3Dx30Rmg7hNqpgatc4iaQ28=
X-Google-Smtp-Source: ADFU+vsPkwjp/edxHym88hZBldUHZyexfy7Xk/wiME9JyUeBEz808K/U/61B3WaQaEFmQGSGm60J1omdnuFX05mz+fw=
X-Received: by 2002:ab0:2408:: with SMTP id f8mr589863uan.126.1582843402012; Thu, 27 Feb 2020 14:43:22 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
In-Reply-To: <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
From: Bernard Aboba 
Date: Thu, 27 Feb 2020 14:43:10 -0800
Message-ID: 
To: Fernando Gont 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="000000000000b64e00059f96721d"
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:43:27 -0000

--000000000000b64e00059f96721d
Content-Type: text/plain; charset="UTF-8"

Fernando --

"the proponents have argued that "we have implemented it,
and the industry wants it" -- as if we just have to rubberstamp what
they have done."

[BA] The IETF has no enforcement authority, so that vendors have the
ability to ship products implementing IETF standards in whole or in part -
or not at all.  However, it is within the authority of the IETF to define
requirements, and to articulate the implications of behavior that (some
people) might consider undesirable, so as to provide information so that
customers can make their own decisions.

"Besides, it should be obvious that removal/insertion of EHs en-route
error reporting (since host typically check that the ICMP errors they
receive correspond to something that they actually sent)."

[BA] This is an example of a consequence that should be considered. IMHO,
these issues are worth writing up.

Tom said:

"IMO, what we haven't seen, was a real attempt to resolve and work out the
engineering issues."

[BA] In practice, these kind of issues are rarely "resolved" - points of
contention in "Tussle space" go through cycles of
deployment/analysis/reaction.  So sometimes rather than seeking
"compromise" (which may satisfy noone) it is better to put publish both a
majority and a minority opinion.  This approach not only clarifies the
points of debate, but also puts the positions on record for posterity.

On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote:

> Folks,
>
> If you haven't been following recent developments in the Spring WG, you
> may be surprised about some of the work that is being pursued (or was
> being pursued)-
>
> Such work has included proposing that some IPv6 routers insert and
> remove routing headers en-route to the final destination.
>
> After many very heated and lengthy debates, some of this work was
> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
> en-route to their final destination, part of what they call "PSP"). For
> the most part, the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done.
>
> On the technical side, the proponents have argued that:
>
>      If a packet employs source routing (and hence its Destination
>      Address is modified en-route to direct the packet through each
>      of these "waypoints"), then any of such "waypoint" routers are
>      free to add or remove IPv6 extension headers at will. (No, not
>      encap/decap, but rather add/remove EHs from the IPv6 header
>      chain).
>
> That seems to me like a very major deviation from what's supposed to be
> our current "architecture", where IPv6 is an end to end protocol.
> Besides, it should be obvious that removal/insertion of EHs en-route
> error reporting (since host typically check that the ICMP errors they
> receive correspond to something that they actually sent).
>
>
> A number of us have raised this a number of times, and at least some of
> us feel that our concerns are being ignored.
>
> It would seem to me that these documents and decisions have a concrete
> impact on our architecture, and that they are being pursued without any
> proper oversight. There is also a widespread feeling that having one or
> a few big vendors pushing these ideas might be playing a role here.
>
> (See, for instance:
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
> )
>
> What I would expect is that all thes major changes to our existing
> architecture and protocols would only done by formally updating existing
> standards *if* deemed appropriate, as opposed to just trying to sneak
> changes "when nobody is watching", or by having very curious
> interpretations of our protocols and standards.
>
> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
> list before, but so far haven't been lucky or seen anything meaningful
> happen in this area.
>
> I have also submitted an errata to make RFC8200 even more clear on the
> topic, but it remains unprocessed.
>
> So my questions are:
>
> * On the technical area:
>
>   + Is IPv6 an End To End protocol?  Or is the IETF's stance that
> routers are free to mangle with the packet structure as they please?
>
>   + Was IPv6 designed that way? And if it wasn't, when/how was the
> architecture changed?
>
>
> * On the procedural area:
>
>    + Where/how should IETF WGs seek for architecture-related advice?
>
>    + What do do in situations like the above?  Wait and see how things
>      evolve, and upon any formal decisions, just submit formal Appeals
>      if deemed necessary?  (and after way too much energy consumed from
>      everyone)
>
>      I would have expected that as soon as these issues were raised,
>      the offending text would be removed rightaway. But that wasn't
>      the case. And when the changes did happen, it wasn't without
>      an extraordinary waste of time and energy from all of us.
>      For instance, any work on IPv6 header insertion/deletion wouldn't
>      seem to fit within the charters of the 6man or spring wgs.
>
>
>      FWIW, this is not the first instance of issues surrounding the same
>      topic. It goes back to the rfc2460bis effort, when a similar set of
>      folks (too many from one big vendor) got to have 6man ship
>      what became RFC8200 with a noted "ambiguity", just to be able
>      to have some playground for EH insertion/deletion. And we only got
>      to improve on that during IETF LC:
>
>     (see:
> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>
>
> Thoughts or advice on the technical and/or procedural aspects will be
> appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: Errata #5933 for RFC8200
> Date: Thu, 27 Feb 2020 17:07:36 -0300
> From: Fernando Gont 
> To: Suresh Krishnan 
> CC: 6man@ietf.org <6man@ietf.org>
>
> Suresh,
>
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> https://www.rfc-editor.org/errata/eid5933
>
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
>
> I send a heads-up on the 6man mailing list
> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
>
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
>
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

--000000000000b64e00059f96721d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fernando --

"the proponents have a=
rgued that "we have implemented it,
and the industry wants it"=
 -- as if we just have to rubberstamp what
they have done."

[BA] The IETF has no enforcement authority, so that vendo=
rs have the ability to ship products implementing IETF standards in whole o=
r in part - or not at all.=C2=A0 However, it is within the authority of the=
 IETF to define requirements, and to articulate the implications of behavio=
r that (some people) might consider undesirable, so as to provide informati=
on=C2=A0so that customers can make their own decisions.=C2=A0
"Besides, it should be obvious that removal/insertion of E=
Hs en-route
error reporting (since host typically check that the ICMP er=
rors they
receive correspond to something that they actually sent)."=
;

[BA] This is an example of a consequence tha=
t should be considered. IMHO, these issues are worth writing up.=C2=A0

Tom said:=C2=A0

"IMO, wh=
at we haven't seen, was a real attempt to resolve and work out the engi=
neering issues."

[BA] In practice, these kind=
 of issues are rarely "resolved" - points of contention in "=
Tussle space" go through cycles of deployment/analysis/reaction.=C2=A0=
 So sometimes rather than seeking "compromise" (which may satisfy=
 noone) it is better to put publish both a majority and a minority opinion.=
=C2=A0 This approach not only clarifies the points of debate, but also puts=
 the positions on record for posterity.=C2=A0

On Thu, Feb 27, 2020 at =
1:43 PM Fernando Gont <fgont@si=
6networks.com> wrote:
Folks,



If you haven't been following recent developments in the Spring WG, you=
 

may be surprised about some of the work that is being pursued (or was 

being pursued)-



Such work has included proposing that some IPv6 routers insert and 

remove routing headers en-route to the final destination.



After many very heated and lengthy debates, some of this work was 

dropped, but other remains (e.g. routers removing IPv6 EHs from packets 
en-route to their final destination, part of what they call "PSP"=
). For 

the most part, the proponents have argued that "we have implemented it=
, 

and the industry wants it" -- as if we just have to rubberstamp what <=
br>
they have done.



On the technical side, the proponents have argued that:



=C2=A0 =C2=A0 =C2=A0If a packet employs source routing (and hence its Desti=
nation

=C2=A0 =C2=A0 =C2=A0Address is modified en-route to direct the packet throu=
gh each

=C2=A0 =C2=A0 =C2=A0of these "waypoints"), then any of such "=
;waypoint" routers are

=C2=A0 =C2=A0 =C2=A0free to add or remove IPv6 extension headers at will. (=
No, not

=C2=A0 =C2=A0 =C2=A0encap/decap, but rather add/remove EHs from the IPv6 he=
ader

=C2=A0 =C2=A0 =C2=A0chain).



That seems to me like a very major deviation from what's supposed to be=
 

our current "architecture", where IPv6 is an end to end protocol.=
 

Besides, it should be obvious that removal/insertion of EHs en-route 

error reporting (since host typically check that the ICMP errors they 

receive correspond to something that they actually sent).





A number of us have raised this a number of times, and at least some of 
us feel that our concerns are being ignored.



It would seem to me that these documents and decisions have a concrete 

impact on our architecture, and that they are being pursued without any 
proper oversight. There is also a widespread feeling that having one or 
a few big vendors pushing these ideas might be playing a role here.



(See, for instance:



* https://mailarchive.ietf.or=
g/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/



* https://mailarchive.ietf.or=
g/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/

)



What I would expect is that all thes major changes to our existing 

architecture and protocols would only done by formally updating existing 
standards *if* deemed appropriate, as opposed to just trying to sneak 

changes "when nobody is watching", or by having very curious 

interpretations of our protocols and standards.



I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d=
 

list before, but so far haven't been lucky or seen anything meaningful =


happen in this area.



I have also submitted an errata to make RFC8200 even more clear on the 

topic, but it remains unprocessed.



So my questions are:



* On the technical area:



=C2=A0 + Is IPv6 an End To End protocol?=C2=A0 Or is the IETF's stance =
that 

routers are free to mangle with the packet structure as they please?



=C2=A0 + Was IPv6 designed that way? And if it wasn't, when/how was the=
 

architecture changed?





* On the procedural area:



=C2=A0 =C2=A0+ Where/how should IETF WGs seek for architecture-related advi=
ce?



=C2=A0 =C2=A0+ What do do in situations like the above?=C2=A0 Wait and see =
how things

=C2=A0 =C2=A0 =C2=A0evolve, and upon any formal decisions, just submit form=
al Appeals

=C2=A0 =C2=A0 =C2=A0if deemed necessary?=C2=A0 (and after way too much ener=
gy consumed from

=C2=A0 =C2=A0 =C2=A0everyone)



=C2=A0 =C2=A0 =C2=A0I would have expected that as soon as these issues were=
 raised,

=C2=A0 =C2=A0 =C2=A0the offending text would be removed rightaway. But that=
 wasn't

=C2=A0 =C2=A0 =C2=A0the case. And when the changes did happen, it wasn'=
t without

=C2=A0 =C2=A0 =C2=A0an extraordinary waste of time and energy from all of u=
s.

=C2=A0 =C2=A0 =C2=A0For instance, any work on IPv6 header insertion/deletio=
n wouldn't

=C2=A0 =C2=A0 =C2=A0seem to fit within the charters of the 6man or spring w=
gs.





=C2=A0 =C2=A0 =C2=A0FWIW, this is not the first instance of issues surround=
ing the same

=C2=A0 =C2=A0 =C2=A0topic. It goes back to the rfc2460bis effort, when a si=
milar set of

=C2=A0 =C2=A0 =C2=A0folks (too many from one big vendor) got to have 6man s=
hip

=C2=A0 =C2=A0 =C2=A0what became RFC8200 with a noted "ambiguity",=
 just to be able

=C2=A0 =C2=A0 =C2=A0to have some playground for EH insertion/deletion. And =
we only got

=C2=A0 =C2=A0 =C2=A0to improve on that during IETF LC:



=C2=A0 =C2=A0 (see: 

https://mailarchive.ietf.org/=
arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)





Thoughts or advice on the technical and/or procedural aspects will be 

appreciated.



Thanks!



Cheers,

Fernando









-------- Forwarded Message --------

Subject: Errata #5933 for RFC8200

Date: Thu, 27 Feb 2020 17:07:36 -0300

From: Fernando Gont <fgont@si6networks.com>

To: Suresh Krishnan <suresh.krishnan@gmail.com>

CC: 6man@ietf.org &l=
t;6man@ietf.org><=
br>


Suresh,



Two months ago I filled an errata on RFC8200 regarding the processing of 
IPv6 extension headers. The errata is available here: 

https://www.rfc-editor.org/errata/eid5933



While I believe that folks with a knowledge of Internet Protocols would 
be able to interpret what is in RFC8200, given recent discussions on the 
topic, and upon a re-read of the text, I believe a clarification is 

warranted, such that we allow all sorts of curious interpretations of 

the text.



I send a heads-up on the 6man mailing list 

(https://mailarchive.ietf.org=
/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), 

and the proposed text received the review of at least Brian Carpenter, 

Ron Bonica, and Mark Smith. Their reviews are available on such thread.



In the light that some folks seem to be pretending to leverage "the la=
ck 

of clarify" in RFC8200 (an Internet Standard) to violate it, I'd <=
br>
appreciate that the reported errata be processed.



Processing the aforementioned errata is key to many of the discussions 

this and other WGs are having.



Thanks,

-- 

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492









_______________________________________________

Architecture-discuss mailing list

Architec=
ture-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/arc=
hitecture-discuss




--000000000000b64e00059f96721d--


From nobody Thu Feb 27 14:44:59 2020
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 904B63A0E52 for ; Thu, 27 Feb 2020 14:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.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 8DpuCCC4i7yq for ; Thu, 27 Feb 2020 14:44:50 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 8012E3A0E83 for ; Thu, 27 Feb 2020 14:44:49 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id v28so972218edw.12 for ; Thu, 27 Feb 2020 14:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d+rDW+YCmN2UjLk0y/wNj+r8YdJMuca65PH9FF0A/GQ=; b=IjXUKEQxLhhHlzYeBFmaXyjvOfw5pXYkZOPyt4hn0I0ZkLbrUq1l7trb7cBXCW/XXi brXFG9pyd7NW8G3JjARzgXkqwf1ESkEZV95ZEZCi2A9GrsaXD4merBEjUvQUxo/hGrWW rJ8/AB6ZKXr1FEPPZUkIg0EoxwBXSDIvGXz6qcwWY/fc9KQmhOXRtVABVmLa/OxLj3Nj GWORGaSsaH1De7z/qqozMRVjSGv7PfzEVVXyYhQsWQNwWBehixhHqCthpr1+6cYdRRGT x1sresL67smrh7bOmPJbgNV9n3IXuFDoH9VgOQUNM82ZzvSoEVkhGwI32CKNDvtdmru1 atjA==
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=d+rDW+YCmN2UjLk0y/wNj+r8YdJMuca65PH9FF0A/GQ=; b=dohk0tZcU9HkJ4FQn6SKBsFs586TMoA5jnQJVM0ha5tRQvyyWXsMO6dr5r4w3v81aD qhL9a+Yjw6+5Vw5pfu6PY7C0U87IzSruGnpdob9gI0CQs+TFjRbNTUYQAAolq8ZfiYVP RHkisw5vI/9gvufOOPb9QlsNfinzSsWO9mNF0zW7vXTGjHfJhjke2xUDwRotlbzJWbuk 9SQFa/rabOJ4HKlqo+JcoNF3bUJD03He8R2w/e83VBIumHRAPhLlL5tcWugWx67C9ePz r8kHW+SV8F67l8bXo4s1MADu5BeLuwC4F2BHj5B3FsFG6lgWKKcl2pNtMthf2brZz5Qc J/2g==
X-Gm-Message-State: APjAAAXVcjK3GsynVZvoWEmUOmINccVJeJ+iKNRskUfdH1BP5c5fYR2T POFk+JFcX3oRadDcJMVi6+n9RKRIGZ0XqIyiNtZ/6A==
X-Google-Smtp-Source: APXvYqxn3ElbGUgRHzNtVxWZDZMZQg6aZHoNt7wEIFg+Gggz1pYJALmLmmMnuDslWYC+RR6Xm2hTDm7kEpmfWAxdqTE=
X-Received: by 2002:aa7:d1d8:: with SMTP id g24mr797735edp.39.1582843488038; Thu, 27 Feb 2020 14:44:48 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
In-Reply-To: 
From: Tom Herbert 
Date: Thu, 27 Feb 2020 14:44:35 -0800
Message-ID: 
To: Phillip Hallam-Baker 
Cc: Fernando Gont , architecture-discuss@iab.org,  Internet Architecture Board , Internet Area ,  "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d6ffdf059f967731"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:44:57 -0000

--000000000000d6ffdf059f967731
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker 
wrote:

> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:
>
>> Fernando,
>>
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
>>
>
> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will. An IP address is merely a piece of
> data that allows a packet to reach its destination. There is no reason to
> insist on it remaining constant along the path.
>
> The sooner people get over that fact the better.
>
> If an IPv4 device interacts with an IPv6 device, there will be address
> translation going on somewhere along the path. That is inevitable.
>
> We discovered that there were good reasons for NATing IPv4 besides address
> multiplexing. The topology of my network is none of your business.
>
> More generally, Internet standards only apply to the Inter-net, the
> network of networks. What happens inside the networks at either end is for
> the owners of those networks to decide. If we go back to the original
> Internet design, they didn't even need to run IP. IP end to end come later.
>
> So let us stop being dogmatic about things that don't actually matter. The
> only job of the network layer is to get packets from one end to another.
> The only job of the transport layer is to provide reliable streams. An
> application protocol that depends on the IP address remaining constant end
> to end is a bad protocol and should be rejected.
>

So Authentication Header and any other sort of Inetwork layer
authentication are bad protocols that should be rejected?

Tom

--000000000000d6ffdf059f967731
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker <=
;phill@hallambaker.com> wro=
te:
On Thu, Feb 27, 2=
020 at 5:09 PM Tom Herbert <tom@herbertland.com> wrote:
Fernando,



I think we need to be careful that IETF is labeled as a collection of

inflexible architectural purists. We know that standards conformance

is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own

purposes.

IP end to end does not mean the IP address is constant=
 end to end. It never has meant that and never will. An IP address is merel=
y a piece of data that allows a packet to reach=C2=A0its destination. There=
 is no reason to insist on it remaining constant along the path.=C2=A0

The sooner people get over th=
at fact the better.

If an=
 IPv4 device interacts with an IPv6 device, there will be address translati=
on going on somewhere along the path. That is inevitable.

We discovered that there were good reaso=
ns for NATing IPv4 besides address multiplexing. The topology of my network=
 is none of your business.

More generally, Internet standards only apply to the Inter-net, the netwo=
rk of networks. What happens inside the networks at either end is for the o=
wners of those networks to decide. If we go back to the original Internet d=
esign, they didn't even need to run IP. IP end to end come later.
=


So let us stop being dogmatic =
about things that don't actually matter. The only job of the network la=
yer is to get packets from one end to another. The only job of the transpor=
t layer is to provide reliable streams. An application protocol that depend=
s on the IP address remaining constant end to end is a bad protocol and sho=
uld be rejected.=C2=A0

So Authentication Header and any othe=
r sort of Inetwork layer authentication are bad protocols that should be re=
jected?

Tom





--000000000000d6ffdf059f967731--


From nobody Thu Feb 27 14:47:55 2020
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 C088A3A0E25; Thu, 27 Feb 2020 14:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 qRAQWCiGoMg2; Thu, 27 Feb 2020 14:47:52 -0800 (PST)
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 57B5B3A0E0E; Thu, 27 Feb 2020 14:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=LttuMOxeuhJ/ujXQ43uRlr63k24O3UZply91l7Qf1RM=; b=ryE1ckvO06ta9ipQdQEwoiNy5 bFpLXYA98Usik7JskBQRbohHhGWcsaOErnPghZFFcg6bNAcpL3MNW9LKz2ixG/s3sz0V7JOY0QkrQ +yFYkAqdyZb2Y5jYIXzkppq+cm/JffZnx4h2zT7XybZis444ULzyaOtpdDHVf4rgOoNTsTDV75kvu b3ytVwrf8u4xydTUHRHehHgMQHYvmAGfoi1+7uyksVNwGY3TP7CpP8blsPOQwe9MlcUa7VVs2Cmjw vnJAgFM4mtVlchl5unRl9kltQcCxYYk53xVEI0frfD/LmQpLp/jT4h8Tq6eZly3EX0CuuximO200f GNeZ0KgQQ==;
Received: from [::1] (port=46320 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7RwZ-0016lf-9G; Thu, 27 Feb 2020 17:47:51 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_f8bb42a5e640aa2441d3577a2eb45516"
Date: Thu, 27 Feb 2020 14:47:47 -0800
From: Joe Touch 
To: Phillip Hallam-Baker 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , ietf@ietf.org
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
Message-ID: <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:47:54 -0000

--=_f8bb42a5e640aa2441d3577a2eb45516
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

On 2020-02-27 14:26, Phillip Hallam-Baker wrote:

> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote: 
> 
>> Fernando,
>> 
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
> 
> IP end to end does not mean the IP address is constant end to end. It never has meant that and never will.

Actually, that's the only thing it ever meant and always will. When
addresses change, *by definition*, the*ends* change (and yes, that's
what NATs do - they create end-to-end CONTENT transfer over separate
end-to-end Internets). 

> ..
> We discovered that there were good reasons for NATing IPv4 besides address multiplexing. The topology of my network is none of your business.

Agreed; there's nothing that forces you to use IP addresses in a way
that exposes your topology (you're free to build a net using host
routing). That has nothing to do with NAT. 

I have not found a rationale for NATs that doesn't start and end with a
business model where servers are charged business rates and clients are
charged customer rates. Everything else about NATs either isn't a NAT
property (hiding topology) or can be achieved by a stateful firewall
(that predates NATs by a decade, e.g. that lets outgoing connections go
through but not incoming). 

> More generally, Internet standards only apply to the Inter-net, the network of networks. What happens inside the networks at either end is for the owners of those networks to decide. If we go back to the original Internet design, they didn't even need to run IP. IP end to end come later.

That's true, but then their "end" on the public Internet would be the
firewall or NAT box at their edge. 

> So let us stop being dogmatic about things that don't actually matter. The only job of the network layer is to get packets from one end to another. The only job of the transport layer is to provide reliable streams. An application protocol that depends on the IP address remaining constant end to end is a bad protocol and should be rejected.

That's a very OSI view of protocols - about as out-dated and about as
useful., IMO. Every layer of the stack might be involved in any
function; anything that claims a single layer owns a single job hasn't
existed since at least IP over IP. 

Joe
--=_f8bb42a5e640aa2441d3577a2eb45516
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8






 





On 2020-02-27 14:26, Phillip Hallam-Baker wrote:








On Thu, Feb 27, 20=
20 at 5:09 PM Tom Herbert <tom@he=
rbertland.com> wrote:






Fernando,

 I thin=
k we need to be careful that IETF is labeled as a collection of
 infle=
xible architectural purists. We know that standards conformance
 is vo=
luntary and we haven't seen the last time that someone, possibly
 even=
 a major vendor, will circumvent the system for their own
 purposes.

 


IP end to end does=
 not mean the IP address is constant end to end. It never has meant that an=
d never will.












 


Actually, that's t=
he only thing it ever meant and always will. When addresses change, *by def=
inition*, the*ends* change (and yes, that's what NATs do - they create end-=
to-end CONTENT transfer over separate end-to-end Internets).










..


We discovered that=
 there were good reasons for NATing IPv4 besides address multiplexing. The =
topology of my network is none of your business.












 


Agreed; there's no=
thing that forces you to use IP addresses in a way that exposes your topolo=
gy (you're free to build a net using host routing). That has nothing to do =
with NAT.


 


I have not found a=
 rationale for NATs that doesn't start and end with a business model where =
servers are charged business rates and clients are charged customer rates=
=2E Everything else about NATs either isn't a NAT property (hiding topology=
) or can be achieved by a stateful firewall (that predates NATs by a decade=
, e.g. that lets outgoing connections go through but not incoming).


 












More generally, In=
ternet standards only apply to the Inter-net, the network of networks. What=
 happens inside the networks at either end is for the owners of those netwo=
rks to decide. If we go back to the original Internet design, they didn't e=
ven need to run IP. IP end to end come later.












 


That's true, but t=
hen their "end" on the public Internet would be the firewall or NAT box at =
their edge.


 












So let us stop bei=
ng dogmatic about things that don't actually matter. The only job of the ne=
twork layer is to get packets from one end to another. The only job of the =
transport layer is to provide reliable streams. An application protocol tha=
t depends on the IP address remaining constant end to end is a bad protocol=
 and should be rejected. 












 


That's a very OSI =
view of protocols - about as out-dated and about as useful., IMO. Every lay=
er of the stack might be involved in any function; anything that claims a s=
ingle layer owns a single job hasn't existed since at least IP over IP.

 


Joe







--=_f8bb42a5e640aa2441d3577a2eb45516--


From nobody Thu Feb 27 14:50:29 2020
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 B651A3A03F3; Thu, 27 Feb 2020 14:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gICz6-Aha8-i; Thu, 27 Feb 2020 14:50:25 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A24D3A0143; Thu, 27 Feb 2020 14:50:25 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F281680C8B; Thu, 27 Feb 2020 23:50:21 +0100 (CET)
To: Phillip Hallam-Baker , Tom Herbert 
Cc: Internet Architecture Board , architecture-discuss@iab.org, Internet Area , "ietf@ietf.org" 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
From: Fernando Gont 
Message-ID: <35324c05-e1de-0186-36e3-081648c1c539@gont.com.ar>
Date: Thu, 27 Feb 2020 19:50:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:50:27 -0000

Philip,

On 27/2/20 19:26, Phillip Hallam-Baker wrote:
> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  > wrote:
> 
>     Fernando,
> 
>     I think we need to be careful that IETF is labeled as a collection of
>     inflexible architectural purists. We know that standards conformance
>     is voluntary and we haven't seen the last time that someone, possibly
>     even a major vendor, will circumvent the system for their own
>     purposes.
> 
> 
> IP end to end does not mean the IP address is constant end to end. It 
> never has meant that and never will. An IP address is merely a piece of 
> data that allows a packet to reach its destination. There is no reason 
> to insist on it remaining constant along the path.

You seem to be missing the point I was trying to make.

We're talking about IPv6 routers doing heavy surgery on IPv6 packets, 
while en-route to destination.

And we are also talking about violating IETF specs at will, and 
circumventing IETF processes.

This does break things, make troubleshooting painful, etc.

AH may break
PMTUD may break
Error may reporting break


I'm not being purist. I'm just arguing that we probably can do better 
than simply rubber-stamping any hacks a vendor with big pockets may 
bring up.

Otherwise, I don't see the point of all this big structure.

For instance, we have an "Internet Architecture Board", which I guess 
have a say on things that affect architecture?

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Thu Feb 27 14:52:42 2020
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 5AB053A07D5; Thu, 27 Feb 2020 14:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 52j8t5XYphBU; Thu, 27 Feb 2020 14:52:33 -0800 (PST)
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 E7FC83A07AC; Thu, 27 Feb 2020 14:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=57pljL3kY9Ij9uym1HyszgWAyfYkjRrkeJkf2nMP0aI=; b=2tTkC3g3u3NLEvxRL2SVRaUJD jkKUEGuhB0FRkbv8GLkdHfJZz99JKtn1FQ4cj2OemffmZdmqmbJMIb7gwezorJz6OoZS+kTDZuDss y8EYzAfBb2qtjjDHtCZhHUlBhAbrLKEJTNEOQ2OmbGDCp2KbBQ4lyjDqxxeT44+DRkX5vZ7vIcr6k BFOfUYn1zIaF5hkubFFiSbWHjbbsgJgBkVV5szE18a+QItTvNCNFXpPz/KjRCZ10K2CrzArAumriI CotjmPXhZNV4w0mgEjI5pmotDEpZDIws7lvdpYylhXryg78L5teHY8MJR3L6R/xdlIj9+IXm10UyH 7pnh3APZw==;
Received: from [::1] (port=35062 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7S15-001BMn-L4; Thu, 27 Feb 2020 17:52:32 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_1b3a0aef95194a03248b5efae301b4d8"
Date: Thu, 27 Feb 2020 14:52:27 -0800
From: Joe Touch 
To: Tom Herbert 
Cc: Fernando Gont , architecture-discuss@iab.org, Internet Architecture Board , Internet Area , ietf@ietf.org
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> 
Message-ID: 
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:52:41 -0000

--=_1b3a0aef95194a03248b5efae301b4d8
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

FWIW - there are separable issues here: 

- whether an IP header (or parts thereof) should be changed in transit 

AFAICT, the answer has always been yes, but limited to the hopcount/ttl
in the base header and hop-by-hop options in the options/extension
headers. 

- whether an IP header length can change in transit 

I see no reason why it can't become smaller, but if it can become larger
then PMTUD and PLPMTUD don't work. 

So the question isn't just what is wanted, it's what is feasible. 

Joe

On 2020-02-27 14:07, Tom Herbert wrote:

> Fernando,
> 
> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists. We know that standards conformance
> is voluntary and we haven't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes. IMO extension header insertion is a great example of that.
> On one hand we have people quoting IPv6 saying that it isn't allowed
> per RFC8200-- period! And on other side there are proponents that see
> a real need for it and believe they have clear use case-- at one
> presentation in IETF a proponent bluntly stated that regardless of any
> discussion in IETF they're going to do it! IMO, what we haven't seen,
> was a real attempt to resolve and work out the engineering issues.
> That's not for lack of trying-- for instance I proposed a direction to
> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
> but saw little discussion on that.
> 
> Tom
> 
> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote: 
> 
>> Folks,
>> 
>> If you haven't been following recent developments in the Spring WG, you
>> may be surprised about some of the work that is being pursued (or was
>> being pursued)-
>> 
>> Such work has included proposing that some IPv6 routers insert and
>> remove routing headers en-route to the final destination.
>> 
>> After many very heated and lengthy debates, some of this work was
>> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
>> en-route to their final destination, part of what they call "PSP"). For
>> the most part, the proponents have argued that "we have implemented it,
>> and the industry wants it" -- as if we just have to rubberstamp what
>> they have done.
>> 
>> On the technical side, the proponents have argued that:
>> 
>> If a packet employs source routing (and hence its Destination
>> Address is modified en-route to direct the packet through each
>> of these "waypoints"), then any of such "waypoint" routers are
>> free to add or remove IPv6 extension headers at will. (No, not
>> encap/decap, but rather add/remove EHs from the IPv6 header
>> chain).
>> 
>> That seems to me like a very major deviation from what's supposed to be
>> our current "architecture", where IPv6 is an end to end protocol.
>> Besides, it should be obvious that removal/insertion of EHs en-route
>> error reporting (since host typically check that the ICMP errors they
>> receive correspond to something that they actually sent).
>> 
>> A number of us have raised this a number of times, and at least some of
>> us feel that our concerns are being ignored.
>> 
>> It would seem to me that these documents and decisions have a concrete
>> impact on our architecture, and that they are being pursued without any
>> proper oversight. There is also a widespread feeling that having one or
>> a few big vendors pushing these ideas might be playing a role here.
>> 
>> (See, for instance:
>> 
>> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>> 
>> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
>> )
>> 
>> What I would expect is that all thes major changes to our existing
>> architecture and protocols would only done by formally updating existing
>> standards *if* deemed appropriate, as opposed to just trying to sneak
>> changes "when nobody is watching", or by having very curious
>> interpretations of our protocols and standards.
>> 
>> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
>> list before, but so far haven't been lucky or seen anything meaningful
>> happen in this area.
>> 
>> I have also submitted an errata to make RFC8200 even more clear on the
>> topic, but it remains unprocessed.
>> 
>> So my questions are:
>> 
>> * On the technical area:
>> 
>> + Is IPv6 an End To End protocol?  Or is the IETF's stance that
>> routers are free to mangle with the packet structure as they please?
>> 
>> + Was IPv6 designed that way? And if it wasn't, when/how was the
>> architecture changed?
>> 
>> * On the procedural area:
>> 
>> + Where/how should IETF WGs seek for architecture-related advice?
>> 
>> + What do do in situations like the above?  Wait and see how things
>> evolve, and upon any formal decisions, just submit formal Appeals
>> if deemed necessary?  (and after way too much energy consumed from
>> everyone)
>> 
>> I would have expected that as soon as these issues were raised,
>> the offending text would be removed rightaway. But that wasn't
>> the case. And when the changes did happen, it wasn't without
>> an extraordinary waste of time and energy from all of us.
>> For instance, any work on IPv6 header insertion/deletion wouldn't
>> seem to fit within the charters of the 6man or spring wgs.
>> 
>> FWIW, this is not the first instance of issues surrounding the same
>> topic. It goes back to the rfc2460bis effort, when a similar set of
>> folks (too many from one big vendor) got to have 6man ship
>> what became RFC8200 with a noted "ambiguity", just to be able
>> to have some playground for EH insertion/deletion. And we only got
>> to improve on that during IETF LC:
>> 
>> (see:
>> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>> 
>> Thoughts or advice on the technical and/or procedural aspects will be
>> appreciated.
>> 
>> Thanks!
>> 
>> Cheers,
>> Fernando
>> 
>> -------- Forwarded Message --------
>> Subject: Errata #5933 for RFC8200
>> Date: Thu, 27 Feb 2020 17:07:36 -0300
>> From: Fernando Gont 
>> To: Suresh Krishnan 
>> CC: 6man@ietf.org <6man@ietf.org>
>> 
>> Suresh,
>> 
>> Two months ago I filled an errata on RFC8200 regarding the processing of
>> IPv6 extension headers. The errata is available here:
>> https://www.rfc-editor.org/errata/eid5933
>> 
>> While I believe that folks with a knowledge of Internet Protocols would
>> be able to interpret what is in RFC8200, given recent discussions on the
>> topic, and upon a re-read of the text, I believe a clarification is
>> warranted, such that we allow all sorts of curious interpretations of
>> the text.
>> 
>> I send a heads-up on the 6man mailing list
>> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
>> and the proposed text received the review of at least Brian Carpenter,
>> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>> 
>> In the light that some folks seem to be pretending to leverage "the lack
>> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
>> appreciate that the reported errata be processed.
>> 
>> Processing the aforementioned errata is key to many of the discussions
>> this and other WGs are having.
>> 
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
--=_1b3a0aef95194a03248b5efae301b4d8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



FWIW - there are separable issues here:


- whether an IP header (or parts thereof) should be changed in transit

AFAICT, the answer has always been yes, bu=
t limited to the hopcount/ttl in the base header and hop-by-hop options in =
the options/extension headers.


- whether an IP header length can change in transit


I see no reason why it can't become smalle=
r, but if it can become larger then PMTUD and PLPMTUD don't work.


So the question isn't just what is wanted, it's what is feasible.


Joe


 





On 2020-02-27 14:07, Tom Herbert wrote:




=
Fernando,

 I think we need to be careful that IETF is labeled as=
 a collection of
 inflexible architectural purists. We know that stand=
ards conformance
 is voluntary and we haven't seen the last time that =
someone, possibly
 even a major vendor, will circumvent the system for=
 their own
 purposes. IMO extension header insertion is a great exampl=
e of that.
 On one hand we have people quoting IPv6 saying that it isn=
't allowed
 per RFC8200-- period! And on other side there are proponen=
ts that see
 a real need for it and believe they have clear use case--=
 at one
 presentation in IETF a proponent bluntly stated that regardle=
ss of any
 discussion in IETF they're going to do it! IMO, what we hav=
en't seen,
 was a real attempt to resolve and work out the engineering=
 issues.
 That's not for lack of trying-- for instance I proposed a di=
rection to
 try for an engineering compromise in draft-herbert-6man-eh=
-attrib-00,
 but saw little discussion on that.

 Tom
<=
br /> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont <fgont@si6networks.com> wrote:


 Folks,

 If you haven't been followin=
g recent developments in the Spring WG, you
 may be surprised about so=
me of the work that is being pursued (or was
 being pursued)-
 Such work has included proposing that some IPv6 routers insert and
 remove routing headers en-route to the final destination.

 Aft=
er many very heated and lengthy debates, some of this work was
 droppe=
d, but other remains (e.g. routers removing IPv6 EHs from packets
 en-=
route to their final destination, part of what they call "PSP"). For
 =
the most part, the proponents have argued that "we have implemented it,
 and the industry wants it" -- as if we just have to rubberstamp what
 they have done.

 On the technical side, the proponents have a=
rgued that:

      If a packet employs s=
ource routing (and hence its Destination
     &nbs=
p;Address is modified en-route to direct the packet through each
 &nbs=
p;    of these "waypoints"), then any of such "waypoint=
" routers are
      free to add or remove IPv=
6 extension headers at will. (No, not
      e=
ncap/decap, but rather add/remove EHs from the IPv6 header
  &nbs=
p;   chain).

 That seems to me like a very major =
deviation from what's supposed to be
 our current "architecture", wher=
e IPv6 is an end to end protocol.
 Besides, it should be obvious that =
removal/insertion of EHs en-route
 error reporting (since host typical=
ly check that the ICMP errors they
 receive correspond to something th=
at they actually sent).


 A number of us have raised this a=
 number of times, and at least some of
 us feel that our concerns are =
being ignored.

 It would seem to me that these documents and dec=
isions have a concrete
 impact on our architecture, and that they are =
being pursued without any
 proper oversight. There is also a widesprea=
d feeling that having one or
 a few big vendors pushing these ideas mi=
ght be playing a role here.

 (See, for instance:

 * <=
a href=3D"https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXv=
Pcpj4/" target=3D"_blank" rel=3D"noopener noreferrer">https://mailarchive=
=2Eietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/

 * https://mailarchive.ie=
tf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
 )

 W=
hat I would expect is that all thes major changes to our existing
 arc=
hitecture and protocols would only done by formally updating existing
=
 standards *if* deemed appropriate, as opposed to just trying to sneak
 changes "when nobody is watching", or by having very curious
 interp=
retations of our protocols and standards.

 I've raised the topic=
 to our AD (Suresh), to the IAB, and on the arch-d
 list before, but s=
o far haven't been lucky or seen anything meaningful
 happen in this a=
rea.

 I have also submitted an errata to make RFC8200 even more =
clear on the
 topic, but it remains unprocessed.

 So my que=
stions are:

 * On the technical area:

   + =
Is IPv6 an End To End protocol?  Or is the IETF's stance that
 ro=
uters are free to mangle with the packet structure as they please?
   + Was IPv6 designed that way? And if it wasn't, when/how wa=
s the
 architecture changed?


 * On the procedural are=
a:

    + Where/how should IETF WGs seek for archi=
tecture-related advice?

    + What do do in situa=
tions like the above?  Wait and see how things
    =
;  evolve, and upon any formal decisions, just submit formal Appe=
als
      if deemed necessary?  (and aft=
er way too much energy consumed from
      ev=
eryone)

      I would have expected tha=
t as soon as these issues were raised,
      =
the offending text would be removed rightaway. But that wasn't
  =
    the case. And when the changes did happen, it wasn'=
t without
      an extraordinary waste of tim=
e and energy from all of us.
      For instan=
ce, any work on IPv6 header insertion/deletion wouldn't
   &=
nbsp;  seem to fit within the charters of the 6man or spring wgs=
=2E


      FWIW, this is not the f=
irst instance of issues surrounding the same
     =
 topic. It goes back to the rfc2460bis effort, when a similar set of      folks (too many from one big vendor) got=
 to have 6man ship
      what became RFC8200 =
with a noted "ambiguity", just to be able
     &nb=
sp;to have some playground for EH insertion/deletion. And we only got
=
      to improve on that during IETF LC:

     (see:
https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyq=
WneNgvtc8sh-fGAu0/)


 Thoughts or advice on the technic=
al and/or procedural aspects will be
 appreciated.

 Thanks!=


 Cheers,
 Fernando




 -------- =
Forwarded Message --------
 Subject: Errata #5933 for RFC8200
 Da=
te: Thu, 27 Feb 2020 17:07:36 -0300
 From: Fernando Gont <fgont@si6networks.com>
 To: S=
uresh Krishnan <suresh.kris=
hnan@gmail.com>
 CC: 6man@ietf=
=2Eorg <6man@ietf.org>
=

 Suresh,

 Two months ago I filled an errata on RFC8200 reg=
arding the processing of
 IPv6 extension headers. The errata is availa=
ble here:
https://www.rfc-editor.org/errata/e=
id5933

 While I believe that folks with a knowledge of Inter=
net Protocols would
 be able to interpret what is in RFC8200, given re=
cent discussions on the
 topic, and upon a re-read of the text, I beli=
eve a clarification is
 warranted, such that we allow all sorts of cur=
ious interpretations of
 the text.

 I send a heads-up on th=
e 6man mailing list
 (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM=
6c/),
 and the proposed text received the review of at least Brian=
 Carpenter,
 Ron Bonica, and Mark Smith. Their reviews are available o=
n such thread.

 In the light that some folks seem to be pretendi=
ng to leverage "the lack
 of clarify" in RFC8200 (an Internet Standard=
) to violate it, I'd
 appreciate that the reported errata be processed=
=2E

 Processing the aforementioned errata is key to many of the =
discussions
 this and other WGs are having.

 Thanks,
 =
--
 Fernando Gont
 SI6 Networks
 e-mail: fgont@si6networks.com
 PGP Fingerprint: 6666=
 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




=
 _______________________________________________
 Int-area mailing lis=
t
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


 _______________________________________________
 Int-area maili=
ng list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-a=
rea





--=_1b3a0aef95194a03248b5efae301b4d8--


From nobody Thu Feb 27 14:58:39 2020
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 3EDA63A07A2; Thu, 27 Feb 2020 14:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 te5FnLs0SKQu; Thu, 27 Feb 2020 14:58:23 -0800 (PST)
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 0F5D33A07CD; Thu, 27 Feb 2020 14:58:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=42DqsvJqK3v+7gBhYrI4VPsSigShX1zuObwbymbdjQQ=; b=P+PlGD+TQBycH4D05/LcGW3y/ hbkYE8xh554s/eXoAPMkL6k5rUNt1BE9shILlLk+gsvhJeXwjVjRHOM/8ak912UviZ0DvINGfLF2W 4yixUxw8ohdHgfTJiKmTgrVPkqNg6iGQ4AS4Zzg3mdchNNOYMEkKQ7rU+LUiSwpihPitbTFWIqQo+ DmiX+UDg54l+6dEIRWkfJ75SQHa5Vl7jN3mNnk7x5TCOkkhGs1c8vtG/PPEmT3VgKxwaWd/1odCLI 2ROGk7IDyl1ncp3F+ZJ1qtvK/eRcS3qCzS6dNI7kN3sIDa0SGm/ttQY4sj38RYc0578GL6R1xhEvs jKKEtrBWw==;
Received: from [::1] (port=45028 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7S6k-001GYE-0U; Thu, 27 Feb 2020 17:58:22 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_473daeef39d403ec4f4aa6356147da86"
Date: Thu, 27 Feb 2020 14:58:17 -0800
From: Joe Touch 
To: Fernando Gont 
Cc: Phillip Hallam-Baker , Tom Herbert , Internet Area , Internet Architecture Board , architecture-discuss@iab.org, ietf@ietf.org
In-Reply-To: <35324c05-e1de-0186-36e3-081648c1c539@gont.com.ar>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <35324c05-e1de-0186-36e3-081648c1c539@gont.com.ar>
Message-ID: <8b61e504637776cdf1c25540d7ad7d4c@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 22:58:30 -0000

--=_473daeef39d403ec4f4aa6356147da86
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

On 2020-02-27 14:50, Fernando Gont wrote:

> ...
> I'm not being purist. I'm just arguing that we probably can do better than simply rubber-stamping any hacks a vendor with big pockets may bring up.

That's a refreshing perspective. 

Refreshing, but confusing - given you promoted "standardizing" vendor
deviations (many arguably bugs) from TCP in TCPM. 

So I'm confused - what do you think drives our standards now? Design or
implementations (including bugs)? 

Joe
--=_473daeef39d403ec4f4aa6356147da86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8






 





On 2020-02-27 14:50, Fernando Gont wrote:




=
...
 I'm not being purist=
=2E I'm just arguing that we probably can do better than simply rubber-stam=
ping any hacks a vendor with big pockets may bring up.




=
 


=
That's a refreshing perspective.


=
 


=
Refreshing, but confusing - given you =
promoted "standardizing" vendor deviations (many arguably bugs) from TCP in=
 TCPM. 


=
 


=
So I'm confused - what do you think dr=
ives our standards now? Design or implementations (including bugs)?<=
/div>

=

Joe



--=_473daeef39d403ec4f4aa6356147da86--


From nobody Thu Feb 27 15:01:31 2020
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 C6D803A077C for ; Thu, 27 Feb 2020 15:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 zHWI6M03cFUs for ; Thu, 27 Feb 2020 15:01:07 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 548E23A07B3 for ; Thu, 27 Feb 2020 15:01:05 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id v28so1013844edw.12 for ; Thu, 27 Feb 2020 15:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bF1kEuNxJ+d8RRz7daKRJ1Ztxd7P6Cd+cpHxbO0SW70=; b=KCErvfL1WVSXds5/uoXXCCJT3aFlCLNqc1Dh6V3HaC8asAR2uhs92roTFpQqatn+4c FXeZ9dI/S71H35yra49HuV1lHFzD0Wj4i2DuGxyudrqeBBcotkBnofb1zE4W3J2HTGkb 492zCpRFiJfY5u4kYdSsvWArQuadsrhP38dVQbx2lbZ7RanDjCddbap1TlTjNDJfi6UJ WueTUzTjr+kvIs1nWTchZ9gO7Fquv08syiemXMfVjiPuiEWPp/iXpOYFCFTweKHi+5LC sirt3yVnI+wrRUwgfmnHC3heGS9hj56EsEsA3h3Yssqm9aRPegN70mXLOd5ixmMWddg1 ec1A==
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=bF1kEuNxJ+d8RRz7daKRJ1Ztxd7P6Cd+cpHxbO0SW70=; b=h/8frb/ODLfypBl/8ltwFlVqLsmqF+SsgxJZVG0sN3FHxwKGm85gj9lBLoOU6B6uoq 0VfjStwemARE5mzuMTf1f1ABwhh0YlRE0njyF6fltymE4gB9aWLbsnInQUmrpV9VUTEe C06BMt1Vcp0b9FNjxuP/W4k7iyl3DyionGQ2+FM71MaGLbUnk02lbdJPzqVwzhkx2tBN f36pJBk0of3uULaxl2tivAqg6B950s3jeGbBGQ+FSwauc7IrBQgwA2rXx0stcixPqlO7 MXkDNYUKILE/TVER2mZPx3R6JVbwN5bcI7B1Cyq/qek+DNG6QHw3nUV4JUD1xpHCGyUn +S3A==
X-Gm-Message-State: APjAAAV48/aMZtIZ2D1cZVFtb2i1TqD3Vx8QIggZ7qO1ySMmwC2/WkW4 H6kbl8U/4fqof/PSK7UgUGHv2UyhettN8QXHhdwh4g==
X-Google-Smtp-Source: APXvYqwmHNCUSOArQQr0iezb6A3LiEC9Ob6azfxKaUbTts4m3E+ZkdyMBrISYTXPQymFWU3hB1qqsamxJCYDwelUgLI=
X-Received: by 2002:a05:6402:3132:: with SMTP id dd18mr884736edb.118.1582844463417;  Thu, 27 Feb 2020 15:01:03 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
In-Reply-To: 
From: Tom Herbert 
Date: Thu, 27 Feb 2020 15:00:52 -0800
Message-ID: 
To: Joe Touch 
Cc: Fernando Gont , architecture-discuss@iab.org,  Internet Architecture Board , Internet Area ,  IETF-Discussion 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:01:16 -0000

On Thu, Feb 27, 2020 at 2:52 PM Joe Touch  wrote:
>
> FWIW - there are separable issues here:
>
> - whether an IP header (or parts thereof) should be changed in transit
>
> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.
>
> - whether an IP header length can change in transit
>
> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work.
>
> So the question isn't just what is wanted, it's what is feasible.
>
Joe,

Per the problem about making packets larger in the network, I'd point
out that this is already common due to in-network tunneling. In any
case, it's really the only interesting case here (as opposed to making
packets smaller).

Tom

> Joe
>
>
>
>
> On 2020-02-27 14:07, Tom Herbert wrote:
>
> Fernando,
>
> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists. We know that standards conformance
> is voluntary and we haven't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes. IMO extension header insertion is a great example of that.
> On one hand we have people quoting IPv6 saying that it isn't allowed
> per RFC8200-- period! And on other side there are proponents that see
> a real need for it and believe they have clear use case-- at one
> presentation in IETF a proponent bluntly stated that regardless of any
> discussion in IETF they're going to do it! IMO, what we haven't seen,
> was a real attempt to resolve and work out the engineering issues.
> That's not for lack of trying-- for instance I proposed a direction to
> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
> but saw little discussion on that.
>
> Tom
>
> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote:
>
>
> Folks,
>
> If you haven't been following recent developments in the Spring WG, you
> may be surprised about some of the work that is being pursued (or was
> being pursued)-
>
> Such work has included proposing that some IPv6 routers insert and
> remove routing headers en-route to the final destination.
>
> After many very heated and lengthy debates, some of this work was
> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
> en-route to their final destination, part of what they call "PSP"). For
> the most part, the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done.
>
> On the technical side, the proponents have argued that:
>
>      If a packet employs source routing (and hence its Destination
>      Address is modified en-route to direct the packet through each
>      of these "waypoints"), then any of such "waypoint" routers are
>      free to add or remove IPv6 extension headers at will. (No, not
>      encap/decap, but rather add/remove EHs from the IPv6 header
>      chain).
>
> That seems to me like a very major deviation from what's supposed to be
> our current "architecture", where IPv6 is an end to end protocol.
> Besides, it should be obvious that removal/insertion of EHs en-route
> error reporting (since host typically check that the ICMP errors they
> receive correspond to something that they actually sent).
>
>
> A number of us have raised this a number of times, and at least some of
> us feel that our concerns are being ignored.
>
> It would seem to me that these documents and decisions have a concrete
> impact on our architecture, and that they are being pursued without any
> proper oversight. There is also a widespread feeling that having one or
> a few big vendors pushing these ideas might be playing a role here.
>
> (See, for instance:
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
> )
>
> What I would expect is that all thes major changes to our existing
> architecture and protocols would only done by formally updating existing
> standards *if* deemed appropriate, as opposed to just trying to sneak
> changes "when nobody is watching", or by having very curious
> interpretations of our protocols and standards.
>
> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
> list before, but so far haven't been lucky or seen anything meaningful
> happen in this area.
>
> I have also submitted an errata to make RFC8200 even more clear on the
> topic, but it remains unprocessed.
>
> So my questions are:
>
> * On the technical area:
>
>   + Is IPv6 an End To End protocol?  Or is the IETF's stance that
> routers are free to mangle with the packet structure as they please?
>
>   + Was IPv6 designed that way? And if it wasn't, when/how was the
> architecture changed?
>
>
> * On the procedural area:
>
>    + Where/how should IETF WGs seek for architecture-related advice?
>
>    + What do do in situations like the above?  Wait and see how things
>      evolve, and upon any formal decisions, just submit formal Appeals
>      if deemed necessary?  (and after way too much energy consumed from
>      everyone)
>
>      I would have expected that as soon as these issues were raised,
>      the offending text would be removed rightaway. But that wasn't
>      the case. And when the changes did happen, it wasn't without
>      an extraordinary waste of time and energy from all of us.
>      For instance, any work on IPv6 header insertion/deletion wouldn't
>      seem to fit within the charters of the 6man or spring wgs.
>
>
>      FWIW, this is not the first instance of issues surrounding the same
>      topic. It goes back to the rfc2460bis effort, when a similar set of
>      folks (too many from one big vendor) got to have 6man ship
>      what became RFC8200 with a noted "ambiguity", just to be able
>      to have some playground for EH insertion/deletion. And we only got
>      to improve on that during IETF LC:
>
>     (see:
> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>
>
> Thoughts or advice on the technical and/or procedural aspects will be
> appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: Errata #5933 for RFC8200
> Date: Thu, 27 Feb 2020 17:07:36 -0300
> From: Fernando Gont 
> To: Suresh Krishnan 
> CC: 6man@ietf.org <6man@ietf.org>
>
> Suresh,
>
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> https://www.rfc-editor.org/errata/eid5933
>
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
>
> I send a heads-up on the 6man mailing list
> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
>
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area


From nobody Thu Feb 27 15:05:35 2020
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 64D983A0764; Thu, 27 Feb 2020 15:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 InioLz7sGTVN; Thu, 27 Feb 2020 15:05:09 -0800 (PST)
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 A60DA3A0809; Thu, 27 Feb 2020 15:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=M7s7yLXL0GL+8BFKTZobWcxuaJBJkRBK7OQy8iT7Wbw=; b=2CfTHyhBnuqgUl6OGiH2ajygt a3G7oPVKWZ5yEE43hZ7lhDcmHlpLyUqsay3PjHp0ao5gE1Ots0E0sGcMjJTbfufdPVpJC5S2xAE5L tlf2IbSh5EQrBhbucMhxTrNW9OFQIR73KR0iS/Wt5JEKccaR04Wk3MeJcV7L+WpPaoZmZCdLwgqBJ ARfcs/ouEY+3r86/7StoFI8NgCqwuzyPM9Iq4VYJyxfwSdEMA1kRl0AANr8iBj7KpViJ88Z5sutkp zWGPru4TOI/sAp3XZcpnESsxmZJW+CSY9zkxbf1bCwrqAxL59FwKLaL85fj4QArWPqGuw1GAc1QFF sdzs9EuqQ==;
Received: from [::1] (port=54180 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7SDI-001RmS-Ep; Thu, 27 Feb 2020 18:05:08 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_962e905e51b5ecafbe0b7ecb3e72807e"
Date: Thu, 27 Feb 2020 15:05:04 -0800
From: Joe Touch 
To: Tom Herbert 
Cc: Fernando Gont , architecture-discuss@iab.org, Internet Architecture Board , Internet Area , IETF-Discussion 
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
Message-ID: 
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:05:21 -0000

--=_962e905e51b5ecafbe0b7ecb3e72807e
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

On 2020-02-27 15:00, Tom Herbert wrote:

> On Thu, Feb 27, 2020 at 2:52 PM Joe Touch  wrote: 
> 
>> FWIW - there are separable issues here:
>> 
>> - whether an IP header (or parts thereof) should be changed in transit
>> 
>> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.
>> 
>> - whether an IP header length can change in transit
>> 
>> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work.
>> 
>> So the question isn't just what is wanted, it's what is feasible.
> Joe,
> 
> Per the problem about making packets larger in the network, I'd point
> out that this is already common due to in-network tunneling. In any
> case, it's really the only interesting case here (as opposed to making
> packets smaller).

Tunnels don't make packets bigger. They make a bigger packet at the
tunnel level. That then becomes the tunnel's problem to deal with (see
draft-intarea-tunnels). 

Making the IP packet bigger itself creates a problem that cannot be
recovered that way. 

I.e., same problem but very different consequences. 

Joe
--=_962e905e51b5ecafbe0b7ecb3e72807e
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8






 





On 2020-02-27 15:00, Tom Herbert wrote:




=
On Thu, Feb 27, 2020 at 2:52 PM Joe Touch <touch@strayalpha.com> wrote:


 FWIW - there are separable issues here:
 - whether an IP header (or parts thereof) should be changed in transit=


 AFAICT, the answer has always been yes, but limited to the hop=
count/ttl in the base header and hop-by-hop options in the options/extensio=
n headers.

 - whether an IP header length can change in transit<=
br />
 I see no reason why it can't become smaller, but if it can beco=
me larger then PMTUD and PLPMTUD don't work.

 So the question is=
n't just what is wanted, it's what is feasible.


Joe,

 Per the problem about making packets larger in the network=
, I'd point
 out that this is already common due to in-network tunneli=
ng. In any
 case, it's really the only interesting case here (as oppos=
ed to making
 packets smaller).




=
 


=
Tunnels don't make packets bigger. They make a bigger packet at the tunnel =
level. That then becomes the tunnel's problem to deal with (see draft-intar=
ea-tunnels).


=
 


=
Making the IP packet bigger itself creates a problem that cannot be recover=
ed that way.


=
 


=
I.e., same problem but very different consequences.


=

Joe



--=_962e905e51b5ecafbe0b7ecb3e72807e--


From nobody Thu Feb 27 15:07:39 2020
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 6BF113A076E; Thu, 27 Feb 2020 15:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O95FBxrbdRVW; Thu, 27 Feb 2020 15:07:30 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104913A07B9; Thu, 27 Feb 2020 15:07:30 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 901D782A18; Fri, 28 Feb 2020 00:07:25 +0100 (CET)
To: Joe Touch , Tom Herbert 
Cc: architecture-discuss@iab.org, Internet Architecture Board , Internet Area , ietf@ietf.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
From: Fernando Gont 
Message-ID: <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com>
Date: Thu, 27 Feb 2020 20:06:44 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:07:38 -0000

On 27/2/20 19:52, Joe Touch wrote:
> FWIW - there are separable issues here:
> 
> - whether an IP header (or parts thereof) should be changed in transit
> 
> AFAICT, the answer has always been yes, but limited to the hopcount/ttl 
> in the base header and hop-by-hop options in the options/extension headers.
> 
> - whether an IP header length can change in transit
> 
> I see no reason why it can't become smaller, but if it can become larger 
> then PMTUD and PLPMTUD don't work.

Besides AH (which obviously breaks), hosts typically try to validate 
that the error messages they receive correspond to something they 
actually sent.

EH removal breaks that.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 15:08:13 2020
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 E15CA3A0813; Thu, 27 Feb 2020 15:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 3-sMZM5RVajy; Thu, 27 Feb 2020 15:07:55 -0800 (PST)
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 7502D3A0818; Thu, 27 Feb 2020 15:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=FjdQ6ijo0mRma6i0+lnxP2u7p8EDYxcXSazlAVCRPZc=; b=bCDVsqLTpAvXjPJXpApR8p0Nh qvqgyCjlTDExaNu1TzSRDt4G6qBbGSwnO89cZSebJG/HL7E7wGTsdyxqDQZrhxGZBKcTbR45k6AIB 6RivTCKQYf/SkLjW56E/RebvC/3SVR+4m7KaMnV4s7cF/pdpwfcdO2h2OzliK8S7KevOffk0OClaW 2yQIsCeZfKNus5C0GVltCHNRaj+Z/ZjEw5ReQNtcp6nvHerYmsqtPjBP5WHxtxPPo+PSawbpCzL5d cLdMEN59OFR3k41XjSURQ88taN5k+zZkoXvlfKnHdYEScqNttTrtucivvg8s0vEVaiH4O7FhpBfZb P3H003C5g==;
Received: from [::1] (port=49116 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7SFz-001Vbq-8p; Thu, 27 Feb 2020 18:07:55 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_261c004a46da80cd44cc55aefc52616c"
Date: Thu, 27 Feb 2020 15:07:51 -0800
From: Joe Touch 
To: Robert Raszuk 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
Message-ID: <435b3561fd446be01d7d464e0c0762c5@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:08:04 -0000

--=_261c004a46da80cd44cc55aefc52616c
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hi, Robert, 

It doesn't matter on what IP header this occurs. 

It does matter whether it happens at the IP source (origin host, tunnel
ingress, etc.) or on the path of that header. 

The former is allowed exactly because it is where source fragmentation
can occur (in IPv6, and preferably the only kind of fragmentation used
in IPv4). 

Joe

On 2020-02-27 15:04, Robert Raszuk wrote:

> Joe, all, 
> 
> Just to clarify something Fernando purposely missed in his call for action: 
> 
> All operations on the packets discussed in SPRING WG are happening NOT on the original (end to end) packet header. They are all defined to happen within new imposed outer encapsulated header (IPv6 in IPv6 to be precise).  
> 
> So original packet just get's tunneled between various points of the network. Last time I checked that operation is allowed by RFC2473.  
> 
> Its subtle detail, but fundamental one to this entire context/discussion. 
> 
> Kind regards, 
> R. 
> 
> On Thu, Feb 27, 2020 at 11:54 PM Joe Touch  wrote: 
> 
>> FWIW - there are separable issues here: 
>> 
>> - whether an IP header (or parts thereof) should be changed in transit 
>> 
>> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers. 
>> 
>> - whether an IP header length can change in transit 
>> 
>> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work. 
>> 
>> So the question isn't just what is wanted, it's what is feasible. 
>> 
>> Joe
--=_261c004a46da80cd44cc55aefc52616c
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Hi, Robert,


It doesn't matter on what IP header this occurs.


It does matter whether it happens at the IP source (origin host, tunnel =
ingress, etc.) or on the path of that header.


The former is allowed exactly because it is where source fragmentation c=
an occur (in IPv6, and preferably the only kind of fragmentation used in IP=
v4).


Joe


 





On 2020-02-27 15:04, Robert Raszuk wrote:






Joe, all,

 


Just to clarify something Fernando purposely missed in his call f=
or action:


 


All operations on the packets discussed in SPRING WG are happening NOT=
 on the original (end to end) packet header. They are all defined to happen=
 within new imposed outer encapsulated header (IPv6 in IPv6 to be precise)=
=2E 


 


So original packet just get's tunneled between various points of the n=
etwork. Last time I checked that operation is allowed by RFC2473. 

 


Its subtle detail, but fundamental one to this entire context/discussi=
on.


 


Kind regards,


R.


 








On Thu, Feb 27, 2020 at 11:54 PM Joe =
Touch <touch@strayalpha.com&=
gt; wrote:






FWIW - there are separable issues here:


- whether an IP header (or parts thereof) should be changed in transit

AFAICT, the answer has always been yes, bu=
t limited to the hopcount/ttl in the base header and hop-by-hop options in =
the options/extension headers.


- whether an IP header length can change in transit


I see no reason why it can't become smalle=
r, but if it can become larger then PMTUD and PLPMTUD don't work.


So the question isn't just what is wanted, it's what is feasible.


Joe













--=_261c004a46da80cd44cc55aefc52616c--


From nobody Thu Feb 27 15:08:49 2020
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 CDAC83A07C5; Thu, 27 Feb 2020 15:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 BQmkyDDVs3uE; Thu, 27 Feb 2020 15:08:39 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CEF3A07C1; Thu, 27 Feb 2020 15:08:36 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5500E8067A; Thu, 27 Feb 2020 23:58:48 +0100 (CET)
To: Bernard Aboba 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> 
From: Fernando Gont 
Message-ID: 
Date: Thu, 27 Feb 2020 19:58:25 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:08:46 -0000

On 27/2/20 19:43, Bernard Aboba wrote:
> Fernando --
> 
> "the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done."
> 
> [BA] The IETF has no enforcement authority, so that vendors have the 
> ability to ship products implementing IETF standards in whole or in part 
> - or not at all.  

Agreed. The problem here is that it's an *IETF* working group 
rubber-stamping what a vendor did. *That* is the problem.

May I ask what is the point of bothering publishing specs if they are 
going to be violated at will *within the same organization that 
published the specs*.


As noted by Jinmei here 
 
, I believe not only are we just rubber-stamping stuff, but also I 
believe that our processes are being circumvented.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 15:11:26 2020
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 CF7323A0861 for ; Thu, 27 Feb 2020 15:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 BKD61i8txHE8 for ; Thu, 27 Feb 2020 15:11:10 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 28E7C3A0853 for ; Thu, 27 Feb 2020 15:11:10 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id x97so869080ota.6 for ; Thu, 27 Feb 2020 15:11:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Ayd4frP60SHmOz+7aP4Pym11T4N/LEa2fwqUCbxd1A=; b=b2HoSDTZZuQwGC8hUE4Hu37gzCIOfi/oIQJ0mAhAlveOwWVIsxWV35DHsGx3B4gV+x g9WT0RPteIA5TaEIDgdiotBYYLjYGaJq/VuWGPniWAvfBsaPBVxqdLjbT+bTpUVhoOZx h02U9EzowryoYXL4aDdjF1gsCIXRA1QKYVmco/ItuU6u83UlR4DibgO0XiRiSF3jZxWt Xh7YNqw9rum+lrb2MmenFbrgUFYLMoERW7b+HeF5L4YoTVOq4u42pRA3TWYMzdkLFfwO hcGSZqvDHWk86m2dABeYY9fHECiT8W/6Ulz8Lli4IcWNUTICCvmkrSrfbdiUPyJ8MwhD 2Idw==
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=6Ayd4frP60SHmOz+7aP4Pym11T4N/LEa2fwqUCbxd1A=; b=a6ZqcS48Qy/i3PD5eJtLFZR4FMPlKrqWx97Ua1iIj5yCVF4hqaOSeT3r1tc2yQRTFH gCoDK5wxLMuV/GK9rVpUcwAhx9fUvAFCWztXtlOY1rgkSRkNYqJwsAKyZbay/wdtHTjo Ir+vjAzzf/zW8EExRsYLjTQNK5MtY2zQKE5wEkPuud+rTLznxUeIZVxrp4rVP+7VndL6 KZHXNbcgVwGKXyKnBwIm3QZ/3Dt5Dira1ScdAzE++C2FEUDQR/Iz0NB8JKCiFXB937Vh hTkYLHMn+1ZSSxeaoAecKmid8XUxvV82GKNqG7pD/sXq6kAz1uQW7Wo/UjgwxFiJ1ibk FJqQ==
X-Gm-Message-State: APjAAAVgmpH8iJAtzJgVN8QMpmcVOxt+GECbs6BJFUM0MCx+2j8I4Weq sYv9x4vtJk0YwoJWolXQAmN0jL8ts/x1HOoWk31Ppg==
X-Google-Smtp-Source: APXvYqznMOdVZutlQ6R0FxFE24MSs4TLRW/emjhQBODrGJvHzSVmoZ1Z1R/rvnfdyuiUci+DEo4vDRvyfU1gtpSo/68=
X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr1023726otr.82.1582845069190;  Thu, 27 Feb 2020 15:11:09 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <435b3561fd446be01d7d464e0c0762c5@strayalpha.com>
In-Reply-To: <435b3561fd446be01d7d464e0c0762c5@strayalpha.com>
From: Robert Raszuk 
Date: Fri, 28 Feb 2020 00:10:59 +0100
Message-ID: 
To: Joe Touch 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: multipart/alternative; boundary="0000000000001588c6059f96d64e"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:11:18 -0000

--0000000000001588c6059f96d64e
Content-Type: text/plain; charset="UTF-8"

> It does matter whether it happens at the IP source (origin host, tunnel
ingress, etc.) or on the path of that header.

It happens on tunnel ingress and tunnel egress nodes (egress = node listed
in DA of the packet).

--0000000000001588c6059f96d64e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



> It does mat=
ter whether it happens at the IP source (origin host, tunnel ingress, etc.)=
 or on the path of that header.=C2=A0=C2=A0

=
It happens on tunnel ingress and tunnel egress nodes (egress =3D node liste=
d in DA of the=C2=A0packet).=C2=A0


















--0000000000001588c6059f96d64e--


From nobody Thu Feb 27 15:13:52 2020
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 8FC813A0867; Thu, 27 Feb 2020 15:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 S6J3R2FD_7Ee; Thu, 27 Feb 2020 15:13:44 -0800 (PST)
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 73FA33A0838; Thu, 27 Feb 2020 15:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=JVYzjjIwOk02SxFg3rA/QTvC6krXxM3O0FZD/HRwlp0=; b=Bk33LTZiuv52+KtC/1wBjLuWs 5eDTMkTzq29uM/RfkgVL/JCJSqF6R0RexFQPIk5dfrBB/7zjIAuFnTRvaxffkvm6boBgjLMdS0Obo 4Y31MBOj3k+rUUFBEpPuht3v1I6k9/ukGd13JCxdbupq6RiHVOY+01HDIxjBLQouD+e/T6URtHp/e 8LdIiLk0zy5nYo30bGPjbBbxPx6nKDSbmn0HXZNJ6aLFSux1xkvFchSlrxnAt01wp0nyfWpmrLLcf zzH4Z5OqpA063YjKGtk1wBXa7hcmiGuJX690x6vK/1NirkPPurcJj5o8xJPVE0taIcsaZTHmHUmBV g6WUV6kxg==;
Received: from [::1] (port=49858 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7SLb-001bvD-Pq; Thu, 27 Feb 2020 18:13:44 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_e9353be2dc638d4b259916efce2c29f1"
Date: Thu, 27 Feb 2020 15:13:39 -0800
From: Joe Touch 
To: Robert Raszuk 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <435b3561fd446be01d7d464e0c0762c5@strayalpha.com> 
Message-ID: 
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:13:51 -0000

--=_e9353be2dc638d4b259916efce2c29f1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

On 2020-02-27 15:10, Robert Raszuk wrote:

>> It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header. 
> It happens on tunnel ingress and tunnel egress nodes (egress = node listed in DA of the packet).

Ingress can create whatever header it wants but needs to do
fragmentation (and potentially PLPMTUD over the tunnel with the egress).


Egress can strip the outer header but not make the inner one bigger,
IMO. 

Is something else being proposed? 

Joe
--=_e9353be2dc638d4b259916efce2c29f1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8






 





On 2020-02-27 15:10, Robert Raszuk wrote:








 


> It does matter whether it happens at the IP source (origin=
 host, tunnel ingress, etc.) or on the path of that header.


 

It happens on tunnel ingress and tunnel egress nodes (egress =3D node liste=
d in DA of the packet). 








 


Ingress can create whatever header it wants but needs to d=
o fragmentation (and potentially PLPMTUD over the tunnel with the egress)=
=2E


 


Egress can strip the outer header but not make the inner o=
ne bigger, IMO.


 


Is something else being proposed?


 


Joe





--=_e9353be2dc638d4b259916efce2c29f1--


From nobody Thu Feb 27 15:14:25 2020
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 113443A07F1 for ; Thu, 27 Feb 2020 15:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 L__KgpCv3HzQ for ; Thu, 27 Feb 2020 15:14:14 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 AEF7A3A046A for ; Thu, 27 Feb 2020 15:04:53 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id l12so979674oil.9 for ; Thu, 27 Feb 2020 15:04:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0rBv0363yaZdi8mqIVKBY4lDwldZi9eix+k78cHGhOQ=; b=faBjYQd67u9Muk3/aqbpv1k0sO8vkl0/jOOcQf+o+JwVTFZfIHrsC8s4U2l3w+Ccpa XLNdhgI+DcDxDt5fBTltnurJ4yvEIk9kCP0Drvv3AKjm66jxe3ThqAFwSwIp3f5QXnYo XNDGj4yh8gK+ba3MUF4F/JVQXdB+31swKafkfrenI/aO9E9XD9ichvhmjopyS6eFDdp0 RsvZ7C6EF+drbG/qKE1fEiSwfdDneXezWBS0SkTuAJ9zR81mT6hbWK7Q7jm1GzEFLYZI uH6UL6wHc4LvthzA/rQZw2PtsPME7QP4UqREpovSu9Qw6NItACrQEk2ymS/BaYG64OS2 e1Zg==
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=0rBv0363yaZdi8mqIVKBY4lDwldZi9eix+k78cHGhOQ=; b=RFSojuOPnWwHd5iPTpNd0VIB16jaHZCvj07IuYYxD5EtwK+duJUk60I2usid1t5Yvm u+9hcvv5QG97v44dzL3yNGbnnkGp061iKhME7OL2dDpEfZ3phyPYDiWFcCODSvxC23As 6/UKypNRdvOR0xegDel5cJFupRIsb8Q4U3ZwDZVkBmj0MnQ0eXYnBuCaPBEHJJ3oNVn1 ZwAanz02sJnbgj5la8V6vNx3WW2pSUAsAVxvTZ6BSrVbLNgcB/2LvJiiFqT+T3kYRusT qAQhMNKol5FcF7IlknOL+Wyb84RLp8gzv2NuhYsrHVPeRnX2f9BRrkPfPvjtDioOrSMd 5S3g==
X-Gm-Message-State: APjAAAWw/JW3w6P4f/DGcDme/HmHUgOFVY1G7QdYdnUO7vXVqhBVq/ly RkfYTpO8etMacB7Il2u5a/wPqA4bz3vr6FVEDt2i0w==
X-Google-Smtp-Source: APXvYqxckpDm6rMBlY/6/RWqwiw4FCBXlwrWRgKjzMXv8kfdDaiZU/3yYVTSJkyCYwcbx++uL9M2xLKB4LWWB1KLw3k=
X-Received: by 2002:a05:6808:611:: with SMTP id y17mr1040604oih.146.1582844693064;  Thu, 27 Feb 2020 15:04:53 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
In-Reply-To: 
From: Robert Raszuk 
Date: Fri, 28 Feb 2020 00:04:43 +0100
Message-ID: 
To: Joe Touch 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: multipart/alternative; boundary="000000000000aa3df0059f96bf07"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:14:22 -0000

--000000000000aa3df0059f96bf07
Content-Type: text/plain; charset="UTF-8"

Joe, all,

Just to clarify something Fernando purposely missed in his call for action:

All operations on the packets discussed in SPRING WG are happening NOT on
the original (end to end) packet header. They are all defined to happen
within new imposed outer encapsulated header (IPv6 in IPv6 to be precise).

So original packet just get's tunneled between various points of the
network. Last time I checked that operation is allowed by RFC2473.

Its subtle detail, but fundamental one to this entire context/discussion.

Kind regards,
R.


On Thu, Feb 27, 2020 at 11:54 PM Joe Touch  wrote:

> FWIW - there are separable issues here:
>
> - whether an IP header (or parts thereof) should be changed in transit
>
> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in
> the base header and hop-by-hop options in the options/extension headers.
>
> - whether an IP header length can change in transit
>
> I see no reason why it can't become smaller, but if it can become larger
> then PMTUD and PLPMTUD don't work.
>
> So the question isn't just what is wanted, it's what is feasible.
>
> Joe
>
>

--000000000000aa3df0059f96bf07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Joe, all,

Just to clar=
ify something Fernando purposely=C2=A0missed in his call for action:
<=
div>
All operations on the packets discussed in SPRING WG are=
 happening NOT on the original (end to end) packet header. They are all def=
ined to happen within new imposed outer encapsulated header (IPv6 in IPv6 t=
o be precise).=C2=A0

So original packet just get&#=
39;s tunneled between various points of the network. Last time I checked th=
at operation is allowed by RFC2473.=C2=A0

Its subt=
le detail, but fundamental one to this entire context/discussion.

Kind regards,
R.


On Thu, Feb =
27, 2020 at 11:54 PM Joe Touch <=
touch@strayalpha.com> wrote:


FWIW - there are separable issues here:


- whether an IP header (or parts thereof) should be changed in transit

AFAICT, the answer has always been yes, but =
limited to the hopcount/ttl in the base header and hop-by-hop options in th=
e options/extension headers.


- whether an IP header length can change in transit


I see no reason why it can't become smal=
ler, but if it can become larger then PMTUD and PLPMTUD don't work.


So the question isn't just what is wanted, it's what is feasible=
.


Joe








--000000000000aa3df0059f96bf07--


From nobody Thu Feb 27 15:15:49 2020
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 15B5E3A0811 for ; Thu, 27 Feb 2020 15:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 dt1pyTKbjYus for ; Thu, 27 Feb 2020 15:15:29 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 A1C8D3A087F for ; Thu, 27 Feb 2020 15:15:29 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id i1so1011787oie.8 for ; Thu, 27 Feb 2020 15:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rwz27jg0+sMYZGHQLHB6YOjMiFDjp2b95lfxrg8Bavg=; b=Rc1+mpCShoIAAWO3bNd8I/mkMMDXlZa1Z0jPYrJqd49ompOucGwbu2BXjEgwRz6OC1 TVPKqeLM+TaWGF5iYfRZFQXx/RqZTMURVF+4XNxRLhRqMwTGjfMef6xgh5bZ5eYt7noP lsJpZq96+nl9Sf6zJlQ7qQ7aMkXiX7CRptc8T/mHnzDgc3f1/UT6i0rl8tBWvXm/EhKr lOuKjkrezqvf0zTK6OpnTRWEPq7Xilirwniw/wdZ4QLFp0bSlSSuBfRbzjEeTg8psqD6 ccCxjTnJObvhJuSzc4EgnypDxf+Wi9jIyvmbZT/nA+hsNQvW0XKH0HoEFyxZxh2sD3Zd x1jw==
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=rwz27jg0+sMYZGHQLHB6YOjMiFDjp2b95lfxrg8Bavg=; b=VzFwSImrLYXtPSnZYDdzJB9yckgE9MEq4IqbhQEkJMqR0jM/NNRq1xfzq+XfzoTJiL 5FBaVZlZsTKzp7BxxEIQCQdt3dNaCNSDePvHXbirS2v+zAkrVxzujrb6LRa3TD6+HOVt XgBaL2NW9vCCXVN1LUf6hbgYpifEJv4mW82pQ8vPBvmG1CZnVsO7GJ1Et6woFgCk4NkA o6wi/hLBjFVXzYuvS5V7qgK6I4sT11SrQXOVOOMx0xEjVW+owXkhnUklBsLb4BaG3UWE ooNFybEPGELzVzfZxecgqSP26Ofj3ryfZ4loRftod1gsoP/2cDdfk6UxTrbUaFhCNpCi Uckg==
X-Gm-Message-State: APjAAAVl7CbCeVg6A2e5tAdaI3nxtXvwWIe0cpdb6ouoRf6C5RDKx14Z Eiqa9S15F+cJcy+5Agjnn9EXMVkc05v0hvT0mDOq+g==
X-Google-Smtp-Source: APXvYqyVFEKzWPBKfbq+fylfP3ZHWbIy54IATK6czqWcafW4hUxSurchtnH3qQOxN+HvGIzKAP8Li+C4k/QEQemXZm4=
X-Received: by 2002:aca:4306:: with SMTP id q6mr1133249oia.54.1582845329041; Thu, 27 Feb 2020 15:15:29 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <435b3561fd446be01d7d464e0c0762c5@strayalpha.com>  
In-Reply-To: 
From: Robert Raszuk 
Date: Fri, 28 Feb 2020 00:15:19 +0100
Message-ID: 
To: Joe Touch 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: multipart/alternative; boundary="00000000000092815d059f96e56f"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:15:40 -0000

--00000000000092815d059f96e56f
Content-Type: text/plain; charset="UTF-8"

>  Is something else being proposed?

No. What you said below is exactly what is proposed.

Thank you,
r.

On Fri, Feb 28, 2020 at 12:13 AM Joe Touch  wrote:

> On 2020-02-27 15:10, Robert Raszuk wrote:
>
>
> > It does matter whether it happens at the IP source (origin host, tunnel
> ingress, etc.) or on the path of that header.
>
> It happens on tunnel ingress and tunnel egress nodes (egress = node listed
> in DA of the packet).
>
>
> Ingress can create whatever header it wants but needs to do fragmentation
> (and potentially PLPMTUD over the tunnel with the egress).
>
> Egress can strip the outer header but not make the inner one bigger, IMO.
>
> Is something else being proposed?
>
> Joe
>

--00000000000092815d059f96e56f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



>=C2=A0 Is something else be=
ing proposed?=C2=A0

No. What you said below is exactly w=
hat is proposed.=C2=A0

Thank you,
r.=C2=
=A0

On Fri, Feb 28, 2020 at 12:13 AM Joe Touch <touch@strayalpha.com> wrote:


On 2020-02-27 15:10, Robert Raszuk wrote:=









=C2=A0


> It does matter whether it happens at the IP source (origin host, t=
unnel ingress, etc.) or on the path of that header.


=C2=A0

It happens on tunnel ingress and tunnel egress nodes (egress =3D node liste=
d in DA of the=C2=A0packet). 








=C2=A0


Ingress can create whatever header it wants but needs to d=
o fragmentation (and potentially PLPMTUD over the tunnel with the egress).<=
/div>

=C2=A0


Egress can strip the outer header but not make the inner o=
ne bigger, IMO.


=C2=A0


Is something else being proposed?


=C2=A0


Joe








--00000000000092815d059f96e56f--


From nobody Thu Feb 27 15:21:18 2020
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 E5EFE3A07B9; Thu, 27 Feb 2020 15:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 CZZlVtwUcFro; Thu, 27 Feb 2020 15:21:11 -0800 (PST)
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 B460C3A07B0; Thu, 27 Feb 2020 15:21:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=chN2PizV8jhdCwwKxp8Kib8UHGfNRC+ayuODi46bXOc=; b=6FU9ZsClI0pxmIk4YqC0Udttl 7qlWyr5rgRAlO+vZV3fIVkTi+Lq8TsfqSj1thjZLwkjmh+WRv2yY+2nbrcMDJ5cMRbc8Q2UpyUmo9 IJ3HfRDeR/+Pil4DyAjibtJe5GMG5Y56PehHJicTenH743JVrgfCFbTVQxc5PaFd6PFz8XqL/kC3q 8M1O7KRumpWlyWjptr6sUFKdwTB6rJJVfWOvNH0HNZDB34KvEJFe9GcfE3WrmcL2+ULf9W86RfY81 B8/I8Kif3tBv6oNtYCSm2AFnm+bWWZTq1dBUZfs/YrmZVoi7Hn2zyqJ9Mj4Q0rN7U1yZlnSGUZUNw GWCWGBxiA==;
Received: from [::1] (port=40812 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1j7SSp-001j9k-KI; Thu, 27 Feb 2020 18:21:11 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_3f338b4322f86b70b3d43c246ea52353"
Date: Thu, 27 Feb 2020 15:21:07 -0800
From: Joe Touch 
To: Fernando Gont 
Cc: Tom Herbert , architecture-discuss@iab.org, Internet Architecture Board , Internet Area , ietf@ietf.org
In-Reply-To: <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com>
Message-ID: <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:21:13 -0000

--=_3f338b4322f86b70b3d43c246ea52353
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

EH isn't a HBH option or extension. 

Joe 

On 2020-02-27 15:06, Fernando Gont wrote:

> On 27/2/20 19:52, Joe Touch wrote: 
> 
>> FWIW - there are separable issues here:
>> 
>> - whether an IP header (or parts thereof) should be changed in transit
>> 
>> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.
>> 
>> - whether an IP header length can change in transit
>> 
>> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work.
> 
> Besides AH (which obviously breaks), hosts typically try to validate that the error messages they receive correspond to something they actually sent.
> 
> EH removal breaks that.
--=_3f338b4322f86b70b3d43c246ea52353
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



EH isn't a HBH option or extension.


Joe


On 2020-02-27 15:06, Fernando Gont wrote:




=
On 27/2/20 19:52, Joe&n=
bsp;Touch wrote:

FWIW - =
there are separable issues here:

- whether an IP header=
 (or parts thereof) should be changed in=
 transit

 AFAICT, the answer has always been yes, bu=
t limited to the hopcount/ttl in the base header and hop-by-hop options in =
the options/extension headers.

- whether an IP header length can ch=
ange in transit

 I see no reason why it can't b=
ecome smaller, but if it can become larger then PMTUD and PLPMTUD don't wor=
k.


 Besides AH (which obviously breaks), hosts typically try to validate=
 that the error messages they receive correspond to something they actually=
 sent.

EH removal =
;breaks that.





--=_3f338b4322f86b70b3d43c246ea52353--


From nobody Thu Feb 27 15:37:18 2020
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 34B1D3A08AE; Thu, 27 Feb 2020 15:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 fzS_EGuR34CR; Thu, 27 Feb 2020 15:36:59 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B0B3A088C; Thu, 27 Feb 2020 15:36:58 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 56CE382A8B; Fri, 28 Feb 2020 00:36:51 +0100 (CET)
To: Joe Touch 
Cc: Tom Herbert , architecture-discuss@iab.org, Internet Architecture Board , Internet Area , ietf@ietf.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>
From: Fernando Gont 
Message-ID: 
Date: Thu, 27 Feb 2020 20:36:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:37:06 -0000

Joe,

What draft-ietf-spring-srv6-network-programming proposes is to remove a 
segment routing header (SRH) along the packet delivery path, before the 
packet arrives at the final destination. They call it PSP.

Before, folks have also proposed to insert Extension Headers (EHs) while 
packets are en-route to their intended destination, etc.

Thanks,
Fernando




On 27/2/20 20:21, Joe Touch wrote:
> EH isn't a HBH option or extension.
> 
> Joe
> 
> On 2020-02-27 15:06, Fernando Gont wrote:
> 
>> On 27/2/20 19:52, Joe Touch wrote:
>>> FWIW - there are separable issues here:
>>>
>>> - whether an IP header (or parts thereof) should be changed in transit
>>>
>>> AFAICT, the answer has always been yes, but limited to the 
>>> hopcount/ttl in the base header and hop-by-hop options in the 
>>> options/extension headers.
>>>
>>> - whether an IP header length can change in transit
>>>
>>> I see no reason why it can't become smaller, but if it can become 
>>> larger then PMTUD and PLPMTUD don't work.
>>
>> Besides AH (which obviously breaks), hosts typically try to validate 
>> that the error messages they receive correspond to something they 
>> actually sent.
>>
>> EH removal breaks that.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 15:55:00 2020
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 D60383A0926; Thu, 27 Feb 2020 15:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAyOCROw4zdd; Thu, 27 Feb 2020 15:54:43 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 1ABD93A0945; Thu, 27 Feb 2020 15:54:43 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AD6F43AB009; Thu, 27 Feb 2020 23:54:42 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 99565160044; Thu, 27 Feb 2020 23:54:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 74353160071; Thu, 27 Feb 2020 23:54:42 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MW9AYVJ13q7I; Thu, 27 Feb 2020 23:54:42 +0000 (UTC)
Received: from [172.30.42.69] (unknown [49.2.105.120]) by zmx1.isc.org (Postfix) with ESMTPSA id C98D2160044; Thu, 27 Feb 2020 23:54:40 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews 
In-Reply-To: 
Date: Fri, 28 Feb 2020 10:54:37 +1100
Cc: Joe Touch , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF-Discussion 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A8582D7-1647-41EC-808D-46C380565014@isc.org>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
To: Tom Herbert 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:54:57 -0000

> On 28 Feb 2020, at 10:00, Tom Herbert  wrote:
>=20
> On Thu, Feb 27, 2020 at 2:52 PM Joe Touch  =
wrote:
>>=20
>> FWIW - there are separable issues here:
>>=20
>> - whether an IP header (or parts thereof) should be changed in =
transit
>>=20
>> AFAICT, the answer has always been yes, but limited to the =
hopcount/ttl in the base header and hop-by-hop options in the =
options/extension headers.
>>=20
>> - whether an IP header length can change in transit
>>=20
>> I see no reason why it can't become smaller, but if it can become =
larger then PMTUD and PLPMTUD don't work.
>>=20
>> So the question isn't just what is wanted, it's what is feasible.
>>=20
> Joe,
>=20
> Per the problem about making packets larger in the network, I'd point
> out that this is already common due to in-network tunneling. In any
> case, it's really the only interesting case here (as opposed to making
> packets smaller).

Encapsulation doesn=E2=80=99t make the packet larger.  It is no =
different to
talking a packet from a ethernet and pushing it out a PPP link.  The
Enclosing headers differ in sizes but the IPv6 packet remains the
same size.

The difference with encapsulation, from the non encapsulation cases, is
that PTBs are sent to the encapsulating node which has to synthesis a
PTB to the original (as far as the encapsulating node is concerned)
sender when they are received with the MTU reduced by the encapsulation
overhead and the encapsulation header removed from the PTB payload.  The
sender of the un-encapsulated packet sees PTB with a MTU which will =
allow
future packets pass both the encapsulating node and the node which =
generated
the PTB of the encapsulated packet and the packet headers it originally =
sent.

Mark

> Tom
>=20
>> Joe
>>=20
>>=20
>>=20
>>=20
>> On 2020-02-27 14:07, Tom Herbert wrote:
>>=20
>> Fernando,
>>=20
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes. IMO extension header insertion is a great example of that.
>> On one hand we have people quoting IPv6 saying that it isn't allowed
>> per RFC8200-- period! And on other side there are proponents that see
>> a real need for it and believe they have clear use case-- at one
>> presentation in IETF a proponent bluntly stated that regardless of =
any
>> discussion in IETF they're going to do it! IMO, what we haven't seen,
>> was a real attempt to resolve and work out the engineering issues.
>> That's not for lack of trying-- for instance I proposed a direction =
to
>> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
>> but saw little discussion on that.
>>=20
>> Tom
>>=20
>> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  =
wrote:
>>=20
>>=20
>> Folks,
>>=20
>> If you haven't been following recent developments in the Spring WG, =
you
>> may be surprised about some of the work that is being pursued (or was
>> being pursued)-
>>=20
>> Such work has included proposing that some IPv6 routers insert and
>> remove routing headers en-route to the final destination.
>>=20
>> After many very heated and lengthy debates, some of this work was
>> dropped, but other remains (e.g. routers removing IPv6 EHs from =
packets
>> en-route to their final destination, part of what they call "PSP"). =
For
>> the most part, the proponents have argued that "we have implemented =
it,
>> and the industry wants it" -- as if we just have to rubberstamp what
>> they have done.
>>=20
>> On the technical side, the proponents have argued that:
>>=20
>>     If a packet employs source routing (and hence its Destination
>>     Address is modified en-route to direct the packet through each
>>     of these "waypoints"), then any of such "waypoint" routers are
>>     free to add or remove IPv6 extension headers at will. (No, not
>>     encap/decap, but rather add/remove EHs from the IPv6 header
>>     chain).
>>=20
>> That seems to me like a very major deviation from what's supposed to =
be
>> our current "architecture", where IPv6 is an end to end protocol.
>> Besides, it should be obvious that removal/insertion of EHs en-route
>> error reporting (since host typically check that the ICMP errors they
>> receive correspond to something that they actually sent).
>>=20
>>=20
>> A number of us have raised this a number of times, and at least some =
of
>> us feel that our concerns are being ignored.
>>=20
>> It would seem to me that these documents and decisions have a =
concrete
>> impact on our architecture, and that they are being pursued without =
any
>> proper oversight. There is also a widespread feeling that having one =
or
>> a few big vendors pushing these ideas might be playing a role here.
>>=20
>> (See, for instance:
>>=20
>> * =
https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>>=20
>> * =
https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
>> )
>>=20
>> What I would expect is that all thes major changes to our existing
>> architecture and protocols would only done by formally updating =
existing
>> standards *if* deemed appropriate, as opposed to just trying to sneak
>> changes "when nobody is watching", or by having very curious
>> interpretations of our protocols and standards.
>>=20
>> I've raised the topic to our AD (Suresh), to the IAB, and on the =
arch-d
>> list before, but so far haven't been lucky or seen anything =
meaningful
>> happen in this area.
>>=20
>> I have also submitted an errata to make RFC8200 even more clear on =
the
>> topic, but it remains unprocessed.
>>=20
>> So my questions are:
>>=20
>> * On the technical area:
>>=20
>>  + Is IPv6 an End To End protocol?  Or is the IETF's stance that
>> routers are free to mangle with the packet structure as they please?
>>=20
>>  + Was IPv6 designed that way? And if it wasn't, when/how was the
>> architecture changed?
>>=20
>>=20
>> * On the procedural area:
>>=20
>>   + Where/how should IETF WGs seek for architecture-related advice?
>>=20
>>   + What do do in situations like the above?  Wait and see how things
>>     evolve, and upon any formal decisions, just submit formal Appeals
>>     if deemed necessary?  (and after way too much energy consumed =
from
>>     everyone)
>>=20
>>     I would have expected that as soon as these issues were raised,
>>     the offending text would be removed rightaway. But that wasn't
>>     the case. And when the changes did happen, it wasn't without
>>     an extraordinary waste of time and energy from all of us.
>>     For instance, any work on IPv6 header insertion/deletion wouldn't
>>     seem to fit within the charters of the 6man or spring wgs.
>>=20
>>=20
>>     FWIW, this is not the first instance of issues surrounding the =
same
>>     topic. It goes back to the rfc2460bis effort, when a similar set =
of
>>     folks (too many from one big vendor) got to have 6man ship
>>     what became RFC8200 with a noted "ambiguity", just to be able
>>     to have some playground for EH insertion/deletion. And we only =
got
>>     to improve on that during IETF LC:
>>=20
>>    (see:
>> =
https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>>=20
>>=20
>> Thoughts or advice on the technical and/or procedural aspects will be
>> appreciated.
>>=20
>> Thanks!
>>=20
>> Cheers,
>> Fernando
>>=20
>>=20
>>=20
>>=20
>> -------- Forwarded Message --------
>> Subject: Errata #5933 for RFC8200
>> Date: Thu, 27 Feb 2020 17:07:36 -0300
>> From: Fernando Gont 
>> To: Suresh Krishnan 
>> CC: 6man@ietf.org <6man@ietf.org>
>>=20
>> Suresh,
>>=20
>> Two months ago I filled an errata on RFC8200 regarding the processing =
of
>> IPv6 extension headers. The errata is available here:
>> https://www.rfc-editor.org/errata/eid5933
>>=20
>> While I believe that folks with a knowledge of Internet Protocols =
would
>> be able to interpret what is in RFC8200, given recent discussions on =
the
>> topic, and upon a re-read of the text, I believe a clarification is
>> warranted, such that we allow all sorts of curious interpretations of
>> the text.
>>=20
>> I send a heads-up on the 6man mailing list
>> =
(https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),=

>> and the proposed text received the review of at least Brian =
Carpenter,
>> Ron Bonica, and Mark Smith. Their reviews are available on such =
thread.
>>=20
>> In the light that some folks seem to be pretending to leverage "the =
lack
>> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
>> appreciate that the reported errata be processed.
>>=20
>> Processing the aforementioned errata is key to many of the =
discussions
>> this and other WGs are having.
>>=20
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>=20
>>=20
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>=20

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org


From nobody Thu Feb 27 15:58:26 2020
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 31EDD3A08FF for ; Thu, 27 Feb 2020 15:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 Sk4udxgzvejL for ; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 8FE1D3A08FA for ; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id d62so1085843oia.11 for ; Thu, 27 Feb 2020 15:58:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gbFgz2Z6I9LvUieMphUsPZoJ9StwZIxZle6TOd4iIc0=; b=STi+v9HOefhB+5cwHq9xksKoj7Hiqiux2pBvuQ15QK/XcT3taSg2msHEBDE/TTDSA6 0Hf6uPUtUPN0TJmybCpJ6W4/pHI+g+RwEkBc2y85wzJBkenoFM8Bnzi7PbrXQVqDHHoy eImTsQjHpNWcTFeUUHGVGpxthtVhTmbrZ2Tkg4eKNhV9zdvY0ZKM+Rs7o7gvHmzENSp9 8Q/uFoNaNm3/oXzn8Zu3oKCcZXarV5y+tGqeMQCbLb4B0RuMhWxw3eyBmnapYbtpMPT1 +a+Zo78l/wlrFAR1ppA3fPmLal7ZqyTQ0BFsoi5aG0tEkWxF6VRn+Ja4AnQst5q5u2hq LGjQ==
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=gbFgz2Z6I9LvUieMphUsPZoJ9StwZIxZle6TOd4iIc0=; b=GrsrrTfnK6lkA0IEmiZdZm2bUiTBK+hMiS6ipMv4g52qQa4EsDLXftHh/fiOZvi3LH GWTrPAFZ7Xg19FtOth0/3wbsRkrLyq/cyqvSNrkDGtEv0yy2XO6DGEAzMJJcFnGwcgdw nNK/oynAgkMLh4PBFeveIHUYe0beDYywH7BELtnnFdctirXvkdakmpWAZQsfwNxvPcXZ VVduv17vMQICyHLcjHzElUelbRCUQKTX9t8Ikq99ZJHnEJIorPjAhRJ5UZ6NyVTsg4VM 9FTOTKBtWt8DJmQYPbdYgkK5Caeu2nfaBHeRef8QXQlNss+Vqlf+IrMjabf/3yXTNnu3 BVPw==
X-Gm-Message-State: APjAAAWgdAKwe3+t+EjjBBuESWo2rmAGEfUCiwq4nF1x5CAebVn7kYmZ hMYVcUFupw70Gmz6ZERvbLBdi3JgtrqQd1+BFFRCeQ==
X-Google-Smtp-Source: APXvYqyaFSKSkamoJ3xLvcO/sVd430GJXEGqebLPgfb2qi069vJ2kCHMwi+MDNX6/GWq2I0RKi/feOU8epHu1VWf/A8=
X-Received: by 2002:a54:4510:: with SMTP id l16mr1219186oil.70.1582847901816;  Thu, 27 Feb 2020 15:58:21 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com> 
In-Reply-To: 
From: Robert Raszuk 
Date: Fri, 28 Feb 2020 00:58:11 +0100
Message-ID: 
To: Fernando Gont 
Cc: Joe Touch , Tom Herbert ,  Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: multipart/alternative; boundary="000000000000ebf261059f977eb7"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 27 Feb 2020 23:58:24 -0000

--000000000000ebf261059f977eb7
Content-Type: text/plain; charset="UTF-8"

> What draft-ietf-spring-srv6-network-programming proposes is to remove a
> segment routing header (SRH) along the packet delivery path, before the
> packet arrives at the final destination. They call it PSP.

That removal as it has been explained to you many times happens at the node
which is explicitly listed as DA of the packet.

>  Before, folks have also proposed to insert Extension Headers (EHs) while
> packets are en-route to their intended destination, etc.

That has been moved to a separate draft to move fwd with the rest of the
work.

Yes this is still useful for TI-LFA (as example).

We need to ask ourselves what is more important ... quality of data plane
for end users with 10s of ms of connectivity restoration times upon failure
or keeping original IPv6 dogmas in place where folks never envisioned such
needs or technologies to be invented.

Rgs,
R.


On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont 
wrote:

> Joe,
>
> What draft-ietf-spring-srv6-network-programming proposes is to remove a
> segment routing header (SRH) along the packet delivery path, before the
> packet arrives at the final destination. They call it PSP.
>
> Before, folks have also proposed to insert Extension Headers (EHs) while
> packets are en-route to their intended destination, etc.
>
> Thanks,
> Fernando
>
>
>
>
> On 27/2/20 20:21, Joe Touch wrote:
> > EH isn't a HBH option or extension.
> >
> > Joe
> >
> > On 2020-02-27 15:06, Fernando Gont wrote:
> >
> >> On 27/2/20 19:52, Joe Touch wrote:
> >>> FWIW - there are separable issues here:
> >>>
> >>> - whether an IP header (or parts thereof) should be changed in transit
> >>>
> >>> AFAICT, the answer has always been yes, but limited to the
> >>> hopcount/ttl in the base header and hop-by-hop options in the
> >>> options/extension headers.
> >>>
> >>> - whether an IP header length can change in transit
> >>>
> >>> I see no reason why it can't become smaller, but if it can become
> >>> larger then PMTUD and PLPMTUD don't work.
> >>
> >> Besides AH (which obviously breaks), hosts typically try to validate
> >> that the error messages they receive correspond to something they
> >> actually sent.
> >>
> >> EH removal breaks that.
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

--000000000000ebf261059f977eb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



> What draf=
t-ietf-spring-srv6-network-programming proposes is to remove a=C2=A0
<=
div dir=3D"ltr">>=C2=A0segment routing header (SRH) along the packet del=
ivery path, before the=C2=A0
>=C2=A0packet arrives=
 at the final destination. They call it PSP.=C2=A0
That removal as it has been explained to you many times happen=
s at the node which is explicitly=C2=A0listed as DA of the packet.=C2=A0

>=C2=A0 Before, folks hav=
e also proposed to insert Extension Headers (EHs) while 
> packets ar=
e en-route to their intended destination, etc.
That has been moved to a separate draft to move fwd with the r=
est of the work.=C2=A0

Yes this is sti=
ll useful for TI-LFA (as example).=C2=A0

We need t=
o ask ourselves what is more important ... quality of data plane for end us=
ers with 10s of ms of connectivity restoration times upon failure or keepin=
g original IPv6 dogmas in place where folks never envisioned such needs or =
technologies to be invented.=C2=A0

Rgs,
=
R.
=C2=A0

On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont <fgont@si6networks.com> wrote:
Joe,



What draft-ietf-spring-srv6-network-programming proposes is to remove a 
segment routing header (SRH) along the packet delivery path, before the 
packet arrives at the final destination. They call it PSP.



Before, folks have also proposed to insert Extension Headers (EHs) while 
packets are en-route to their intended destination, etc.



Thanks,

Fernando









On 27/2/20 20:21, Joe Touch wrote:

> EH isn't a HBH option or extension.

> 

> Joe

> 

> On 2020-02-27 15:06, Fernando Gont wrote:

> 

>> On=C2=A027/2/20=C2=A019:52,=C2=A0Joe=C2=A0Touch=C2=A0wrote:

>>> FWIW=C2=A0-=C2=A0there=C2=A0are=C2=A0separable=C2=A0issues=C2=
=A0here:

>>>

>>> -=C2=A0whether=C2=A0an=C2=A0IP=C2=A0header=C2=A0(or=C2=A0parts=
=C2=A0thereof)=C2=A0should=C2=A0be=C2=A0changed=C2=A0in=C2=A0transit

>>>

>>> AFAICT, the answer has always been yes, but limited to the 
>>> hopcount/ttl in the base header and hop-by-hop options in the =


>>> options/extension headers.

>>>

>>> -=C2=A0whether=C2=A0an=C2=A0IP=C2=A0header=C2=A0length=C2=A0ca=
n=C2=A0change=C2=A0in=C2=A0transit

>>>

>>> I see no reason why it can't become smaller, but if it can=
 become 

>>> larger then PMTUD and PLPMTUD don't work.

>>

>> Besides AH (which obviously breaks), hosts typically try to valida=
te 

>> that the error messages they receive correspond to something they =


>> actually sent.

>>

>> EH=C2=A0removal=C2=A0breaks=C2=A0that.





-- 

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492












--000000000000ebf261059f977eb7--


From nobody Thu Feb 27 16:21:59 2020
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 80ABD3A09EF; Thu, 27 Feb 2020 16:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level: 
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sNgVStXV-tU0; Thu, 27 Feb 2020 16:21:56 -0800 (PST)
Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 C567E3A09EC; Thu, 27 Feb 2020 16:21:55 -0800 (PST)
Received: by mail-ot1-f41.google.com with SMTP id 66so993164otd.9; Thu, 27 Feb 2020 16:21:55 -0800 (PST)
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=gSix1Je2Q0HDku6KA0XkNiXjesG5r3+iNEkHOUGpkL4=; b=WWQ0yF4dOaV0NbP0ClH5PWtXL61yZ9v4xcwREgDzmGLB1XvLny/TXAQ/GePpQf6jVF vMrLYjlLSz6MJJ8X9v9q4UdprV38Dd8tjV5a2zn6DGBp0Vddd4u3bD+tVwDDoFcIpI8Q B6EC7UyWVRzwhLxKfEqNNiEikcW9WM3KW1XTz4BvycPJKT5+q8LRKQKIVp5HwqVQf356 6uBd3dAPicxXOlvfzQngjYsMQ0E7sH9H3aermXqNQFYOslVvmeP9h0KINPKGsvVHRL6s 3HdWOTcvUPatYr3t6oy0YexPyplR1XAezZIxilmX1C7xX8Hvbk/1Fk1BuqRvv1ipr5OD SeBw==
X-Gm-Message-State: APjAAAU+FbGztfZGtfRnhvp6F6GUmSFkVwDH9a1StKwGQc4gMoEHPyWd hNmmkjHAW4bh8gCcpXd1/LBYAMWInGt2QyTmMck=
X-Google-Smtp-Source: APXvYqxBUMJcKlFspbLfW6QoiVgoDqAqJ/ynSIxRU1ixeQiVoigGpL4kUQmY8H6NLy0gG6lU+nZeEoBykNCBD0hccmM=
X-Received: by 2002:a05:6830:1305:: with SMTP id p5mr1166669otq.124.1582849315120;  Thu, 27 Feb 2020 16:21:55 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>
In-Reply-To: <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>
From: Phillip Hallam-Baker 
Date: Thu, 27 Feb 2020 19:21:43 -0500
Message-ID: 
To: Joe Touch 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF Discussion Mailing List 
Content-Type: multipart/alternative; boundary="000000000000292c16059f97d302"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 00:21:58 -0000

--000000000000292c16059f97d302
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020 at 5:47 PM Joe Touch  wrote:

> On 2020-02-27 14:26, Phillip Hallam-Baker wrote:
>
> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:
>
>> Fernando,
>>
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
>
>
> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will.
>
>
> Actually, that's the only thing it ever meant and always will. When
> addresses change, *by definition*, the*ends* change (and yes, that's what
> NATs do - they create end-to-end CONTENT transfer over separate end-to-end
> Internets).
>

By whose definition? Not by mine.

TCP and TLS give me a reliable end-to-end stream. The fact that the IP
address is exposed is merely an unfortunate defect in the legacy APIs.

As the application layer designer, I am the customer here. I do not care
about the IP address.



> ..
> We discovered that there were good reasons for NATing IPv4 besides address
> multiplexing. The topology of my network is none of your business.
>
>
> Agreed; there's nothing that forces you to use IP addresses in a way that
> exposes your topology (you're free to build a net using host routing). That
> has nothing to do with NAT.
>
> I have not found a rationale for NATs that doesn't start and end with a
> business model where servers are charged business rates and clients are
> charged customer rates. Everything else about NATs either isn't a NAT
> property (hiding topology) or can be achieved by a stateful firewall (that
> predates NATs by a decade, e.g. that lets outgoing connections go through
> but not incoming).
>

Then you have had a remarkably sheltered upbringing.

Concealing details of the internal network structure is only common sense.



>
>
> More generally, Internet standards only apply to the Inter-net, the
> network of networks. What happens inside the networks at either end is for
> the owners of those networks to decide. If we go back to the original
> Internet design, they didn't even need to run IP. IP end to end come later.
>
>
> That's true, but then their "end" on the public Internet would be the
> firewall or NAT box at their edge.
>

There isn't a single 'end' in a protocol which is one of the reasons
end-to-end security has been done so badly. If Alice sends Bob a business
email, we have the following ends:

1) Application layer: SUBMIT Client -> SUBMIT Service, SMTP Client -> SMTP
Service, IMAP Client -> IMAP Service.
2) Message layer: Alice Email client -> Bob Email Client
3) Trust: Alice's employer <-> Bob's employer

Feel free to introduce extra ends if you like, it is irrelevant to my
concerns at the application layer.



>
>
> So let us stop being dogmatic about things that don't actually matter. The
> only job of the network layer is to get packets from one end to another.
> The only job of the transport layer is to provide reliable streams. An
> application protocol that depends on the IP address remaining constant end
> to end is a bad protocol and should be rejected.
>
>
> That's a very OSI view of protocols - about as out-dated and about as
> useful., IMO. Every layer of the stack might be involved in any function;
> anything that claims a single layer owns a single job hasn't existed since
> at least IP over IP.
>

The notion of encapsulation has been established in the object oriented
programming world for decades. The notion that the application program
should be abstracted from the transport and network layer is hardly a
controversial one.

As for OSI, I would not know as I have not made a detailed study of it. It
is not a model I find interesting as it doesn't describe the role of the
naming systems and it isn't able to describe systems like SDN and VPN which
we make use of.

--000000000000292c16059f97d302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


<=
font face=3D"arial, sans-serif" size=3D"4">

On Thu, Feb 27, 2020 at 5:47 PM Joe Touch <touch@strayalpha.com> wrote:


On 2020-02-27 14:26, Phillip=
 Hallam-Baker wrote:








On Thu, Feb 27,=
 2020 at 5:09 PM Tom Herbert <tom@herbertland.com> wrote:






Fernando,

 I think we need to be careful that IET=
F is labeled as a collection of
 inflexible architectural purists. We kn=
ow that standards conformance
 is voluntary and we haven't seen the =
last time that someone, possibly
 even a major vendor, will circumvent t=
he system for their own
 purposes.


=C2=A0


IP end to end d=
oes not mean the IP address is constant end to end. It never has meant that=
 and never will.












=C2=A0

Actually, that&=
#39;s the only thing it ever meant and always will. When addresses change, =
*by definition*, the*ends* change (and yes, that's what NATs do - they =
create end-to-end CONTENT transfer over separate end-to-end Internets).

By whose definition? Not by mi=
ne.

TCP and TLS give me a re=
liable end-to-end stream. The fact that the IP address is exposed is merely=
 an unfortunate defect in the legacy APIs.=C2=A0

<=
/font>
As the application layer designer, I am the customer h=
ere. I do not care about the IP address. 

=C2=A0










..

We disco=
vered that there were good reasons for NATing IPv4 besides address multiple=
xing. The topology of my network is none of your business.












=C2=A0

Agreed; there&#=
39;s nothing that forces you to use IP addresses in a way that exposes your=
 topology (you're free to build a net using host routing). That has not=
hing to do with NAT.


=C2=A0

I have not foun=
d a rationale for NATs that doesn't start and end with a business model=
 where servers are charged business rates and clients are charged customer =
rates. Everything else about NATs either isn't a NAT property (hiding t=
opology) or can be achieved by a stateful firewall (that predates NATs by a=
 decade, e.g. that lets outgoing connections go through but not incoming).<=
/font>

Then you have had a remar=
kably sheltered upbringing.

Concealing details of the internal network structure is only common sense.=
 

=

=C2=A0


=C2=A0











More generally,=
 Internet standards only apply to the Inter-net, the network of networks. W=
hat happens inside the networks at either end is for the owners of those ne=
tworks to decide. If we go back to the original Internet design, they didn&=
#39;t even need to run IP. IP end to end come later.












=C2=A0

That's true=
, but then their "end" on the public Internet would be the firewa=
ll or NAT box at their edge.

There isn't a single 'end' in a protocol which is one of the =
reasons end-to-end security has been done so badly. If Alice sends Bob a bu=
siness email, we have the following ends:

<=
/div>
1) Application layer: SUBMIT Client -> SUBMIT Service, SMT=
P Client -> SMTP Service, IMAP Client -> IMAP Service.
2) Message layer: Alice Email client -> Bob Email Client
3) Trust: Alice's employer <-> Bob's employer

Feel free to introduce extra ends if you like, it is irrelevant t=
o my concerns at the application layer.

=C2=A0


=C2=A0











So let us stop =
being dogmatic about things that don't actually matter. The only job of=
 the network layer is to get packets from one end to another. The only job =
of the transport layer is to provide reliable streams. An application proto=
col that depends on the IP address remaining constant end to end is a bad p=
rotocol and should be rejected. 












=C2=A0

That's a ve=
ry OSI view of protocols - about as out-dated and about as useful., IMO. Ev=
ery layer of the stack might be involved in any function; anything that cla=
ims a single layer owns a single job hasn't existed since at least IP o=
ver IP.

The notion of encap=
sulation has been established in the object oriented programming world for =
decades. The notion that the application program should be abstracted from =
the transport and network layer is hardly a controversial=C2=A0one.<=
/div>
=
As for OSI, I would not know as I have not made a detailed=
 study of it. It is not a model I find interesting as it doesn't descri=
be the role of the naming systems and it isn't able to describe systems=
 like SDN and VPN which we make use of.=C2=A0

<=
/div>

--000000000000292c16059f97d302--


From nobody Thu Feb 27 16:28:06 2020
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 007263A0A11; Thu, 27 Feb 2020 16:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level: 
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hKWBHH0Reg6i; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 AF73B3A0A12; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
Received: by mail-ot1-f53.google.com with SMTP id r16so1047684otd.2; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
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=I7EJiQgN10DRsEZihzbK4/8wIKUvJXpq/NcQY7yOPm8=; b=ilGsEGNLmJymyY4hJGUi0R1Iapy02svY+z0sJaYYVGRQjw90nO4KEz86Rq2KBcpI6R csn0vRNCJETIV9T7IVlMCdBLO4MaCI66NMwuxME8JhJq80d2IA4JRfN1bwTRLxEiZL39 UltU/Lbvvl6WhiWHkewU45VM4oeueMMzkqRYNJBRyWtDsgLL/4iI1tatSLDkbF4YtxRC ZY8LRoFI41gUTnUOZfYjYNvVS5Ce7w8iiAPzYQzhX8uiaf1JdrRvdU1PdggNdFA8kZXs lJyo9h2fuoPEaeAqmPg+lCcDkQ3mcxtaeI5+y76O3noVoA1tcqFs0ziohEtVMJxhbtYF uYEg==
X-Gm-Message-State: APjAAAX1AtpFEeLBjmJ44kFbdrPGajaX2v/haL0qL+XZNJ7zMaqyxbt+ tFTz5jzIMkEWZ/HN4j1qwbK/r9B4u1eQTEPqOks=
X-Google-Smtp-Source: APXvYqy94Szh5ibyPFdBR0boturKsH4XJ2TOQFFt+ethUyiquKeIaR82xdYUA+SzeUF0P25nx1T2Gwa1OaJGFzE1ouU=
X-Received: by 2002:a05:6830:154a:: with SMTP id l10mr1276285otp.44.1582849673998;  Thu, 27 Feb 2020 16:27:53 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Thu, 27 Feb 2020 19:27:41 -0500
Message-ID: 
To: Tom Herbert 
Cc: Fernando Gont , architecture-discuss@iab.org,  Internet Architecture Board , Internet Area ,  "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000008d348d059f97e816"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 00:27:56 -0000

--0000000000008d348d059f97e816
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert  wrote:

>
>
> On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker 
> wrote:
>
>> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:
>>
>>> Fernando,
>>>
>>> I think we need to be careful that IETF is labeled as a collection of
>>> inflexible architectural purists. We know that standards conformance
>>> is voluntary and we haven't seen the last time that someone, possibly
>>> even a major vendor, will circumvent the system for their own
>>> purposes.
>>>
>>
>> IP end to end does not mean the IP address is constant end to end. It
>> never has meant that and never will. An IP address is merely a piece of
>> data that allows a packet to reach its destination. There is no reason to
>> insist on it remaining constant along the path.
>>
>> The sooner people get over that fact the better.
>>
>> If an IPv4 device interacts with an IPv6 device, there will be address
>> translation going on somewhere along the path. That is inevitable.
>>
>> We discovered that there were good reasons for NATing IPv4 besides
>> address multiplexing. The topology of my network is none of your business.
>>
>> More generally, Internet standards only apply to the Inter-net, the
>> network of networks. What happens inside the networks at either end is for
>> the owners of those networks to decide. If we go back to the original
>> Internet design, they didn't even need to run IP. IP end to end come later.
>>
>> So let us stop being dogmatic about things that don't actually matter.
>> The only job of the network layer is to get packets from one end to
>> another. The only job of the transport layer is to provide reliable
>> streams. An application protocol that depends on the IP address remaining
>> constant end to end is a bad protocol and should be rejected.
>>
>
> So Authentication Header and any other sort of Inetwork layer
> authentication are bad protocols that should be rejected?
>

The IPSEC authentication header is a complete failure of design. It is the
reason IPSEC doesn't work in the real world and has been replaced by SSH.

Stuff that doesn't work in the real world is just bad and should be
rejected. I remember the security ADs of the time smirking as they said
IPSEC not working with NAT represented a feature, not a bug. They were
wrong then and you are wrong now.

--0000000000008d348d059f97e816
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert <tom@herbertland.com> wrote:
<=
/div>


On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote=
:
On Thu, Feb 27, 2020 at =
5:09 PM Tom Herbert <tom@herbertland.com> wrote:
=

IP =
end to end does not mean the IP address is constant end to end. It never ha=
s meant that and never will. An IP address is merely a piece of data that a=
llows a packet to reach=C2=A0its destination. There is no reason to insist =
on it remaining constant along the path.=C2=A0

The sooner people get over=
 that fact the better.

If an IPv4 device interacts with an IPv6 device, t=
here will be address translation going on somewhere along the path. That is=
 inevitable.

We discovered that there were good reasons for NATing IPv4 b=
esides address multiplexing. The topology of my network is none of your bus=
iness.

More generally, Internet standards only apply to the Inter-net, th=
e network of networks. What happens inside the networks at either end is fo=
r the owners of those networks to decide. If we go back to the original Int=
ernet design, they didn't even need to run IP. IP end to end come later=
.

So let us stop being dogmatic about things that don't actually matt=
er. The only job of the network layer is to get packets from one end to ano=
ther. The only job of the transport layer is to provide reliable streams. A=
n application protocol that depends on the IP address remaining constant en=
d to end is a bad protocol and should be rejected.=C2=A0
<=
/blockquote>

So Au=
thentication Header and any other sort of Inetwork layer authentication are=
 bad protocols that should be rejected?

The IPSEC a=
uthentication header is a complete failure of design. It is the reason IPSE=
C doesn't work in the real world and has been replaced by SSH.

Stuff that doesn't work in th=
e real world is just bad and should be rejected. I remember the security AD=
s of the time smirking as they said IPSEC not working with NAT represented =
a feature, not a bug. They were wrong then and you are wrong now.



--0000000000008d348d059f97e816--


From nobody Thu Feb 27 16:39:38 2020
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 980353A0A6F for ; Thu, 27 Feb 2020 16:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 aezIK5lpcJJp for ; Thu, 27 Feb 2020 16:39:31 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 743843A0A71 for ; Thu, 27 Feb 2020 16:39:31 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id c26so1272231eds.8 for ; Thu, 27 Feb 2020 16:39:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h1OodK2NeakoGUy3u9MXPvZSwDqVU958kWGfQzd+Mn0=; b=YHmoMbJsaUFMV2uvr1Z8otBH9Rqhbsk3j0FPi4BJosVm6so0I1UyTRLdF722LqVvd1 xZg2dYoYQ1C710LR9o/gWVIrFTuVu15D37Bp8NCY/h0oK2ndYa7agkO2jKJH+/Y5eExk EfP5Mkccl4t5gCLrXZq7q9W57VKtOKtBzZia3DTQ3BNlGwCSB4eLH5hBzgHRiLpGUIv8 3rZ+yLTakjm6RxzzOjuc+rsamrCjvk+tGAJvVt1H4tHNODVmqyBdzWkLUeJGlMnWY48O jLQ8UnLNER+6FfXRYzTVledB7epBhmu9A51Y6xmI8K367VBbgNXti5gjoNqo7j7RVclf 8rfA==
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=h1OodK2NeakoGUy3u9MXPvZSwDqVU958kWGfQzd+Mn0=; b=K7UyNWFYBmEMpEJYRkFQja0U1zbAZKLtJSe+FEqWkZ/UZmtgzy+MyMVZgHjds35o2h T4yhSo+EXPzPD04kzGqmAN9AiXV1YsuiyrRLvKl/7RMNWXKgszeBPjYS0OfsnqhwrNas XTS0scQAptILGMKocBG48zjWeMAt8VBpxBIc8I4adVqQDQjIPV4OIzGl41KBL18WNsHa GhaqdlEfQJNo/nmDtIAY6qrB0Jurkq4SF4921J9gdInrYOmTsK97s1UOOXp6qbHNBW43 68/we+jDIACSDlUF1UB4O7tFQs9xb1KPm+VfG7Rv3wt8LgfhptYEExv8A3QUYyxXWRhq ifow==
X-Gm-Message-State: APjAAAWzrAqpoFl9sPUCEx8sWppHkGhGY5VCQ9PZ2/xTAkxUGTkrHlWJ uhCuthDKfnsbevd34OOzvTncvMJJGrXp7gmuUTB2VA==
X-Google-Smtp-Source: APXvYqzcXAGDjWO5zXnhEBxcupYfzYoGt4EYbdL+nKvmbwpEWisnkScg4qhyrsxvM65OQ3P9VMLhK1LGMAtGvyMaYyk=
X-Received: by 2002:a05:6402:3132:: with SMTP id dd18mr1221757edb.118.1582850369917;  Thu, 27 Feb 2020 16:39:29 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    
In-Reply-To: 
From: Tom Herbert 
Date: Thu, 27 Feb 2020 16:39:17 -0800
Message-ID: 
To: Phillip Hallam-Baker 
Cc: Fernando Gont , architecture-discuss@iab.org,  Internet Architecture Board , Internet Area ,  "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000083134059f98120a"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 00:39:34 -0000

--000000000000083134059f98120a
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020, 4:27 PM Phillip Hallam-Baker 
wrote:

>
>
> On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert  wrote:
>
>>
>>
>> On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker 
>> wrote:
>>
>>> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert  wrote:
>>>
>>>> Fernando,
>>>>
>>>> I think we need to be careful that IETF is labeled as a collection of
>>>> inflexible architectural purists. We know that standards conformance
>>>> is voluntary and we haven't seen the last time that someone, possibly
>>>> even a major vendor, will circumvent the system for their own
>>>> purposes.
>>>>
>>>
>>> IP end to end does not mean the IP address is constant end to end. It
>>> never has meant that and never will. An IP address is merely a piece of
>>> data that allows a packet to reach its destination. There is no reason to
>>> insist on it remaining constant along the path.
>>>
>>> The sooner people get over that fact the better.
>>>
>>> If an IPv4 device interacts with an IPv6 device, there will be address
>>> translation going on somewhere along the path. That is inevitable.
>>>
>>> We discovered that there were good reasons for NATing IPv4 besides
>>> address multiplexing. The topology of my network is none of your business.
>>>
>>> More generally, Internet standards only apply to the Inter-net, the
>>> network of networks. What happens inside the networks at either end is for
>>> the owners of those networks to decide. If we go back to the original
>>> Internet design, they didn't even need to run IP. IP end to end come later.
>>>
>>> So let us stop being dogmatic about things that don't actually matter.
>>> The only job of the network layer is to get packets from one end to
>>> another. The only job of the transport layer is to provide reliable
>>> streams. An application protocol that depends on the IP address remaining
>>> constant end to end is a bad protocol and should be rejected.
>>>
>>
>> So Authentication Header and any other sort of Inetwork layer
>> authentication are bad protocols that should be rejected?
>>
>
> The IPSEC authentication header is a complete failure of design. It is the
> reason IPSEC doesn't work in the real world and has been replaced by SSH.
>
> Stuff that doesn't work in the real world is just bad and should be
> rejected. I remember the security ADs of the time smirking as they said
> IPSEC not working with NAT represented a feature, not a bug. They were
> wrong then and you are wrong now.
>
Thanks for your opinion, but I see nothing of relevance here that is worth
a reply.


>

--000000000000083134059f98120a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 27, 2020, 4:27 PM Phillip Hallam-Baker <=
;phill@hallambaker.com> wro=
te:

<=
br>
On Thu,=
 Feb 27, 2020 at 5:44 PM Tom Herbert <tom@herbertland.com> wrote=
:


On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker <phill@hall=
ambaker.com> wrote:
On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <tom@herbertlan=
d.com> wrote:
Fernando,



I think we need to be careful that IETF is labeled as a collection of

inflexible architectural purists. We know that standards conformance

is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own

purposes.

IP =
end to end does not mean the IP address is constant end to end. It never ha=
s meant that and never will. An IP address is merely a piece of data that a=
llows a packet to reach=C2=A0its destination. There is no reason to insist =
on it remaining constant along the path.=C2=A0

The sooner people get over=
 that fact the better.

If an IPv4 device interacts with an IPv6 device, t=
here will be address translation going on somewhere along the path. That is=
 inevitable.

We discovered that there were good reasons for NATing IPv4 b=
esides address multiplexing. The topology of my network is none of your bus=
iness.

More generally, Internet standards only apply to the Inter-net, th=
e network of networks. What happens inside the networks at either end is fo=
r the owners of those networks to decide. If we go back to the original Int=
ernet design, they didn't even need to run IP. IP end to end come later=
.

So let us stop being dogmatic about things that don't actually matt=
er. The only job of the network layer is to get packets from one end to ano=
ther. The only job of the transport layer is to provide reliable streams. A=
n application protocol that depends on the IP address remaining constant en=
d to end is a bad protocol and should be rejected.=C2=A0
<=
/blockquote>

So Au=
thentication Header and any other sort of Inetwork layer authentication are=
 bad protocols that should be rejected?

The IPSEC a=
uthentication header is a complete failure of design. It is the reason IPSE=
C doesn't work in the real world and has been replaced by SSH.

Stuff that doesn't work in th=
e real world is just bad and should be rejected. I remember the security AD=
s of the time smirking as they said IPSEC not working with NAT represented =
a feature, not a bug. They were wrong then and you are wrong now.
Thanks for your op=
inion, but I see nothing of relevance here that is worth a reply.

<=
br>




--000000000000083134059f98120a--


From nobody Thu Feb 27 16:43:55 2020
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 831733A0A96 for ; Thu, 27 Feb 2020 16:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no 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 ZAzSbpux8NpS for ; Thu, 27 Feb 2020 16:43:47 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2C53C3A0A85 for ; Thu, 27 Feb 2020 16:43:47 -0800 (PST)
Received: from xse110.mail2web.com ([66.113.196.110] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j7Tkk-0005un-Om for architecture-discuss@iab.org; Fri, 28 Feb 2020 01:43:44 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48T9l02TNnz5H8K for ; Thu, 27 Feb 2020 16:43:40 -0800 (PST)
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j7Tki-0006H8-78 for architecture-discuss@iab.org; Thu, 27 Feb 2020 16:43:40 -0800
Received: (qmail 32380 invoked from network); 28 Feb 2020 00:43:39 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.103]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2020 00:43:39 -0000
To: Fernando Gont 
Cc: Internet Area , IETF , architecture-discuss@iab.org, Internet Architecture Board 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>  
From: Christian Huitema 
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: 
Date: Thu, 27 Feb 2020 16:43:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.110
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.110/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.110/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDeW3+HZ7LK0h6oEMb2VkOa5vM xCtZSe87wnSOA0YTnlDnx8yeplRO3sLIqUlSH7OGdWB4ZOnxtCom4o0Zgoc6AYMlhcTgOXSCz8qb ysTVYVkMDlXDa3aVnxGK2HywWN/no8EIU8kPBKVxGytjfa32oFM9LD4J6QJNigNrycDHdbmOo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJscf1pPDHIpzyRJIAFazjKW6RASN07BfDbZjH/G35+HgTlAVlGe2OjJ3WizJZeEx7on kgW+Iat8lmjZ6klJit9YDOzmBV2HQt7Uatu+Zv1N1Z4mmvpoWVIpsx8iHX5DLie3Qqd2XfXJT/ME oiWVmyQo/sUa41ZkcaRrUnL1JoI9S7y7tIhej2eEU/xstu4Oo/hdo2QDmp0gac+kY2trv9IyBvv/ k66v7MKWLhEc1tk3517jgjVZ88yZgVxwvzrfHb38rLWurtYhxMrkuxg9br3KEss4M/VcoachNizi xYnUGyTmCCXeDL0NDX+BHG7xztXYg2px1fSoqxQCCHnLMo/mDU6PNRkfow1xbM/2UJ2204s78JWb K25bRomaFIfnPuaRVYKU9W9tbmVXJBqdHHDmtl4ZBm5rFDTzZHq3tVoXjbFV5oTvAcwA4rM3FkfW 8/0g7RdPSaUm7rgnoiAytAv9
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 00:43:51 -0000

Fernando,

Your original question was "is IPv6 end to end".

For me, the practical test of end to end is, can it be encrypted? A
message is end-to-end if it can be sent from end point A to endpoint B
using encryption services so that it cannot be modified in transit, only
the intended destination can receive it, and that destination can verify
that it came from the specified origin. Under that definition, Quic or
TLS are end to end. UDP, TCP, IPv4 and IPv6 on which they are built, not
so much.

This may be a cynical point of view, but it matches what Bernard Aboba
mentions in his description of "tussle space". Experience shows that if
intermediaries gain benefits in messing around with data in transit,
they will. The IETF may send them RFC copies in triplicate, but that
won't stop them. In the absence of encryption, the only reason it is a
tussle and not a free for all is the fear of breaking existing
applications. The network operators will not deploy a middle-box that
breaks important services, because disruption will make them lose
customers or otherwise incur costs. Standards are helpful there, because
they constrain the players to remain within a plausible envelope. But
the strength of standards comes from their adoption, not from the ink on
the paper. For standards that are widely adopted and followed, the
players that try to deploy breakage will experience customer feedback
and lose their end of the tussle. But standards that have limited
adoption will not have that power.

You are mentioning segment routing variants. For me, they fall very much
in this tussle category. Network equipment makers believe that this
technology will make the network better in some ways -- maybe faster, or
maybe easier to manage. It is definitely a departure from Steve
Deering's IPv6 vision of a simple network happily forwarding IPv6
datagrams. But as long as the network provider maintains an end to end
IPv6 service, there probably won't be that much customer backlash. The
tussle will play elsewhere, for example if network providers try to move
from changing the implementation of the service to changing its
definition. We have seen that in the past with attempts at QoS
deployment that looked like trying to tax specific applications. Those
were rejected because the entire ecosystem believed that "a bit is a
bit". But of course, some players are going to try again.

-- Christian Huitema



From nobody Thu Feb 27 17:05:32 2020
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 D28FD3A0AC5; Thu, 27 Feb 2020 17:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2JfMUqjiSeta; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 B17FA3A0A6D; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id y3so397065uae.3; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
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=Q9jxTKMpacA61yqy7dA1yTRZVl+Ts1439naph9dUjc0=; b=S1OhCE6aWOCtApmHCDzupOWdSht843dGIWsXbtQOwv1EKywtyWNzvNEIVNOYuH2Tgq S32B2N/QCdz/IUscd/BmMAl8mULCHhg3a9YiiMgj/ckpksQCBlR5bKx4RojDrkqndl+g 06aAAFIC9TVauy8AmzTdziudUcD5OFhgxBnJ6xuJple7caQKIKK7ewB3/uawQvmf92v0 n4dH9I8CW/IH8bfnZGKdnxIkHP/ezn/2u55DFHGKewauNhamqyNiwU+whAHloXfZ/9Vi teRmqC6GGE4vZG15gjm058TCeQmfBuNLvqAxcVeu0IZYtaKHTbRWH/vAKjlrfsGUIlMA ov4A==
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=Q9jxTKMpacA61yqy7dA1yTRZVl+Ts1439naph9dUjc0=; b=eRHo2TY523yvdGIJkRORrpe8eX3Q0zCEz2k9+71G0omSM8hGnYOafW/FyR2iG9zHL+ X4ribfenSBmMj92z8RzDD4IKg0uWBPZGd6wr1H3nBuCScW8OPbUCtE8//AXX8tfFy0gv B0xlIpyjFC0mhaUe62zYqDLKPdqouGwLPEFKbksWep6LpxDg2h0UkQhMi1B/EZlslXXI ON8TRBFfdUyuV3rgEGWB0/qNykN1U5jebL5WwN8XyeR7WUNrZLk09Ef4przP4wuEo5fn qqMuHqWsyCW5RRKaTyiVr3sPdHMMk/zbcWVe/oXy92sp04nsmpTpJ5a9wXj4v3K6ar78 IOXw==
X-Gm-Message-State: ANhLgQ33lSB0284X6fULt+7oOQxQI+9G7YBBIVLbfXzKTBHLxzXBO5Z4 tm50sjE26BYC/Fa3F0+WylJWMoYMXeGHEabVEKM=
X-Google-Smtp-Source: ADFU+vtCQkxc8ItVBjb5hADiwfO5wJ4BLOCERMzNtpuDH5wYsuMmjOhyR/LwoLQXaufxz6IotdFj4VH72+FmNZ+KcK4=
X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr855891uar.62.1582851920602; Thu, 27 Feb 2020 17:05:20 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>  
In-Reply-To: 
From: Bernard Aboba 
Date: Thu, 27 Feb 2020 17:05:09 -0800
Message-ID: 
To: Fernando Gont 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="00000000000075ad55059f986e13"
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 01:05:25 -0000

--00000000000075ad55059f986e13
Content-Type: text/plain; charset="UTF-8"

Fernando said:

"May I ask what is the point of bothering publishing specs if they are
going to be violated at will *within the same organization that
published the specs*."

[BA] The point of publishing specifications is to make them available for
evaluation and potential implementation.  It's a contribution to the
"marketplace of ideas".  As noted in RFC 5218, the imprimatur (e.g. the
standards status or stream) has little influence on acceptance.  Some
widely deployed specifications are Standards Track, others are
Informational. In practice, factors such as the availability of reference
implementations have more influence on deployment.

This levels the playing field - a single person (or small group) can design
a new protocol and put out an open source implementation, with a very good
chance that the work will be evaluated and succeed/fail on its own merits,
regardless of what "the experts" might think of it.

So if you take issue with a particular approach, offer up your own
alternative, or articulate the reasons why it is a bad idea.

Better to light a candle than to curse the darkness.


On Thu, Feb 27, 2020 at 2:58 PM Fernando Gont  wrote:

> On 27/2/20 19:43, Bernard Aboba wrote:
> > Fernando --
> >
> > "the proponents have argued that "we have implemented it,
> > and the industry wants it" -- as if we just have to rubberstamp what
> > they have done."
> >
> > [BA] The IETF has no enforcement authority, so that vendors have the
> > ability to ship products implementing IETF standards in whole or in part
> > - or not at all.
>
> Agreed. The problem here is that it's an *IETF* working group
> rubber-stamping what a vendor did. *That* is the problem.
>
> May I ask what is the point of bothering publishing specs if they are
> going to be violated at will *within the same organization that
> published the specs*.
>
>
> As noted by Jinmei here
> 
>
> , I believe not only are we just rubber-stamping stuff, but also I
> believe that our processes are being circumvented.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

--00000000000075ad55059f986e13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fernando said:=C2=A0
"May I ask what is the point of bothering publishing s=
pecs if they are
going to be violated at will *within the same organiz=
ation that
published the specs*."

[BA=
] The point of publishing specifications is to make them available for eval=
uation and potential implementation.=C2=A0 It's a contribution to the &=
quot;marketplace of ideas".=C2=A0 As noted in RFC 5218, the imprimatur=
 (e.g. the standards status or stream) has little influence on acceptance.=
=C2=A0 Some widely deployed specifications are Standards Track, others are =
Informational. In practice, factors such as the availability of reference i=
mplementations have more influence on deployment.

=
This levels the playing field - a single person (or small group) can design=
 a new protocol and put out an open source implementation, with a very good=
 chance that the work will be evaluated and succeed/fail on its own merits,=
 regardless of what "the experts" might think of it.
So if you take issue with a particular approach, offer up your=
 own alternative, or articulate the reasons why it is a bad idea.=C2=A0=C2=
=A0

Better to light a candle than to curse the dar=
kness.=C2=A0


On Thu, Feb 27, 2020 at 2:58 P=
M Fernando Gont <fgont@si6netwo=
rks.com> wrote:
On 27/2/20 19:43, Bernard Aboba wrote:

> Fernando --

> 

> "the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp w=
hat

> they have done."

> 

> [BA] The IETF has no enforcement authority, so that vendors have the <=
br>
> ability to ship products implementing IETF standards in whole or in pa=
rt 

> - or not at all.=C2=A0 



Agreed. The problem here is that it's an *IETF* working group 

rubber-stamping what a vendor did. *That* is the problem.



May I ask what is the point of bothering publishing specs if they are 

going to be violated at will *within the same organization that 

published the specs*.





As noted by Jinmei here 

<https://mailarchive.iet=
f.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/> 

, I believe not only are we just rubber-stamping stuff, but also I 

believe that our processes are being circumvented.



Thanks,

-- 

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492












--00000000000075ad55059f986e13--


From nobody Thu Feb 27 17:34:52 2020
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 510AE3A0B92; Thu, 27 Feb 2020 17:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 pBsNXd4pgv80; Thu, 27 Feb 2020 17:34:40 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F223A0B94; Thu, 27 Feb 2020 17:34:39 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D054A80998; Fri, 28 Feb 2020 02:34:32 +0100 (CET)
To: Christian Huitema 
Cc: Internet Area , IETF , architecture-discuss@iab.org, Internet Architecture Board 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>   
From: Fernando Gont 
Message-ID: <9e91a8dc-2796-070b-f174-c8abcb29b88c@si6networks.com>
Date: Thu, 27 Feb 2020 22:34:18 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 01:34:43 -0000

Christian,

Thanks for your response! In-line...

On 27/2/20 21:43, Christian Huitema wrote:
[....]
> This may be a cynical point of view, but it matches what Bernard Aboba
> mentions in his description of "tussle space". Experience shows that if
> intermediaries gain benefits in messing around with data in transit,
> they will. The IETF may send them RFC copies in triplicate, but that
> won't stop them. In the absence of encryption, the only reason it is a
> tussle and not a free for all is the fear of breaking existing
> applications. The network operators will not deploy a middle-box that
> breaks important services, because disruption will make them lose
> customers or otherwise incur costs.

There seems to be plenty of empirical evidence that that's not the case.

Not that they mean to break things, but they do -- e.g., a box that 
rewrites TCP sequence numbers, but fails to rewrite the SACK options. 
And many many others.


[....]
> You are mentioning segment routing variants. For me, they fall very much
> in this tussle category. Network equipment makers believe that this
> technology will make the network better in some ways -- maybe faster, or
> maybe easier to manage. It is definitely a departure from Steve
> Deering's IPv6 vision of a simple network happily forwarding IPv6
> datagrams. 

Don't we have a standards process for this, as in "Publish a draft that 
formally updates RFC8200, gain consensus, and get it published as RFC"?

Or, where/when did things change to "This wg has decided to violate the 
specs from another wg"?

And, more generally: does anybody do anywork or have a say on the 
architecture of the whole system?

For instance, we have an "Internet Architecture Board". Does the IAB 
have a say one the architecture and principles that we're developing 
specs within?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 17:42:13 2020
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 337723A0BB5; Thu, 27 Feb 2020 17:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Yij6q9iLgS-x; Thu, 27 Feb 2020 17:42:00 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7836F3A0BB2; Thu, 27 Feb 2020 17:41:59 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CBFB980CC8; Fri, 28 Feb 2020 02:41:55 +0100 (CET)
To: Bernard Aboba 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
From: Fernando Gont 
Message-ID: <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>
Date: Thu, 27 Feb 2020 22:41:47 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 01:42:03 -0000

On 27/2/20 22:05, Bernard Aboba wrote:
> Fernando said:
> 
> "May I ask what is the point of bothering publishing specs if they are
> going to be violated at will *within the same organization that
> published the specs*."
> 
> [BA] The point of publishing specifications is to make them available 
> for evaluation and potential implementation.  It's a contribution to the 
> "marketplace of ideas". 

It would seem to me there's much more than that.

If that were the case, anything and everything would be published as an RFC.

Among other things, the specs we publish are supposed to be subject to a 
decent level of review, and are also supposed to be coherent groups of 
specifications.

If you have one spec that says one thing, and then you have another, 
from the same Std Org, that says the opposite, without "obsoleting" the 
former, then you end up with something that won't have a single bit of 
coherence, virtually impossible to digest by anybody else other by than 
a limited group of people that just happens to know how everyone 
violates each others specs.


Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 17:50:57 2020
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 628593A0BEA; Thu, 27 Feb 2020 17:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE3DzcgW3R2J; Thu, 27 Feb 2020 17:50:54 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D0F3A0BCC; Thu, 27 Feb 2020 17:50:53 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DE06D82A18; Fri, 28 Feb 2020 02:50:49 +0100 (CET)
To: Robert Raszuk 
Cc: Internet Area , IETF , Tom Herbert , architecture-discuss@iab.org, Internet Architecture Board 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>  
From: Fernando Gont 
Message-ID: 
Date: Thu, 27 Feb 2020 22:50:26 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 01:50:55 -0000

On 27/2/20 20:58, Robert Raszuk wrote:
> 
[...]
> 
> We need to ask ourselves what is more important ... quality of data 
> plane for end users with 10s of ms of connectivity restoration times 
> upon failure or keeping original IPv6 dogmas in place where folks never 
> envisioned such needs or technologies to be invented.

I don't care myself about dogmas.

But there's an established process to do these things:

* You propose to change the existing behavior, and normally explain 
what's that beneficial, and maybe you elaborate on why you are not 
pursuing any possible alternatives.

* Once you gain consensus on the changes, you apply them.

And if the impact on the architecture is rather major, you probably 
better have people give a careful though about it.


Now, what has been going on in Spring is a vendor or set of vendors 
coming with a set of documents for a group to rubber-stamp, violating 
existing specs at will, with interpretations of existing specs that are 
confused beyond belief, or intentional to circumvent our existing processes.

Folks that care to "attract new people", etc., should really keep an eye 
on these things, as to many this reads like: "When there's stuff at 
stake, only big vendors get to play, with their own rules".

I'll refer to Jinmei's email, which esentially conveys the same message 


Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 18:18:46 2020
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 6B7283A0C44; Thu, 27 Feb 2020 18:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 B2J0Pwnd3xXI; Thu, 27 Feb 2020 18:18:35 -0800 (PST)
Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 3F7233A0C3D; Thu, 27 Feb 2020 18:18:35 -0800 (PST)
Received: by mail-oi1-f178.google.com with SMTP id a142so1397973oii.7; Thu, 27 Feb 2020 18:18:35 -0800 (PST)
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=3rOcd53MjRvRWXOGNqIf426fWCIz/LrIfn+4QXNT0nc=; b=JKxx6+RZ6Mtr3XsuNFcSSv3P4rA9WHXf+ksVSSTe1eovIdwkqD3LAI0mOQdgtBCcdO nw0z34VuroH53b9NuQKzjGToiHSvp+xdcy6Y7eSbnQ53Oq6GQV7iVFXCtDwo+yTWJLeM NyxnqwxPWL8NZprfbZPeWN6I8abgXeeqyZk7EPrxm05055JRxV3jqs17cVGFedrkMpVh Nm0O5sJhPK7mYWqzOYCEpWLjuj9/il/6DSXy9adGQuQgdhiLeOpEi7rs31NETXL/oUm0 /xcDJLe/5xMcMkvHZNT8CznyDjbfQ1QqEQqy15f/kD2Wx+VJF4HLLpszPWZaO+TDMDRa 8Lqg==
X-Gm-Message-State: APjAAAVwGNvgA9o5MfhXAxUx9+MpOi/sCdmzBEyyqE0gGHDwRVm80QXT NiW9bL6ahPqJ2gZSja/9x/ogFRcVBVAnt5yKeoA=
X-Google-Smtp-Source: APXvYqx7gH7i9uUjVQnWYSLwiP8tCGEMv0qqRuuuBdmWiiGezOuiei6kdb2pihfMm8cs3idMCbqerjXkIGUVgXFGIoM=
X-Received: by 2002:aca:cf94:: with SMTP id f142mr1504985oig.31.1582856314547;  Thu, 27 Feb 2020 18:18:34 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>   
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Thu, 27 Feb 2020 21:18:22 -0500
Message-ID: 
To: Fernando Gont 
Cc: Robert Raszuk , Tom Herbert ,  Internet Architecture Board , Internet Area ,  IETF , architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="0000000000005bf0ec059f997410"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 02:18:37 -0000

--0000000000005bf0ec059f997410
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont  wrote:

> On 27/2/20 20:58, Robert Raszuk wrote:
> >
> [...]
> >
> > We need to ask ourselves what is more important ... quality of data
> > plane for end users with 10s of ms of connectivity restoration times
> > upon failure or keeping original IPv6 dogmas in place where folks never
> > envisioned such needs or technologies to be invented.
>
> I don't care myself about dogmas.
>
> But there's an established process to do these things:
>
> * You propose to change the existing behavior, and normally explain
> what's that beneficial, and maybe you elaborate on why you are not
> pursuing any possible alternatives.
>
> * Once you gain consensus on the changes, you apply them.
>

That was the OSI model.

The Internet was based on a model of permisive experimentation.

The IETF is a catalyst for generating the necessary critical mass for
deployment. But some deployments don't need a catalyst.

--0000000000005bf0ec059f997410
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont <<=
a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com> wrote=
:
On 27/2/20 20:=
58, Robert Raszuk wrote:

> 

[...]

> 

> We need to ask ourselves what is more important ... quality of data 
> plane for end users with 10s of ms of connectivity restoration times <=
br>
> upon failure or keeping original IPv6 dogmas in place where folks neve=
r 

> envisioned such needs or technologies to be invented.



I don't care myself about dogmas.



But there's an established process to do these things:



* You propose to change the existing behavior, and normally explain 

what's that beneficial, and maybe you elaborate on why you are not 

pursuing any possible alternatives.



* Once you gain consensus on the changes, you apply them.
<=
div>
T=
hat was the OSI model.

The Internet was based on a model of permisive exper=
imentation. 

The IE=
TF is a catalyst for generating the necessary critical mass for deployment.=
 But some deployments don't need a catalyst.



--0000000000005bf0ec059f997410--


From nobody Thu Feb 27 19:06:57 2020
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 C15CE3A0D2A; Thu, 27 Feb 2020 19:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wVkpC8bFmZ9; Thu, 27 Feb 2020 19:06:53 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1773E3A0D28; Thu, 27 Feb 2020 19:06:53 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 123A982D50; Fri, 28 Feb 2020 04:06:44 +0100 (CET)
To: Phillip Hallam-Baker 
Cc: Internet Area , IETF , Robert Raszuk , architecture-discuss@iab.org, Internet Architecture Board 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>    
From: Fernando Gont 
Message-ID: <607b9e61-58c5-a54d-c99f-1bf0570ad0c3@si6networks.com>
Date: Fri, 28 Feb 2020 00:04:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 03:06:55 -0000

On 27/2/20 23:18, Phillip Hallam-Baker wrote:
> 
> 
> On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont  > wrote:
> 
>     On 27/2/20 20:58, Robert Raszuk wrote:
>      >
>     [...]
>      >
>      > We need to ask ourselves what is more important ... quality of data
>      > plane for end users with 10s of ms of connectivity restoration times
>      > upon failure or keeping original IPv6 dogmas in place where folks
>     never
>      > envisioned such needs or technologies to be invented.
> 
>     I don't care myself about dogmas.
> 
>     But there's an established process to do these things:
> 
>     * You propose to change the existing behavior, and normally explain
>     what's that beneficial, and maybe you elaborate on why you are not
>     pursuing any possible alternatives.
> 
>     * Once you gain consensus on the changes, you apply them.
> 
> 
> That was the OSI model.

Huh? What does OSI ahve to do with that???  I'm referring to existing 
IETF process to publish a spec.

And that's the procedure/rules that are normally applied to some of us, 
mere mortals that don't happen to be working for a big vendor.



> The Internet was based on a model of permisive experimentation.
> 
> The IETF is a catalyst for generating the necessary critical mass for 
> deployment. But some deployments don't need a catalyst.

Then I suggest you email the webmaster at www.ietf.org, because the text 
there must be outdated, then.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 19:29:00 2020
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 B44573A0DAE for ; Thu, 27 Feb 2020 19:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.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 kUiuLSi8E6ax for ; Thu, 27 Feb 2020 19:28:56 -0800 (PST)
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 121C83A0D9F for ; Thu, 27 Feb 2020 19:28:56 -0800 (PST)
Received: by mail-ed1-x543.google.com with SMTP id dm3so1699195edb.1 for ; Thu, 27 Feb 2020 19:28:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5qfCQr3BQd2T08K4/dzatRw3+9NjQKU71tI4cJRBnZQ=; b=v9tn9SXI6tqmM6ZGfgVEIwfqZDpOyzMoHsjIAl1emB3tdZ58uApfG3riF3Sze6lalR TwcbpcZ2PXlDfOPIRcCsgSWYtwij1L5s8Pt0UsdbZPTeGoWLyYEHIhKvGD+lqcDuBFBL emdx3mhpMYWB8QIT7oet+E6VVlrHnfuR2PbKfKyoh0e5Sx1gB+6GJxzrTIgIN/SlfLFH UUJ9dd8mGP/zm4P0tEF0LAVLz9UYwTWNb2f/4WnapTfggF5Z8zbV2fOc+4yBDarbtl5a /dOFhHnImVYPLws8i4YxgY3O3h0rghgB/2JoZcQpRi0VzUHD13aTL2Rx28/IvX5gQJWf L7Nw==
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:content-transfer-encoding; bh=5qfCQr3BQd2T08K4/dzatRw3+9NjQKU71tI4cJRBnZQ=; b=FEzMJYl7UnTqTLK24moBBpU1DoXaALXMEBFNQtdMA6haAPvTNWjsY0vRdtQJelz3bf pTzN+ENKFQhDM2YJrTTKuLL5zBz9o7kDpl2okN3dpCyd+wXM8Bc3GhoJ8d03247Jtpm7 E74cAV0nsPM8Tq0UcYREmRC5hLSvHy+rovvSiUaf0H8dBnCsXphOSgdGnRYuysgfbpCF lAtu7AVs1PNe5NPw7O4DOSeljbbP+oWUG2UJDH+1w/oG4bvygzvViiSTHvYr2jgqvJ5O bShIuuCjr+alAW4ks/DN5bIoMm/GFYkwDBYy5rnlG71bfByaSJYIRX+6xbGkINim0GyX dyKw==
X-Gm-Message-State: APjAAAXyXkkU+evP2eCImYQp3HPsGZ0zK8HiuTuaS7BIF0ty+KWHQ2aY usa9KHJOTcZEsWhV4n+mX7NkzOZXvQ8w88npGn6m7g==
X-Google-Smtp-Source: APXvYqySizyJVvIEsznC+kg8Kc0y1FB5dCJ48XDrFUP0xpMHiGpDsA2BWkwyKCpzdol7Gx+xx2dXICsB3y+97kwA+rM=
X-Received: by 2002:a05:6402:6c2:: with SMTP id n2mr1658532edy.241.1582860534476;  Thu, 27 Feb 2020 19:28:54 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>  
In-Reply-To: 
From: Tom Herbert 
Date: Thu, 27 Feb 2020 19:28:42 -0800
Message-ID: 
To: Robert Raszuk 
Cc: Fernando Gont , Joe Touch ,  Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 03:28:58 -0000

On Thu, Feb 27, 2020 at 3:58 PM Robert Raszuk  wrote:
>
>
> > What draft-ietf-spring-srv6-network-programming proposes is to remove a
> > segment routing header (SRH) along the packet delivery path, before the
> > packet arrives at the final destination. They call it PSP.
>
> That removal as it has been explained to you many times happens at the no=
de which is explicitly listed as DA of the packet.
>
> >  Before, folks have also proposed to insert Extension Headers (EHs) whi=
le
> > packets are en-route to their intended destination, etc.
>
> That has been moved to a separate draft to move fwd with the rest of the =
work.
>
> Yes this is still useful for TI-LFA (as example).
>
> We need to ask ourselves what is more important ... quality of data plane=
 for end users with 10s of ms of connectivity restoration times upon failur=
e or keeping original IPv6 dogmas in place where folks never envisioned suc=
h needs or technologies to be invented.
>
Robert,

To me, security, robustness, and interoperability are more important
than performance for end users. We obviously want everything, and
IETF's part in this seems to be ensuring those sort of attributes in
standard protocols.

There's a lot of history here. If you go back through the 6man
archives, you'll find there was substantial technical discussion on
extension header insertion. There were specific concerns raised
particular concerns about the loss of attribution of packet contents.
The extension header proponents did not adequately address those
concerns. I don't believe there was ever consensus in 6man that
outright rejected the idea, but neither there wasn't much effort by
the proponents to establish consensus for the proposal. It was their
impetus to do that (frankly, publicly saying "regardless of any
discussion in IETF, the protocol is going to go forward" hurt the
cause). To say that the proponents have only been met only with dogma
would be a mischaracterization of what actually transpired.

Tom

> Rgs,
> R.
>
>
> On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont  wr=
ote:
>>
>> Joe,
>>
>> What draft-ietf-spring-srv6-network-programming proposes is to remove a
>> segment routing header (SRH) along the packet delivery path, before the
>> packet arrives at the final destination. They call it PSP.
>>
>> Before, folks have also proposed to insert Extension Headers (EHs) while
>> packets are en-route to their intended destination, etc.
>>
>> Thanks,
>> Fernando
>>
>>
>>
>>
>> On 27/2/20 20:21, Joe Touch wrote:
>> > EH isn't a HBH option or extension.
>> >
>> > Joe
>> >
>> > On 2020-02-27 15:06, Fernando Gont wrote:
>> >
>> >> On 27/2/20 19:52, Joe Touch wrote:
>> >>> FWIW - there are separable issues here:
>> >>>
>> >>> - whether an IP header (or parts thereof) should be changed in trans=
it
>> >>>
>> >>> AFAICT, the answer has always been yes, but limited to the
>> >>> hopcount/ttl in the base header and hop-by-hop options in the
>> >>> options/extension headers.
>> >>>
>> >>> - whether an IP header length can change in transit
>> >>>
>> >>> I see no reason why it can't become smaller, but if it can become
>> >>> larger then PMTUD and PLPMTUD don't work.
>> >>
>> >> Besides AH (which obviously breaks), hosts typically try to validate
>> >> that the error messages they receive correspond to something they
>> >> actually sent.
>> >>
>> >> EH removal breaks that.
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>


From nobody Thu Feb 27 19:39:37 2020
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 B3C253A0E7C; Thu, 27 Feb 2020 19:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2jyRPiU0ZgBR; Thu, 27 Feb 2020 19:39:20 -0800 (PST)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 8E5AD3A0E6B; Thu, 27 Feb 2020 19:39:20 -0800 (PST)
Received: by mail-pf1-x429.google.com with SMTP id i6so983788pfc.1; Thu, 27 Feb 2020 19:39:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=fvzDHxQQglKrUCjMb3tSGOoh2mbDJqWpidCyVVI0irQ=; b=kVyYtztz1QJcWz3UU2m+tWmDLOUuyFh1HnxMBnLV1ShdfO7fSbN0TLQuHyRwJAREB+ 5CeVGhxnoxrupvJI3VvcpXl3sC/xloYNvS8wdk3mvLrKMKU0aA1vWEnKkpmM6qsf9YIC oz1TZvjN4I4gCwUwVR8QzkNs9tDTmtCB5EpApWB/hOh/5EYhu2zj5NOZRHdIECP+GYLV Bs7zfgdQ3QZLvQ6SPnpcByq18uMl2rK+isrwg76i6ZYCkQBPSeKx/BQx+U2BD7mWD61/ V4c4ooXuxw+LN8ko0gSKwMPH8+q/o2k6LSVe8g+MXR5qJm0vhIHbQJh8rI+w84yntpUN iEDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=fvzDHxQQglKrUCjMb3tSGOoh2mbDJqWpidCyVVI0irQ=; b=VbILLMYZwdEvdmS8J6/p5dfD6fVtp96OMtYwoZYeGTWfosZvv78rPyzqXk1uOuG+zl bni17rZVTN83hGtOFad4N25UQ0fCPgyfB08vUKtNkYzlBtT4QSB+sRYW2CoyS6JMb3rU Wdl2VPMRao4XkIWiVR72133zRqQlbDvi6G3bHOj9Gb74Y7tTUJV0a3ApvGxlD3R9a1oQ 8B6CVYgGsUlhzdxAGD+TjuJ5YwWYW8nHQ3bFGfDOpji1NlqqGsYo2Qi1cgU/2PJPJjrz 6urJmly4jLLTOSRbRK7dX8Pdwa9segSTniFww7MH8vMvUaagqL920spAu+ytzo7DNRTd bCIQ==
X-Gm-Message-State: APjAAAVlb+6BIE5JlLy3q4K3WtREfu6Sl6wkYDm5PPd4EtaH1ZhPn5bg HvQYmh3bg0to3GBR6tyJrcYhhTe6
X-Google-Smtp-Source: APXvYqz/cEYd44WOBL+coXoXEjrXBcTiubPkI0KObzGnaULYTcXZ4xj9DfGGWCBC1D89qbm3K1aecw==
X-Received: by 2002:a63:af52:: with SMTP id s18mr2568072pgo.281.1582861159733;  Thu, 27 Feb 2020 19:39:19 -0800 (PST)
Received: from ?IPv6:2601:646:9600:af10:ed45:87c6:524d:335d? ([2601:646:9600:af10:ed45:87c6:524d:335d]) by smtp.gmail.com with ESMTPSA id g16sm8512156pgb.54.2020.02.27.19.39.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Feb 2020 19:39:19 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Dino Farinacci 
Mime-Version: 1.0 (1.0)
Date: Thu, 27 Feb 2020 19:39:16 -0800
Message-Id: <3D64B077-9478-46AF-81E4-F60691B9377E@gmail.com>
References: 
Cc: Robert Raszuk , Internet Area , IETF , architecture-discuss@iab.org, Internet Architecture Board 
In-Reply-To: 
To: Tom Herbert 
X-Mailer: iPhone Mail (17E5233g)
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 03:39:26 -0000

> On Feb 27, 2020, at 7:29 PM, Tom Herbert  wrote:
>=20
> To me, security, robustness, and interoperability are more important
> than performance for end users. We

You chose a 3-tuple to a 1-tuple tradeoff . There is no tradeoff. One must d=
eliver a 4-tuple.=20

My 2 cents,
Dino=


From nobody Thu Feb 27 20:08:15 2020
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 623533A0EDF for ; Thu, 27 Feb 2020 20:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.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 5Disc7MHP0d6 for ; Thu, 27 Feb 2020 20:08:11 -0800 (PST)
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 BBE0D3A0EDB for ; Thu, 27 Feb 2020 20:08:10 -0800 (PST)
Received: by mail-ed1-x542.google.com with SMTP id m13so1745077edb.6 for ; Thu, 27 Feb 2020 20:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xlrGmDiaBgRJFYtGA9l2osPh0Hd06REn3xnbZsY4Z+c=; b=pcZkwdVaGmfsMQuzkTV172aDTpItGcTSoOp2AGAcfUighyYVTGJ/EUdALR6oOsUoBP J+8eLsjNdQN6J/IDGJUk7g9Zab0HzwKpGnoso5aYApAxg0oml3p+rGVvlWkH0G4u7U8N VJkG0tBC/jM9mlvN1VP2Xn0K0fpLcg4g8NkOvHEkLBLKuzifdL8o9/jEZc/Wsj//Lxbi CubNUnRdaznLgejIrA4gvhok7gNcZUpAT40rE+ev47aIXI8U1T1/ji0/90xcg4y9ziUE lkYLNeCLoBfoRjGFeMgeQ1KCAr2ekhMBmoGjgMA2O5GWx7qU/Qppf/9UkvMH7KJvajtx eRDw==
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=xlrGmDiaBgRJFYtGA9l2osPh0Hd06REn3xnbZsY4Z+c=; b=iOHxNv6xN6kzXQIfGglGZbfNCiW4VsiQ16vgQwzuK4xeOLcpNNZ+eOqPS+fn5KB8yd XOIbxcqLnGbUIVUgwsPt15GcoVRJa2hwaU3IrwjkvH/Oycen6PRWoDZUQ/lWqwiJicPW l2Fyl9w7NYhW9cxge0xbCxHsQoCp27YYhHU7YKnq1unmioUD9mJ5WtUoPh6ag+HRou/4 +5nqeqdyx6leX57oSq+WzD+YL0HPn657RkgjTyTw+gCoiQR8n5S8R/o36FWfNFRQCdel ySLqxhgpKKHL+4Z7api1q+SC9HZlaeK2G1Lio1px1i1Ma2nBsmwP4mJb3WNxQkcd01QR PZ+g==
X-Gm-Message-State: APjAAAX7wS9zgeewADs8tkFRraIlRPmkTnXkEwe8qGFNZl308XHAbp4L LT1TLELpW2GA44JtIHYY6UtKFzCqWcqUzYaBS1BRFw==
X-Google-Smtp-Source: APXvYqy3RH/tfT1NgHvoTnrUOwNbA9Dkyf6miwOYGFDY9HeZNf+LK08Ulcyk6YK9eVLivV3/K/EX6I2aVIItCQlIiFs=
X-Received: by 2002:aa7:d505:: with SMTP id y5mr1953223edq.370.1582862889264;  Thu, 27 Feb 2020 20:08:09 -0800 (PST)
MIME-Version: 1.0
References:  <3D64B077-9478-46AF-81E4-F60691B9377E@gmail.com>
In-Reply-To: <3D64B077-9478-46AF-81E4-F60691B9377E@gmail.com>
From: Tom Herbert 
Date: Thu, 27 Feb 2020 20:07:58 -0800
Message-ID: 
To: Dino Farinacci 
Cc: Robert Raszuk , Internet Area , IETF ,  architecture-discuss@iab.org, Internet Architecture Board 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:08:12 -0000

On Thu, Feb 27, 2020 at 7:39 PM Dino Farinacci  wrote:
>
> > On Feb 27, 2020, at 7:29 PM, Tom Herbert  wrote:
> >
> > To me, security, robustness, and interoperability are more important
> > than performance for end users. We
>
> You chose a 3-tuple to a 1-tuple tradeoff . There is no tradeoff. One must deliver a 4-tuple.
>
Sure, but EH insertion has not been shown to be secure, robust, or
interoperable. So this is currently is trading off three critical
requirements for just one (assuming that EH insertion is necessary for
performance which isn't even clear).

Tom


> My 2 cents,
> Dino


From nobody Thu Feb 27 20:16:06 2020
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 122003A0EF1; Thu, 27 Feb 2020 20:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iVkMICCCegWH; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 1919A3A0EF0; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: by mail-vk1-xa41.google.com with SMTP id x62so559990vkg.11; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
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=vItfVZBSFCm3TuCeDg179NsSoQtCkmQOiUqS6KXaVA8=; b=q1qT+5ZvYXMwSY6UWOQQWpGeCdBlbuIvvDNok/qjVmUxNX+LqALL2AMG3Qv2kSYr9m TfBK/9zszA2/B+Q4FmCp4HpoR8SqS0NgZ1wlmb2kZBRKItCPB9srtid3sXr7wEvbXWEp C+SSTpBUUZgCeelL2mWDcMMgBrXLUU8Z0dJHdt9s18crlYChx7ISfC0rGIMhjuzBZCpx bOMVK/48RiRvWUr1Xv8VCWKVfk7Y4hlUFsuvT2Ug4xraSORLVa87W0QAyRwCPjeiJVdZ n0Pvr+8S66EZooip3A+lLWte9VAzhro4CePF2CmxMVyrj6KgneioEYhkgIwQcR6Rasqz Cy0Q==
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=vItfVZBSFCm3TuCeDg179NsSoQtCkmQOiUqS6KXaVA8=; b=kGsxDffpWFO52fqrpZT3/BZcOPpRBF4nNacmZ3pDPcIxC+COM55YfIfy3PrjT6g0g1 CcqVpQd56C5szXCWgHekol/nHYhmiFZAQZQ8p1NOm0mYMelr8uBeKWYjdE/0MOwW7L3Y 5llNaGX2dVzyUJYQQ/BS5GadZVzuK31Ar/Rwjf5AxV076MYvJQOEwQycCvFg2c85JBDO lpKzc31mIOGWCMuZovSDjVtKKwERfq3p3zBz1d7YOYf44FcKPh6ibsY3VEpP+ymqklWH L8bL/kmkWDlugaLH+kQVsS1X54nuhJYIa7RvSGSIweadlYjIcAzUq9PHKfQHNAYNs0MJ RFcg==
X-Gm-Message-State: ANhLgQ1KSby87/s70dpqatKRy70TSKnE0tfL/dzvxy3k9bHMoWq59OzT mLBIOIgBdBtpjZYs18616sM8ku0Ng2hgpe/Uyf4=
X-Google-Smtp-Source: ADFU+vssuFTCSl2paxU5fKDMoskcL3P5fOjoF+bKXksgS+LNM0MK1fUiRRW+X/P6HRxSd3y6XM9HsUZHxzc8qBA3Rns=
X-Received: by 2002:a1f:2c58:: with SMTP id s85mr1490168vks.93.1582863361998;  Thu, 27 Feb 2020 20:16:01 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>
In-Reply-To: <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>
From: Bernard Aboba 
Date: Thu, 27 Feb 2020 20:15:51 -0800
Message-ID: 
To: Fernando Gont 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="0000000000006b8632059f9b1823"
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:16:05 -0000

--0000000000006b8632059f9b1823
Content-Type: text/plain; charset="UTF-8"

Fernando said:

"If that were the case, anything and everything would be published as an
RFC."

[BA] So you're saying that this is not the case already?

"Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications."

[BA] Please feel free to design a process that can accomplish this, given
the level of participation we have within the IETF.
The IESG members have a near-impossible job, so they have to rely on
Directorates, who in turn do the best they can. But the IETF process
exercises much of its restraint at the beginning of the process (*before* a
WG is chartered).  Once Chartered, it is rare for a WG document with
sufficient energy behind it to fail to get through the process.  The review
process does not guarantee that drafts conform to BCPs or IAB statements,
let alone consistency with other RFCs.

"If you have one spec that says one thing, and then you have another, from
the same Std Org, that says the opposite, without "obsoleting" the former,
then you end up with something that won't have a single bit of coherence,
virtually impossible to digest by anybody else other by than a limited
group of people that just happens to know how everyone
violates each others specs."

[BA] This has been the case from the earliest days.  For example, as
documented in RFC 4840, back in the early 1980s, there were 3+ approaches
to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the marketplace
sorted things out then, as they did later when some of the same issues
arose with WiMax/802.16 (RIP).  If there are dueling approaches, it is
often best to document them; rather than relying on standards bodies to
"choose a winner".

On Thu, Feb 27, 2020 at 5:41 PM Fernando Gont  wrote:

> On 27/2/20 22:05, Bernard Aboba wrote:
> > Fernando said:
> >
> > "May I ask what is the point of bothering publishing specs if they are
> > going to be violated at will *within the same organization that
> > published the specs*."
> >
> > [BA] The point of publishing specifications is to make them available
> > for evaluation and potential implementation.  It's a contribution to the
> > "marketplace of ideas".
>
> It would seem to me there's much more than that.
>
> If that were the case, anything and everything would be published as an
> RFC.
>
> Among other things, the specs we publish are supposed to be subject to a
> decent level of review, and are also supposed to be coherent groups of
> specifications.
>
> If you have one spec that says one thing, and then you have another,
> from the same Std Org, that says the opposite, without "obsoleting" the
> former, then you end up with something that won't have a single bit of
> coherence, virtually impossible to digest by anybody else other by than
> a limited group of people that just happens to know how everyone
> violates each others specs.
>
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

--0000000000006b8632059f9b1823
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fernando said:=C2=A0

"If that were=
 the case, anything and everything would be published as an RFC."

[BA] So you're saying that this is not the case al=
ready?

"Among other things, the specs we publish are supposed t=
o be subject to a
decent level of review, and are also supposed to be co=
herent groups of
specifications."

[BA] Ple=
ase feel free to design a process that can accomplish this, given the level=
 of participation we have within the IETF.=C2=A0
The IESG members=
 have a near-impossible job, so they have to rely on Directorates, who in t=
urn do the best they can. But the IETF process exercises much of its restra=
int at the beginning of the process (*before* a WG is chartered).=C2=A0 Onc=
e Chartered, it is rare for a WG document with sufficient energy behind it =
to fail to get through the process.=C2=A0 The review process does not guara=
ntee that drafts conform to BCPs or IAB statements, let alone consistency w=
ith other RFCs.

"If you have one spec that sa=
ys one thing, and then you have another, from the same Std Org, that says t=
he opposite, without "obsoleting" the former, then you end up wit=
h something that won't have a single bit of coherence, virtually imposs=
ible to digest by anybody else other by than a limited group of people that=
 just happens to know how everyone
violates each others specs."

[BA] This has been the case from the earliest days.=
=C2=A0 For example, as documented in RFC 4840, back in the early 1980s, the=
re were 3+ approaches to the encapsulation of IP on Ethernet/IEEE 802.1.=C2=
=A0 Yet the marketplace sorted things out then, as they did later when some=
 of the same issues arose with WiMax/802.16 (RIP).=C2=A0 If there are dueli=
ng approaches, it is often best to document them; rather than relying on st=
andards bodies to "choose a winner".

On Thu, Feb 27, 2020 at=
 5:41 PM Fernando Gont <fgont@s=
i6networks.com> wrote:
On 27/2/20 22:05, Bernard Aboba wrote:

> Fernando said:

> 

> "May I ask what is the point of bothering publishing specs if the=
y are

> going to be violated at will *within the same organization that

> published the specs*."

> 

> [BA] The point of publishing specifications is to make them available =


> for evaluation and potential implementation.=C2=A0 It's a contribu=
tion to the 

> "marketplace of ideas". 



It would seem to me there's much more than that.



If that were the case, anything and everything would be published as an RFC=
.



Among other things, the specs we publish are supposed to be subject to a 
decent level of review, and are also supposed to be coherent groups of 

specifications.



If you have one spec that says one thing, and then you have another, 

from the same Std Org, that says the opposite, without "obsoleting&quo=
t; the 

former, then you end up with something that won't have a single bit of =


coherence, virtually impossible to digest by anybody else other by than 
a limited group of people that just happens to know how everyone 

violates each others specs.





Thanks,

-- 

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492












--0000000000006b8632059f9b1823--


From nobody Thu Feb 27 20:27:59 2020
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 A86B23A0F0D; Thu, 27 Feb 2020 20:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 O4URZ-oiYPxB; Thu, 27 Feb 2020 20:27:50 -0800 (PST)
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 5C0883A0F05; Thu, 27 Feb 2020 20:27:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=uON4vVKPTmcUjPnffLBu6Q2ku/JHncwob414F81reZY=; b=nh51bqhcv1g+OjGQq/wdQMY/O nADKyOpgBvsPgubNf3i3eLWGNjeSYBS2CkidBieo5oF3147KOg6Pc82KjIXwB3oSqTImzcId0woqD EhlgANF/UEw5ekTvVCSKTb7FNSG+tL2vZmYPTDEGdGVKN+FKHB7BDCrZhgYKWwMjOdCsBg8iYGiZe MJKjNI9Uyh6GMnSGOtqW2HlPgTE5B+9PpPZk6/b/hRGfaPnOx3LTlU1WsawDQGHFaQU8vuOcIQ6zV 9uoDtiKaaheufHpQN5ezsf2hZ8CZljp5uny1f6HmGjV/w+Bq7ZiI+JBPuU4lGSEGe+5dL3bnkIi2i S9txcQvMw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58079 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7XFZ-002cDf-Ct; Thu, 27 Feb 2020 23:27:49 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_44D2FFE2-CADD-4064-B57D-3C5C8A131047"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: <7A8582D7-1647-41EC-808D-46C380565014@isc.org>
Date: Thu, 27 Feb 2020 20:27:44 -0800
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF-Discussion 
Message-Id: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <7A8582D7-1647-41EC-808D-46C380565014@isc.org>
To: Mark Andrews 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:27:52 -0000

--Apple-Mail=_44D2FFE2-CADD-4064-B57D-3C5C8A131047
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 27, 2020, at 3:54 PM, Mark Andrews  wrote:
> ...
> Encapsulation doesn=E2=80=99t make the packet larger.

Not strictly; it does make the unit of transfer larger. It=E2=80=99s the =
tunnel ingress=E2=80=99s job to adapt to that, e.g., using source =
fragmentation at the ingress.

> It is no different to
> talking a packet from a ethernet and pushing it out a PPP link.  The
> Enclosing headers differ in sizes but the IPv6 packet remains the
> same size.

We=E2=80=99re talking about the unit of transfer - which does get =
larger=E2=80=A6.

>=20
> The difference with encapsulation, from the non encapsulation cases, =
is
> that PTBs are sent to the encapsulating node which has to synthesis a
> PTB to the original (as far as the encapsulating node is concerned)

No, it really doesn=E2=80=99t. I don=E2=80=99t expect to chop packets =
into 48 byte units just to go over an ATM =E2=80=9Chop=E2=80=9D in an IP =
path. The only party who needs to know about the PTB of a tunnel transit =
is the tunnel ingress. Again, see draft-intarea-tunnels.

Joe=

--Apple-Mail=_44D2FFE2-CADD-4064-B57D-3C5C8A131047
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 27, 2020, at 3:54 PM, Mark Andrews <marka@isc.org> =
wrote:
...
Encapsulation doesn=E2=80=99t =
make the packet larger. 

Not strictly; it does make the unit of transfer =
larger. It=E2=80=99s the tunnel ingress=E2=80=99s job to adapt to that, =
e.g., using source fragmentation at the ingress.

It is no different to
talking a packet from a =
ethernet and pushing it out a PPP link.  The
Enclosing =
headers differ in sizes but the IPv6 packet remains the
same=
 size.

We=E2=80=99re talking about the unit of transfer - =
which does get larger=E2=80=A6.


The difference with encapsulation, from the non encapsulation =
cases, is
that PTBs are sent to the encapsulating node =
which has to synthesis a
PTB to the original (as far as =
the encapsulating node is concerned)

No, =
it really doesn=E2=80=99t. I don=E2=80=99t expect to chop packets into =
48 byte units just to go over an ATM =E2=80=9Chop=E2=80=9D in an IP =
path. The only party who needs to know about the PTB of a tunnel transit =
is the tunnel ingress. Again, see draft-intarea-tunnels.

Joe
=

--Apple-Mail=_44D2FFE2-CADD-4064-B57D-3C5C8A131047--


From nobody Thu Feb 27 20:34:08 2020
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 849B13A0F1F; Thu, 27 Feb 2020 20:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 XPPyZH3FiLla; Thu, 27 Feb 2020 20:34:03 -0800 (PST)
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 AADD93A0F1A; Thu, 27 Feb 2020 20:34:03 -0800 (PST)
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=ifSxmR067gT7iwrCN6LjKwH98bcIjxK/GHfrFnxeQvA=; b=v6XAXkYRa8eW9rWdA4yyJYdap fzmipUgvr1hKRkdHZipZJw9z83xI/EtBtti0pDnQQSNiwwPGlDEZjaARRhP/S7lVhyoNMZdtF0DEJ q3Wtx1/7ffmrFM7Vehx1YLtwIALKy6tsTdFT5Q2MsZX/8/UhLElYPdRb/FXK2wP+TWMurxcDFVqf4 oewPir2s8qnnTo8zI/OjjQOnXc7wDWUNUs3URserdlhgtLP6v9sw2VEoW/mnrBnd67fR9Vrl8zGgk AFXa9wkTkc+x/idYQVg1EOWaNiANO7UWxoF5S3T4LsKs6Ix69DftlIPAP4Z3tkl8fwr5LY8oMPeGF sQUwqxhaw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58091 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7XLa-002iCI-GA; Thu, 27 Feb 2020 23:34:02 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: 
Date: Thu, 27 Feb 2020 20:33:57 -0800
Cc: Fernando Gont , Tom Herbert ,  Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>  
To: Robert Raszuk 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:34:06 -0000

> On Feb 27, 2020, at 3:58 PM, Robert Raszuk  wrote:
>=20
>=20
> > What draft-ietf-spring-srv6-network-programming proposes is to =
remove a=20
> > segment routing header (SRH) along the packet delivery path, before =
the=20
> > packet arrives at the final destination. They call it PSP.=20
>=20
> That removal as it has been explained to you many times happens at the =
node which is explicitly listed as DA of the packet.=20
>=20
> >  Before, folks have also proposed to insert Extension Headers (EHs) =
while=20
> > packets are en-route to their intended destination, etc.
>=20
> That has been moved to a separate draft to move fwd with the rest of =
the work.=20
>=20
> Yes this is still useful for TI-LFA (as example).=20
>=20
> We need to ask ourselves what is more important ... quality of data =
plane for end users with 10s of ms of connectivity restoration times =
upon failure or keeping original IPv6 dogmas in place where folks never =
envisioned such needs or technologies to be invented.=20

I don=E2=80=99t care about what you WANT to do; I care whether it breaks =
what everyone else expects.

Any device along an IP path that makes a packet larger IN ANY WAY is =
ITSELF responsible for making sure that packet can continue forward. At =
a tunnel, that means work at BOTH the ingress (source fragmentation) and =
egress (reassembly).

Now, if you add EHs to an IP packet and you=E2=80=99re in control of the =
ability to do source fragmentation AND reassembly ***IN THE PATH YOU =
MANAGE***, then you simply can=E2=80=99t do it. Because it WILL break =
PLPMTUD.

So if you still WANT to do this(1), then YOU need to prove you can CLEAN =
UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other =
things, will continue to work?

Joe

(1) this whole thing sounds a lot like Active Nets, which was a retread =
of SoftNet. So the cycle goes, every 20 years or so. Take the slowest =
thing a router does and expect it to do more of it, as Jon said. What is =
it Einstein said about the definition of insanity?


From nobody Thu Feb 27 20:36:47 2020
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 9A58F3A0F26; Thu, 27 Feb 2020 20:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 e-YUKMWhFgQG; Thu, 27 Feb 2020 20:36:35 -0800 (PST)
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 61FB43A0F23; Thu, 27 Feb 2020 20:36:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=PR1ZtLBm2zMPgviRmDlJN5pBY6aKAkOCIYJHPPlwtsA=; b=7UI1fe/5ZXGY8SJhkO3l6tToo u/nGxUeOe2C/KNOwOkgDkiU+fO4umVx1tgYvF7fNYm2XULH7koSwqCrdib8Md4R7BuaMoKB9Jwf/Q AuGO+oUAUf604D38/ge0mSanTDsfGau+esKkTX1XLRHHnIB/CBGN0BJ5czX6zRsFOhosrhTHPT0GD 2vKTob7m8o/nxKrO3l1TxptjeQ+0iODBvyNSJrlKhFaZXD2mczixgKWTvxEUul/Ijw8a/tHb3gwrE +PGlPdoiXI4LyvMWk4Tg6aM4dW6xINOUVUjeXJvgotX9hfrgufsOB2/x5WV7CJIkrQIX9vGSH19hf nXcY9YYeg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58094 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7XO2-002kXW-Rf; Thu, 27 Feb 2020 23:36:35 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_68867991-103B-4979-B9D7-D15C30F39E65"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: 
Date: Thu, 27 Feb 2020 20:36:29 -0800
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF Discussion Mailing List 
Message-Id: <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com> 
To: Phillip Hallam-Baker 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:36:37 -0000

--Apple-Mail=_68867991-103B-4979-B9D7-D15C30F39E65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker =
 wrote:
>=20
>> IP end to end does not mean the IP address is constant end to end. It =
never has meant that and never will.
> =20
> Actually, that's the only thing it ever meant and always will. When =
addresses change, *by definition*, the*ends* change (and yes, that's =
what NATs do - they create end-to-end CONTENT transfer over separate =
end-to-end Internets).
>=20
> By whose definition? Not by mine.

I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also the =
pseudo header in RFC 793, to be very specific.

> TCP and TLS give me a reliable end-to-end stream. The fact that the IP =
address is exposed is merely an unfortunate defect in the legacy APIs.=20=

>=20
> As the application layer designer, I am the customer here. I do not =
care about the IP address.

Hmmm. By what value do you call  TCP endpoint?

You must have magic sockets that don=E2=80=99t actually refer to IP =
addresses.

Joe


--Apple-Mail=_68867991-103B-4979-B9D7-D15C30F39E65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

IP end to end does not =
mean the IP address is constant end to end. It never has meant that and =
never will.
 
Actually, that's the =
only thing it ever meant and always will. When addresses change, *by =
definition*, the*ends* change (and yes, that's what NATs do - they =
create end-to-end CONTENT transfer over separate end-to-end =
Internets).

By whose definition? =
Not by =
mine.

I=E2=80=99d start with RFCs 791 and 1122, but =
there=E2=80=99s also the pseudo header in RFC 793, to be very =
specific.

TCP=
 and TLS give me a reliable end-to-end stream. The fact that the IP =
address is exposed is merely an unfortunate defect in the legacy =
APIs. 

As the application layer designer, I am the customer here. I =
do not care about the IP =
address.

Hmmm. By what value do you call  TCP =
endpoint?

You must have magic =
sockets that don=E2=80=99t actually refer to IP addresses.

Joe

=

--Apple-Mail=_68867991-103B-4979-B9D7-D15C30F39E65--


From nobody Thu Feb 27 20:44:11 2020
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 39DB43A0F36; Thu, 27 Feb 2020 20:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdpRSAdWgRsR; Thu, 27 Feb 2020 20:44:08 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D71D3A0F32; Thu, 27 Feb 2020 20:44:08 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EEEC680037; Fri, 28 Feb 2020 05:44:03 +0100 (CET)
To: Bernard Aboba 
Cc: "ietf@ietf.org" , Internet Architecture Board , Internet Area , architecture-discuss@iab.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com> 
From: Fernando Gont 
Message-ID: <426b2a17-5e27-fd9b-f84f-373e4f8186cd@si6networks.com>
Date: Fri, 28 Feb 2020 01:43:54 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 04:44:10 -0000

On 28/2/20 01:15, Bernard Aboba wrote:
> Fernando said:
> 
> "If that were the case, anything and everything would be published as an 
> RFC."
> 
> [BA] So you're saying that this is not the case already?

Yes, that's not the case, particularly for people that participate 
independently.




> "Among other things, the specs we publish are supposed to be subject to a
> decent level of review, and are also supposed to be coherent groups of
> specifications."
> 
> [BA] Please feel free to design a process that can accomplish this, 
> given the level of participation we have within the IETF.
> The IESG members have a near-impossible job, so they have to rely on 
> Directorates, who in turn do the best they can. But the IETF process 
> exercises much of its restraint at the beginning of the process 
> (*before* a WG is chartered).  Once Chartered, it is rare for a WG 
> document with sufficient energy behind it to fail to get through the 
> process.  The review process does not guarantee that drafts conform to 
> BCPs or IAB statements, let alone consistency with other RFCs.

There's a big difference between a document being published, and the 
authors of a document crafting whatever they please into that document, 
and having the IETF rubberstamp it.




> "If you have one spec that says one thing, and then you have another, 
> from the same Std Org, that says the opposite, without "obsoleting" the 
> former, then you end up with something that won't have a single bit of 
> coherence, virtually impossible to digest by anybody else other by than 
> a limited group of people that just happens to know how everyone
> violates each others specs."
> 
> [BA] This has been the case from the earliest days.  For example, as 
> documented in RFC 4840, back in the early 1980s, there were 3+ 
> approaches to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the 
> marketplace sorted things out then, as they did later when some of the 
> same issues arose with WiMax/802.16 (RIP).  If there are dueling 
> approaches, it is often best to document them; rather than relying on 
> standards bodies to "choose a winner".

I'm not referring to competing technologies. I'm talking about one spec 
(e.g. SRv6) blatantly violating another one (IPv6).

When you have conflicting specs, you're kind of at odds with being a 
*standards* organization.... -- nobody knows what to expect, because one 
document says one thing, and another says another thing.

There's a reason for which we have the "Update" and "Obsolete" tags in 
RFCs...

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Feb 27 22:35:28 2020
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 8842D3A1146; Thu, 27 Feb 2020 22:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J_zxvKWYGqfn; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 4451B3A1144; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
Received: by mail-ot1-x342.google.com with SMTP id x97so1630365ota.6; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jv+ZzBlGxHVsJsz/cKCqfLUJ5UYctP4d/yPs6O2EuaM=; b=QNG9nU4cWSFpWcUSRTqOUfZG8ckYL6Jckz4zTMbjQUITPCMD3QZbd69BEX4Apa9gMf yd4SW5GwBim4kIKMp6opHvYc3Sdna4SMlIfrGvvShX2eVe1foEf83iIY04udqKI/isju YOFEnmi9f78dj/jLYMZ4bqqZK/SsUlJdhSrNpLmcqAEI25AWdkjl9Qx+qYRXjGsVufOg nSdgeWo6aceVlBIqZzuKo54uK6uXFdGHYt6Y5Fq2GmXWLsGoGdAzTCqioh6XkFZD2PgS s+G4+WdVFmlBoZWbkPUirqYbjecZyrHKlYKsp1AEYWM4wBiEYR6ofcNTbpGTxG/Mf2R6 0PAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jv+ZzBlGxHVsJsz/cKCqfLUJ5UYctP4d/yPs6O2EuaM=; b=Nn0s4JQ8lFUx7ahxtVxY7TeTcXzBW0V8qvU368Bjkg1liERM1FK0HQn13qOFaFD8w4 yKnen+uXPei3PC2LuTQIYpXWuSdvyq5vDiYrws21XHCpjTRmR2uTmMtln1HnOnzFSkqW vVO8cinI/r5cnTl4ZfY+mFpzvBELU8MyczxDn64jHQmvCkZbmP97384KEJUaS6lTRwa6 sECpVB8+kvpWrQkrB14OsKvU9yNaphkqYxNhx/oPkomkpzEG+ricHCZksexrVqJg2hfl v/zWLWei98KRKZSMntuBNs1nS7CAf+sLoMn97KP8hv31xM1us/8hMFqp5V8TcvAnFWe+ EHOQ==
X-Gm-Message-State: APjAAAXGPsVByTeKOCXIRRiruKcHc389V5duCX/FdQ3X0swBS55CojHg 9wTm+tW9xgcfkSWymcdsBDUAKzAbVLMvq29KYnE=
X-Google-Smtp-Source: APXvYqwV07CK2fwhmMEUPdrcvGqeFcKs8s6tkBokhs5icn8LZ1v3mg88sBbr2xrZT6m54FURQQJKrbiOM5XVfkGnrI4=
X-Received: by 2002:a9d:63c6:: with SMTP id e6mr2010570otl.365.1582871722479;  Thu, 27 Feb 2020 22:35:22 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 27 Feb 2020 22:35:21 -0800 (PST)
In-Reply-To: <426b2a17-5e27-fd9b-f84f-373e4f8186cd@si6networks.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>  <426b2a17-5e27-fd9b-f84f-373e4f8186cd@si6networks.com>
From: Guntur Wiseno Putra 
Date: Fri, 28 Feb 2020 13:35:21 +0700
Message-ID: 
To: Fernando Gont 
Cc: Bernard Aboba ,  "architecture-discuss@iab.org" , Internet Architecture Board ,  Internet Area , "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000be54e0059f9d0ac1"
Archived-At: 
Subject: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 06:35:26 -0000

--000000000000be54e0059f9d0ac1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Fernando &
architecture-discuss,

F. Gont said about proposals regarding with IP(v6) and among others (in the
first message of this thread):


"* On the procedural area:

  + Where/how should IETF WGs seek for architecture-related advice"?


I finded Dave Thaler said in "Evolution of the IP Model" (2009):

"(From the 1978 IEN, the 1980 RFC 760 to the 1981 RFC 7611:) The evolution
didn=E2=80=99t stop there, however, and the IP model has continued to chang=
e over
the years to meet new demands. Some of those changes were intentional. Some
were because we found deficiencies. Others were the result of new
capabilities. Often, the changes were a consequence of trying to do
something else.

By 1989, there was already some confusion concerning the IP model. RFC 1122
was written in an effort to clear up some of that confusion as well as to
extend the service model. There are plenty of other RFCs that offered
advice on various specific aspects of the IP model, and as a result, to
gain an understanding of the IP model, one needed to search many RFCs.

Another RFC appeared in 2004, which is probably the one that is closest in
spirit to this work. That one-RFC 3819-offered advice for link-layer
protocol designers on how to minimize the impact on layers above the link
layer. Hence, it dealt with the service model at the bottom of IP, whereas
the present work deals with the service model at the top of IP.

...".
https://www.ietfjournal.org/evolution-of-the-ip-model/


Regard,
Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Fernando Gont  menulis=
:

> On 28/2/20 01:15, Bernard Aboba wrote:
>
>> Fernando said:
>>
>> "If that were the case, anything and everything would be published as an
>> RFC."
>>
>> [BA] So you're saying that this is not the case already?
>>
>
> Yes, that's not the case, particularly for people that participate
> independently.
>
>
>
>
> "Among other things, the specs we publish are supposed to be subject to a
>> decent level of review, and are also supposed to be coherent groups of
>> specifications."
>>
>> [BA] Please feel free to design a process that can accomplish this, give=
n
>> the level of participation we have within the IETF.
>> The IESG members have a near-impossible job, so they have to rely on
>> Directorates, who in turn do the best they can. But the IETF process
>> exercises much of its restraint at the beginning of the process (*before=
* a
>> WG is chartered).  Once Chartered, it is rare for a WG document with
>> sufficient energy behind it to fail to get through the process.  The rev=
iew
>> process does not guarantee that drafts conform to BCPs or IAB statements=
,
>> let alone consistency with other RFCs.
>>
>
> There's a big difference between a document being published, and the
> authors of a document crafting whatever they please into that document, a=
nd
> having the IETF rubberstamp it.
>
>
>
>
> "If you have one spec that says one thing, and then you have another, fro=
m
>> the same Std Org, that says the opposite, without "obsoleting" the forme=
r,
>> then you end up with something that won't have a single bit of coherence=
,
>> virtually impossible to digest by anybody else other by than a limited
>> group of people that just happens to know how everyone
>> violates each others specs."
>>
>> [BA] This has been the case from the earliest days.  For example, as
>> documented in RFC 4840, back in the early 1980s, there were 3+ approache=
s
>> to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the marketplace
>> sorted things out then, as they did later when some of the same issues
>> arose with WiMax/802.16 (RIP).  If there are dueling approaches, it is
>> often best to document them; rather than relying on standards bodies to
>> "choose a winner".
>>
>
> I'm not referring to competing technologies. I'm talking about one spec
> (e.g. SRv6) blatantly violating another one (IPv6).
>
> When you have conflicting specs, you're kind of at odds with being a
> *standards* organization.... -- nobody knows what to expect, because one
> document says one thing, and another says another thing.
>
> There's a reason for which we have the "Update" and "Obsolete" tags in
> RFCs...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

--000000000000be54e0059f9d0ac1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Fernando &
architecture-discuss,

F. Gon=
t said about proposals regarding with IP(v6) and among others (in the first=
 message of this thread):


"* On t=
he procedural area:

=C2=A0 + Where/how should IETF W=
Gs seek for architecture-related advice"?

I finded Dave Thaler said in &quo=
t;Evolution of the IP Model" (2009):
"(From the 1978 IEN, the 1980 RFC 760 to=
 the 1981 RFC 7611:) The evolution didn=E2=80=99t stop there, however, and =
the IP model has continued to change over the years to meet new demands. So=
me of those changes were intentional. Some were because we found deficienci=
es. Others were the result of new capabilities. Often, the changes were a c=
onsequence of trying to do something else.
By 1989, there was already some confusion co=
ncerning the IP model. RFC 1122 was written in an effort to clear up some o=
f that confusion as well as to extend the service model. There are plenty o=
f other RFCs that offered advice on various specific aspects of the IP mode=
l, and as a result, to gain an understanding of the IP model, one needed to=
 search many RFCs.
Another RFC appeared in 2004, which is probably the one that is clos=
est in spirit to this work. That one-RFC 3819-offered advice for link-layer=
 protocol designers on how to minimize the impact on layers above the link =
layer. Hence, it dealt with the service model at the bottom of IP, whereas =
the present work deals with the service model at the top of IP.
...".
https:=
//www.ietfjournal.org/evolution-of-the-ip-model/


Regard,
Guntur Wiseno Putra

Pada Jum=
at, 28 Februari 2020, Fernando Gont <fgont@si6networks.com> menulis:
On 28/2/20 01:15, Bernard Aboba wrote:



Fernando said:



"If that were the case, anything and everything would be published as =
an RFC."



[BA] So you're saying that this is not the case already?





Yes, that's not the case, particularly for people that participate inde=
pendently.











"Among other things, the specs we publish are supposed to be subject t=
o a

decent level of review, and are also supposed to be coherent groups of

specifications."



[BA] Please feel free to design a process that can accomplish this, given t=
he level of participation we have within the IETF.

The IESG members have a near-impossible job, so they have to rely on Direct=
orates, who in turn do the best they can. But the IETF process exercises mu=
ch of its restraint at the beginning of the process (*before* a WG is chart=
ered).=C2=A0 Once Chartered, it is rare for a WG document with sufficient e=
nergy behind it to fail to get through the process.=C2=A0 The review proces=
s does not guarantee that drafts conform to BCPs or IAB statements, let alo=
ne consistency with other RFCs.





There's a big difference between a document being published, and the au=
thors of a document crafting whatever they please into that document, and h=
aving the IETF rubberstamp it.











"If you have one spec that says one thing, and then you have another, =
from the same Std Org, that says the opposite, without "obsoleting&quo=
t; the former, then you end up with something that won't have a single =
bit of coherence, virtually impossible to digest by anybody else other by t=
han a limited group of people that just happens to know how everyone

violates each others specs."



[BA] This has been the case from the earliest days.=C2=A0 For example, as d=
ocumented in RFC 4840, back in the early 1980s, there were 3+ approaches to=
 the encapsulation of IP on Ethernet/IEEE 802.1.=C2=A0 Yet the marketplace =
sorted things out then, as they did later when some of the same issues aros=
e with WiMax/802.16 (RIP).=C2=A0 If there are dueling approaches, it is oft=
en best to document them; rather than relying on standards bodies to "=
choose a winner".





I'm not referring to competing technologies. I'm talking about one =
spec (e.g. SRv6) blatantly violating another one (IPv6).



When you have conflicting specs, you're kind of at odds with being a *s=
tandards* organization.... -- nobody knows what to expect, because one docu=
ment says one thing, and another says another thing.



There's a reason for which we have the "Update" and "Obs=
olete" tags in RFCs...



-- 

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492









_______________________________________________

Architecture-discuss mailing list

Architec=
ture-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/architecture-discu=
ss






--000000000000be54e0059f9d0ac1--


From nobody Fri Feb 28 00:19:10 2020
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 57FA73A12EF for ; Fri, 28 Feb 2020 00:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 JYkpHDgvNYdx for ; Fri, 28 Feb 2020 00:19:03 -0800 (PST)
Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 1E7C53A12F2 for ; Fri, 28 Feb 2020 00:19:03 -0800 (PST)
Received: by mail-ot1-x344.google.com with SMTP id 66so1806039otd.9 for ; Fri, 28 Feb 2020 00:19:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+x3yQzKo9MvlIYTjbjj+RTbbgL1JvHEMNGLPlmiwcA=; b=PRR495ii5vw0PhuKTgwQLJUA3h1CrhuXrU4EbKRTzlAzomQWharFq7aaUZWdCt6wWt tL/ASgINf+NPGGzZx6xCdkEewdBs+rrnknfDN+xFqbvgyGXoDStjzDM11dG4WP5ovs2i npg92p2piVoCP0jpEqyU3xwjThxnkDuP2K4RP9SuY86TwjSOKiOjAGfcJe/LMFXolMso Qp41VzoVz4xWMbPCI67l2aspWtQ0Bl5OsYTcSNsRUtrSJAZqQo1I/BdfndcAWYZ9UtsV Jw0WjiokBqfCvUH/g8sSIsJbmRY60XfmECqMgL8RNeH8d7T43iHYwNNrvePlR3/6pLsJ xC1w==
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=6+x3yQzKo9MvlIYTjbjj+RTbbgL1JvHEMNGLPlmiwcA=; b=uaW3pW4Kg9daRpm4j5KDEtYjGGnYq3fydaV0wFhZe7jLWdM8Hyz1nNJ1RaF483FB1V XwWejLLPrJo+4coB+JzTvqv90g2p/lipw3/wp9qJvrvPwmiTeRnvRKTa4c9FEz7ZekZw fgbxgeO3WyiCoPPXiKJ61qcqTHrVzFrslpDL80FkiD72jYwng3ITngH9Ow46uOX6Ihdc NEgxwgCbOMqE3SlhhxhJ5QB3KXN3BY7qxhA2yUTWqZS4tYFam86/Flrh36FZqgVq8k6y g3F4OAx3Q69AMV/6HGXqhWeRIHlUk+fg3PtQxX6nSu60y3EH+zG21pYeUVWEZM3J738u FxVw==
X-Gm-Message-State: APjAAAWz2S81Fy1XudFXGy8lyOhNQ0QhSc9dAekMSmr4m0cNPwzH/fMT MPPGrlkXmKvsYvPJFoedWzIcPBlAm9CyqdLd9dHhQw==
X-Google-Smtp-Source: APXvYqzQGtk4eUs9AfBDi5n6It6r34zkCmPzuIVXOEmA5+IXBlVd0mGgxRSVSOj4UrzZNCbGjjFqpPMDdhNnX01KPqo=
X-Received: by 2002:a9d:6a4f:: with SMTP id h15mr2393349otn.86.1582877942171;  Fri, 28 Feb 2020 00:19:02 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>   
In-Reply-To: 
From: Robert Raszuk 
Date: Fri, 28 Feb 2020 09:18:52 +0100
Message-ID: 
To: Joseph Touch 
Cc: Fernando Gont , Tom Herbert ,  Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF 
Content-Type: multipart/alternative; boundary="000000000000775a71059f9e7d31"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 08:19:05 -0000

--000000000000775a71059f9e7d31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  I don=E2=80=99t care about what you WANT to do; I care whether it breaks=
 what
everyone else expects.

I see many folks on this colorful thread simply forgot what networks are
for. To deliver packets in the most robust and resilient way to end user
applications.

As links and node fails there is established need to quickly repair when
the failure occurs to minimize packet loss.

I see that even among "routing experts" there is still false believe that
when a failure happens let's crunk up OSPF or ISIS or BGP to repair control
plane end to end to go around broken link or node. They call it "network
convergence".

In the same time for over 20 years now it has been well established that
above model is wrong approach to fast repair. Repair must happen at the
point of failure or just next to it. The terminology we use to describe
this in contrast to network convergence is connectivity restoration. With
that network protocols do not need to be stressed any more and they can
take as much time (in realistic scale) as they need to converge while user
packets bypass the failure.

And to accomplish such model in a loop free fashion *bits are added on the
fly to the packets. *If operator would do it in a way that end users suffer
he will loose revenue or job. So this is not IETF business to say - no you
can not do it as it may sometimes fail say due to MTU. If ingress to ones
network is 4K and his network can carry 9K MTU - the issues would never
cause any problems during said repair.

Sometimes bits are added in a form of new MPLS label(s) MPLS-FRR, sometimes
in a form of new encapsulation IP-FRR. Here while we are at the SR debate
such addition can be something in between. That is in my view enhancement
of IPv6 to make it more attractive to be deployed and used. I find it very
surprising that those who should promote the technology the most are
spending hours to make it less attractive for real life use.

- - -

As stated in the other thread I think SR folks were just trying to be good
IETF citizens and went towards the path of IPv6 "extension". I would just
go as building on prior art approach without even talking to 6man WG :)

Kind regards,
R.

On Fri, Feb 28, 2020 at 5:34 AM Joseph Touch  wrote:

>
>
> > On Feb 27, 2020, at 3:58 PM, Robert Raszuk  wrote:
> >
> >
> > > What draft-ietf-spring-srv6-network-programming proposes is to remove
> a
> > > segment routing header (SRH) along the packet delivery path, before
> the
> > > packet arrives at the final destination. They call it PSP.
> >
> > That removal as it has been explained to you many times happens at the
> node which is explicitly listed as DA of the packet.
> >
> > >  Before, folks have also proposed to insert Extension Headers (EHs)
> while
> > > packets are en-route to their intended destination, etc.
> >
> > That has been moved to a separate draft to move fwd with the rest of th=
e
> work.
> >
> > Yes this is still useful for TI-LFA (as example).
> >
> > We need to ask ourselves what is more important ... quality of data
> plane for end users with 10s of ms of connectivity restoration times upon
> failure or keeping original IPv6 dogmas in place where folks never
> envisioned such needs or technologies to be invented.
>
> I don=E2=80=99t care about what you WANT to do; I care whether it breaks =
what
> everyone else expects.
>
> Any device along an IP path that makes a packet larger IN ANY WAY is
> ITSELF responsible for making sure that packet can continue forward. At a
> tunnel, that means work at BOTH the ingress (source fragmentation) and
> egress (reassembly).
>
> Now, if you add EHs to an IP packet and you=E2=80=99re in control of the =
ability
> to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE***,
> then you simply can=E2=80=99t do it. Because it WILL break PLPMTUD.
>
> So if you still WANT to do this(1), then YOU need to prove you can CLEAN
> UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other
> things, will continue to work?
>
> Joe
>
> (1) this whole thing sounds a lot like Active Nets, which was a retread o=
f
> SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing =
a
> router does and expect it to do more of it, as Jon said. What is it
> Einstein said about the definition of insanity?
>
>

--000000000000775a71059f9e7d31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



>=C2=A0 I don=E2=80=99t=
 care about what you WANT to do; I care whether it breaks what everyone els=
e expects.=C2=A0=C2=A0

I see many folks on thi=
s colorful thread simply forgot what networks are for. To deliver packets i=
n the most robust and resilient=C2=A0way to end user applications.=C2=A0

As links and node fails there is established need to=
 quickly repair when the failure occurs to minimize packet loss.=C2=A0

I see that even among "routing experts" ther=
e is still false believe that when a failure happens let's crunk up OSP=
F or ISIS or BGP to repair control plane end to end to go around broken lin=
k or node. They call it "network convergence".=C2=A0
In the same time for over 20 years now it has been well establ=
ished that above model is wrong approach to fast repair. Repair must happen=
 at the point of failure or just next to it. The terminology we use to desc=
ribe this in contrast to network convergence is connectivity restoration. W=
ith that network protocols do not need to be stressed any more and they can=
 take as much time (in realistic=C2=A0scale) as they need to converge while=
 user packets bypass the failure.=C2=A0

And to acc=
omplish such model in a loop free=C2=A0fashion bits are added on the fly=
 to the packets. If operator would do it in a way that end users suffer=
 he will loose=C2=A0revenue or job. So this is not IETF business to say - n=
o you can not do it as it may sometimes fail say due to MTU. If ingress to =
ones network is 4K and his network can carry 9K MTU - the issues would neve=
r cause any problems during said repair.=C2=A0

Som=
etimes=C2=A0bits are added in a form of new MPLS label(s) MPLS-FRR, sometim=
es in a form of new encapsulation IP-FRR. Here while we are at the SR debat=
e such addition can be something in between. That is in my view enhancement=
 of IPv6 to make it more attractive to be deployed and used. I find it very=
 surprising that those who should promote the technology the most are spend=
ing hours to make it less attractive for real life use.=C2=A0
- - -=C2=A0

As stated in the other thr=
ead I think SR folks were just trying to be good IETF citizens and went tow=
ards the path of IPv6 "extension". I would just go as building on=
 prior art approach without even talking to 6man WG :)=C2=A0

=

Kind regards,
R.

<=
div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 28, 2020 at 5:34 AM Joseph=
 Touch <touch@strayalpha.com=
> wrote:




> On Feb 27, 2020, at 3:58 PM, Robert Raszuk <robert@raszuk.net> wrote:

> 

> 

> > What draft-ietf-spring-srv6-network-programming proposes is to re=
move a 

> > segment routing header (SRH) along the packet delivery path, befo=
re the 

> > packet arrives at the final destination. They call it PSP. 

> 

> That removal as it has been explained to you many times happens at the=
 node which is explicitly listed as DA of the packet. 

> 

> >=C2=A0 Before, folks have also proposed to insert Extension Header=
s (EHs) while 

> > packets are en-route to their intended destination, etc.

> 

> That has been moved to a separate draft to move fwd with the rest of t=
he work. 

> 

> Yes this is still useful for TI-LFA (as example). 

> 

> We need to ask ourselves what is more important ... quality of data pl=
ane for end users with 10s of ms of connectivity restoration times upon fai=
lure or keeping original IPv6 dogmas in place where folks never envisioned =
such needs or technologies to be invented. 



I don=E2=80=99t care about what you WANT to do; I care whether it breaks wh=
at everyone else expects.



Any device along an IP path that makes a packet larger IN ANY WAY is ITSELF=
 responsible for making sure that packet can continue forward. At a tunnel,=
 that means work at BOTH the ingress (source fragmentation) and egress (rea=
ssembly).



Now, if you add EHs to an IP packet and you=E2=80=99re in control of the ab=
ility to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE**=
*, then you simply can=E2=80=99t do it. Because it WILL break PLPMTUD.



So if you still WANT to do this(1), then YOU need to prove you can CLEAN UP=
 YOUR MESS. Where is the draft that explains how PLPMTUD, among other thing=
s, will continue to work?



Joe



(1) this whole thing sounds a lot like Active Nets, which was a retread of =
SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing a =
router does and expect it to do more of it, as Jon said. What is it Einstei=
n said about the definition of insanity?






--000000000000775a71059f9e7d31--


From nobody Fri Feb 28 01:02:13 2020
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 B992D3A138B; Fri, 28 Feb 2020 01:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PeqPYu8bUZMO; Fri, 28 Feb 2020 01:02:07 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 835773A138A; Fri, 28 Feb 2020 01:02:07 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id p125so2150360oif.10; Fri, 28 Feb 2020 01:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vyjqsTS71CHuzn/Is4ESlgINM6HS+HveFSpLrRIcj34=; b=eALDtmtoYv2dTrdeltallDXrtjEwXLOpeN/od8TAxf62ttcLspXpjDdDHzpZsPnsw1 1UiKK0gEWb4yYfkjCzglRPvL/Z2SbF8mTk1gH12+Zrxt7cplK8EnW2oiS+pn+s5cLm2b PeWnw2eNd4NFkcFArJ1xPJCVzDthn4XIf/6UkI6EQDDeMUGDvK/zZZBQ6M27XIcteT7j ilS+uAgMumNwMQM2fsrQ+ahthqYJK1Ix7/KsJG14f1M3Hx4KDNpuOvJmxCa+ABrzTzMM GfIi9ASXgPKho5fkJmsxPiQRoKQT1bpPNHNbNou/xD+MUl6uL69lBRtJgmDvLwfl0SGY F3Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vyjqsTS71CHuzn/Is4ESlgINM6HS+HveFSpLrRIcj34=; b=RFf7Ed5MNWjpV5zehJRjFfl+qvONILb/s2dIM+xgn2bUu9qexTLcEAuBx8uWI7Ls8G rVggEqvfa3chlNTFs/rQE9E60Bv4tvueY1CKE8uEemqDhlHhP+Gkm/Aa7VN6zrvthwB1 D061UAhXEOdkAvhrBUUz4g/wwA17mvITivrLNb/qL035PB8u5v++Scf4eyDkAbbHosBL CluD2teeHz6htkXLEeP3ukpb36jaiJHwIU0BfYh+v+DUhn/vpOkzDUZ25w5Xt2BheI/o H9V7dX0fcT68DgbS1372IUGnHOkrAz5Wapj6hxiwBwRxE8VlrbgdIkcyVAe7UHZQyF4S 5Y3A==
X-Gm-Message-State: APjAAAVTL1dFqDHN2LmqhmgQ3fiyBgBEJtkJ3REgG9XAFHGKLyyjoy4Q W0hzbfqmq4KnuThMF0dHnrw3dizlS7g46rYy5uc=
X-Google-Smtp-Source: APXvYqzwKC2kVCvArcjFcQ7iYamGsYwlVtHlaA1pZg0BMsk2/iekguVptcG/2AV5ds5ZMYWGPC3IzLS6T9LOuyYuRDI=
X-Received: by 2002:a54:4396:: with SMTP id u22mr2420043oiv.128.1582880526752;  Fri, 28 Feb 2020 01:02:06 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 28 Feb 2020 01:02:06 -0800 (PST)
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>    
From: Guntur Wiseno Putra 
Date: Fri, 28 Feb 2020 16:02:06 +0700
Message-ID: 
To: Robert Raszuk 
Cc: Joseph Touch , Internet Area , IETF , Tom Herbert ,  "architecture-discuss@iab.org" , Internet Architecture Board 
Content-Type: multipart/alternative; boundary="00000000000084e15d059f9f1772"
Archived-At: 
Subject: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 09:02:11 -0000

--00000000000084e15d059f9f1772
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Fernando, Robert &
architecture-discuss,


Change & Architectural Thinking and Planning...:

To add what was about D. Thaler's regarding with "proposals and changes"
and R. Raszuk's "technology for real life uses", there are also



P. Nikander in "Reflections on Architecture" (2005) proposed

"What we perhaps don=E2=80=99t consider very often is the fact that there a=
re huge
asset values embedded in various parts of the network.

Any change requires a reason to overcome the associated hurdle.
Consequently, I have found it very instructive to try to think about the
network and protocols in terms of assets, incentives, costs, and benefits".

Nikander said that there are different types and sources of complexity as
it is represented in the Internet system: emergent complexity &
architectural complexity. "While we can at most work towards understanding
emergent complexity in the first place, there is a great deal we can do
about architectural complexity." And, he said, here we need visions.

https://www.ietfjournal.org/reflections-on-architecture/#



When technology is about human passions for beauty: By a second reading on
Heidegger's via Boris Groys ("Art, Technology and Humanity, 2017), there is
an understanding that "changes of/in technology" is made/engineered
"precisely to immunize man against change, to liberate man from his
dependency on physis, on fate, on accident."


https://www.e-flux.com/journal/82/127763/art-technology-and-humanism/



Regard,
Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Robert Raszuk  menulis:

>
> >  I don=E2=80=99t care about what you WANT to do; I care whether it brea=
ks what
> everyone else expects.
>
> I see many folks on this colorful thread simply forgot what networks are
> for. To deliver packets in the most robust and resilient way to end user
> applications.
>
> As links and node fails there is established need to quickly repair when
> the failure occurs to minimize packet loss.
>
> I see that even among "routing experts" there is still false believe that
> when a failure happens let's crunk up OSPF or ISIS or BGP to repair contr=
ol
> plane end to end to go around broken link or node. They call it "network
> convergence".
>
> In the same time for over 20 years now it has been well established that
> above model is wrong approach to fast repair. Repair must happen at the
> point of failure or just next to it. The terminology we use to describe
> this in contrast to network convergence is connectivity restoration. With
> that network protocols do not need to be stressed any more and they can
> take as much time (in realistic scale) as they need to converge while use=
r
> packets bypass the failure.
>
> And to accomplish such model in a loop free fashion *bits are added on
> the fly to the packets. *If operator would do it in a way that end users
> suffer he will loose revenue or job. So this is not IETF business to say =
-
> no you can not do it as it may sometimes fail say due to MTU. If ingress =
to
> ones network is 4K and his network can carry 9K MTU - the issues would
> never cause any problems during said repair.
>
> Sometimes bits are added in a form of new MPLS label(s) MPLS-FRR,
> sometimes in a form of new encapsulation IP-FRR. Here while we are at the
> SR debate such addition can be something in between. That is in my view
> enhancement of IPv6 to make it more attractive to be deployed and used. I
> find it very surprising that those who should promote the technology the
> most are spending hours to make it less attractive for real life use.
>
> - - -
>
> As stated in the other thread I think SR folks were just trying to be goo=
d
> IETF citizens and went towards the path of IPv6 "extension". I would just
> go as building on prior art approach without even talking to 6man WG :)
>
> Kind regards,
> R.
>
> On Fri, Feb 28, 2020 at 5:34 AM Joseph Touch  wrote=
:
>
>>
>>
>> > On Feb 27, 2020, at 3:58 PM, Robert Raszuk  wrote:
>> >
>> >
>> > > What draft-ietf-spring-srv6-network-programming proposes is to
>> remove a
>> > > segment routing header (SRH) along the packet delivery path, before
>> the
>> > > packet arrives at the final destination. They call it PSP.
>> >
>> > That removal as it has been explained to you many times happens at the
>> node which is explicitly listed as DA of the packet.
>> >
>> > >  Before, folks have also proposed to insert Extension Headers (EHs)
>> while
>> > > packets are en-route to their intended destination, etc.
>> >
>> > That has been moved to a separate draft to move fwd with the rest of
>> the work.
>> >
>> > Yes this is still useful for TI-LFA (as example).
>> >
>> > We need to ask ourselves what is more important ... quality of data
>> plane for end users with 10s of ms of connectivity restoration times upo=
n
>> failure or keeping original IPv6 dogmas in place where folks never
>> envisioned such needs or technologies to be invented.
>>
>> I don=E2=80=99t care about what you WANT to do; I care whether it breaks=
 what
>> everyone else expects.
>>
>> Any device along an IP path that makes a packet larger IN ANY WAY is
>> ITSELF responsible for making sure that packet can continue forward. At =
a
>> tunnel, that means work at BOTH the ingress (source fragmentation) and
>> egress (reassembly).
>>
>> Now, if you add EHs to an IP packet and you=E2=80=99re in control of the=
 ability
>> to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE***,
>> then you simply can=E2=80=99t do it. Because it WILL break PLPMTUD.
>>
>> So if you still WANT to do this(1), then YOU need to prove you can CLEAN
>> UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other
>> things, will continue to work?
>>
>> Joe
>>
>> (1) this whole thing sounds a lot like Active Nets, which was a retread
>> of SoftNet. So the cycle goes, every 20 years or so. Take the slowest th=
ing
>> a router does and expect it to do more of it, as Jon said. What is it
>> Einstein said about the definition of insanity?
>>
>>

--00000000000084e15d059f9f1772
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Fernando, Robert &
architecture-discuss,


Change & Architectural Thinking and Planning...:

To add what was about D. Thaler's regarding wit=
h "proposals and changes" and R. Raszuk's "technology fo=
r real life uses", there are also





P. Nikander in "Reflections on Architecture" (2005) proposed 


"What we perhaps don=E2=80=99t consider very often is the fact tha=
t there are huge asset values embedded in various parts of the network.



Any change requires a reason to overcome the associated hurdle. Consequentl=
y, I have found it very instructive to try to think about the network and p=
rotocols in terms of assets, incentives, costs, and benefits". 


Nikander said that there are different types and sources of complexity =
as it is represented in the Internet system: emergent complexity & arch=
itectural complexity.=C2=A0"While we can at most work towards understa=
nding emergent complexity in the first place, there is a great deal we can =
do about architectural complexity." And, he said, here we need visions=
.



https://www.ietfjournal.org/reflections-on-architecture/#=




=C2=A0


When technology is about human passions for beauty: By a second reading=
 on Heidegger's via Boris Groys ("Art, Technology and Humanity, 20=
17), there is an understanding that "changes of/in technology" is=
 made/engineered "precisely to immunize man against change, to liberat=
e man from his dependency on physis, on fate, on accident." 





https://www.e-flux.com/journal/82/127763/art-=
technology-and-humanism/



Regard,
Guntur Wiseno Putra

Pada Jumat, =
28 Februari 2020, Robert Raszuk <robert@raszuk.net> menulis:

>=C2=A0 I don=
=E2=80=99t care about what you WANT to do; I care whether it breaks what ev=
eryone else expects.=C2=A0=C2=A0

I see many fo=
lks on this colorful thread simply forgot what networks are for. To deliver=
 packets in the most robust and resilient=C2=A0way to end user applications=
.=C2=A0

As links and node fails there is establish=
ed need to quickly repair when the failure occurs to minimize packet loss.=
=C2=A0

I see that even among "routing experts=
" there is still false believe that when a failure happens let's c=
runk up OSPF or ISIS or BGP to repair control plane end to end to go around=
 broken link or node. They call it "network convergence".=C2=A0

In the same time for over 20 years now it has been =
well established that above model is wrong approach to fast repair. Repair =
must happen at the point of failure or just next to it. The terminology we =
use to describe this in contrast to network convergence is connectivity res=
toration. With that network protocols do not need to be stressed any more a=
nd they can take as much time (in realistic=C2=A0scale) as they need to con=
verge while user packets bypass the failure.=C2=A0

And to accomplish such model in a loop free=C2=A0fashion bits are added=
 on the fly to the packets. If operator would do it in a way that end u=
sers suffer he will loose=C2=A0revenue or job. So this is not IETF business=
 to say - no you can not do it as it may sometimes fail say due to MTU. If =
ingress to ones network is 4K and his network can carry 9K MTU - the issues=
 would never cause any problems during said repair.=C2=A0

Sometimes=C2=A0bits are added in a form of new MPLS label(s) MPLS-F=
RR, sometimes in a form of new encapsulation IP-FRR. Here while we are at t=
he SR debate such addition can be something in between. That is in my view =
enhancement of IPv6 to make it more attractive to be deployed and used. I f=
ind it very surprising that those who should promote the technology the mos=
t are spending hours to make it less attractive for real life use.=C2=A0

- - -=C2=A0

As stated in th=
e other thread I think SR folks were just trying to be good IETF citizens a=
nd went towards the path of IPv6 "extension". I would just go as =
building on prior art approach without even talking to 6man WG :)=C2=A0

Kind regards,
R.

On Fri, Feb 28, 2020 at 5:3=
4 AM Joseph Touch <touch@strayalpha.com> wrote:




> On Feb 27, 2020, at 3:58 PM, Robert Raszuk <robert@raszuk.net> wrote:

> 

> 

> > What draft-ietf-spring-srv6-network-programming proposes is =
to remove a 

> > segment routing header (SRH) along the packet delivery path, befo=
re the 

> > packet arrives at the final destination. They call it PSP. 

> 

> That removal as it has been explained to you many times happens at the=
 node which is explicitly listed as DA of the packet. 

> 

> >=C2=A0 Before, folks have also proposed to insert Extension Header=
s (EHs) while 

> > packets are en-route to their intended destination, etc.

> 

> That has been moved to a separate draft to move fwd with the rest of t=
he work. 

> 

> Yes this is still useful for TI-LFA (as example). 

> 

> We need to ask ourselves what is more important ... quality of data pl=
ane for end users with 10s of ms of connectivity restoration times upon fai=
lure or keeping original IPv6 dogmas in place where folks never envisioned =
such needs or technologies to be invented. 



I don=E2=80=99t care about what you WANT to do; I care whether it breaks wh=
at everyone else expects.



Any device along an IP path that makes a packet larger IN ANY WAY is ITSELF=
 responsible for making sure that packet can continue forward. At a tunnel,=
 that means work at BOTH the ingress (source fragmentation) and egress (rea=
ssembly).



Now, if you add EHs to an IP packet and you=E2=80=99re in control of the ab=
ility to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE**=
*, then you simply can=E2=80=99t do it. Because it WILL break PLPMTUD.



So if you still WANT to do this(1), then YOU need to prove you can CLEAN UP=
 YOUR MESS. Where is the draft that explains how PLPMTUD, among other thing=
s, will continue to work?



Joe



(1) this whole thing sounds a lot like Active Nets, which was a retread of =
SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing a =
router does and expect it to do more of it, as Jon said. What is it Einstei=
n said about the definition of insanity?








--00000000000084e15d059f9f1772--


From nobody Fri Feb 28 05:32:12 2020
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 501323A180D; Fri, 28 Feb 2020 05:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level: 
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 BncC78wauein; Fri, 28 Feb 2020 05:32:07 -0800 (PST)
Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (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 B50B33A180A; Fri, 28 Feb 2020 05:32:07 -0800 (PST)
Received: by mail-oi1-f177.google.com with SMTP id g6so1129609oiy.1; Fri, 28 Feb 2020 05:32:07 -0800 (PST)
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=LrjM6SvH0asz17Wmj/mbfchzddYXf9LWg9KhAWOzBLc=; b=ru5V+DueyrDijP1FFldfpaVLPH4iUEvLFATFniaoP//b+P315v7aVWjrUbFEVIfsIA u5nUY8sTHXSaBIj7FEUCh29KcGDqKRG108FeNPpy7ZSzpVQt7PKkGAgJrPxxOUYFrECL ygcL31r5HI4XU7WcBSvAQ4SBehFXRmpQBfmEnrfZwtkKSDD1YgN9Gt+xiYxu2GWMGLfw FV0jSe15lddjYjU6wtWKlfVkG2kM7m/EiNV0/2z536vlTntjZWO7VVKMlY4MNPrO3nAQ aoAMj5S4mYdQi4rZ/9DHfdWiN1tam2Cswf1rnpDjpDfLQcezMII7myCNwyF4dAPSvfYy +J5A==
X-Gm-Message-State: APjAAAWN2kvHVM05ijMQFHAIYBB2eSQnq83+UvTzYjfBd5utGv2AdDau 54io7U2sjVCs7D31HsJPHe0xzpCQdOnwj35HV8Y=
X-Google-Smtp-Source: APXvYqxJFbIWZq3IUws94GGqnUFuRfPN0FM9hKHcDKT51WZlsMjS/zzTQVyZD8K9S817HXWWBfowM9CD9n43RB75V4Q=
X-Received: by 2002:aca:cf94:: with SMTP id f142mr3042599oig.31.1582896726892;  Fri, 28 Feb 2020 05:32:06 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>  <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com>
In-Reply-To: <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com>
From: Phillip Hallam-Baker 
Date: Fri, 28 Feb 2020 08:31:55 -0500
Message-ID: 
To: Joseph Touch 
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF Discussion Mailing List 
Content-Type: multipart/alternative; boundary="0000000000001f647e059fa2ddf3"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 13:32:10 -0000

--0000000000001f647e059fa2ddf3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch  wrote:

>
>
> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker 
> wrote:
>
> IP end to end does not mean the IP address is constant end to end. It
>> never has meant that and never will.
>>
>>
>> Actually, that's the only thing it ever meant and always will. When
>> addresses change, *by definition*, the*ends* change (and yes, that's wha=
t
>> NATs do - they create end-to-end CONTENT transfer over separate end-to-e=
nd
>> Internets).
>>
>
> By whose definition? Not by mine.
>
>
> I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also the ps=
eudo header in
> RFC 793, to be very specific.
>
> TCP and TLS give me a reliable end-to-end stream. The fact that the IP
> address is exposed is merely an unfortunate defect in the legacy APIs.
>
> As the application layer designer, I am the customer here. I do not care
> about the IP address.
>
>
> Hmmm. By what value do you call  TCP endpoint?
>
> You must have magic sockets that don=E2=80=99t actually refer to IP addre=
sses.
>

I have a library that implements RFC6763. So my application code doesn't
actually consider IP addresses.

Since the platform doesn't provide real DNS resolution, I have to write my
own of course. And I will be putting DNSSEC in there at some point
probably. But it is a feature set that should be in the platform.

At some point, I am going to have to look at implementing TURN/STUN/PCP
etc. for NAT traversal. That certainly isn't application layer code.

So as far as i am concerned, I am resolving a triple of SRV prefix, DNS
name and account name to a socket.

The only case in which my application code would deal in a raw IP address
and port is if the resolution is delegated to an external presence service.
If Alice is trying to make a person-person call to Bob, we may want to
route the packets direct. So there has to be some sort of presence service
in the cloud to set up the connection which is going to end up telling one
of them to place a call for an IP address/port and the other of them to
listen for the incoming.


The test of this design is straightforward, all the proposals for DNS
privacy etc. sit inside the library. I can drop out regular client DNS for
DPRIV. Or I can use my omnibroker version which makes use of the RFC6763
interface.

Abstracting away from TLS and UDP means I can adapt to new transports like
QUIC very easily. For certain types of message, I have my own UDP based
transport. Most cryptographic service transactions consist of a single
request packet followed by one to a dozen response packets. That sits in
the same box.


It really isn't 'magic', it is just understanding that this is platform
code not application code.

We do not have 'layers' in the Internet architecture but we have modules
that we call layers. And those layers have interfaces to the layers above
and beneath them that are mediated by a naming infrastructure. And we
should be really explicit about what those interfaces are because they have
to be stable over long periods of time.

--0000000000001f647e059fa2ddf3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch <<=
a href=3D"mailto:touch@strayalpha.com">touch@strayalpha.com> wrote:<=
br>


On Fe=
b 27, 2020, at 4:21 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=

IP end to end does not mean the IP address is constant end to=
 end. It never has meant that and never will.
=C2=A0
Actually, that's the only thing it e=
ver meant and always will. When addresses change, *by definition*, the*ends=
* change (and yes, that's what NATs do - they create end-to-end CONTENT=
 transfer over separate end-to-end Internets).

=

By whose defini=
tion? Not by mine.
<=
div>
I=E2=80=99d start with RFCs 791 and 1122, but there=E2=
=80=99s also the pseudo header in RFC 793, to be very specific.

TCP an=
d TLS give me a reliable end-to-end stream. The fact that the IP address is=
 exposed is merely an unfortunate defect in the legacy APIs.=C2=A0

=
As the application layer design=
er, I am the customer here. I do not care about the IP address.

Hmmm. By what value do=
 you call =C2=A0TCP endpoint?

You must have magic =
sockets that don=E2=80=99t actually refer to IP addresses.

I have a library that implements RFC6763. So my application code do=
esn't actually consider IP addresses.

Since the platform doesn't provide real DNS reso=
lution, I have to write my own of course. And I will be putting DNSSEC in t=
here at some point probably. But it is a feature set that should be in the =
platform.

<=
/div>
At some point, =
I am going to have to look at implementing TURN/STUN/PCP etc. for NAT trave=
rsal. That certainly isn't application layer code.

So as far as i am concerned, I am resolving a=
 triple of SRV prefix, DNS name and account name to a socket.

The only case in which my application =
code would deal in a raw IP address and port is if the resolution is delega=
ted to an external presence service. If Alice is trying to make a person-pe=
rson call to Bob, we may want to route the packets direct. So there has to =
be some sort of presence service in the cloud to set up the connection whic=
h is going to end up telling one of them to place a call for an IP address/=
port and the other of them to listen for the incoming.


The test of this design is straightforward, all the pr=
oposals for DNS privacy etc. sit inside the library. I can drop out regular=
 client DNS for DPRIV. Or I can use my omnibroker version which makes use o=
f the RFC6763 interface.

=
Abstracting away from TLS and UDP means I can adapt to new transports like =
QUIC very easily. For certain types of message, I have my own UDP based tra=
nsport. Most cryptographic service transactions consist of a single request=
 packet followed by one to a dozen response packets. That sits in the same =
box.

=


It really isn't 'magic=
', it is just understanding that this is platform code not application =
code.

We do not have '=
;layers' in the Internet architecture but we have modules that we call =
layers. And those layers have interfaces to the layers above and beneath th=
em that are mediated by a naming infrastructure. And we should be really ex=
plicit about what those interfaces are because they have to be stable over =
long periods of time.


--0000000000001f647e059fa2ddf3--


From nobody Fri Feb 28 08:15:05 2020
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 EEEFA3A1A77 for ; Fri, 28 Feb 2020 08:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 4H_QYPSoq0_O for ; Fri, 28 Feb 2020 08:14:53 -0800 (PST)
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 9A1883A1A7B for ; Fri, 28 Feb 2020 08:14:52 -0800 (PST)
Received: by mail-ed1-x544.google.com with SMTP id c26so3943984eds.8 for ; Fri, 28 Feb 2020 08:14:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yfkrdZQKab5QtWW2OqZAPyTcbdRJ0wT5/TgetjxwKaE=; b=i9JipcZ0R2CN439e+1/R/mcqLhkv/+yPU4jvC8QUkhZe7Gr1FfofSV93hij++pnWl0 GAwpOUCBGGaoIIoBqEtDDsT81SaFOhYryEeIlVczzam2I4g+i89ZQEwHv63cz0Aygy08 H5YfeYE+rTyJGnDDhQR+s0txntrMTq2VczQ2s1kpFWTjApTUAGUWslYt6Ix/UnbPSbJa AFabkJyJrL+4lrS4luOnZb4RuwYNaMZWjkJ8MbEqhl9KNAl3e+xZzOzVNAd+AqWR6r9S zKIsMFXzP6qF9RIjdioxA6fzY8vQNXs1Ea5KonAtd+skXh9Z3mMps1lQmP7OilW+CUPI 1A5w==
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:content-transfer-encoding; bh=yfkrdZQKab5QtWW2OqZAPyTcbdRJ0wT5/TgetjxwKaE=; b=DJpbIiFeEeaSjXOsV22C18BrXvpwDR40Ckk5hpC10ZVkv/mwqsvdhU4uXl90W6jb2Y tXEthUM+h0ip/VDwCEqD2TDTc/sjyTOLjG3eNwU5948zyjH+CoeWF+efI5QMWjTlpZ7l AplZf7oIOSszkcXtDW7w9JUiuNdpDfoZKMiv2AAN4KvoWl/0PIO4w+QGRJfRRNivAcud 4gcD/iPTemznHs0lV+G9NYiPEMxZDGzElaeZie7NmgeDZT0V5tlcgM3/ZOxtdo77dKCs OSQCXZWWj0eHmRYgsq+tixNiEURpwhvCcuPBGSF78Q30CHVAQbK2mni5X4t108IFlLp0 YxvQ==
X-Gm-Message-State: APjAAAXzStSQIeb/rCxG0vBze26BzAqldSUEQNyHKiTPG95AQkQi64B8 szd7Zs1oLU2cAdot3qAzk1IZ6aQEBSVLcAX5AFWbqw==
X-Google-Smtp-Source: APXvYqw6PfHdiDHtsgTJyM5XMTAv0LEzvWryI2LWvmW+v3+7cvK40M8vR3H3HSssHkkSlda69YsktL+Z/O4MVdlHmcg=
X-Received: by 2002:a17:906:128f:: with SMTP id k15mr1823221ejb.266.1582906490793;  Fri, 28 Feb 2020 08:14:50 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>  <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com> 
In-Reply-To: 
From: Tom Herbert 
Date: Fri, 28 Feb 2020 08:14:39 -0800
Message-ID: 
To: Phillip Hallam-Baker 
Cc: Joseph Touch , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF Discussion Mailing List 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 16:14:56 -0000

On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
 wrote:
>
>
>
> On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch  wrot=
e:
>>
>>
>>
>> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker  wrote:
>>
>>> IP end to end does not mean the IP address is constant end to end. It n=
ever has meant that and never will.
>>>
>>>
>>> Actually, that's the only thing it ever meant and always will. When add=
resses change, *by definition*, the*ends* change (and yes, that's what NATs=
 do - they create end-to-end CONTENT transfer over separate end-to-end Inte=
rnets).
>>
>>
>> By whose definition? Not by mine.
>>
>>
>> I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also the p=
seudo header in RFC 793, to be very specific.
>>
>> TCP and TLS give me a reliable end-to-end stream. The fact that the IP a=
ddress is exposed is merely an unfortunate defect in the legacy APIs.
>>
>> As the application layer designer, I am the customer here. I do not care=
 about the IP address.
>>
>>
>> Hmmm. By what value do you call  TCP endpoint?
>>
>> You must have magic sockets that don=E2=80=99t actually refer to IP addr=
esses.
>
>
> I have a library that implements RFC6763. So my application code doesn't =
actually consider IP addresses.
>
It's great that _you_ have a solution, but not everyone does. The
standard says that a TCP connection endpoint is defined by a 4-tuple
of source address, destination address, source port, destination port.
It is an invariant that we have forty years of operational experience
with. If you think that design decision is obsolete or should be
revisited, then by all means propose an alternative in tsvwg.

Tom

> Since the platform doesn't provide real DNS resolution, I have to write m=
y own of course. And I will be putting DNSSEC in there at some point probab=
ly. But it is a feature set that should be in the platform.
>
> At some point, I am going to have to look at implementing TURN/STUN/PCP e=
tc. for NAT traversal. That certainly isn't application layer code.
>
> So as far as i am concerned, I am resolving a triple of SRV prefix, DNS n=
ame and account name to a socket.
>
> The only case in which my application code would deal in a raw IP address=
 and port is if the resolution is delegated to an external presence service=
. If Alice is trying to make a person-person call to Bob, we may want to ro=
ute the packets direct. So there has to be some sort of presence service in=
 the cloud to set up the connection which is going to end up telling one of=
 them to place a call for an IP address/port and the other of them to liste=
n for the incoming.
>
>
> The test of this design is straightforward, all the proposals for DNS pri=
vacy etc. sit inside the library. I can drop out regular client DNS for DPR=
IV. Or I can use my omnibroker version which makes use of the RFC6763 inter=
face.
>
> Abstracting away from TLS and UDP means I can adapt to new transports lik=
e QUIC very easily. For certain types of message, I have my own UDP based t=
ransport. Most cryptographic service transactions consist of a single reque=
st packet followed by one to a dozen response packets. That sits in the sam=
e box.
>
>
> It really isn't 'magic', it is just understanding that this is platform c=
ode not application code.
>
> We do not have 'layers' in the Internet architecture but we have modules =
that we call layers. And those layers have interfaces to the layers above a=
nd beneath them that are mediated by a naming infrastructure. And we should=
 be really explicit about what those interfaces are because they have to be=
 stable over long periods of time.


From nobody Fri Feb 28 09:20:33 2020
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 B034A3A1C59; Fri, 28 Feb 2020 09:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level: 
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hOJPGCOGH3SA; Fri, 28 Feb 2020 09:20:00 -0800 (PST)
Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) (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 A568B3A0C86; Fri, 28 Feb 2020 09:20:00 -0800 (PST)
Received: by mail-oi1-f194.google.com with SMTP id q84so3575786oic.4; Fri, 28 Feb 2020 09:20:00 -0800 (PST)
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=iuwyW1f4sqbHT0sThfnqfsz1WCiF++s6d9KzJrxFz+8=; b=WvNekAQr2VfMWtv2vUtId1pimOn6o7oIncgUlvS6zH+iXZRBnepFiKC5Uyj4ttP05H yNHyKLi17901WEHX1+Smbq3C9SMwJHuGIcBySYNuIkyX3Hv7L3nR3qzG1LzHjnlAtDWW 6I1gNZdzf+YAQBHEnUeOhdn+QxMpGskjiVy6RGK4c6ETHEB/BOrroAb0NrPt+azHT5/9 uyYZARsKVoDvugbcSKKxZtZ7S41lNSSAmZ8zG5FeJD+Bc9DQcR+Z+YPXoo7/k4/gpgLd 9qPSdOvMlLo7jrl3AUVVzRpEaPzCnoihexsRBkNkXWoOCSXroy4zoxo8iPCW5q8aaiU1 Xv3A==
X-Gm-Message-State: APjAAAUlrbk6pPFMbqBcU3JzfiNXnF1jAdOko9lD+ax0e92xdaSunUQc ewct6lDKeqtb0SKEC2prvo/I+NE/CG7wAVisi3c=
X-Google-Smtp-Source: APXvYqzwEHmtvgzLQ4IRxwPqbzymspYHZ500XIjbARL+3aopqT1KD4JXhARpBj59QcXWzv57WVIcjFN1B6e74tODmm4=
X-Received: by 2002:a05:6808:45:: with SMTP id v5mr3776515oic.90.1582910399679;  Fri, 28 Feb 2020 09:19:59 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>  <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com>  
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Fri, 28 Feb 2020 12:19:48 -0500
Message-ID: 
To: Tom Herbert 
Cc: Joseph Touch , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF Discussion Mailing List 
Content-Type: multipart/alternative; boundary="0000000000001595dc059fa60cb0"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 17:20:07 -0000

--0000000000001595dc059fa60cb0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 28, 2020 at 11:14 AM Tom Herbert  wrote:

> On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
>  wrote:
> >
> >
> >
> > On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch 
> wrote:
> >>
> >>
> >>
> >> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <
> phill@hallambaker.com> wrote:
> >>
> >>> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will.
> >>>
> >>>
> >>> Actually, that's the only thing it ever meant and always will. When
> addresses change, *by definition*, the*ends* change (and yes, that's what
> NATs do - they create end-to-end CONTENT transfer over separate end-to-en=
d
> Internets).
> >>
> >>
> >> By whose definition? Not by mine.
> >>
> >>
> >> I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also the=
 pseudo header in
> RFC 793, to be very specific.
> >>
> >> TCP and TLS give me a reliable end-to-end stream. The fact that the IP
> address is exposed is merely an unfortunate defect in the legacy APIs.
> >>
> >> As the application layer designer, I am the customer here. I do not
> care about the IP address.
> >>
> >>
> >> Hmmm. By what value do you call  TCP endpoint?
> >>
> >> You must have magic sockets that don=E2=80=99t actually refer to IP ad=
dresses.
> >
> >
> > I have a library that implements RFC6763. So my application code doesn'=
t
> actually consider IP addresses.
> >
> It's great that _you_ have a solution, but not everyone does. The
> standard says that a TCP connection endpoint is defined by a 4-tuple
> of source address, destination address, source port, destination port.
> It is an invariant that we have forty years of operational experience
> with. If you think that design decision is obsolete or should be
> revisited, then by all means propose an alternative in tsvwg.
>
> Tom
>

That is a TCP connection. Applications don't deal in TCP connections, they
deal in sockets.

Its called abstraction. All that complexity belongs in a box that the
application programmer doesn't need to open.

Now current practice is that people use the gethostbyname() call to do DNS
resolution and so they end up being unable to make use of DNS properly. But
that is a problem with the 40 year old legacy API which can be changed or
circumvented entirely

RFC6763 is what the application layer should use.

--0000000000001595dc059fa60cb0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Feb 28, 2020 at 11:14 AM Tom Herbert <tom@herbertland.com> wrote:
=

On Fri, Feb 28, 202=
0 at 5:32 AM Phillip Hallam-Baker

<phill@hallam=
baker.com> wrote:

>

>

>

> On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch <touch@strayalpha.com> wrote:
>>

>>

>>

>> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <phill@hallambaker.com>=
; wrote:

>>

>>> IP end to end does not mean the IP address is constant end to =
end. It never has meant that and never will.

>>>

>>>

>>> Actually, that's the only thing it ever meant and always w=
ill. When addresses change, *by definition*, the*ends* change (and yes, tha=
t's what NATs do - they create end-to-end CONTENT transfer over separat=
e end-to-end Internets).

>>

>>

>> By whose definition? Not by mine.

>>

>>

>> I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also=
 the pseudo header in RFC 793, to be very specific.

>>

>> TCP and TLS give me a reliable end-to-end stream. The fact that th=
e IP address is exposed is merely an unfortunate defect in the legacy APIs.=


>>

>> As the application layer designer, I am the customer here. I do no=
t care about the IP address.

>>

>>

>> Hmmm. By what value do you call=C2=A0 TCP endpoint?

>>

>> You must have magic sockets that don=E2=80=99t actually refer to I=
P addresses.

>

>

> I have a library that implements RFC6763. So my application code doesn=
't actually consider IP addresses.

>

It's great that _you_ have a solution, but not everyone does. The

standard says that a TCP connection endpoint is defined by a 4-tuple

of source address, destination address, source port, destination port.

It is an invariant that we have forty years of operational experience

with. If you think that design decision is obsolete or should be

revisited, then by all means propose an alternative in tsvwg.



Tom

That is a TCP connection. Applications don't deal in TCP=
 connections, they deal in sockets.

Its called abstraction. All that complexity belongs in a box tha=
t the application programmer doesn't need to open.=C2=A0

Now current practice is that people use=
 the gethostbyname() call to do DNS resolution and so they end up being una=
ble to make use of DNS properly. But that is a problem with the 40 year old=
 legacy API which can be changed or circumvented entirely

RFC6763 is what the application layer sh=
ould use.


--0000000000001595dc059fa60cb0--


From nobody Fri Feb 28 10:12:23 2020
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 5A1813A1B8B for ; Fri, 28 Feb 2020 10:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.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 S9gpkoHUiKNc for ; Fri, 28 Feb 2020 10:12:18 -0800 (PST)
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 032C13A1B79 for ; Fri, 28 Feb 2020 10:12:17 -0800 (PST)
Received: by mail-ed1-x542.google.com with SMTP id h62so2475557edd.12 for ; Fri, 28 Feb 2020 10:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nbqj66hSx047hP3c2jdr/Ia18PUNaaE5PFZIaHs2zJY=; b=g6LEVdWSz+ysvrk8DrNIrMeGvHTXcQ5vCKCC+n+CREQVOi3huXaE/mFpXnwLdso8Hn wbShg1qN/ngSmv8dnKA+RBPpgKyIpMkU1CvndDo+Frdi1GimAKETK1XJAkt7aDt1sBN9 G0RgBolT7DNR4i+iwvSuPtz2URs6jb+R4CiffObNnMpfqYZmO9ZA/cQ9PslUVUSRnbJ8 zoNTfov2FgDMpZw+rwCYp+kp7CRd6TVllP1ZWf6sL0vZsbe3MNfma3HZRYX0Z89KURX6 5dM9FZPn6iNJDBbL8Cv92zVw1KKG5XaFXLQF/brz9bF7W9V5GQrtRsWs9mXR5eb976Or AI2w==
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:content-transfer-encoding; bh=nbqj66hSx047hP3c2jdr/Ia18PUNaaE5PFZIaHs2zJY=; b=Oxum0TqYVkD3Hj32RrxBLlyuLbaML+MyNL5bVXYCPSU/Ra/wk5mnmhA8myWKHBe6qh AWIxakDa+kYyOEu/ah2lqqt3TNsN2xGZr/5ri2mu9+h8dJn8HafQ0vvBWA4X6a2itEqS yln6y8oVj8UUGJxWVvlIbnMeZkTru1itKVme4X9/1MGR+m+1Ol1HY7Q1pggOFoKZWbui NG+UYEOAUcXJILdQwD/c+3xrkxNJEgZKgcwOnWsvnYsEm5PDbtVkMBpohiiJZRJjfRf7 Wrlrkq8cFmKGvZMawDdklts+0SPpWkXQAeHjqSnhYTjVQBCqHxfUXJTzrqzMHA3lDoPR TaiQ==
X-Gm-Message-State: ANhLgQ2U3/DmzTCrSYY/CoCMm67+/ijAi8j+wyzXJo2GOcmUXChB4HHj ca+alJddmg7hTNPjOZxO3IBJ0zc4IUb4n0pf6QXd7w==
X-Google-Smtp-Source: ADFU+vt5Do6QBx27KTHAajMP6KBpqFz193bGVl7UOn0sAZU8voOzHiVaRFRw//Yn9ktymZ4FP25PbATNxOh5PyaGfSQ=
X-Received: by 2002:a17:906:729c:: with SMTP id b28mr528875ejl.295.1582913536346;  Fri, 28 Feb 2020 10:12:16 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>  <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com>   
In-Reply-To: 
From: Tom Herbert 
Date: Fri, 28 Feb 2020 10:12:05 -0800
Message-ID: 
To: Phillip Hallam-Baker 
Cc: Joseph Touch , Internet Architecture Board , architecture-discuss@iab.org,  Internet Area , IETF Discussion Mailing List 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 28 Feb 2020 18:12:21 -0000

On Fri, Feb 28, 2020 at 9:20 AM Phillip Hallam-Baker
 wrote:
>
>
>
> On Fri, Feb 28, 2020 at 11:14 AM Tom Herbert  wrote:
>>
>> On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
>>  wrote:
>> >
>> >
>> >
>> > On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch  w=
rote:
>> >>
>> >>
>> >>
>> >> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker  wrote:
>> >>
>> >>> IP end to end does not mean the IP address is constant end to end. I=
t never has meant that and never will.
>> >>>
>> >>>
>> >>> Actually, that's the only thing it ever meant and always will. When =
addresses change, *by definition*, the*ends* change (and yes, that's what N=
ATs do - they create end-to-end CONTENT transfer over separate end-to-end I=
nternets).
>> >>
>> >>
>> >> By whose definition? Not by mine.
>> >>
>> >>
>> >> I=E2=80=99d start with RFCs 791 and 1122, but there=E2=80=99s also th=
e pseudo header in RFC 793, to be very specific.
>> >>
>> >> TCP and TLS give me a reliable end-to-end stream. The fact that the I=
P address is exposed is merely an unfortunate defect in the legacy APIs.
>> >>
>> >> As the application layer designer, I am the customer here. I do not c=
are about the IP address.
>> >>
>> >>
>> >> Hmmm. By what value do you call  TCP endpoint?
>> >>
>> >> You must have magic sockets that don=E2=80=99t actually refer to IP a=
ddresses.
>> >
>> >
>> > I have a library that implements RFC6763. So my application code doesn=
't actually consider IP addresses.
>> >
>> It's great that _you_ have a solution, but not everyone does. The
>> standard says that a TCP connection endpoint is defined by a 4-tuple
>> of source address, destination address, source port, destination port.
>> It is an invariant that we have forty years of operational experience
>> with. If you think that design decision is obsolete or should be
>> revisited, then by all means propose an alternative in tsvwg.
>>
>> Tom
>
>
> That is a TCP connection. Applications don't deal in TCP connections, the=
y deal in sockets.
>
> Its called abstraction. All that complexity belongs in a box that the app=
lication programmer doesn't need to open.
>
Yes, but in BSD sockets, the most common networking API, "bind" takes
an address and port number argument, "connect" takes and address and
port number argument, getsockname and getpeername return the
respective pairs set on a socket. So the TCP 4-tuple is very visible
to applications and has been for many years. If there's a better way
to do this that hides this and makes it easier I say go for it, but
please don't call this a solved problem until you've achieved
ubiquitous deployment and we can obsolete the sockets API since no one
is using it anymore.

In any case, I don't see how any of this is relevant to protocol
discussion. We build APIs based on protocol requirements, not the
other way around.

Tom
> Now current practice is that people use the gethostbyname() call to do DN=
S resolution and so they end up being unable to make use of DNS properly. B=
ut that is a problem with the 40 year old legacy API which can be changed o=
r circumvented entirely
>
> RFC6763 is what the application layer should use.


From nobody Fri Feb 28 17:56:04 2020
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 A66113A091B; Fri, 28 Feb 2020 17:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 hLwz27NLM4N6; Fri, 28 Feb 2020 17:55:47 -0800 (PST)
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 C2A0F3A0914; Fri, 28 Feb 2020 17:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=X5IcYCh1TgOb92GJ5QcDsTedG637m5w4dIVKafa5D0E=; b=0PYoK+bv67ImmsehFa7P67ApN gb3s8wCqi/RtB9Vntecp/og+ylAMGJokyA/pPmglvX0PYcJ03fgCHocITjAuhagG2H49+Vd5tfaE3 ZUkU/EkXlRctNaj2YZsscBHYKQuYXI0Gz6GCqTVCEdqCM6IfHE/PSv17SHpUVjoOKrM6+hggwKznM Szv6VBAFV1LJWAU7UHPWyfuk8mBJ6CIgasL4DB5qJub+Gws9RV+lH8AdsF1UbAWm+WC2QADbrGnSK aMJAoDf+7++eL4oN53qZd/dv0U+QtAmSrKAtPe0VEU4gFYWQh0fHqoyqYiQAExkXGAFekA2vC36m1 Cn1xpG2xg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59484 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7rLt-000m0m-1K; Fri, 28 Feb 2020 20:55:42 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B5CB3541-5275-43E8-9448-35076BB982BE"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 28 Feb 2020 17:55:36 -0800
Cc: Fernando Gont , Tom Herbert ,  Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
Message-Id: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>    
To: Robert Raszuk 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 29 Feb 2020 01:56:01 -0000

--Apple-Mail=_B5CB3541-5275-43E8-9448-35076BB982BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 28, 2020, at 12:18 AM, Robert Raszuk  wrote:
>=20
> >  I don=E2=80=99t care about what you WANT to do; I care whether it =
breaks what everyone else expects. =20
>=20
> I see many folks on this colorful thread simply forgot what networks =
are for. To deliver packets in the most robust and resilient way to end =
user applications.=20

They=E2=80=99re for delivering packets, agreed.

I did look at the protocols involved here; the ingress does add headers =
but doesn=E2=80=99t appear to handle fragmentation.

That=E2=80=99s a non-starter if you want your packets to traverse a =
network because people WILL hand you 1280-byte packets, so what will you =
do?

Joe=

--Apple-Mail=_B5CB3541-5275-43E8-9448-35076BB982BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 28, 2020, at 12:18 AM, Robert Raszuk <robert@raszuk.net> =
wrote:

>  I don=E2=80=99t care about what you WANT to do; I =
care whether it breaks what everyone else expects.  

I see many folks on this colorful =
thread simply forgot what networks are for. To deliver packets in the =
most robust and resilient way to end user =
applications. 

They=E2=80=99re for delivering packets, agreed.

I did look at the =
protocols involved here; the ingress does add headers but doesn=E2=80=99t =
appear to handle fragmentation.

That=E2=80=99s a non-starter if you =
want your packets to traverse a network because people WILL hand you =
1280-byte packets, so what will you do?

Joe
=

--Apple-Mail=_B5CB3541-5275-43E8-9448-35076BB982BE--


From nobody Fri Feb 28 17:57:31 2020
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 960B63A0917; Fri, 28 Feb 2020 17:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 Eif3phJKcA1C; Fri, 28 Feb 2020 17:57:21 -0800 (PST)
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 7010C3A0936; Fri, 28 Feb 2020 17:57:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=TmKlkDyLBVckp3n6Q152Q4ZLUgtY1KQ0t4EjXGC5r/Y=; b=Mp+OpEJmxTyAlxFwW25koguJ8 etTnlFGhiwvllgVSeELIMu59tnhScuMbtLeESyb/Q1gVmkBHDNZSIkyBgA961sg32qsvp2O7/CpXK LtwPzqe64t73bmDX1JVIAm5eBJQRa2kKWSUovhJh0HEwuUjq/Nkh5DGa/CmUZd2I4YBx6LyKUl0gY RX+Ck2Y3aaivj+4/IpsC7yalaaMTXTU6nrd6kiIr8IUYhaxTU0t/V52TbXR/2bkx4vKd/3xCeX3LD VjYGRSya9gp54+l+2IWwSGil+OKrM7elqfc9eTsUlltsN+9Q+GegiwrZyH0GsEjWE3JcRNQLg7P8W 5InY6Nqeg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59499 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7rNU-000nNr-Oq; Fri, 28 Feb 2020 20:57:21 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1B87947-52C4-4A87-AC9E-D5EC41A39512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 28 Feb 2020 17:57:15 -0800
Cc: Tom Herbert , Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF Discussion Mailing List 
Message-Id: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com>  <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com> 
To: Phillip Hallam-Baker 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 29 Feb 2020 01:57:23 -0000

--Apple-Mail=_E1B87947-52C4-4A87-AC9E-D5EC41A39512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 28, 2020, at 5:31 AM, Phillip Hallam-Baker =
 wrote:
>=20
> I have a library that implements RFC6763. So my application code =
doesn't actually consider IP addresses.

Something does. I=E2=80=99m not aware of a network that uses DNS FQDNs =
as endpoint addresses or that can open a socket without ultimately using =
an IP address.

Just because you don=E2=80=99t see it doesn=E2=80=99t mean it isn=E2=80=99=
t how your system actually works.

Joe


--Apple-Mail=_E1B87947-52C4-4A87-AC9E-D5EC41A39512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 28, 2020, at 5:31 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I have a library that implements =
RFC6763. So my application code doesn't actually consider IP =
addresses.

Something =
does. I=E2=80=99m not aware of a network that uses DNS FQDNs as endpoint =
addresses or that can open a socket without ultimately using an IP =
address.

Just because you don=E2=80=99=
t see it doesn=E2=80=99t mean it isn=E2=80=99t how your system actually =
works.

Joe

=

--Apple-Mail=_E1B87947-52C4-4A87-AC9E-D5EC41A39512--


From nobody Sat Feb 29 04:18:51 2020
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 6BD5F3A0947 for ; Sat, 29 Feb 2020 04:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 s6Pd-kTAeCY5 for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 19B123A0941 for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id v19so5619733oic.12 for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=l14DujBptl21qhs7MYFfkDMWavEMChKT/hSOhICMBNc=; b=rgpI1qfnX8AMmcWDzfl3ZgWmGEwVJDiAdvh6nul+PG5FpXsGn/y/2A/LXlFR65B6Qt zMYpXR818o+Z7pwwkcbx0jdt83lOOtn5J0auAi6p/m/YyToRk+4zLbdmR4BPby/Meuom BaZWRIv74V0H1aQnbpQoDDYA6+zg659x/TWh3yHy4155dRJTOy7BHKQERDOmnowVk+H5 +ie/3jHGB5ndggDl02rAO6MjStn4RfISSLPqr2OK30/zuNQwwzSjynuMjgXZLtKPnr3C Mcg1BzM7wlh95MIfwhQpjwGR0+Day+HMHGZxwu4k71GvrIOAxJVEzyAaj380s15ifc8o YOtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l14DujBptl21qhs7MYFfkDMWavEMChKT/hSOhICMBNc=; b=qJr/BLJJ3Stk98cUfbkk7+zOShILA4VafvxE5sGzEyQPTKDxusWQXfar4pSdTGhG8+ 80pKte3Gv9yqWbgVyPCtMfdq5EXRMnClYxCtFJhBv9gcDlkDqE69zSeoRrso0QZj1aQX lyNMjq7WDJWPokqQ5cLouPx1KDRCGNHy7CsUO0dLzUWtHeFgKD2t5Y3xFeSiQxljUQvl xWDDLzGkLaLDj9o6JIvRhVnt4ICdZZBD6Uon6VM2bKsxuvmdapEJZeOUNLW/3RvrNrL3 BIV74fXyDkKnGmOcW8zEJM4WxfeqBjmN/fA6Ad1jRSBfKq6U8YkWUwYP7jTMGU2uhdYR 6jqw==
X-Gm-Message-State: APjAAAWFn6ylEsRMnma2NyaC6hwJjNU7N0MVMTsRkCVmSa1hscsuBXlN luzRCyQgqFusiSDL3q10u+ixHvC4fuUP1/nPdbVqPg==
X-Google-Smtp-Source: APXvYqzbhW3dte1yEdy926Jvupu4XwNLJonAylgEFwJvV6a1iebnjuUKfqT+WhjfErz2J2ULtV10C8un82nCYaejVcg=
X-Received: by 2002:a54:4396:: with SMTP id u22mr6210807oiv.128.1582978727341;  Sat, 29 Feb 2020 04:18:47 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 04:18:46 -0800 (PST)
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 19:18:46 +0700
Message-ID: 
To: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="000000000000baf243059fb5f4a1"
Archived-At: 
Subject: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 12:18:49 -0000

--000000000000baf243059fb5f4a1
Content-Type: text/plain; charset="UTF-8"

Dear architecture-discuss,

It seems like a "puzzle": how could it be happened as this list has its
address architecture-discuss@ietf.org as I have been registered to.


https://www.ietf.org/mailman/listinfo/architecture-discuss

but, there is also another address architecture-discuss@iab.org shown by
the discussion under the thread "[arch-d] Is IPv6 End-to-End? R.I.P.
Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far 28-29
February 2020)  as I could both receive in my mailbox and participate in

https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
983OzMUPx1mX4BthpESUhCTMC0/


While by this page the address is still architecture-discuss@ietf.org

https://www.iab.org/mailman/listinfo/architecture-discuss

Regard,
Guntur Wiseno Putra

--000000000000baf243059fb5f4a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

It seems like a "puzzle&=
quot;: how could it be happened as this list has its address architecture-discuss@i=
etf.org as I have been registered to.



but, there is also another addre=
ss archit=
ecture-discuss@iab.org shown by the discussion under the thread "<=
span style=3D"color:rgb(34,34,34);font-family:HelveticaNeue-Light,'Helv=
etica Neue Light','Helvetica Neue',Helvetica,Arial,sans-serif;f=
ont-size:14px;line-height:22.1200008392334px;background-color:rgb(241,241,2=
41)">[arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 f=
or RFC8200)" =C2=A0(it is so far 28-29 February 2020) =C2=A0as =
I could both receive in my mailbox and participate in

<=
div>https://mailarchive.ietf.org=
/arch/msg/architecture-discuss/p983OzMUPx1mX4BthpESUhCTMC0/


While by this page the address i=
s still =
architecture-discuss@ietf.org


Regard,
Guntur Wiseno Putra


--000000000000baf243059fb5f4a1--


From nobody Sat Feb 29 04:18:55 2020
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 72B8A3A0949 for ; Sat, 29 Feb 2020 04:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uP888Dr5U6vF for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 277DA3A0943 for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id p125so5644066oif.10 for ; Sat, 29 Feb 2020 04:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=l14DujBptl21qhs7MYFfkDMWavEMChKT/hSOhICMBNc=; b=rgpI1qfnX8AMmcWDzfl3ZgWmGEwVJDiAdvh6nul+PG5FpXsGn/y/2A/LXlFR65B6Qt zMYpXR818o+Z7pwwkcbx0jdt83lOOtn5J0auAi6p/m/YyToRk+4zLbdmR4BPby/Meuom BaZWRIv74V0H1aQnbpQoDDYA6+zg659x/TWh3yHy4155dRJTOy7BHKQERDOmnowVk+H5 +ie/3jHGB5ndggDl02rAO6MjStn4RfISSLPqr2OK30/zuNQwwzSjynuMjgXZLtKPnr3C Mcg1BzM7wlh95MIfwhQpjwGR0+Day+HMHGZxwu4k71GvrIOAxJVEzyAaj380s15ifc8o YOtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l14DujBptl21qhs7MYFfkDMWavEMChKT/hSOhICMBNc=; b=XFW3SFxbGAd5dlkU80K0yNxYA6WSg9OB4dBbKRXAupUzXTHzp4WBlT7cFDTctzEdC1 CWFFiU4glhU60h/t7NEtXcQW2MwMhsa742g2KT6KyfVMMZUx8apLBtqOhLo/VCksiFf4 UCo9TGOde0eSg3LbeBYbNyrNpfFrCpM2zWMjPo/rLwn8djE1Tw1/6F4XCCoW0Q5urGZT eO9h7FB0zvoQ0GB3tJl4Fnz/xCk4POCV8g+HlxBgCll2pPnM1Ot4nYM17s2dC8doqrhi 7Id/S45YfBVEvbqdxYP/sqKJ13XGFNxXME7jowraeNelX8dwKR9uekS/ey0hkNxRtYGA JIIw==
X-Gm-Message-State: APjAAAUNwyFLWEy2OeyHxqCUZ1rdWaXaUXeslKbh7j43pZA9GyjxEPAe qB80t364jbwYSGi7N53PSTODmuMBUKgVbnlhVzqQ2Q==
X-Google-Smtp-Source: APXvYqzbhW3dte1yEdy926Jvupu4XwNLJonAylgEFwJvV6a1iebnjuUKfqT+WhjfErz2J2ULtV10C8un82nCYaejVcg=
X-Received: by 2002:a54:4396:: with SMTP id u22mr6210807oiv.128.1582978727341;  Sat, 29 Feb 2020 04:18:47 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 04:18:46 -0800 (PST)
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 19:18:46 +0700
Message-ID: 
To: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="000000000000baf243059fb5f4a1"
Archived-At: 
Subject: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 12:18:50 -0000

--000000000000baf243059fb5f4a1
Content-Type: text/plain; charset="UTF-8"

Dear architecture-discuss,

It seems like a "puzzle": how could it be happened as this list has its
address architecture-discuss@ietf.org as I have been registered to.


https://www.ietf.org/mailman/listinfo/architecture-discuss

but, there is also another address architecture-discuss@iab.org shown by
the discussion under the thread "[arch-d] Is IPv6 End-to-End? R.I.P.
Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far 28-29
February 2020)  as I could both receive in my mailbox and participate in

https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
983OzMUPx1mX4BthpESUhCTMC0/


While by this page the address is still architecture-discuss@ietf.org

https://www.iab.org/mailman/listinfo/architecture-discuss

Regard,
Guntur Wiseno Putra

--000000000000baf243059fb5f4a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,

It seems like a "puzzle&=
quot;: how could it be happened as this list has its address architecture-discuss@i=
etf.org as I have been registered to.



but, there is also another addre=
ss archit=
ecture-discuss@iab.org shown by the discussion under the thread "<=
span style=3D"color:rgb(34,34,34);font-family:HelveticaNeue-Light,'Helv=
etica Neue Light','Helvetica Neue',Helvetica,Arial,sans-serif;f=
ont-size:14px;line-height:22.1200008392334px;background-color:rgb(241,241,2=
41)">[arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 f=
or RFC8200)" =C2=A0(it is so far 28-29 February 2020) =C2=A0as =
I could both receive in my mailbox and participate in

<=
div>https://mailarchive.ietf.org=
/arch/msg/architecture-discuss/p983OzMUPx1mX4BthpESUhCTMC0/


While by this page the address i=
s still =
architecture-discuss@ietf.org


Regard,
Guntur Wiseno Putra


--000000000000baf243059fb5f4a1--


From nobody Sat Feb 29 05:34:41 2020
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 B2D643A0AA0 for ; Sat, 29 Feb 2020 05:34:38 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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=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 4sa3HlYqGTzn for ; Sat, 29 Feb 2020 05:34:36 -0800 (PST)
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 5EFDD3A0A9F for ; Sat, 29 Feb 2020 05:34:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60BEDBE20; Sat, 29 Feb 2020 13:34:33 +0000 (GMT)
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 xcWXoB4BFllQ; Sat, 29 Feb 2020 13:34:31 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42980BE3E; Sat, 29 Feb 2020 13:34:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582983240; bh=FDRqA06HAIErzuPFEHKo7F41TvqmWPUgh1iAlNw5YHs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0JFkFo8Y0clO/gzg+WdsTqDrYsgaIIvYAbvVPDvg8j9WYzO0dfqMw+STa6Ha4MHcp zx66d9ZCW5iXedB6fRD+YqoeuDM85YFHljJVMbWVN7nIdtI6NA2ZPaPxHzvnU+vWdE 9sDtNT6S4KF+VH4W1AnZfUQAlOSLVF/4cN15ikz4=
To: Guntur Wiseno Putra , "architecture-discuss@ietf.org" , "architecture-discuss@iab.org" 
References: 
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: 
Date: Sat, 29 Feb 2020 13:33:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 13:34:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu
Content-Type: multipart/mixed; boundary="qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1";
 protected-headers="v1"
From: Stephen Farrell 
To: Guntur Wiseno Putra ,
 "architecture-discuss@ietf.org" ,
 "architecture-discuss@iab.org" 
Message-ID: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
References: 
In-Reply-To: 

--qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1
Content-Type: multipart/mixed;
 boundary="------------D14910E0AEDD9ACB7D3B455B"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------D14910E0AEDD9ACB7D3B455B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> Dear architecture-discuss,
>=20
> It seems like a "puzzle": how could it be happened as this list has
> its address architecture-discuss@ietf.org as I have been registered
> to.
>=20

I don't see anything puzzling. I've not checked but I
guess at some point in time only one of architecture-
discuss@ietf.org and architecture-discuss@iab.org existed
and people were sending mail to the wrong one so someone
created an alias to solve the problem.

Cheers,
S.

>=20
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>=20
> but, there is also another address architecture-discuss@iab.org shown
> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> 28-29 February 2020)  as I could both receive in my mailbox and
> participate in
>=20
> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p=20
> 983OzMUPx1mX4BthpESUhCTMC0/
>=20
>=20
> While by this page the address is still
> architecture-discuss@ietf.org
>=20
> https://www.iab.org/mailman/listinfo/architecture-discuss
>=20
> Regard, Guntur Wiseno Putra
>=20
>=20
> _______________________________________________ Architecture-discuss
> mailing list Architecture-discuss@ietf.org=20
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>=20

--------------D14910E0AEDD9ACB7D3B455B
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
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------D14910E0AEDD9ACB7D3B455B--

--qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1--

--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5aaEcACgkQWrL68XsX
K+rA8RAAxYEHKno9FJsNYfw+k4zy5Dtice/qo/v1Cp5vNDmzW794yHiyQy1fIE6S
a+wugx9exSeFKluZX1fvNAbA/a9RnRjpbgO/ni2hTET0SLUEqSOVGEcLIc8LSE5v
pu3mu5xJ/GIa8y5+R7y6EXim+Uq3x+7+sDbspB3509XHntfFVsURBGCGEE3RGpEn
RHc4CYz4zlQkRUu8bqqSk/aV6QDbv/pgaZd+0MOxJmL9RUpOCH3kXj+qUpXyjpDa
/RJcyUjKHGX9uHtZlIDdtcnXFTtlieKQrMF3o3tCVAD+u09SJ0KgoLOFJwU1gMrC
4V7XNaAUX3PmAOsSjuuw6Doqzlg2+bNXmY4dnllxRTECASu7jsUEmQOARpD6KTR8
WQLqbeyb+ycT4xtX6bPSrGLHcGv2KEVEHJrZV9zKht3UtqrRsX2CmIu7sZTI/fNi
/hFx9tulyUnuzUeurNg2Ii/EawbriVsRjuPXpReZokPYA9fWEJvG+2pCK0uwPkUt
RqijedD9FWbB4RJXZ1pCCk/lkK80N0hIdWER9yvpwN5hWx85qJMqRvigRDDuDs1K
pAIDq9/jQWCpgy/UEr0cs5aJvEyu4YacupqCHo44UdFofyHDZOASEKgLzv7uINTV
Mb8U/hqX/SPoWsqsAE+iZnyoxEXkgmYppdUX6vq6pmTfWg+U6Ks=
=zTs+
-----END PGP SIGNATURE-----

--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu--


From nobody Sat Feb 29 05:35:05 2020
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 689EE3A0A9F for ; Sat, 29 Feb 2020 05:34:39 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PdlnfWHPpGEM for ; Sat, 29 Feb 2020 05:34:36 -0800 (PST)
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 4DED53A0A9E for ; Sat, 29 Feb 2020 05:34:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60BEDBE20; Sat, 29 Feb 2020 13:34:33 +0000 (GMT)
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 xcWXoB4BFllQ; Sat, 29 Feb 2020 13:34:31 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42980BE3E; Sat, 29 Feb 2020 13:34:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582983240; bh=FDRqA06HAIErzuPFEHKo7F41TvqmWPUgh1iAlNw5YHs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0JFkFo8Y0clO/gzg+WdsTqDrYsgaIIvYAbvVPDvg8j9WYzO0dfqMw+STa6Ha4MHcp zx66d9ZCW5iXedB6fRD+YqoeuDM85YFHljJVMbWVN7nIdtI6NA2ZPaPxHzvnU+vWdE 9sDtNT6S4KF+VH4W1AnZfUQAlOSLVF/4cN15ikz4=
To: Guntur Wiseno Putra , "architecture-discuss@ietf.org" , "architecture-discuss@iab.org" 
References: 
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: 
Date: Sat, 29 Feb 2020 13:33:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 13:34:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu
Content-Type: multipart/mixed; boundary="qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1";
 protected-headers="v1"
From: Stephen Farrell 
To: Guntur Wiseno Putra ,
 "architecture-discuss@ietf.org" ,
 "architecture-discuss@iab.org" 
Message-ID: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
References: 
In-Reply-To: 

--qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1
Content-Type: multipart/mixed;
 boundary="------------D14910E0AEDD9ACB7D3B455B"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------D14910E0AEDD9ACB7D3B455B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> Dear architecture-discuss,
>=20
> It seems like a "puzzle": how could it be happened as this list has
> its address architecture-discuss@ietf.org as I have been registered
> to.
>=20

I don't see anything puzzling. I've not checked but I
guess at some point in time only one of architecture-
discuss@ietf.org and architecture-discuss@iab.org existed
and people were sending mail to the wrong one so someone
created an alias to solve the problem.

Cheers,
S.

>=20
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>=20
> but, there is also another address architecture-discuss@iab.org shown
> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> 28-29 February 2020)  as I could both receive in my mailbox and
> participate in
>=20
> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p=20
> 983OzMUPx1mX4BthpESUhCTMC0/
>=20
>=20
> While by this page the address is still
> architecture-discuss@ietf.org
>=20
> https://www.iab.org/mailman/listinfo/architecture-discuss
>=20
> Regard, Guntur Wiseno Putra
>=20
>=20
> _______________________________________________ Architecture-discuss
> mailing list Architecture-discuss@ietf.org=20
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>=20

--------------D14910E0AEDD9ACB7D3B455B
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
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------D14910E0AEDD9ACB7D3B455B--

--qd1e3mF6ojs6RN6ccwVkjiJjPMBYXfZR1--

--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5aaEcACgkQWrL68XsX
K+rA8RAAxYEHKno9FJsNYfw+k4zy5Dtice/qo/v1Cp5vNDmzW794yHiyQy1fIE6S
a+wugx9exSeFKluZX1fvNAbA/a9RnRjpbgO/ni2hTET0SLUEqSOVGEcLIc8LSE5v
pu3mu5xJ/GIa8y5+R7y6EXim+Uq3x+7+sDbspB3509XHntfFVsURBGCGEE3RGpEn
RHc4CYz4zlQkRUu8bqqSk/aV6QDbv/pgaZd+0MOxJmL9RUpOCH3kXj+qUpXyjpDa
/RJcyUjKHGX9uHtZlIDdtcnXFTtlieKQrMF3o3tCVAD+u09SJ0KgoLOFJwU1gMrC
4V7XNaAUX3PmAOsSjuuw6Doqzlg2+bNXmY4dnllxRTECASu7jsUEmQOARpD6KTR8
WQLqbeyb+ycT4xtX6bPSrGLHcGv2KEVEHJrZV9zKht3UtqrRsX2CmIu7sZTI/fNi
/hFx9tulyUnuzUeurNg2Ii/EawbriVsRjuPXpReZokPYA9fWEJvG+2pCK0uwPkUt
RqijedD9FWbB4RJXZ1pCCk/lkK80N0hIdWER9yvpwN5hWx85qJMqRvigRDDuDs1K
pAIDq9/jQWCpgy/UEr0cs5aJvEyu4YacupqCHo44UdFofyHDZOASEKgLzv7uINTV
Mb8U/hqX/SPoWsqsAE+iZnyoxEXkgmYppdUX6vq6pmTfWg+U6Ks=
=zTs+
-----END PGP SIGNATURE-----

--k6KGYGVqpfm80M9RHgNu3HRUgE8mDfUMu--


From nobody Sat Feb 29 06:12:26 2020
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 B28583A0B3E for ; Sat, 29 Feb 2020 06:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rhLH7Ulj1prX for ; Sat, 29 Feb 2020 06:12:15 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 686FF3A0B42 for ; Sat, 29 Feb 2020 06:12:14 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id x19so563914otp.7 for ; Sat, 29 Feb 2020 06:12:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p0BJCRx7vOmTpYnQZrdd21KlykGeHgudbupWZ2vR7SY=; b=iGrgDiSEFEqYdUKBkaJdCjG2x0d86IA+wmkNM30zLyrQhtQOAvxnSlLSF/ruJ43KrX WtvMjQTbitQddJMr+Ju7Pk55UJqwh7AsI4ch6DoTQeOUIzqOUOUVMuls8VLEGpiUHeVG 7PgPVVvxFChDkorvh0VRC1L2Vp5hS6VD63CPDS83+qR6XSWIuV60K+c5wSxquDJHK1EN WoxLuaUjqeDsddA06H0+6J3q3944HvxE0Hw1f+wDjbxhhJjpZjss5RGWtJRxtsoiUyiu 81YoeAdp4k5difiyYJF8UNjkrwquafxm9wJq0ZEb11xciS693PK6cIeVpf0JhOgP71G1 ba9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p0BJCRx7vOmTpYnQZrdd21KlykGeHgudbupWZ2vR7SY=; b=o3yEPzmGhcNUV/qw3oCYax4kzOlzECHTeuE0ZZtOsfs8TBGWINh6MWCwpANLaA0hLZ OL5R0mlUXdi1X5pv8WmRiw/c3VGBEQa66D6Bvdy40TM5/8MamZ5FgqXV0ApVMOEQhtVl 7AL5pQ5QpdwWLTzoH2fh2n8yLIaAfn4BXO2fJilgz2hmd+VkPg2DS42QLKe5HUeYEeT+ IxajJjmbFcGCmvJbGcDKsPndsveJrxPZYRI6X8eiCo2kk0IosZd30K88k+39BH6UZ4nB MFnbMi1qIlzchyms+In6BXn6BVinKn5sO+NUD6ZiyZnCVgpN8ybXS8cNY7qzvrkkvL3q 4wBw==
X-Gm-Message-State: APjAAAXA7LqI+cpA4UkDj4IF7By9u7sYSRBo8cMvjaRC69UkTw23w+uA z73uAhCzZqNsTnSGXjeL7l/GUstVTmn49wMaCNk=
X-Google-Smtp-Source: APXvYqzYalW+5ZpNZQVZmKBxROGVq1JAHnPqQBnT5oRnWpSi2wMnDwaTzV9wgNcG3y4/8zRnnB4AOlWjuIxcnX47xS0=
X-Received: by 2002:a05:6830:1098:: with SMTP id y24mr7203695oto.197.1582985532335;  Sat, 29 Feb 2020 06:12:12 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 06:12:11 -0800 (PST)
In-Reply-To: 
References:  
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 21:12:11 +0700
Message-ID: 
To: Stephen Farrell 
Cc: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="00000000000056eb2b059fb78a1c"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:12:25 -0000

--00000000000056eb2b059fb78a1c
Content-Type: text/plain; charset="UTF-8"

Dear Stephen &
architecture-discuss,



So it is allright to corespond by and with either of the two addresses...?



Thank You & Regard,
Guntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell 
menulis:

>
> Hiya,
>
> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> > Dear architecture-discuss,
> >
> > It seems like a "puzzle": how could it be happened as this list has
> > its address architecture-discuss@ietf.org as I have been registered
> > to.
> >
>
> I don't see anything puzzling. I've not checked but I
> guess at some point in time only one of architecture-
> discuss@ietf.org and architecture-discuss@iab.org existed
> and people were sending mail to the wrong one so someone
> created an alias to solve the problem.
>
> Cheers,
> S.
>
> >
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
> > but, there is also another address architecture-discuss@iab.org shown
> > by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> > R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> > 28-29 February 2020)  as I could both receive in my mailbox and
> > participate in
> >
> > https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
> > 983OzMUPx1mX4BthpESUhCTMC0/
> >
> >
> > While by this page the address is still
> > architecture-discuss@ietf.org
> >
> > https://www.iab.org/mailman/listinfo/architecture-discuss
> >
> > Regard, Guntur Wiseno Putra
> >
> >
> > _______________________________________________ Architecture-discuss
> > mailing list Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
>

--00000000000056eb2b059fb78a1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Stephen &
architecture-discuss,


<=
/div>

So it is allright to corespond by and with either =
of the two addresses...?



=

Thank You & Regard,
Guntur Wiseno Putra

Pada Sabt=
u, 29 Februari 2020, Stephen Farrell <stephen.farrell@cs.tcd.ie> menulis:


Hiya,



On 29/02/2020 12:18, Guntur Wiseno Putra wrote:

> Dear architecture-discuss,

> 

> It seems like a "puzzle": how could it be happened as this l=
ist has

> its address architect=
ure-discuss@ietf.org as I have been registered

> to.

> 



I don't see anything puzzling. I've not checked but I

guess at some point in time only one of architecture-

discuss@ietf.org and architecture-discuss@iab.org existed<=
br>
and people were sending mail to the wrong one so someone

created an alias to solve the problem.



Cheers,

S.



> 

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss

> 

> but, there is also another address architecture-discuss@iab.org shown

> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?<=
br>
> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"=C2=A0 (it i=
s so far

> 28-29 February 2020)=C2=A0 as I could both receive in my mailbox and
> participate in

> 

> https://mailarchive.ietf.org/arch/msg/architectur=
e-discuss/p 

> 983OzMUPx1mX4BthpESUhCTMC0/

> 

> 

> While by this page the address is still

> architecture-discuss@=
ietf.org

> 

> https://www.iab.org/mailman/listinfo/architecture-di=
scuss

> 

> Regard, Guntur Wiseno Putra

> 

> 

> _______________________________________________ Architecture-disc=
uss

> mailing list Architec=
ture-discuss@ietf.org 

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss

> 




--00000000000056eb2b059fb78a1c--


From nobody Sat Feb 29 06:12:35 2020
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 AD0B93A0B3E for ; Sat, 29 Feb 2020 06:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ElW9G60nkSjC for ; Sat, 29 Feb 2020 06:12:14 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 955583A0B46 for ; Sat, 29 Feb 2020 06:12:14 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id g96so5330117otb.13 for ; Sat, 29 Feb 2020 06:12:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p0BJCRx7vOmTpYnQZrdd21KlykGeHgudbupWZ2vR7SY=; b=iGrgDiSEFEqYdUKBkaJdCjG2x0d86IA+wmkNM30zLyrQhtQOAvxnSlLSF/ruJ43KrX WtvMjQTbitQddJMr+Ju7Pk55UJqwh7AsI4ch6DoTQeOUIzqOUOUVMuls8VLEGpiUHeVG 7PgPVVvxFChDkorvh0VRC1L2Vp5hS6VD63CPDS83+qR6XSWIuV60K+c5wSxquDJHK1EN WoxLuaUjqeDsddA06H0+6J3q3944HvxE0Hw1f+wDjbxhhJjpZjss5RGWtJRxtsoiUyiu 81YoeAdp4k5difiyYJF8UNjkrwquafxm9wJq0ZEb11xciS693PK6cIeVpf0JhOgP71G1 ba9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p0BJCRx7vOmTpYnQZrdd21KlykGeHgudbupWZ2vR7SY=; b=m5mvTv0R65R1GrMt1DjTRCgOfXQatdhV2tKpQPZ23e6aSrpvnZR/nQ7jC1HCYvRcA/ /xZcAxEHdgVVTTTsCmw61Oggj+Nlz2v5rYMk7nxwV/alo7iQ8lAxKhtO1J0QwEhNZjHC tGTAXQyHsG1OVyO7InZSeHKqqeIO8ZlTAXsbL06TPy+sN5tJLbY8IGNyzwTnpZVaXfmn bHWMMOOmqy30Tohcnr78+qy9hVCUfnabvarsuUkjkbb/vNehVt1FnomeStKtjgrXzwCc TxDU4/56i9q7v4CHPZFD4WIELFUDQ0MQFfXShVDls81w7JCoXgmG8T7+nS41VSVUqHOu 9iBw==
X-Gm-Message-State: APjAAAXjROWk2nKTafscoeTXG5G4LL2Ut/Ns91MlMrcBFs3wgE3WvdSL ExmmMZUt2muKKYUNS93aqRFHGeCWipIG1QGIAT9SVw==
X-Google-Smtp-Source: APXvYqzYalW+5ZpNZQVZmKBxROGVq1JAHnPqQBnT5oRnWpSi2wMnDwaTzV9wgNcG3y4/8zRnnB4AOlWjuIxcnX47xS0=
X-Received: by 2002:a05:6830:1098:: with SMTP id y24mr7203695oto.197.1582985532335;  Sat, 29 Feb 2020 06:12:12 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 06:12:11 -0800 (PST)
In-Reply-To: 
References:  
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 21:12:11 +0700
Message-ID: 
To: Stephen Farrell 
Cc: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="00000000000056eb2b059fb78a1c"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:12:26 -0000

--00000000000056eb2b059fb78a1c
Content-Type: text/plain; charset="UTF-8"

Dear Stephen &
architecture-discuss,



So it is allright to corespond by and with either of the two addresses...?



Thank You & Regard,
Guntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell 
menulis:

>
> Hiya,
>
> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> > Dear architecture-discuss,
> >
> > It seems like a "puzzle": how could it be happened as this list has
> > its address architecture-discuss@ietf.org as I have been registered
> > to.
> >
>
> I don't see anything puzzling. I've not checked but I
> guess at some point in time only one of architecture-
> discuss@ietf.org and architecture-discuss@iab.org existed
> and people were sending mail to the wrong one so someone
> created an alias to solve the problem.
>
> Cheers,
> S.
>
> >
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
> > but, there is also another address architecture-discuss@iab.org shown
> > by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> > R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> > 28-29 February 2020)  as I could both receive in my mailbox and
> > participate in
> >
> > https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
> > 983OzMUPx1mX4BthpESUhCTMC0/
> >
> >
> > While by this page the address is still
> > architecture-discuss@ietf.org
> >
> > https://www.iab.org/mailman/listinfo/architecture-discuss
> >
> > Regard, Guntur Wiseno Putra
> >
> >
> > _______________________________________________ Architecture-discuss
> > mailing list Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
>

--00000000000056eb2b059fb78a1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Stephen &
architecture-discuss,


<=
/div>

So it is allright to corespond by and with either =
of the two addresses...?



=

Thank You & Regard,
Guntur Wiseno Putra

Pada Sabt=
u, 29 Februari 2020, Stephen Farrell <stephen.farrell@cs.tcd.ie> menulis:


Hiya,



On 29/02/2020 12:18, Guntur Wiseno Putra wrote:

> Dear architecture-discuss,

> 

> It seems like a "puzzle": how could it be happened as this l=
ist has

> its address architect=
ure-discuss@ietf.org as I have been registered

> to.

> 



I don't see anything puzzling. I've not checked but I

guess at some point in time only one of architecture-

discuss@ietf.org and architecture-discuss@iab.org existed<=
br>
and people were sending mail to the wrong one so someone

created an alias to solve the problem.



Cheers,

S.



> 

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss

> 

> but, there is also another address architecture-discuss@iab.org shown

> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?<=
br>
> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"=C2=A0 (it i=
s so far

> 28-29 February 2020)=C2=A0 as I could both receive in my mailbox and
> participate in

> 

> https://mailarchive.ietf.org/arch/msg/architectur=
e-discuss/p 

> 983OzMUPx1mX4BthpESUhCTMC0/

> 

> 

> While by this page the address is still

> architecture-discuss@=
ietf.org

> 

> https://www.iab.org/mailman/listinfo/architecture-di=
scuss

> 

> Regard, Guntur Wiseno Putra

> 

> 

> _______________________________________________ Architecture-disc=
uss

> mailing list Architec=
ture-discuss@ietf.org 

> https://www.ietf.org/mailman/listinfo/architecture-=
discuss

> 




--00000000000056eb2b059fb78a1c--


From nobody Sat Feb 29 06:16:15 2020
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 87FF43A0B54 for ; Sat, 29 Feb 2020 06:16:12 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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=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 OEjj8DI3InQZ for ; Sat, 29 Feb 2020 06:16:09 -0800 (PST)
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 608733A0B4A for ; Sat, 29 Feb 2020 06:16:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7E9CBE24; Sat, 29 Feb 2020 14:16:06 +0000 (GMT)
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 ZHdsCyUPSVDF; Sat, 29 Feb 2020 14:16:04 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2EE7BDCF; Sat, 29 Feb 2020 14:16:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582985764; bh=QI/wUAKOqbU/HkwwBMLVv2l0uovqK0LoCyEesgN9qLI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gW43TgXCUV0FU1AXetSFObWz1hoshAqz2WCKkqi6uTv4KBVplrS2UBJDmx/Gczg3+ gVTg4YfHBqUxMcKlYykbJoB4KkQ5lt87k7a6Pi80iza8FSY8UUGNq3Abhpi1DhXgNE B3bRxDO4mW9uN1OuFIUEi1EwWJYcNhMzD8i84RB8=
To: Guntur Wiseno Putra 
Cc: "architecture-discuss@ietf.org" , "architecture-discuss@iab.org" 
References:   
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
Date: Sat, 29 Feb 2020 14:16:04 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:16:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm
Content-Type: multipart/mixed; boundary="nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn";
 protected-headers="v1"
From: Stephen Farrell 
To: Guntur Wiseno Putra 
Cc: "architecture-discuss@ietf.org" ,
 "architecture-discuss@iab.org" 
Message-ID: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
Subject: Re: @ietf & @ iab: architecture-discuss
References: 
 
 
In-Reply-To: 

--nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn
Content-Type: multipart/mixed;
 boundary="------------9764BB703FA939986F927AAB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------9764BB703FA939986F927AAB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 29/02/2020 14:12, Guntur Wiseno Putra wrote:
> Dear Stephen &
> architecture-discuss,
>=20
> So it is allright to corespond by and with either of the two addresses.=
=2E.?
>=20

I believe so. If something doesn't work, feel free to
ping me off list.

S.

>=20
>=20
> Thank You & Regard,
> Guntur Wiseno Putra
>=20
> Pada Sabtu, 29 Februari 2020, Stephen Farrell 
> menulis:
>=20
>>
>> Hiya,
>>
>> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
>>> Dear architecture-discuss,
>>>
>>> It seems like a "puzzle": how could it be happened as this list has
>>> its address architecture-discuss@ietf.org as I have been registered
>>> to.
>>>
>>
>> I don't see anything puzzling. I've not checked but I
>> guess at some point in time only one of architecture-
>> discuss@ietf.org and architecture-discuss@iab.org existed
>> and people were sending mail to the wrong one so someone
>> created an alias to solve the problem.
>>
>> Cheers,
>> S.
>>
>>>
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>> but, there is also another address architecture-discuss@iab.org shown=

>>> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
>>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
>>> 28-29 February 2020)  as I could both receive in my mailbox and
>>> participate in
>>>
>>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
>>> 983OzMUPx1mX4BthpESUhCTMC0/
>>>
>>>
>>> While by this page the address is still
>>> architecture-discuss@ietf.org
>>>
>>> https://www.iab.org/mailman/listinfo/architecture-discuss
>>>
>>> Regard, Guntur Wiseno Putra
>>>
>>>
>>> _______________________________________________ Architecture-discuss
>>> mailing list Architecture-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>
>=20

--------------9764BB703FA939986F927AAB
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
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------9764BB703FA939986F927AAB--

--nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn--

--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5aciQACgkQWrL68XsX
K+q3ShAAtiichsTA9saDY7r058+oHd0OIRYq72uE632c+qTljD7UCEQME1ncq66u
DW3fteyT80cWmHeKOm6ryyiL2u3jcoqJ0P9565BuBbRztyf0zOys4ZKmhc/T7ihM
Yis8B0u7GvSHujyN+x/NeoyIU0g6N1CuJf63H7CwfHeya5W3tmnuMkBLs53eUHyC
ekYzJmjyWFCa6I/A6lCFRu2BfK9D7YKVEfbmLTzL8RbN9WpLDCy7QjHZ1mt16Ld2
m5lakCTbkyVdpIse98gitgZFFztMHC7V7Oz4WH2rpy5143W8iUz/J80xsIh9xHPo
/EpbQrhSOWusqva25/Wj02nBCypVKd2WStFC1De5+jzyYKyZSmtldW2GYVNSWxdN
bFimBDIQtCSGiEfRYwdtUulw4i/Q64X7AYkx3jKAwV0xPGvsxKETPpELnFEo/6ma
3UlL/uzdyqD7fb7MuTBZMMnxk7wQcKh04js2vk4anrlEvN9u/J0EUf/t7qD75/a8
ZW2rKdqnxWwfaBccPduk67WLpx9pJWsTnnopoV9HJfb8cfBIaZ1+UrOdN8l0cgym
PjwA4zOAXvzP8To23p6hjjG5QF3O8m1G6YAK2Nvw+U5WeLjDEw2nyA8gy0oy1cVN
v6rMhlQvx69CiHuXltxMR9ScAm0oFKM5/N7DGy15Ip/2J12OgXk=
=Zxup
-----END PGP SIGNATURE-----

--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm--


From nobody Sat Feb 29 06:16:27 2020
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 012593A0BA7 for ; Sat, 29 Feb 2020 06:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 luQDtQUOsE4o for ; Sat, 29 Feb 2020 06:16:10 -0800 (PST)
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 1D50D3A0B53 for ; Sat, 29 Feb 2020 06:16:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7E9CBE24; Sat, 29 Feb 2020 14:16:06 +0000 (GMT)
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 ZHdsCyUPSVDF; Sat, 29 Feb 2020 14:16:04 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2EE7BDCF; Sat, 29 Feb 2020 14:16:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582985764; bh=QI/wUAKOqbU/HkwwBMLVv2l0uovqK0LoCyEesgN9qLI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gW43TgXCUV0FU1AXetSFObWz1hoshAqz2WCKkqi6uTv4KBVplrS2UBJDmx/Gczg3+ gVTg4YfHBqUxMcKlYykbJoB4KkQ5lt87k7a6Pi80iza8FSY8UUGNq3Abhpi1DhXgNE B3bRxDO4mW9uN1OuFIUEi1EwWJYcNhMzD8i84RB8=
To: Guntur Wiseno Putra 
Cc: "architecture-discuss@ietf.org" , "architecture-discuss@iab.org" 
References:   
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
Date: Sat, 29 Feb 2020 14:16:04 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:16:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm
Content-Type: multipart/mixed; boundary="nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn";
 protected-headers="v1"
From: Stephen Farrell 
To: Guntur Wiseno Putra 
Cc: "architecture-discuss@ietf.org" ,
 "architecture-discuss@iab.org" 
Message-ID: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
Subject: Re: @ietf & @ iab: architecture-discuss
References: 
 
 
In-Reply-To: 

--nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn
Content-Type: multipart/mixed;
 boundary="------------9764BB703FA939986F927AAB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------9764BB703FA939986F927AAB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 29/02/2020 14:12, Guntur Wiseno Putra wrote:
> Dear Stephen &
> architecture-discuss,
>=20
> So it is allright to corespond by and with either of the two addresses.=
=2E.?
>=20

I believe so. If something doesn't work, feel free to
ping me off list.

S.

>=20
>=20
> Thank You & Regard,
> Guntur Wiseno Putra
>=20
> Pada Sabtu, 29 Februari 2020, Stephen Farrell 
> menulis:
>=20
>>
>> Hiya,
>>
>> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
>>> Dear architecture-discuss,
>>>
>>> It seems like a "puzzle": how could it be happened as this list has
>>> its address architecture-discuss@ietf.org as I have been registered
>>> to.
>>>
>>
>> I don't see anything puzzling. I've not checked but I
>> guess at some point in time only one of architecture-
>> discuss@ietf.org and architecture-discuss@iab.org existed
>> and people were sending mail to the wrong one so someone
>> created an alias to solve the problem.
>>
>> Cheers,
>> S.
>>
>>>
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>> but, there is also another address architecture-discuss@iab.org shown=

>>> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
>>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
>>> 28-29 February 2020)  as I could both receive in my mailbox and
>>> participate in
>>>
>>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
>>> 983OzMUPx1mX4BthpESUhCTMC0/
>>>
>>>
>>> While by this page the address is still
>>> architecture-discuss@ietf.org
>>>
>>> https://www.iab.org/mailman/listinfo/architecture-discuss
>>>
>>> Regard, Guntur Wiseno Putra
>>>
>>>
>>> _______________________________________________ Architecture-discuss
>>> mailing list Architecture-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>
>=20

--------------9764BB703FA939986F927AAB
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
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------9764BB703FA939986F927AAB--

--nyPE0L3gWA3zqrsRmgVPeymNrxeqJQxOn--

--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5aciQACgkQWrL68XsX
K+q3ShAAtiichsTA9saDY7r058+oHd0OIRYq72uE632c+qTljD7UCEQME1ncq66u
DW3fteyT80cWmHeKOm6ryyiL2u3jcoqJ0P9565BuBbRztyf0zOys4ZKmhc/T7ihM
Yis8B0u7GvSHujyN+x/NeoyIU0g6N1CuJf63H7CwfHeya5W3tmnuMkBLs53eUHyC
ekYzJmjyWFCa6I/A6lCFRu2BfK9D7YKVEfbmLTzL8RbN9WpLDCy7QjHZ1mt16Ld2
m5lakCTbkyVdpIse98gitgZFFztMHC7V7Oz4WH2rpy5143W8iUz/J80xsIh9xHPo
/EpbQrhSOWusqva25/Wj02nBCypVKd2WStFC1De5+jzyYKyZSmtldW2GYVNSWxdN
bFimBDIQtCSGiEfRYwdtUulw4i/Q64X7AYkx3jKAwV0xPGvsxKETPpELnFEo/6ma
3UlL/uzdyqD7fb7MuTBZMMnxk7wQcKh04js2vk4anrlEvN9u/J0EUf/t7qD75/a8
ZW2rKdqnxWwfaBccPduk67WLpx9pJWsTnnopoV9HJfb8cfBIaZ1+UrOdN8l0cgym
PjwA4zOAXvzP8To23p6hjjG5QF3O8m1G6YAK2Nvw+U5WeLjDEw2nyA8gy0oy1cVN
v6rMhlQvx69CiHuXltxMR9ScAm0oFKM5/N7DGy15Ip/2J12OgXk=
=Zxup
-----END PGP SIGNATURE-----

--feyHGWe1xutiM6sZiHG9GsgKwG0VbdqOm--


From nobody Sat Feb 29 06:33:14 2020
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 251533A0BBD for ; Sat, 29 Feb 2020 06:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dGNRr2mj46k1 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 3E17D3A0BB0 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id q81so5921713oig.0 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dzXF2QDDUMi1Ne+ZFiztCkYivx22MVsst+qpB/gfXXk=; b=Y2dLsi9/2PGkcLcypdBNyncxDzImAD8ya20DIcrj0govPLSg/EL0qOUpZu4nKZWgTe 1t7h4N0lyv1Yd0raqucIkSK98sMxwwVPOnmItL2CA++S2wRVJC/ueGhEThe9UFi9jJlY I+vyElJo6X0GZofTVs6LruVWQn5J+5X73NIVjAIFRS7gf7vsyYKMkO8y1gzmsgP2b2y+ UwvrnfXfRskjG5IX3MRgBepbntiVVU6Nwg/IiZIt7BrZwAcRs5SSq7eGbrlGKOOE0Bhu /tOXO7Zwp446tX60Gu1TSu2BJIJeFw1AOo/D1eiOmjG/yXNXGIvi5q74lpo3UxQebNH/ E0vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dzXF2QDDUMi1Ne+ZFiztCkYivx22MVsst+qpB/gfXXk=; b=nCHeWeKph+bdKQ45gMNvEjh1FJm5n6XP5Bh2qu61pRgZ/erYlj9fKogY2DapkRYaBD KTKqXAyqNZgkJq+VSyDJU/7lIhOh+Hjlxe1Ro6xJWynx5eWHskPQjozxMjDmdmZJ1GtY r3ucQivoeTaMlfE/ZfvqLZhVPLBVBwIxOpfp4jhTz32cBzlHrkCiKlPr7lC+wo9iSQt2 YZJG7wG1bbjSJcKZpzhKAawQ6obUfm5ghS/f/e4+SdM6fACVqoLKud2vDWoFPAf/8SMJ 06ZijblfUdJU9/MkbNKiahm5kmnGOINvP1Fdv1IXCe6RIh3FVg3jvb4a7zhFAK9lgIwG ifaQ==
X-Gm-Message-State: APjAAAUtiCL7BKeT2e6XosD6C3Pq4jLWAGMYh7NHJcvLzzvRTk8hBtME JpBZAFtIVSInGb24Nc2pp5F0n92qf1JNtGzjpRijrQ==
X-Google-Smtp-Source: APXvYqxg2LDJ5tgi1+wwHfmjmfFKRy0yMr8Novu2/2AP6np0f2C6uk/ic9yCzn1vfB22rEzOcNKArgYFhvgL5vtWt5w=
X-Received: by 2002:aca:504e:: with SMTP id e75mr6188099oib.143.1582986788582;  Sat, 29 Feb 2020 06:33:08 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 06:33:08 -0800 (PST)
In-Reply-To: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
References:    <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 21:33:08 +0700
Message-ID: 
To: Stephen Farrell 
Cc: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="00000000000037b89b059fb7d51c"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:33:11 -0000

--00000000000037b89b059fb7d51c
Content-Type: text/plain; charset="UTF-8"

Dear Stephen &
architecture-discuss,

Thank you, Stephen.


Regard,
Guntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell 
menulis:

>
>
> On 29/02/2020 14:12, Guntur Wiseno Putra wrote:
> > Dear Stephen &
> > architecture-discuss,
> >
> > So it is allright to corespond by and with either of the two
> addresses...?
> >
>
> I believe so. If something doesn't work, feel free to
> ping me off list.
>
> S.
>
> >
> >
> > Thank You & Regard,
> > Guntur Wiseno Putra
> >
> > Pada Sabtu, 29 Februari 2020, Stephen Farrell  >
> > menulis:
> >
> >>
> >> Hiya,
> >>
> >> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> >>> Dear architecture-discuss,
> >>>
> >>> It seems like a "puzzle": how could it be happened as this list has
> >>> its address architecture-discuss@ietf.org as I have been registered
> >>> to.
> >>>
> >>
> >> I don't see anything puzzling. I've not checked but I
> >> guess at some point in time only one of architecture-
> >> discuss@ietf.org and architecture-discuss@iab.org existed
> >> and people were sending mail to the wrong one so someone
> >> created an alias to solve the problem.
> >>
> >> Cheers,
> >> S.
> >>
> >>>
> >>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> >>>
> >>> but, there is also another address architecture-discuss@iab.org shown
> >>> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> >>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> >>> 28-29 February 2020)  as I could both receive in my mailbox and
> >>> participate in
> >>>
> >>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
> >>> 983OzMUPx1mX4BthpESUhCTMC0/
> >>>
> >>>
> >>> While by this page the address is still
> >>> architecture-discuss@ietf.org
> >>>
> >>> https://www.iab.org/mailman/listinfo/architecture-discuss
> >>>
> >>> Regard, Guntur Wiseno Putra
> >>>
> >>>
> >>> _______________________________________________ Architecture-discuss
> >>> mailing list Architecture-discuss@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> >>>
> >>
> >
>

--00000000000037b89b059fb7d51c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Stephen &
architecture-discuss,

Thank=
 you, Stephen.


Regard,
Gu=
ntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell=
 <stephen.farrell@cs.tcd.ie=
> menulis:




On 29/02/2020 14:12, Guntur Wiseno Putra wrote:

> Dear Stephen &

> architecture-discuss,

> 

> So it is allright to corespond by and with either of the two addresses=
...?

> 



I believe so. If something doesn't work, feel free to

ping me off list.



S.



> 

> 

> Thank You & Regard,

> Guntur Wiseno Putra

> 

> Pada Sabtu, 29 Februari 2020, Stephen Farrell <stephen.farrell@cs.tcd.ie>

> menulis:

> 

>>

>> Hiya,

>>

>> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:

>>> Dear architecture-discuss,

>>>

>>> It seems like a "puzzle": how could it be happened a=
s this list has

>>> its address a=
rchitecture-discuss@ietf.org as I have been registered

>>> to.

>>>

>>

>> I don't see anything puzzling. I've not checked but I

>> guess at some point in time only one of architecture-

>> discuss@ietf.org and architecture-discuss@iab.org=
 existed

>> and people were sending mail to the wrong one so someone

>> created an alias to solve the problem.

>>

>> Cheers,

>> S.

>>

>>>

>>> https://www.ietf.org/mailman/listinfo/archi=
tecture-discuss

>>>

>>> but, there is also another address architecture-discuss@iab.org shown

>>> by the discussion under the thread "[arch-d] Is IPv6 End-=
to-End?

>>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"=C2=
=A0 (it is so far

>>> 28-29 February 2020)=C2=A0 as I could both receive in my mailb=
ox and

>>> participate in

>>>

>>> https://mailarchive.ietf.org/arch/msg/arc=
hitecture-discuss/p

>>> 983OzMUPx1mX4BthpESUhCTMC0/

>>>

>>>

>>> While by this page the address is still

>>> architecture-=
discuss@ietf.org

>>>

>>> https://www.iab.org/mailman/listinfo/archite=
cture-discuss

>>>

>>> Regard, Guntur Wiseno Putra

>>>

>>>

>>> _______________________________________________ Architect=
ure-discuss

>>> mailing list =
Architecture-discuss@ietf.org

>>> https://www.ietf.org/mailman/listinfo/archi=
tecture-discuss

>>>

>>

> 




--00000000000037b89b059fb7d51c--


From nobody Sat Feb 29 06:33:19 2020
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 CDD663A0BBD for ; Sat, 29 Feb 2020 06:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 poItS4LxoEn1 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0: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 6076F3A0BB2 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
Received: by mail-oi1-x22a.google.com with SMTP id r16so5866300oie.6 for ; Sat, 29 Feb 2020 06:33:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dzXF2QDDUMi1Ne+ZFiztCkYivx22MVsst+qpB/gfXXk=; b=Y2dLsi9/2PGkcLcypdBNyncxDzImAD8ya20DIcrj0govPLSg/EL0qOUpZu4nKZWgTe 1t7h4N0lyv1Yd0raqucIkSK98sMxwwVPOnmItL2CA++S2wRVJC/ueGhEThe9UFi9jJlY I+vyElJo6X0GZofTVs6LruVWQn5J+5X73NIVjAIFRS7gf7vsyYKMkO8y1gzmsgP2b2y+ UwvrnfXfRskjG5IX3MRgBepbntiVVU6Nwg/IiZIt7BrZwAcRs5SSq7eGbrlGKOOE0Bhu /tOXO7Zwp446tX60Gu1TSu2BJIJeFw1AOo/D1eiOmjG/yXNXGIvi5q74lpo3UxQebNH/ E0vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dzXF2QDDUMi1Ne+ZFiztCkYivx22MVsst+qpB/gfXXk=; b=sXf5Vh8PQO7pgZchHaIDX3pNR8ZXNzlBfFKirZUE34B5/W6SEfj0qv0Jdt+bECNILY 2r3sKzo5bdfhnGHPb5o0aSyEBPkPbaSJMNjSuS6X406X9dpZXYT478ud/O1ir1ZsegxK kTIZ/MYZta3n5S5LKZaDuZ3PM2oZqsiKkmGlKgQsgfLxtL7R0efho//IC4PZqtPn5Ow4 60Q5ee1ltNHYo+xtwvjBC9BKw5E21lGplITmaFkjaC6NVfLVzQS7O7oxP/tAY33hU3DS JA1UV6J2geDKWhTfvA3UKZvqbpX77xlXyXLCpSGYiBrd99zvFN1o+edKWl8eIgXa/0Qa 7V2g==
X-Gm-Message-State: APjAAAWqAwPo/pJ+rN0DE8J9T6GyigOJ63n6gQROpI4Kmp2upmQbeECl n1Wfrq/IrTr0yKj7S0NTFaMgIxtDjuScdUQEgAM=
X-Google-Smtp-Source: APXvYqxg2LDJ5tgi1+wwHfmjmfFKRy0yMr8Novu2/2AP6np0f2C6uk/ic9yCzn1vfB22rEzOcNKArgYFhvgL5vtWt5w=
X-Received: by 2002:aca:504e:: with SMTP id e75mr6188099oib.143.1582986788582;  Sat, 29 Feb 2020 06:33:08 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 06:33:08 -0800 (PST)
In-Reply-To: <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
References:    <0e3add61-b14b-00a5-337a-2d3ac5e693b1@cs.tcd.ie>
From: Guntur Wiseno Putra 
Date: Sat, 29 Feb 2020 21:33:08 +0700
Message-ID: 
To: Stephen Farrell 
Cc: "architecture-discuss@ietf.org" ,  "architecture-discuss@iab.org" 
Content-Type: multipart/alternative; boundary="00000000000037b89b059fb7d51c"
Archived-At: 
Subject: Re: [arch-d] @ietf & @ iab: architecture-discuss
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, 29 Feb 2020 14:33:14 -0000

--00000000000037b89b059fb7d51c
Content-Type: text/plain; charset="UTF-8"

Dear Stephen &
architecture-discuss,

Thank you, Stephen.


Regard,
Guntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell 
menulis:

>
>
> On 29/02/2020 14:12, Guntur Wiseno Putra wrote:
> > Dear Stephen &
> > architecture-discuss,
> >
> > So it is allright to corespond by and with either of the two
> addresses...?
> >
>
> I believe so. If something doesn't work, feel free to
> ping me off list.
>
> S.
>
> >
> >
> > Thank You & Regard,
> > Guntur Wiseno Putra
> >
> > Pada Sabtu, 29 Februari 2020, Stephen Farrell  >
> > menulis:
> >
> >>
> >> Hiya,
> >>
> >> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:
> >>> Dear architecture-discuss,
> >>>
> >>> It seems like a "puzzle": how could it be happened as this list has
> >>> its address architecture-discuss@ietf.org as I have been registered
> >>> to.
> >>>
> >>
> >> I don't see anything puzzling. I've not checked but I
> >> guess at some point in time only one of architecture-
> >> discuss@ietf.org and architecture-discuss@iab.org existed
> >> and people were sending mail to the wrong one so someone
> >> created an alias to solve the problem.
> >>
> >> Cheers,
> >> S.
> >>
> >>>
> >>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> >>>
> >>> but, there is also another address architecture-discuss@iab.org shown
> >>> by the discussion under the thread "[arch-d] Is IPv6 End-to-End?
> >>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"  (it is so far
> >>> 28-29 February 2020)  as I could both receive in my mailbox and
> >>> participate in
> >>>
> >>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/p
> >>> 983OzMUPx1mX4BthpESUhCTMC0/
> >>>
> >>>
> >>> While by this page the address is still
> >>> architecture-discuss@ietf.org
> >>>
> >>> https://www.iab.org/mailman/listinfo/architecture-discuss
> >>>
> >>> Regard, Guntur Wiseno Putra
> >>>
> >>>
> >>> _______________________________________________ Architecture-discuss
> >>> mailing list Architecture-discuss@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> >>>
> >>
> >
>

--00000000000037b89b059fb7d51c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Stephen &
architecture-discuss,

Thank=
 you, Stephen.


Regard,
Gu=
ntur Wiseno Putra

Pada Sabtu, 29 Februari 2020, Stephen Farrell=
 <stephen.farrell@cs.tcd.ie=
> menulis:




On 29/02/2020 14:12, Guntur Wiseno Putra wrote:

> Dear Stephen &

> architecture-discuss,

> 

> So it is allright to corespond by and with either of the two addresses=
...?

> 



I believe so. If something doesn't work, feel free to

ping me off list.



S.



> 

> 

> Thank You & Regard,

> Guntur Wiseno Putra

> 

> Pada Sabtu, 29 Februari 2020, Stephen Farrell <stephen.farrell@cs.tcd.ie>

> menulis:

> 

>>

>> Hiya,

>>

>> On 29/02/2020 12:18, Guntur Wiseno Putra wrote:

>>> Dear architecture-discuss,

>>>

>>> It seems like a "puzzle": how could it be happened a=
s this list has

>>> its address a=
rchitecture-discuss@ietf.org as I have been registered

>>> to.

>>>

>>

>> I don't see anything puzzling. I've not checked but I

>> guess at some point in time only one of architecture-

>> discuss@ietf.org and architecture-discuss@iab.org=
 existed

>> and people were sending mail to the wrong one so someone

>> created an alias to solve the problem.

>>

>> Cheers,

>> S.

>>

>>>

>>> https://www.ietf.org/mailman/listinfo/archi=
tecture-discuss

>>>

>>> but, there is also another address architecture-discuss@iab.org shown

>>> by the discussion under the thread "[arch-d] Is IPv6 End-=
to-End?

>>> R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)"=C2=
=A0 (it is so far

>>> 28-29 February 2020)=C2=A0 as I could both receive in my mailb=
ox and

>>> participate in

>>>

>>> https://mailarchive.ietf.org/arch/msg/arc=
hitecture-discuss/p

>>> 983OzMUPx1mX4BthpESUhCTMC0/

>>>

>>>

>>> While by this page the address is still

>>> architecture-=
discuss@ietf.org

>>>

>>> https://www.iab.org/mailman/listinfo/archite=
cture-discuss

>>>

>>> Regard, Guntur Wiseno Putra

>>>

>>>

>>> _______________________________________________ Architect=
ure-discuss

>>> mailing list =
Architecture-discuss@ietf.org

>>> https://www.ietf.org/mailman/listinfo/archi=
tecture-discuss

>>>

>>

> 




--00000000000037b89b059fb7d51c--


From nobody Sat Feb 29 17:30:22 2020
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 922E93A1746 for ; Sat, 29 Feb 2020 17:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] 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 ajryvyGRSeK9 for ; Sat, 29 Feb 2020 17:30:12 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606493A081B for ; Sat, 29 Feb 2020 17:30:11 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2105.outbound.protection.outlook.com [104.47.18.105]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-7-c9TGl985P02DrdlmeiiYjQ-1; Sun, 01 Mar 2020 01:30:04 +0000
X-MC-Unique: c9TGl985P02DrdlmeiiYjQ-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5191.eurprd03.prod.outlook.com (20.179.46.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Sun, 1 Mar 2020 01:30:02 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.018; Sun, 1 Mar 2020 01:30:02 +0000
From: Andrew Alston 
To: Guntur Wiseno Putra , Robert Raszuk 
CC: Internet Area , IETF , Tom Herbert , "architecture-discuss@iab.org" , Internet Architecture Board 
Thread-Topic: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Thread-Index: AQHV7hX2fo5LhdujpkaAQVIa4VmXnKgzJ/cA
Date: Sun, 1 Mar 2020 01:30:01 +0000
Message-ID: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [2c0f:fe40:3:3:808d:eb0:4250:7e10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 695e9b6d-801d-473e-2b40-08d7bd801040
x-ms-traffictypediagnostic: DBBPR03MB5191:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0329B15C8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(346002)(376002)(136003)(39850400004)(366004)(199004)(189003)(66556008)(66476007)(5660300002)(36756003)(64756008)(66446008)(6512007)(71200400001)(186003)(66946007)(2906002)(478600001)(4326008)(8936002)(2616005)(316002)(54906003)(6486002)(110136005)(81166006)(81156014)(33656002)(76116006)(86362001)(91956017)(8676002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5191; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6vKQOBsoHyeyi1KTIO4/Cg2r/wIwDOxV5LNATG6Z0zsR8lSdMxaj9/Ukw2qMMf4g8aFYPdT0xzCXl/QqTu/oVwVZgci07x6Y74LhltEwKAyv/F5w7cARr9QiULlYqexohXdK+a2O4TtDSQtji1wqTHciXVMtkxPbinzyQdwSWW8bMbu47RIcAIq/+XQMnIPhCfg0NnVhJ6UC204UgkWFDlz3fMSzKH8Ty2QpSVVAkSMVADkzADmDtQuytTpn7ctLwnJDa49Qa1lYur4K/kl0MhXWtklwJoSLKumEiiS5eUwFZ6Eedc5EQ3j8f4SlLMOLa4WcJYcJCkFnsD14PurZci7gOk9NKiixZIXP3nXDSu3Xm/cIw1d02QQL5syraVNnuqQwsDcpihiwrGDXvICbAcD1hg3SVQQSqbkHVakSy09LDyZChsEAbQ3zAWZ5F4Ta
x-ms-exchange-antispam-messagedata: aGXRvHyjEI0Cu5RwlW8cmuU521WuEqxK8FCeTH4IrOMyd8hifH745625P2/DxECeGkP1DjMcKvuX2Stu4JaoWIJ5F/3QPe7kghARjIILc3/wDn6ldFTL3nBAXxrvNp3iFLtyV8YG12nUTCyYcDGznxDp+2nuyKLqbtENYBUjwgyG5goFCrIyngHRwGB8w1yF3OOzluhFt788TVri7A5cdA==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 695e9b6d-801d-473e-2b40-08d7bd801040
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2020 01:30:01.9640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WSnzgYECaFn3A20KzJ9BDdfwDA0Hh966fzye4SSmJKOCpOPJdBZgHdiA94Kuh56d00aLzi0N8yz8EGGj9VfHmwsEXizzqk0aZZ+bElvcOu0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5191
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_A150592278664D03AEF8E90E0090A9B7liquidtelecomcom_"
Archived-At: 
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 01:30:20 -0000

--_000_A150592278664D03AEF8E90E0090A9B7liquidtelecomcom_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

R3VudHVyLA0KDQpJIGhhdmUgdG8gc2F5IOKAkyBJIHNhdCBhbmQgdGhvdWdodCBhYm91dCB3aGF0
IHlvdSB3cm90ZSBoZXJlIOKAkyBhbmQgdGhlcmUgd2FzIG9uZSBsaW5lIHRoYSByZWFsbHkgc3Ry
dWNrIGluIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgd2hvbGUgZGViYXRlDQoNCjxzbmlwPg0KPiBB
bnkgY2hhbmdlIHJlcXVpcmVzIGEgcmVhc29uIHRvIG92ZXJjb21lIHRoZSBhc3NvY2lhdGVkIGh1
cmRsZS4gQ29uc2VxdWVudGx5LCBJIGhhdmUgZm91bmQgaXQgdmVyeSBpbnN0cnVjdGl2ZSB0byB0
cnkgdG8gdGhpbmsgYWJvdXQgdGhlIG5ldHdvcmsgYW5kIHByb3RvY29scyBpbiB0ZXJtcyBvZiBh
c3NldHMsIGluY2VudGl2ZXMsIGNvc3RzLCBhbmQgYmVuZWZpdHMiLg0KDQpPbiB0aGlzIOKAkyB3
ZSBhcmUgaW4gdG90YWwgYWdyZWVtZW50IOKAkyB3aGljaCBpcyB3aHkgd2hlbiBJIGxvb2sgYXQg
d2hhdCBoYXMgb2NjdXJyZWQgaW4gU1BSSU5HIOKAkyBJIGZpbmQgbXlzZWxmIGdldHRpbmcgdmVy
eSBkZXByZXNzZWQuDQoNCkluIG9yZGVyIHRvIGNvbnNpZGVyIHByb3RvY29scyBhbmQgY2hhbmdl
IGluIHRoZSBjb250ZXh0IG9mIHRoZSBmb3VyIGNyaXRlcmlhIHlvdSBsaXN0ZWQg4oCTIHdlIHdv
dWxkIG5lZWQgY2VydGFpbiBpbmZvcm1hdGlvbiDigJMNCg0KDQogIDEuICBXaHkgZG8gdGhlIGF1
dGhvcnMgb2YgdGhlIGRpc3B1dGVkIGRyYWZ0IGluc2lzdCBvbiBob2xkaW5nIHdpdGggUFNQIOKA
kyB3aGF0IGlzIHRoZSBzdWJzdGFudGl2ZSB1c2UgY2FzZSDigJMgSSBmb3Igb25lIOKAkyBkbyBu
b3QgYmVsaWV2ZSB0aGlzIGhhcyBiZWVuIGNsb3NlIHRvIGFkZHJlc3NlZCBpbiBsaWdodCBvZiB0
aGUgZmFjdCB0aGF0IHRoZXJlIHdlcmUgbm8gbGVzcyB0aGFuIDQgd2F5cyB0byBwcm9ncmVzcyB0
aGUgY29udGVudGlvdXMgZHJhZnQgKGNvbXByb21pc2VzIHdlcmUgb2ZmZXJlZCwgZXZlcnl0aGlu
ZyBmcm9tLCBwcm9ncmVzcyB0aGUgZHJhZnQgd2l0aCB0aGlzIG1vdmVkIHRvIGFub3RoZXIgZG9j
dW1lbnQgdGhhdCBjb3VsZCBiZSBkZWJhdGVkLCB0byB1cGRhdGUgdGhlIHJmYzgyMDApIOKAkyBp
biBldmVyeSBjYXNlIOKAkyB0aGUgYXV0aG9ycyByZWZ1c2VkIHRvIGJ1ZGdlDQogIDIuICBJbiBv
cmRlciB0byBldmFsdWF0ZSBiZW5lZml0IHlvdSBuZWVkIHBlb3BsZSB3aG8gYXJlIHByZXBhcmVk
IHRvIHN0YXRlIHRoZSBiZW5lZml0IHRoZXkgc2VlIGluIHNvbWV0aGluZyDigJMgaW5zdGVhZCB3
ZSBoYXZlIGEgZG9jdW1lbnQgYWR2YW5jaW5nIGJhc2VkIG5vdCBvbiBjb25zZW5zdXMgYnV0IG9u
IChhbmQgSSBxdW90ZSkg4oCcV2UgaGFkIHRvIG1vdmUgdGhpcyBmb3J3YXJk4oCdIGFuZCBjaXRp
bmcgYSBidW5jaCBvZiBwZW9wbGUgd2hvICsx4oCZZWQgYSBsaXN0IGluIHdoYXQgd2FzIGluIG15
IHZpZXcgYSBjbGVhcmx5IG9yY2hlc3RyYXRlZCArMSBjYW1wYWlnbiBhcyBqdXN0aWZpY2F0aW9u
IGZvciBzdXBwb3J0LiAgSeKAmWxsIGJlIHJlbGVhc2luZyBhIHJhdGhlciBpbnRlcmVzdGluZyBz
dW1tYXJ5IGZyb20gdGhlIGxpc3RzIHNob3dpbmcganVzdCBob3cgbWFueSB0aW1lcyB0aGUgbWFq
b3JpdHkgb2YgdGhvc2UgcGVvcGxlIGhhdmUgKmV2ZXIqIHBvc3RlZCB0byB0aGUgbGlzdHMgYmVm
b3JlIOKAkyBpdCBtYWtlcyBmb3IgYW4gaW50ZXJlc3RpbmcgcmVhZC4NCiAgMy4gIFdpdGggcmVn
YXJkcyB0byB0aGUgY29zdHMg4oCTIHdpdGhvdXQga25vd2luZyB3aGF0IHRoZSByZWFsIHJlYXNv
biBmb3IgaW5zaXN0aW5nIG9uIGhvbGRpbmcgdG8gdGhpcyDigJMgYW5kIHRoZXJlIG11c3QgYmUg
ZG9uZSBjb25zaWRlcmluZyB0aGUgZG9nZ2VkIHdheSB0aGUgYXV0aG9ycyBhbmQgdGhlIHZlbmRv
ciBiZWhpbmQgdGhpcyBkb2N1bWVudCBoYXZlIGluc2lzdGVkIG9uIGl0IOKAkyB3aXRob3V0IGdp
dmluZyBwcm9wZXIgcmVhc29ucyDigJMgdGhpcyBjYW5ub3QgYmUgZXZhbHVhdGVkLg0KDQpTbyDi
gJMgb24gdGhlIGJhc2lzIG9mIHRoZSBjcml0ZXJpYSB5b3UgbGlzdGVkIGFsb25lIOKAkyB0aGUg
ZmFjdCB0aGF0IHdlIGFyZSBzZWVpbmcgc29tZXRoaW5nIGJlaW5nIHJhaWxlZCB0aHJvdWdoIGEg
d29ya2luZyBncm91cCDigJMgZGVzcGl0ZSBzdWJzdGFudGl2ZSDigJMgbnVtZXJvdXMg4oCTIGFu
ZCB1bmFkZHJlc3NlZCBvYmplY3Rpb25zIGluIHRvdGFsIHZpb2xhdGlvbiBvZiB0aGUgdmVyeSBj
b25jZXB0IG9mIGNvbnNlbnN1cyDigJMgZGlzdHVyYnMgbWUgZ3JlYXRseS4gIEkgaGF2ZSBhbHdh
eXMgYmVsaWV2ZWQgdGhhdCBpZiB0aGluZ3MgbGlrZSBhcHBlYWxzIGNhbiBiZSBhdm9pZGVkIOKA
kyB0aGF0IGlzIGFsd2F5cyBmaXJzdCBwcml6ZSDigJMgc2FkbHkgaW4gdGhpcyBjYXNlIOKAkyB3
ZSBhcmUgbm93IGZvcmNlZCBpbnRvIGFuIGFwcGVhbCBwcm9jZXNzIGFuZCB3ZSB3aWxsIHNlZSBo
b3cgaXQgcGxheXMgb3V0IOKAkyBidXQg4oCTIGluIGxpZ2h0IG9mIGFsbCB0aGlzIOKAkyBJIGNh
biB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgb24gc28gbWFueSBsaXN0cyBhcmUgcXVlc3Rpb25pbmcg
d2hhdCBpcyBnb2luZyBvbi4NCg0KVGhhbmtzDQoNCkFuZHJldw0K
--_000_A150592278664D03AEF8E90E0090A9B7liquidtelecomcom_
Content-Type: text/html; charset=UTF-8
Content-ID: <7BC4046FB9FFE64AAEEE75F15BDB5A45@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg
ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10
b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu
LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg
NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYzMzQ5MDYx
MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTc4MTI5
OTE3OCAtNzE0MTI5NjYgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEz
NDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDEN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6
IiUxXC5cKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h
bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs
aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0
Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs
OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k
ZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90
dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tS0UiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HdW50dXIsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj5JIGhhdmUgdG8gc2F5IOKAkyBJIHNhdCBhbmQgdGhvdWdodCBhYm91dCB3aGF0IHlvdSB3
cm90ZSBoZXJlIOKAkyBhbmQgdGhlcmUgd2FzIG9uZSBsaW5lIHRoYSByZWFsbHkgc3RydWNrIGlu
IGluIHRoZSBjb250ZXh0IG9mIHRoaXMgd2hvbGUgZGViYXRlPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
bHQ7c25pcCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+QW55IGNoYW5nZSByZXF1aXJlcyBhIHJlYXNv
biB0byBvdmVyY29tZSB0aGUgYXNzb2NpYXRlZCBodXJkbGUuIENvbnNlcXVlbnRseSwgSSBoYXZl
IGZvdW5kIGl0IHZlcnkgaW5zdHJ1Y3RpdmUgdG8gdHJ5IHRvIHRoaW5rIGFib3V0IHRoZSBuZXR3
b3JrIGFuZCBwcm90b2NvbHMgaW4gdGVybXMgb2YgYXNzZXRzLCBpbmNlbnRpdmVzLCBjb3N0cywg
YW5kIGJlbmVmaXRzJnF1b3Q7Lg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gdGhpcyDigJMgd2UgYXJlIGluIHRv
dGFsIGFncmVlbWVudCDigJMgd2hpY2ggaXMgd2h5IHdoZW4gSSBsb29rIGF0IHdoYXQgaGFzIG9j
Y3VycmVkIGluIFNQUklORyDigJMgSSBmaW5kIG15c2VsZiBnZXR0aW5nIHZlcnkgZGVwcmVzc2Vk
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gb3JkZXIgdG8gY29uc2lkZXIgcHJvdG9jb2xzIGFuZCBj
aGFuZ2UgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGZvdXIgY3JpdGVyaWEgeW91IGxpc3RlZCDigJMg
d2Ugd291bGQgbmVlZCBjZXJ0YWluIGluZm9ybWF0aW9uIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlw
ZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow
Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaHkgZG8gdGhl
IGF1dGhvcnMgb2YgdGhlIGRpc3B1dGVkIGRyYWZ0IGluc2lzdCBvbiBob2xkaW5nIHdpdGggUFNQ
IOKAkyB3aGF0IGlzIHRoZSBzdWJzdGFudGl2ZSB1c2UgY2FzZSDigJMgSSBmb3Igb25lIOKAkyBk
byBub3QgYmVsaWV2ZSB0aGlzIGhhcyBiZWVuIGNsb3NlIHRvIGFkZHJlc3NlZA0KIGluIGxpZ2h0
IG9mIHRoZSBmYWN0IHRoYXQgdGhlcmUgd2VyZSBubyBsZXNzIHRoYW4gNCB3YXlzIHRvIHByb2dy
ZXNzIHRoZSBjb250ZW50aW91cyBkcmFmdCAoY29tcHJvbWlzZXMgd2VyZSBvZmZlcmVkLCBldmVy
eXRoaW5nIGZyb20sIHByb2dyZXNzIHRoZSBkcmFmdCB3aXRoIHRoaXMgbW92ZWQgdG8gYW5vdGhl
ciBkb2N1bWVudCB0aGF0IGNvdWxkIGJlIGRlYmF0ZWQsIHRvIHVwZGF0ZSB0aGUgcmZjODIwMCkg
4oCTIGluIGV2ZXJ5IGNhc2Ug4oCTIHRoZQ0KIGF1dGhvcnMgcmVmdXNlZCB0byBidWRnZTxvOnA+
PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBsYW5nPSJFTi1VUyI+
SW4gb3JkZXIgdG8gZXZhbHVhdGUgYmVuZWZpdCB5b3UgbmVlZCBwZW9wbGUgd2hvIGFyZSBwcmVw
YXJlZCB0byBzdGF0ZSB0aGUgYmVuZWZpdCB0aGV5IHNlZSBpbiBzb21ldGhpbmcg4oCTIGluc3Rl
YWQgd2UgaGF2ZSBhIGRvY3VtZW50IGFkdmFuY2luZyBiYXNlZCBub3Qgb24gY29uc2Vuc3VzDQog
YnV0IG9uIChhbmQgSSBxdW90ZSkg4oCcV2UgaGFkIHRvIG1vdmUgdGhpcyBmb3J3YXJk4oCdIGFu
ZCBjaXRpbmcgYSBidW5jaCBvZiBwZW9wbGUgd2hvICYjNDM7MeKAmWVkIGEgbGlzdCBpbiB3aGF0
IHdhcyBpbiBteSB2aWV3IGEgY2xlYXJseSBvcmNoZXN0cmF0ZWQgJiM0MzsxIGNhbXBhaWduIGFz
IGp1c3RpZmljYXRpb24gZm9yIHN1cHBvcnQuJm5ic3A7IEnigJlsbCBiZSByZWxlYXNpbmcgYSBy
YXRoZXIgaW50ZXJlc3Rpbmcgc3VtbWFyeSBmcm9tIHRoZSBsaXN0cyBzaG93aW5nDQoganVzdCBo
b3cgbWFueSB0aW1lcyB0aGUgbWFqb3JpdHkgb2YgdGhvc2UgcGVvcGxlIGhhdmUgKjxiPmV2ZXI8
L2I+KiBwb3N0ZWQgdG8gdGhlIGxpc3RzIGJlZm9yZSDigJMgaXQgbWFrZXMgZm9yIGFuIGludGVy
ZXN0aW5nIHJlYWQuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh
Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxz
cGFuIGxhbmc9IkVOLVVTIj5XaXRoIHJlZ2FyZHMgdG8gdGhlIGNvc3RzIOKAkyB3aXRob3V0IGtu
b3dpbmcgd2hhdCB0aGUgcmVhbCByZWFzb24gZm9yIGluc2lzdGluZyBvbiBob2xkaW5nIHRvIHRo
aXMg4oCTIGFuZCB0aGVyZSBtdXN0IGJlIGRvbmUgY29uc2lkZXJpbmcgdGhlIGRvZ2dlZCB3YXkg
dGhlIGF1dGhvcnMNCiBhbmQgdGhlIHZlbmRvciBiZWhpbmQgdGhpcyBkb2N1bWVudCBoYXZlIGlu
c2lzdGVkIG9uIGl0IOKAkyB3aXRob3V0IGdpdmluZyBwcm9wZXIgcmVhc29ucyDigJMgdGhpcyBj
YW5ub3QgYmUgZXZhbHVhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28g4oCTIG9uIHRo
ZSBiYXNpcyBvZiB0aGUgY3JpdGVyaWEgeW91IGxpc3RlZCBhbG9uZSDigJMgdGhlIGZhY3QgdGhh
dCB3ZSBhcmUgc2VlaW5nIHNvbWV0aGluZyBiZWluZyByYWlsZWQgdGhyb3VnaCBhIHdvcmtpbmcg
Z3JvdXAg4oCTIGRlc3BpdGUgc3Vic3RhbnRpdmUg4oCTIG51bWVyb3VzIOKAkyBhbmQgdW5hZGRy
ZXNzZWQgb2JqZWN0aW9ucyBpbiB0b3RhbCB2aW9sYXRpb24gb2YgdGhlIHZlcnkNCiBjb25jZXB0
IG9mIGNvbnNlbnN1cyDigJMgZGlzdHVyYnMgbWUgZ3JlYXRseS4mbmJzcDsgSSBoYXZlIGFsd2F5
cyBiZWxpZXZlZCB0aGF0IGlmIHRoaW5ncyBsaWtlIGFwcGVhbHMgY2FuIGJlIGF2b2lkZWQg4oCT
IHRoYXQgaXMgYWx3YXlzIGZpcnN0IHByaXplIOKAkyBzYWRseSBpbiB0aGlzIGNhc2Ug4oCTIHdl
IGFyZSBub3cgZm9yY2VkIGludG8gYW4gYXBwZWFsIHByb2Nlc3MgYW5kIHdlIHdpbGwgc2VlIGhv
dyBpdCBwbGF5cyBvdXQg4oCTIGJ1dCDigJMgaW4gbGlnaHQgb2YNCiBhbGwgdGhpcyDigJMgSSBj
YW4gdW5kZXJzdGFuZCB3aHkgcGVvcGxlIG9uIHNvIG1hbnkgbGlzdHMgYXJlIHF1ZXN0aW9uaW5n
IHdoYXQgaXMgZ29pbmcgb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3M8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K
--_000_A150592278664D03AEF8E90E0090A9B7liquidtelecomcom_--


From nobody Sat Feb 29 17:54:48 2020
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 5E4523A136D; Sat, 29 Feb 2020 17:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 PxSyi_Pda0BU; Sat, 29 Feb 2020 17:54:24 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70D63A1797; Sat, 29 Feb 2020 17:54:23 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8E027802F7; Sun,  1 Mar 2020 02:54:16 +0100 (CET)
To: Joseph Touch , Robert Raszuk 
Cc: Internet Area , IETF , architecture-discuss@iab.org, Internet Architecture Board 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>     
From: Fernando Gont 
Message-ID: <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar>
Date: Sat, 29 Feb 2020 22:46:03 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 01:54:27 -0000

On 28/2/20 22:55, Joseph Touch wrote:
> 
> 
>> On Feb 28, 2020, at 12:18 AM, Robert Raszuk > > wrote:
>>
>> >  I don’t care about what you WANT to do; I care whether it breaks 
>> what everyone else expects.
>>
>> I see many folks on this colorful thread simply forgot what networks 
>> are for. To deliver packets in the most robust and resilient way to 
>> end user applications. 
> 
> They’re for delivering packets, agreed.
> 
> I did look at the protocols involved here; the ingress does add headers 
> but doesn’t appear to handle fragmentation.
> 
> That’s a non-starter if you want your packets to traverse a network 
> because people WILL hand you 1280-byte packets, so what will you do?

FWIW, we have been insisting on this point (and others) since they first 
tried to push EH insertion in draft-ietf-6man-segment-routing-header.

THey removed it from *that* document, but they keep trying to push 
similar ideas in other documents.

-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Sat Feb 29 18:20:39 2020
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 B3F303A17E9; Sat, 29 Feb 2020 18:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 gzzbdze9kbpf; Sat, 29 Feb 2020 18:20:15 -0800 (PST)
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 EA45C3A17EB; Sat, 29 Feb 2020 18:20:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=vtwIXcVn5MrWvPHXYni6honY/mm0V2aMH6OKiCiIc0w=; b=X+beVDqvcm+DIgK4XvfpD/PBd 9Vuswh3GptPPEE+QTEUqK/3+8LjYOz8L3VQuoVGIpP3++NJ6hlQ5dWDfCMBYXgCguYxrnevxQ4vvi nAixEYUEmwdYAnknmXJhzbNU3ZDCZZefl27/iVpudUgNjXBjY8pxIHwsG5s3YYNWihQrvjn6JuHQR e2ixd+iJeQy/IT/lgKhTT4gHTc6nX7dCY+eGoonncqqSIjqwi7Di73baLOmN92uJ3miSXB7bxEoD2 2M0ToDFRPwxwYcQ9tkozk6ZWWBdcyrFkSeK7pBwsOLN05vHyqNaRCxaNwUldKZGIysz4y2TP1GSM3 EIfzztIuw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64414 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j8ED9-0041IK-Hc; Sat, 29 Feb 2020 21:20:11 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_1AED863B-4C37-4B96-8B14-D8FC443318DB"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar>
Date: Sat, 29 Feb 2020 18:19:55 -0800
Cc: Robert Raszuk , Internet Area , IETF , architecture-discuss@iab.org, Internet Architecture Board 
Message-Id: <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>      <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar>
To: Fernando Gont 
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 - iab.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] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 02:20:17 -0000

--Apple-Mail=_1AED863B-4C37-4B96-8B14-D8FC443318DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 29, 2020, at 5:46 PM, Fernando Gont  =
wrote:
>=20
>> I did look at the protocols involved here; the ingress does add =
headers but doesn=E2=80=99t appear to handle fragmentation.
>> That=E2=80=99s a non-starter if you want your packets to traverse a =
network because people WILL hand you 1280-byte packets, so what will you =
do?
>=20
> FWIW, we have been insisting on this point (and others) since they =
first tried to push EH insertion in =
draft-ietf-6man-segment-routing-header.
>=20
> THey removed it from *that* document, but they keep trying to push =
similar ideas in other documents.

Well its seems simple to me - they need a plan for fragmentation or =
it=E2=80=99s simply a nonstarter because they can=E2=80=99t support =
1280-B packets traversing the network.

No amount of =E2=80=9Cbut this is what the user wants=E2=80=9D =
translates to =E2=80=9Cthey want their packets dropped silently=E2=80=9D.

Joe=

--Apple-Mail=_1AED863B-4C37-4B96-8B14-D8FC443318DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 29, 2020, at 5:46 PM, Fernando Gont <fernando@gont.com.ar> wrote:

I did =
look at the protocols involved here; the ingress does add headers but =
doesn=E2=80=99t appear to handle fragmentation.
That=E2=80=99=
s a non-starter if you want your packets to traverse a network because =
people WILL hand you 1280-byte packets, so what will you do?

FWIW, we have been insisting on this point (and others) since =
they first tried to push EH insertion in =
draft-ietf-6man-segment-routing-header.

THey removed it from *that* document, but they keep trying to =
push similar ideas in other =
documents.

Well its seems simple to me - they need a plan for =
fragmentation or it=E2=80=99s simply a nonstarter because they can=E2=80=99=
t support 1280-B packets traversing the network.

No amount of =E2=80=9Cbut this is what =
the user wants=E2=80=9D translates to =E2=80=9Cthey want their packets =
dropped silently=E2=80=9D.

Joe
=

--Apple-Mail=_1AED863B-4C37-4B96-8B14-D8FC443318DB--


From nobody Sat Feb 29 18:28:21 2020
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 028D13A1809 for ; Sat, 29 Feb 2020 18:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 oDL5gfU7TzNh for ; Sat, 29 Feb 2020 18:28:13 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B320B3A1804 for ; Sat, 29 Feb 2020 18:28:12 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2057.outbound.protection.outlook.com [104.47.9.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-81--912_hvBOWeHGr7MzdDRXA-1; Sun, 01 Mar 2020 02:27:04 +0000
X-MC-Unique: -912_hvBOWeHGr7MzdDRXA-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5160.eurprd03.prod.outlook.com (10.255.78.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Sun, 1 Mar 2020 02:27:02 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.018; Sun, 1 Mar 2020 02:27:02 +0000
From: Andrew Alston 
To: Joseph Touch , Fernando Gont 
CC: "architecture-discuss@iab.org" , Internet Architecture Board , Internet Area , IETF 
Thread-Topic: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Thread-Index: AQHV7bcNl1ULGT9qmUy3IjCyJijihKgvmTCAgAAMjICAAAP9AIAABAWAgAAEWoCAAAYBgIAATQ2AgAA+1wCAASdAAIABj6mAgAAJd4CAADRFAA==
Date: Sun, 1 Mar 2020 02:27:02 +0000
Message-ID: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>      <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar> <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
In-Reply-To: <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [2c0f:fe40:3:3:808d:eb0:4250:7e10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 60f7a6e0-62c1-4372-dcd6-08d7bd8806ac
x-ms-traffictypediagnostic: DBBPR03MB5160:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0329B15C8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(366004)(39850400004)(136003)(346002)(189003)(199004)(6512007)(2906002)(2616005)(54906003)(6506007)(81156014)(81166006)(110136005)(8936002)(186003)(53546011)(6486002)(33656002)(5660300002)(71200400001)(4326008)(8676002)(66946007)(66476007)(66556008)(64756008)(478600001)(86362001)(316002)(66446008)(66574012)(91956017)(36756003)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5160; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EX6ecBA2v3OAyC7d35hELspdZJ0MOgTWrUEBUggd8Yz7E2RywofuZe4kXmK42catjNki78HMWi9yE7TEErPwVAloeZ/4YDbO65BK/t0B8DK682e9SQG+bGmB/IkJvKxqTL8DUqDtcPKS6w76c409HZMeQEdjhwo8boZtdvIIWosjF3mHHeCz3tNjOLNddlHmR/E00pQQHsFqRyMEYUAfH00+EWbPhALQhv6mi8ixHLyk2yzDnUt/MrKyBVU9CARFnGRzQiFGm+bF2Ap9PKwD2GivorqQjtK1VvQx7pCwyB1+FQON5rCBPhdZOgm5EO8qw+9at7Goww09/Xioqlf2RdiL0W1VhNDpW6aX4l5SIh9TavoyebuPqWQI73X2pl9CRwYODbZ8DEMltA4z4AM63vyGD2gbDUCFBWg6lXZrWh/pLzvv3gyhkGgZPdAsa6b/
x-ms-exchange-antispam-messagedata: 2KoMfjw4nIcXJ781t6wpZ1RjEDPWT1UAJIaKc0R+RN6ASs4m/KfC3LO+s9e5W+WJjpNXGSffVBDJiVf7GCD8YR/IgSyT1ks53K507UFbB3CUeMkK1vmmy1b9OJK2TbF0cPAw0y6GyZE0DiPV6rDjzGHZBaQp31hMk93pi2lj7iJ33PYhWQdq62uAUjyG3iYAyDkTcuuX0A0NwOna1wD2Iw==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60f7a6e0-62c1-4372-dcd6-08d7bd8806ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2020 02:27:02.0359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gD6+xFaKv4Nd9BfsYS62p4ptzOGydANKRCypw0gpYXMX/gjBiH2mcbmusIyYXrFZalAN4JgufgS7maCbdWPt0cg99HnaLMbRolCO9hfiPUk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5160
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_A2A1EA3553F84D21B311D94E515D5226liquidtelecomcom_"
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 02:28:20 -0000

--_000_A2A1EA3553F84D21B311D94E515D5226liquidtelecomcom_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SSByYWlzZWQgdGhlIGlzc3VlIG9mIHRoZSBsaW1pdGF0aW9ucyBpbXBvc2VkIGJ5IFJGQyA3MTEy
IGR1cmluZyB0aGUgY291cnNlIG9mIHRoaXMgc2FnYSDigJMgaXTigJlzIG9uIHRoZSBsaXN0IG9m
IHRoaW5ncyB0aGF0IHdlcmUgYmx1bnRseSBhbmQgc2hhbWVsZXNzbHkgaWdub3JlZCB3aXRob3V0
IGEgc2luZ2xlIGNvbW1lbnQgYmVmb3JlIHRoaXMgZG9jdW1lbnQgbXlzdGVyaW91c2x5IHdhcyBk
ZWNsYXJlZCB0byBiZSBtb3ZpbmcgZm9yd2FyZCBvdXQgb2YgbGFzdCBjYWxsIG9uIHRoZSBiYXNp
cyBvZiBzb21lICsx4oCZcy4NCg0KVGhhbmtzDQoNCkFuZHJldw0KDQoNCkZyb206IGlldGYgPGll
dGYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpvc2VwaCBUb3VjaCA8dG91Y2hAc3Ry
YXlhbHBoYS5jb20+DQpEYXRlOiBTdW5kYXksIDEgTWFyY2ggMjAyMCBhdCAwNToyMQ0KVG86IEZl
cm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPg0KQ2M6ICJhcmNoaXRlY3R1cmUtZGlz
Y3Vzc0BpYWIub3JnIiA8YXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWFiLm9yZz4sIEludGVybmV0IEFy
Y2hpdGVjdHVyZSBCb2FyZCA8aWFiQGlhYi5vcmc+LCBJbnRlcm5ldCBBcmVhIDxpbnQtYXJlYUBp
ZXRmLm9yZz4sIElFVEYgPGlldGZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJ
cyBJUHY2IEVuZC10by1FbmQ/IFIuSS5QLiBBcmNoaXRlY3R1cmU/IChGd2Q6IEVycmF0YSAjNTkz
MyBmb3IgUkZDODIwMCkNCg0KDQoNCg0KT24gRmViIDI5LCAyMDIwLCBhdCA1OjQ2IFBNLCBGZXJu
YW5kbyBHb250IDxmZXJuYW5kb0Bnb250LmNvbS5hcjxtYWlsdG86ZmVybmFuZG9AZ29udC5jb20u
YXI+PiB3cm90ZToNCg0KSSBkaWQgbG9vayBhdCB0aGUgcHJvdG9jb2xzIGludm9sdmVkIGhlcmU7
IHRoZSBpbmdyZXNzIGRvZXMgYWRkIGhlYWRlcnMgYnV0IGRvZXNu4oCZdCBhcHBlYXIgdG8gaGFu
ZGxlIGZyYWdtZW50YXRpb24uDQpUaGF04oCZcyBhIG5vbi1zdGFydGVyIGlmIHlvdSB3YW50IHlv
dXIgcGFja2V0cyB0byB0cmF2ZXJzZSBhIG5ldHdvcmsgYmVjYXVzZSBwZW9wbGUgV0lMTCBoYW5k
IHlvdSAxMjgwLWJ5dGUgcGFja2V0cywgc28gd2hhdCB3aWxsIHlvdSBkbz8NCg0KRldJVywgd2Ug
aGF2ZSBiZWVuIGluc2lzdGluZyBvbiB0aGlzIHBvaW50IChhbmQgb3RoZXJzKSBzaW5jZSB0aGV5
IGZpcnN0IHRyaWVkIHRvIHB1c2ggRUggaW5zZXJ0aW9uIGluIGRyYWZ0LWlldGYtNm1hbi1zZWdt
ZW50LXJvdXRpbmctaGVhZGVyLg0KDQpUSGV5IHJlbW92ZWQgaXQgZnJvbSAqdGhhdCogZG9jdW1l
bnQsIGJ1dCB0aGV5IGtlZXAgdHJ5aW5nIHRvIHB1c2ggc2ltaWxhciBpZGVhcyBpbiBvdGhlciBk
b2N1bWVudHMuDQoNCldlbGwgaXRzIHNlZW1zIHNpbXBsZSB0byBtZSAtIHRoZXkgbmVlZCBhIHBs
YW4gZm9yIGZyYWdtZW50YXRpb24gb3IgaXTigJlzIHNpbXBseSBhIG5vbnN0YXJ0ZXIgYmVjYXVz
ZSB0aGV5IGNhbuKAmXQgc3VwcG9ydCAxMjgwLUIgcGFja2V0cyB0cmF2ZXJzaW5nIHRoZSBuZXR3
b3JrLg0KDQpObyBhbW91bnQgb2Yg4oCcYnV0IHRoaXMgaXMgd2hhdCB0aGUgdXNlciB3YW50c+KA
nSB0cmFuc2xhdGVzIHRvIOKAnHRoZXkgd2FudCB0aGVpciBwYWNrZXRzIGRyb3BwZWQgc2lsZW50
bHnigJ0uDQoNCkpvZQ0K
--_000_A2A1EA3553F84D21B311D94E515D5226liquidtelecomcom_
Content-Type: text/html; charset=UTF-8
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow
Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv
d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5
Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJlbi1LRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSByYWlzZWQgdGhlIGlzc3VlIG9mIHRo
ZSBsaW1pdGF0aW9ucyBpbXBvc2VkIGJ5IFJGQyA3MTEyIGR1cmluZyB0aGUgY291cnNlIG9mIHRo
aXMgc2FnYSDigJMgaXTigJlzIG9uIHRoZSBsaXN0IG9mIHRoaW5ncyB0aGF0IHdlcmUgYmx1bnRs
eSBhbmQgc2hhbWVsZXNzbHkgaWdub3JlZCB3aXRob3V0IGEgc2luZ2xlIGNvbW1lbnQNCiBiZWZv
cmUgdGhpcyBkb2N1bWVudCBteXN0ZXJpb3VzbHkgd2FzIGRlY2xhcmVkIHRvIGJlIG1vdmluZyBm
b3J3YXJkIG91dCBvZiBsYXN0IGNhbGwgb24gdGhlIGJhc2lzIG9mIHNvbWUgJiM0Mzsx4oCZcy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5pZXRm
ICZsdDtpZXRmLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKb3NlcGggVG91Y2gg
Jmx0O3RvdWNoQHN0cmF5YWxwaGEuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIDEg
TWFyY2ggMjAyMCBhdCAwNToyMTxicj4NCjxiPlRvOiA8L2I+RmVybmFuZG8gR29udCAmbHQ7ZmVy
bmFuZG9AZ29udC5jb20uYXImZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDthcmNoaXRlY3R1cmUt
ZGlzY3Vzc0BpYWIub3JnJnF1b3Q7ICZsdDthcmNoaXRlY3R1cmUtZGlzY3Vzc0BpYWIub3JnJmd0
OywgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkICZsdDtpYWJAaWFiLm9yZyZndDssIEludGVy
bmV0IEFyZWEgJmx0O2ludC1hcmVhQGlldGYub3JnJmd0OywgSUVURiAmbHQ7aWV0ZkBpZXRmLm9y
ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJbnQtYXJlYV0gSXMgSVB2NiBFbmQtdG8t
RW5kPyBSLkkuUC4gQXJjaGl0ZWN0dXJlPyAoRndkOiBFcnJhdGEgIzU5MzMgZm9yIFJGQzgyMDAp
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi
cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmVi
IDI5LCAyMDIwLCBhdCA1OjQ2IFBNLCBGZXJuYW5kbyBHb250ICZsdDs8YSBocmVmPSJtYWlsdG86
ZmVybmFuZG9AZ29udC5jb20uYXIiPmZlcm5hbmRvQGdvbnQuY29tLmFyPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu
czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h
ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow
cHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPkkgZGlkIGxvb2sgYXQgdGhlIHByb3RvY29scyBpbnZvbHZl
ZCBoZXJlOyB0aGUgaW5ncmVzcyBkb2VzIGFkZCBoZWFkZXJzIGJ1dCBkb2VzbuKAmXQgYXBwZWFy
IHRvIGhhbmRsZSBmcmFnbWVudGF0aW9uLjxicj4NClRoYXTigJlzIGEgbm9uLXN0YXJ0ZXIgaWYg
eW91IHdhbnQgeW91ciBwYWNrZXRzIHRvIHRyYXZlcnNlIGEgbmV0d29yayBiZWNhdXNlIHBlb3Bs
ZSBXSUxMIGhhbmQgeW91IDEyODAtYnl0ZSBwYWNrZXRzLCBzbyB3aGF0IHdpbGwgeW91IGRvPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+
DQpGV0lXLCB3ZSBoYXZlIGJlZW4gaW5zaXN0aW5nIG9uIHRoaXMgcG9pbnQgKGFuZCBvdGhlcnMp
IHNpbmNlIHRoZXkgZmlyc3QgdHJpZWQgdG8gcHVzaCBFSCBpbnNlcnRpb24gaW4gZHJhZnQtaWV0
Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIuPGJyPg0KPGJyPg0KVEhleSByZW1vdmVkIGl0
IGZyb20gKnRoYXQqIGRvY3VtZW50LCBidXQgdGhleSBrZWVwIHRyeWluZyB0byBwdXNoIHNpbWls
YXIgaWRlYXMgaW4gb3RoZXIgZG9jdW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwgaXRz
IHNlZW1zIHNpbXBsZSB0byBtZSAtIHRoZXkgbmVlZCBhIHBsYW4gZm9yIGZyYWdtZW50YXRpb24g
b3IgaXTigJlzIHNpbXBseSBhIG5vbnN0YXJ0ZXIgYmVjYXVzZSB0aGV5IGNhbuKAmXQgc3VwcG9y
dCAxMjgwLUIgcGFja2V0cyB0cmF2ZXJzaW5nIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBhbW91bnQgb2Yg4oCcYnV0
IHRoaXMgaXMgd2hhdCB0aGUgdXNlciB3YW50c+KAnSB0cmFuc2xhdGVzIHRvIOKAnHRoZXkgd2Fu
dCB0aGVpciBwYWNrZXRzIGRyb3BwZWQgc2lsZW50bHnigJ0uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==
--_000_A2A1EA3553F84D21B311D94E515D5226liquidtelecomcom_--


From nobody Sat Feb 29 18:45:23 2020
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 DF1F23A1855; Sat, 29 Feb 2020 18:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 6mDyKT4D-EiV; Sat, 29 Feb 2020 18:45:02 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724863A1865; Sat, 29 Feb 2020 18:45:01 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C461A83248; Sun,  1 Mar 2020 03:44:55 +0100 (CET)
To: Joseph Touch , Fernando Gont 
Cc: architecture-discuss@iab.org, Internet Architecture Board , Internet Area , IETF , Robert Raszuk 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>      <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar> <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
From: Fernando Gont 
Message-ID: <224aec71-128c-02a4-29fc-89e2fc1674bc@si6networks.com>
Date: Sat, 29 Feb 2020 23:44:43 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 02:45:14 -0000

On 29/2/20 23:19, Joseph Touch wrote:
> 
> 
>> On Feb 29, 2020, at 5:46 PM, Fernando Gont > > wrote:
>>
>>> I did look at the protocols involved here; the ingress does add 
>>> headers but doesn’t appear to handle fragmentation.
>>> That’s a non-starter if you want your packets to traverse a network 
>>> because people WILL hand you 1280-byte packets, so what will you do?
>>
>> FWIW, we have been insisting on this point (and others) since they 
>> first tried to push EH insertion in 
>> draft-ietf-6man-segment-routing-header.
>>
>> THey removed it from *that* document, but they keep trying to push 
>> similar ideas in other documents.
> 
> Well its seems simple to me - they need a plan for fragmentation or it’s 
> simply a nonstarter because they can’t support 1280-B packets traversing 
> the network.

Indeed.

But it's worse than that. The proponents, and others, claim that IPv6 
supports extension header insertion/removal en-route to a destination.

In order for that to be the case, the IPv6 specification itself 
(RFC8200) would have a plan to make PMTUD work (and IPsec AH, too). But 
obviously it doesn't (because it never supporte EH insertion/removal 
en-route to destination).

Still, the errata I submitted 
(https://www.rfc-editor.org/errata/eid5933), is unprocessed, and at 
least there was a statement that would be "held for document update" 
(see: 
https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/)




> No amount of “but this is what the user wants” translates to “they want 
> their packets dropped silently”.

It smells even worse when they pretend that the IPv6 allows for their 
proposed behavior.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Sat Feb 29 18:50:04 2020
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 98A993A184F; Sat, 29 Feb 2020 18:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Ajms63Zr7dtZ; Sat, 29 Feb 2020 18:49:47 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5623A1850; Sat, 29 Feb 2020 18:49:47 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AFE3F80C7D; Sun,  1 Mar 2020 03:49:43 +0100 (CET)
To: Robert Raszuk , Joe Touch 
Cc: Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   
From: Fernando Gont 
Message-ID: <02d51d11-c3da-3e1e-fe1f-ca88fc48e734@si6networks.com>
Date: Sat, 29 Feb 2020 23:49:36 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 02:49:50 -0000

On 27/2/20 20:04, Robert Raszuk wrote:
> Joe, all,
> 
> Just to clarify something Fernando purposely missed in his call for action: >
> All operations on the packets discussed in SPRING WG are happening NOT 
> on the original (end to end) packet header. They are all defined to 
> happen within new imposed outer encapsulated header (IPv6 in IPv6 to be 
> precise).

Nobody ever claimed something different.

But I tell you what: the outer packets are IPv6 packets. Hence, when you 
add/remove extension headers en-route to destination, you are violating 
RFC8200.

Please repeat with me: IPv6 does not allow the insertion/removal of 
extension header while the packets are en-route to the final destination.

I wished this conversation could go back to a honest one.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Sat Feb 29 18:58:19 2020
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 F095D3A186A; Sat, 29 Feb 2020 18:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VKCTLNOGSGlS; Sat, 29 Feb 2020 18:58:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8132D3A1869; Sat, 29 Feb 2020 18:58:01 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B551583248; Sun,  1 Mar 2020 03:57:56 +0100 (CET)
To: Robert Raszuk , Joe Touch 
Cc: Internet Architecture Board , architecture-discuss@iab.org, Internet Area , IETF 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>    <435b3561fd446be01d7d464e0c0762c5@strayalpha.com> 
From: Fernando Gont 
Message-ID: <161201b5-24af-5fd9-3a3c-efa1d1e75e97@si6networks.com>
Date: Sat, 29 Feb 2020 23:57:44 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 02:58:04 -0000

On 27/2/20 20:10, Robert Raszuk wrote:
> 
>> It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header.
> 
> It happens on tunnel ingress and tunnel egress nodes (egress = node 
> listed in DA of the packet).

That is obviously a lie.

PSP happens en-route.  Isn't it obvious from the fact that "PSP" stands 
for "PENULTIMATE Segment Pop"? It's done at the last waypoint on the way 
to the final destination of the packet.

The same is true for the TI-LFA behavior with you moved out to a 
different document: it causes an extension header to be inserted in IPv6 
packets while en-route to the final destination 
(https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa).

It is quite curious the mode in which the proponents of this behavior, 
and even more that consensus has been claimed on this document.

I'm glad that there are more eyes now looking at what's going on.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Sat Feb 29 19:10:27 2020
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 739813A09DA; Sat, 29 Feb 2020 19:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 acsPy5TWyofm; Sat, 29 Feb 2020 19:10:08 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 4AFFB3A1893; Sat, 29 Feb 2020 19:10:08 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id x19so1615777otp.7; Sat, 29 Feb 2020 19:10:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YpSIlLJ9wIEFPOicTxcX2+aXlg0pjHF/A/PsYx56BZQ=; b=ELtuKbKP1bH8o+LlccuyDPQuYrRwKrwMcaYTECsPqMfkx4dyMDVcyb0z9QnenMXza6 Q2JuT1riwZDIDD2D5E5GnqWOgVYJ5mDfVsw5G8xXuJTru6FaPKSM7myYc9YtxwJ51/Hi mdZCwH2CDvXe1/7/c0NNxqqMLTCHYsuS7FN17318AycrlKkHMfpH+rQfeCewTbEto+F5 r10PjIJgbxnwLHE+ziX1Etuzu157HayE/crPLeaILMHbVD8pbaP4z5Z3OCUA284D89J6 8D5XUuc+WPh4iXSsrWPFFRAlJoBWj3Ab1EYLceLWuWyUwJrW0TfNpr50eWdAnCWUZ8ra QRcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YpSIlLJ9wIEFPOicTxcX2+aXlg0pjHF/A/PsYx56BZQ=; b=V+an8y/LG49aSXiWN/w/1m2MLooAgK1+m7gNYe7DVV8SOxaBdSVfgR0Go8kU0uW3VB cOBuQCTLW2Rt6Gjs/l+CqBbS+RigFrIKZa4oIND8isuz7D7qjJS97vhrGLQC6ZGmUKsS FoLSOSk8UF0GWKswU1LQvXhA1goO0sbfA0Ns80OCAC1lyZfuIB31NVHUzPsE70Sk/YIb 4rL6ae/mKpiAapQpV6e1K1MStDxov5kecme/EbScTI0Ns8HDPtSyFD1o9C577/zdwB16 ft8dTU1tTzwjrQ0y8+kCwo5w39OzvxZLNYiFyxjX7tBhNehkC/hxV2uMUz4uYYLqWXrR SMPg==
X-Gm-Message-State: APjAAAWBHcxdqrfuxkKZfbHXo++qtJbzO9waIwu6t6OCW5eW+jyk+rZD EPepnKgEMBb6iCgwRuipTIkNPIxpvibysj9iG68=
X-Google-Smtp-Source: APXvYqxhgdDyNx+0RvFHw2ipsJvSeBW1GUrlK8YLE92yrTSACW1QnOnpRSkGBHkiLQZirNUHZXgD5VEf7ATlU4/UOL4=
X-Received: by 2002:a9d:3df6:: with SMTP id l109mr8569771otc.284.1583032207321;  Sat, 29 Feb 2020 19:10:07 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sat, 29 Feb 2020 19:10:06 -0800 (PST)
In-Reply-To: 
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>   <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>      
From: Guntur Wiseno Putra 
Date: Sun, 1 Mar 2020 10:10:06 +0700
Message-ID: 
To: Andrew Alston 
Cc: Robert Raszuk , Internet Area , IETF , Tom Herbert ,  "architecture-discuss@iab.org" , Internet Architecture Board 
Content-Type: multipart/alternative; boundary="00000000000062ac66059fc268f8"
Archived-At: 
Subject: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
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, 01 Mar 2020 03:10:12 -0000

--00000000000062ac66059fc268f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Andrew &
architecture-discuss,


I struggled to read yours, Andrew, and others mentioned in this message.

What are about the 4 criteria (assets, incentives, costs and benefits)
mentioned by Pikander...?


He mentioned about "vision" following the criteria:

" We need some kind of an architectural vision and a related transition
path; an idea of where we are heading and perhaps how we could get there.

...".



"Vision is a coincidence between what are Pikander's on the Internet
Architecture (especially about protocols and changes) and what is
Heidegger's on art, technology and humanity:


He ... (Heidegger)... believes this because, as he explains in his earlier
text =E2=80=9CThe Origin of the Work of Art,=E2=80=9D art is nothing other =
than the
revelation of the way we use things=E2=80=94and, if one wants, of the way w=
e are
used by things.2 Here it is important to note that for Heidegger, the
artwork is not a thing but a vision that opens to the artist in the
clearing of Being.


More generally, the "vision" to elaborate concerns with developing the
Internet technology research and standards: L. Daigle (2009) said


"(In developing the Internet technology based on innivation and
interoprability:) In that model of development, there are three key types
of activity from which feedback needs to be fostered: (1) development of
technical specifications, (2) deployment, and (3) answering open questions
(research). The IETF focuses primarily on the first activity, but it has a
close relationship with the third in the shape of the Internet Research
Task Force (IRTF). The IETF process itself is deliberately open to and
seeking feedback from the second activity: deployment experiences".

https://www.ietfjournal.org/developing-internet-technology-
research-and-standards/

More recently about the "vision" to elaborate is section 4. How We See the
Internet of 2019 ISOC GlobalbReport "Consolidation in the Internet Economy"

https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/=
InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf




Regard,
Guntur Wiseno Putra

Pada Minggu, 01 Maret 2020, Andrew Alston 
menulis:

> Guntur,
>
>
>
> I have to say =E2=80=93 I sat and thought about what you wrote here =E2=
=80=93 and there
> was one line tha really struck in in the context of this whole debate
>
>
>
> 
>
> > Any change requires a reason to overcome the associated hurdle.
> Consequently, I have found it very instructive to try to think about the
> network and protocols in terms of assets, incentives, costs, and benefits=
".
>
> On this =E2=80=93 we are in total agreement =E2=80=93 which is why when I=
 look at what has
> occurred in SPRING =E2=80=93 I find myself getting very depressed.
>
>
>
> In order to consider protocols and change in the context of the four
> criteria you listed =E2=80=93 we would need certain information =E2=80=93
>
>
>
>    1. Why do the authors of the disputed draft insist on holding with PSP
>    =E2=80=93 what is the substantive use case =E2=80=93 I for one =E2=80=
=93 do not believe this has
>    been close to addressed in light of the fact that there were no less t=
han 4
>    ways to progress the contentious draft (compromises were offered,
>    everything from, progress the draft with this moved to another documen=
t
>    that could be debated, to update the rfc8200) =E2=80=93 in every case =
=E2=80=93 the authors
>    refused to budge
>    2. In order to evaluate benefit you need people who are prepared to
>    state the benefit they see in something =E2=80=93 instead we have a do=
cument
>    advancing based not on consensus but on (and I quote) =E2=80=9CWe had =
to move this
>    forward=E2=80=9D and citing a bunch of people who +1=E2=80=99ed a list=
 in what was in my
>    view a clearly orchestrated +1 campaign as justification for support. =
 I=E2=80=99ll
>    be releasing a rather interesting summary from the lists showing just =
how
>    many times the majority of those people have **ever** posted to the
>    lists before =E2=80=93 it makes for an interesting read.
>    3. With regards to the costs =E2=80=93 without knowing what the real r=
eason
>    for insisting on holding to this =E2=80=93 and there must be done cons=
idering the
>    dogged way the authors and the vendor behind this document have insist=
ed on
>    it =E2=80=93 without giving proper reasons =E2=80=93 this cannot be ev=
aluated.
>
>
>
> So =E2=80=93 on the basis of the criteria you listed alone =E2=80=93 the =
fact that we are
> seeing something being railed through a working group =E2=80=93 despite s=
ubstantive
> =E2=80=93 numerous =E2=80=93 and unaddressed objections in total violatio=
n of the very
> concept of consensus =E2=80=93 disturbs me greatly.  I have always believ=
ed that if
> things like appeals can be avoided =E2=80=93 that is always first prize =
=E2=80=93 sadly in
> this case =E2=80=93 we are now forced into an appeal process and we will =
see how it
> plays out =E2=80=93 but =E2=80=93 in light of all this =E2=80=93 I can un=
derstand why people on so
> many lists are questioning what is going on.
>
>
>
> Thanks
>
>
>
> Andrew
>

--00000000000062ac66059fc268f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Andrew &
architecture-discuss,


I struggled to read yours, Andrew, and others mentioned in this mess=
age.

What are about the 4 criteria (assets, incent=
ives, costs and benefits) mentioned by Pikander...?=C2=A0


He mentioned about "vision" following the =
criteria:

" We need some kind of =
an architectural vision and a related transition path; an idea of where we =
are heading and perhaps how we could get there.

...".=C2=A0

<=
/div>


"Vision is a coincidence betwe=
en what are Pikander's on the Internet Architecture (especially about p=
rotocols and changes) and what is Heidegger's on art, technology and hu=
manity:


He ... (Heidegger)... believes this because, as he expla=
ins in his earlier text =E2=80=9CThe Origin of the Work of Art,=E2=80=9D ar=
t is nothing other than the revelation of the way we use things=E2=80=94and=
, if one wants, of the way we are used by things.2=C2=A0Here it is important to note that for Heidegger, the =
artwork is not a thing but a vision that opens to the artist in the clearin=
g of Being.


More general=
ly, the "vision" to elaborate concerns with developing the Intern=
et technology research and standards: L. Daigle (2009) said=C2=A0


"(In developing the Internet techn=
ology based on innivation and interoprability:) In that model of developmen=
t, there are three key types of activity from which feedback needs to be fo=
stered: (1) development of technical specifications, (2) deployment, and (3=
) answering open questions (research). The IETF focuses primarily on the fi=
rst activity, but it has a close relationship with the third in the shape o=
f the Internet Research Task Force (IRTF). The IETF process itself is delib=
erately open to and seeking feedback from the second activity: deployment e=
xperiences".

More recently about the=
 "vision" to elaborate is section 4. How We See the Internet of 2=
019 ISOC GlobalbReport "Consolidation in the Internet Economy"





Regard,
Guntur Wiseno Putra=


Pada Minggu, 01 Maret 2020, Andrew Alston <Andrew.Alston@liquidtelecom=
.com> menulis:











Guntur,

=C2=A0


I have to say =E2=80=93 I sat a=
nd thought about what you wrote here =E2=80=93 and there was one line tha r=
eally struck in in the context of this whole debate

=C2=A0


<snip>


> Any change requires=
 a reason to overcome the associated hurdle. Consequently, I have found it =
very instructive to try to think about the network and protocols in terms o=
f assets, incentives, costs, and benefits".







On this =E2=80=93 we are in tot=
al agreement =E2=80=93 which is why when I look at what has occurred in SPR=
ING =E2=80=93 I find myself getting very depressed.

=C2=A0


In order to consider protocols =
and change in the context of the four criteria you listed =E2=80=93 we woul=
d need certain information =E2=80=93


=C2=A0


    

  1. Why do the authors of th=
e disputed draft insist on holding with PSP =E2=80=93 what is the substanti=
ve use case =E2=80=93 I for one =E2=80=93 do not believe this has been clos=
e to addressed
 in light of the fact that there were no less than 4 ways to progress the c=
ontentious draft (compromises were offered, everything from, progress the d=
raft with this moved to another document that could be debated, to update t=
he rfc8200) =E2=80=93 in every case =E2=80=93 the
 authors refused to budge
  2. In order to evaluate benefit you need people who=
 are prepared to state the benefit they see in something =E2=80=93 instead =
we have a document advancing based not on consensus
 but on (and I quote) =E2=80=9CWe had to move this forward=E2=80=9D and cit=
ing a bunch of people who +1=E2=80=99ed a list in what was in my view a cle=
arly orchestrated +1 campaign as justification for support.=C2=A0 I=E2=80=
=99ll be releasing a rather interesting summary from the lists showing
 just how many times the majority of those people have *ever* posted=
 to the lists before =E2=80=93 it makes for an interesting read.<=
/u>
  3. With rega=
rds to the costs =E2=80=93 without knowing what the real reason for insisti=
ng on holding to this =E2=80=93 and there must be done considering the dogg=
ed way the authors
 and the vendor behind this document have insisted on it =E2=80=93 without =
giving proper reasons =E2=80=93 this cannot be evaluated.


=C2=A0


So =E2=80=93 on the basis of th=
e criteria you listed alone =E2=80=93 the fact that we are seeing something=
 being railed through a working group =E2=80=93 despite substantive =E2=80=
=93 numerous =E2=80=93 and unaddressed objections in total violation of the=
 very
 concept of consensus =E2=80=93 disturbs me greatly.=C2=A0 I have always be=
lieved that if things like appeals can be avoided =E2=80=93 that is always =
first prize =E2=80=93 sadly in this case =E2=80=93 we are now forced into a=
n appeal process and we will see how it plays out =E2=80=93 but =E2=80=93 i=
n light of
 all this =E2=80=93 I can understand why people on so many lists are questi=
oning what is going on.


=C2=A0


Thanks


=C2=A0


Andrew











--00000000000062ac66059fc268f8--