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

Toerless Eckert <tte@cs.fau.de> Wed, 08 April 2020 19:42 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 A0EF23A0C8E for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Apr 2020 12:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level:
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 QSL1VWE2VeTQ for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Apr 2020 12:42:00 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EA23A0B7D for <architecture-discuss@ietf.org>; Wed, 8 Apr 2020 12:41:59 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 52B6E548015; Wed, 8 Apr 2020 21:41:54 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 49D13440040; Wed, 8 Apr 2020 21:41:54 +0200 (CEST)
Date: Wed, 08 Apr 2020 21:41:54 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, architecture-discuss@ietf.org
Message-ID: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de>
References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/F05SPlE0WrC-_lce_iD_AlWlv44>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
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, 08 Apr 2020 19:42:03 -0000

On Wed, Apr 08, 2020 at 08:57:02PM +0200, Carsten Bormann wrote:
> Hi Stephane,
> 
> > On 2020-04-08, at 07:42, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> > 
> >> 
> >> ??? and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of
> >> 
> >> https://datatracker.ietf.org/liaison/1677/
> > 
> > It seems that IETF's answer is about another project, by ITU.
> 
> Yes.  I do know about the difference between ETSI and ITU-T.
> But the technical content (that I could find) was, at first look, indistinguishable to me; Alissa???s text can be used right away as a reply to this press release.

>From Alissa's statement:
"The IETF maintains copyright and change control for the IP specifications..."

That fact is AFAIK the reason why ETSI choose expicitly call their
effort "Non IP", even if it might come up with proposals that for
reasons of global adoption might better be done within the IETF.
That and the probably more limited scope of networks considered
is probably the key difference to ITU-T goals.

Alissas liaison statement goes on to give IMHO a correct but ineffective
explanation how contributors from other SDOs can come to IETF.

Given how this is a leadership-to-leadership exchange,
i would be surprised if any relevant amount of ITU contributors
would even be made aware of Alissas text explicitly and officially
by ITU. Which is IMHO the same on the reverse side. When would have
IETF leadership ever have tried to explain/help IETF attendants to
do better work in another SDO ? Which meeting did i miss about this ?
Maybe with the small exception of RTCweb and W3C (or maybe even more
 in APP, i am not that much involved there).

IMHO, IETF leadership would be well helping IETF by figuring out a
better outreach method to other SDO than such liaison statements. 
But of course there is the main issues of SDOs first trying to
fight for their own survival and relevance.

> There has been a decade of ???clean slate Internet??? discussion, and only ICN emerged as an interesting new architecture from that context.  So I???m not very optimistic with any process that tries to relive that process.  But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time.

Flying cars give 3 dimensions of social distancing.
Obvious Covid-19 solution.

Our IETF issue to make more progress than we do is IMHO
rooted that we conflate everything into one concept "Internet".
In reality, "Internet" is one instance of an overlay
"Internetwork Layer" running on at least one or more interconnected
"Network Layers", such as formed by IP/MPLS or IPv4/IPv6 or SRv6.
And then we apply one architecture (RFC8200) to the often
contradictory requirements of Internetwork and 
Network layers and wonder why we have problems.

If we would at least acknowledge this architecture
and fundamental difference in requirements, it would be a lot
easier not only for IETF to make progress, but also for
more specialized SDOs to propose enhancements for the
Network Layer in networks they are interested in
(5G) and i think they would have a lot more interest to fit
their work into an IETF lead overall Internetwork Layer 
+ Network Layer(s) architecture. 

I think IETF is just going through puberty, having to evolve
from reactive to proactive:

When technologies are young, you just let engineers
innovate and implement and when everything is done, you
can go and fight for it to get standardized. When an
industries becomes more mature and a lot more capital
investment heavy, you need to revert this and SDOs
need to play a lot more proactive role in defining
next-gen solutions. See 3GPP. IETF is not doing this
at the architecture scale. Only at small incremental
enhancements.

Cheers
    Toerless

> Grüße, Carsten
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss