Re: [arch-d] Time to reboot RFC1984 and RFC2804?
Toerless Eckert <tte@cs.fau.de> Wed, 14 October 2020 00:12 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C74F3A126C for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 17:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 6CXO8Gafh8pc for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 17:12:52 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B20C3A0115 for <architecture-discuss@ietf.org>; Tue, 13 Oct 2020 17:12:52 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D35A0548019; Wed, 14 Oct 2020 02:12:46 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C483F440059; Wed, 14 Oct 2020 02:12:46 +0200 (CEST)
Date: Wed, 14 Oct 2020 02:12:46 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Andrew Campling <andrew.campling@419.consulting>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Message-ID: <20201014001246.GD57007@faui48f.informatik.uni-erlangen.de>
References: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com> <975E28FE326C22E8CD32DCC8@PSB> <5021a377-e9ca-1580-c2f0-3351b9f5fe04@huitema.net> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <e80b6f1e-3949-b2ee-6e61-a2f3dfce9b0c@cs.tcd.ie> <586DC363-B5F8-4727-8734-815F3E17F345@gmail.com> <c5b37390-d463-fa35-215b-569698098d6a@cs.tcd.ie> <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com> <e29dc18a-fd5d-ca0d-90a0-4ec840678054@gmail.com> <LO2P265MB0573F23F5C23ABD3933E49FDC2040@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <LO2P265MB0573F23F5C23ABD3933E49FDC2040@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/66japvIiFyyAp1CKNeOYIgbbkbU>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 00:12:55 -0000
Andrew, inline On Tue, Oct 13, 2020 at 08:33:57PM +0000, Andrew Campling wrote: > > I think one of the challenges here is that there are no easy answers - if there were then this particular issue would not keep coming up. We have a conflict between preventing harm by "bad actors" on the one hand and protecting privacy on the other. > > In my view this is not a technical problem, but is instead a case of determining which of two sets of conflicting requirements should be prioritised. This reads to me as you proliferate what i think to be the core fallacy that the IETF: it has allowed rough consensus to be abused to prohibit work that some rough mayority does not like. In many cases because it is against their business interest, and annoyingly enough that real goal is often hidden behind a shield of "its not good for the Internet, its not good for the users". There may only be one solution for the "Internet", but there can easily be many competing and contradicting solutions for different markets. [ insert toerless again comparing TCP/IP solution with an iceberg: 10 % across the waterline is Internet, 90% invisible below the waterline are controlled networks]. TLS 1.3 is the best example. The abuse of IETF principles by its rough mayority was not the rough consensis on rfc8446, but how it was made clear that dissenting profiles, even if mean to be used only for controlled networks would not find a home in the IETF. In result we have stuff like ETSI TS 103 523-3 happening outside the IETF. If such a document would have been done inside the IETF it would have showed much better the will of the IETF to not only serve 10 % of the iceberg but also significant parts of the other 90%. Even more so, the outcome could have been technically better or at least be a lot more elaborating of the risk and possible mitigation strategies of such a "weakened" security solution. > RFC 8890 suggests that, in such circumstances, > we should try to minimize negative impact whilst also noting that when a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good trade-off. Based on the arguments made that initiated this discussion, we could conclude that the approach taken by the IETF to date appears to have harmed at least some users. Given how RFC8890 is only scoped for the Internet: What is and what is not allowed/desired on public IP networks will more and more be subject to non-IETF controlled policies. Be those of big OTT App providers with global networks or governments of any kind. The more dogmatic the IETF is about what can and what can not be branded Internet, the more the Internet will be more the Internet will shrink to that subset of operators/regions/countries that agree with those "Internet" policies. I for once am all for keeping the spirit of a clear and strict open policy for "Internet", even at the risk of shrinkage. I would like to avoid the IETF to become less relevant by excluding more and more of the demands of the non-Internet TCP/IP networks from its work scope. Especially when a lot of this non-technology-inclusiveness is not even driven from the Internet values but from business and political interest of groups inside the IETF. Cheers Toerless > The RFC also encourages stakeholder engagement. We have a clear message here from one group of stakeholders that harm is occurring and that changes are needed. It would seem reasonable to take steps to understand their case in more detail rather than just dismissing it as wrong, too difficult, badly defined or ill thought out (to be clear, I'm not suggesting that Brian has in fact done any of those things!). > > Therefore, rather than trying to debate the topic and solve it here, surely the most appropriate next step would be to seek discussion with the affected stakeholders, and possibly others to ensure a balanced view has been gained. > > > Andrew > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de
- [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Mo Balaa
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Vittorio Bertola
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Joel M. Halpern
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Guntur Wiseno Putra
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter