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

[Toerless Eckert <[e-mail]>]

Thanks for the discussion points, Lars,
inline.

On Thu, Apr 09, 2020 at 04:51:16PM +0300, Lars Eggert wrote:
> Hi,
> 
> On 2020-4-9, at 15:19, Toerless Eckert <[e-mail]> wrote:
> > On Thu, Apr 09, 2020 at 12:14:04PM +0300, Lars Eggert wrote:
> >> On 2020-4-8, at 22:41, Toerless Eckert <[e-mail]> wrote:
> >>> 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.
> >> 
> >> if this is what you belief needs to happen, please do take this work to the ITU-T.
> > 
> > Just making sure i understand your statement correctly:
> > 
> > You only want for IAB and IETF to continue do only small
> > incremental enhancements ?
> 
> You seem to think small, incremental enhancements are somehow
a bad thing. We're disagreeing on that.

I am surprised to read that because that is not what i
wrote and not what i think. I fear that maybe other people
too are interpreting too much and wrong things into the
whole excurse with ITU-T.

I said "only":

Incremental improvements are are absolutely essential.
They are just not sufficient anymore IMHO for specific
topics.

> We've managed to evolve the Internet and its architecture
> pretty well through a series of small, incremental
> enhancements at all layers. I don't see why continuing
> on this path is such a bad thing.

Yes, and 30 years ago we made a mayor new step (IPNG -> IPv6)
and learned a lot through it.

After > 25 years of IPv6 we do not even seem to welcome a
broader discussion how well or how-not-well-enough that
step and its evolution since then has been. Or thinking
about the benefits that even thinking about another
IPNG step could have. Without saying that the result
couldn't even be just a set of incremental enhancements
(which mfor example could be expanding beyond RFC8200).

Btw: stackevo does have a nice set of analysis of
subsets of what we learned. Alas, the whole problem
of evolving transport stack functions started with SPUD
was not really followed up on.

> You seem to want to do some large-scale,
> monolithically-designed "v2" architecture thing.

I never said this, and i don't want that. I am not
sure i would read from the ITU-T(TSAG) statements
a monolithical-designed v2, but i understand how
that claim was made. I already said that i and
my team where not involved in that but that our
undersstanding of problems is in our gap draft
and that we have not published specific architecture
propsals beyond what you can glean from that draft.

> This is not what the IETF does.

I am not even sure what a good definition of
monolythic architecture would be, but obviously one
doesn't want to throw out the baby with the bathwater,
and if we're talking about modularity, i think we
rather need more than less. Aka: reusing CBOR
as a common presentation layer like ancoding instead
of monolytic one-off TLV definitions, or equally
(my pet peeve) reused transport protocol components
(such as SPUD) instead of every protocol (like QUIC)
reinventing the whole wheel). Just examples.

> Hence, my suggestion is you try and do the work in
> a forum that likes to work that way, and see if you
> manage to get anyone to deploy the outcome in the end.

Oh, i did work in such a forum. Its called a big vendor
inventing new stuff, getting it deployed and then
going to the IETF and attempting to get it standardized.

When today most routers are becoming white box vendors,
the opportunity to do innovation that way in that
space is just going to shift quite a bit.

> > Btw: I do not need to take any work to ITU-T or 3GPP.
> > These SDOs will move forward with whatever they want to
> > do without consulting IETF.
> 
> Great. I guess we can then stop this discussion on am IETF list.

Well.. "this" thread was already "derailed" by Carsten
with an ITU-T mentioning, even though it says "ETSI".
(not a complaint...)

I am indeed happy if we do not need to continue to
 discuss ITU-T/TSAG statments, but as long as there is the
presumption that that ITU-T/TSAG statement is
about what i and my colleagues are talking about,
i am very happy that you give me the opportunity
to clear up that misperception and confusion in threads like this.

Thanks again
    Toerless

> Lars