Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

John C Klensin <> Mon, 13 April 2020 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55F83A1C2F for <>; Mon, 13 Apr 2020 11:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KLlpRJFvkiEB for <>; Mon, 13 Apr 2020 11:56:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A5983A1C2E for <>; Mon, 13 Apr 2020 11:56:40 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jO4G4-0003hj-Kr; Mon, 13 Apr 2020 14:56:36 -0400
Date: Mon, 13 Apr 2020 14:56:30 -0400
From: John C Klensin <>
To: Christian Huitema <>, Brian E Carpenter <>
Message-ID: <E029AEC023B1A60E3E956641@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
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, 13 Apr 2020 18:56:42 -0000

--On Friday, April 10, 2020 17:22 -0700 Christian Huitema
<> wrote:

> On 4/9/2020 2:08 PM, Brian E Carpenter wrote:
>> Actually, I disagree. IPv6 is a very conservative design that
>> had exactly no effect on fundamentals. That was intentional.
>> Remember TUBA (TCP and UDP over Bigger Addresses)? That's
>> what we did, with the tiny detail of using homebrew IPv6
>> instead of ISO8473. What we learned is that even a minor step
>> like bigger addresses is expensive *because of the even more
>> tiny details* like the socket API, router CLI commands, and
>> the address configuration mechanism.
>> The major lower-layer atchitecture change in the last 30 years
>> was completely unplanned: middleboxes.
> The post-2013 general deployment of encryption is a pretty big
> change too. It was only partially planned. And if QUIC comes
> to displace TCP, that too would be a significant change.

It may also be worth noting that a, perhaps the, major add-on
change in IPv6 --much touted in its early days-- was supposed to
be ubiquitous lP-level encryption.  That post-2013 encryption
deployment, at least AFAICT, relies on methods much closer to
the applications layer, sometimes ones that are at least
partially specific to particular applications and applications
protocols.  If there is a message in those things, I think it is
either that we are not good at predicting which of our
innovations will be successful and which will not or that, when
the IETF says "go forth and do X", thee are no guarantees that
the world will listen.

And I expect it will be some years more before we actually know
whether our more recent push toward encryption has helped the
Internet and its users by increasing privacy or whether pushback
and reactions from the political and law enforcement sectors
ultimately result in fragmentation, large-scale interconnection
problems, and the either development of a lot of ad hoc
solutions or movement of work to other SDOs because the IETF was
too stuck on the importance of encryption no matter what.   I
don't predict that outcome and definitely don't wish for it, but
I think our architectural work would be improved by more
recognition of the possibility.