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

S Moonesamy <> Fri, 17 April 2020 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56EA93A094B for <>; Fri, 17 Apr 2020 16:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kMWmnclUd3C8 for <>; Fri, 17 Apr 2020 16:02:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 30EB83A0949 for <>; Fri, 17 Apr 2020 16:02:36 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.15.2/8.14.5) with ESMTPSA id 03HN1xD0009198 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2020 16:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1587164533; x=1587250933;; bh=26K7AW3BY4TYvVubThsIY8VYwUhBB2P3ijhH1uV8rfs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rl3nWRapxlzj7GtS5/oiGgwreVnPTdwOrj0muEejOxPNHHr5CDhz4A5hy5leMcYfW xGquXxyYi3YfQbzGJldP+gvB3MW5bXa9rpVcWMjngRJ9IsxhV4xl6H3X2E0CDBc8Uq ZtpJHNebV5aYWu2fpKSU3qZoZptF0SuNISOFIo24=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 17 Apr 2020 15:51:04 -0700
To: Toerless Eckert <>,
From: S Moonesamy <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <E029AEC023B1A60E3E956641@PSB> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: Fri, 17 Apr 2020 23:02:49 -0000

Hi Toerless,
At 09:27 AM 17-04-2020, Toerless Eckert wrote:
>Hahaha. Am i assuming correctly that "central planning department" is
>intentionally written to sound dismissive, or am i just reading
>that into your text ?

The point was to convey that such an approach in another context was 
not successful.

>We do have an official IETF photographer. Why can't we have an official
>IETF cartoonist ? I would love to see a rendering of the "central planning
>department of the IETF". Also the whole discussion about IETF photography,
>badges and datatracker mugshots  would take a real interesting turn if we
>changed over to cartoons.

That is a discussion for ietf@. :-)

>Kidding aside: i think we need to be careful in not discouraging
>innovation when it is ambitious. The sole reason why the IETF exists is to
>create innovation that depends on multiple parties to become active.
>And the primary place where IPsec IMHO failed to gain adoption is on
>those parts IETF continues not to want to work in: host-stacks, APIs,
>(policy) etc..

The innovation happens when the specification is implemented and 
widely deployed.  For what it is worth, there was some effort to 
assess that.  I don't remember what happened to it.

>The reference seems to be more about depressing language barriers than
>technical aspects. But sure, the London led collonialization of
>the finance industry of this planet is coming to an end (sob ? hurray ? ;-)

The acronym is from Jane Gardam's novel:

>I have only seen few bits and pieces about those IETF outreach programs,
>but it was all from people i respect and activites i felt where useful,
>so i have no example data points to be cynical about.


>In India, subsistence farmers get updates of different city market prices
>realtime via SMS on their cell phones so they know where to sell 
>their produce.
>In Germany, Corona case tracking is delayed for days through a multi-stage
>series or FAX between different bureaucracies that manually process and
>propagate information.
>Maybe IPv6 was specifically architected not to be too much better
>than IPv4 to ensure that developing countries that can skip IPv4
>and start with simple IPv6 greenfields can not leap ahead of
>"developed" nations with all their historic IPv4 baggage too much.

I am not trying to be dismissive.  I heard the greenfield argument 
being made around a decade ago.

Around two years' ago, I had an interesting discussion with some 
younger persons in the region about "why don't we use IPv6 to solve 
the problem".  As someone from the Internet Corporation of Assigned 
Names and Numbers discussed the topic with me a day earlier, I asked 
the person to explain the issues to them.  I left it to the younger 
persons to draw their own conclusions.

S. Moonesamy