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