IETF Logo Mail Archive

Re: What is the long term plan for Internet evolution?

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 30 June 2021 02:14 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D363A128E for <ietf@ietfa.amsl.com>; Tue, 29 Jun 2021 19:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 fnblBhUJ5wAk for <ietf@ietfa.amsl.com>; Tue, 29 Jun 2021 19:14:22 -0700 (PDT)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513393A128C for <ietf@ietf.org>; Tue, 29 Jun 2021 19:14:22 -0700 (PDT)
Received: by mail-yb1-f169.google.com with SMTP id i18so2287453yba.13 for <ietf@ietf.org>; Tue, 29 Jun 2021 19:14:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PqzgfonwLiNYRY6DXrgsrLTQmS5yKfd3j64R2nK7VTI=; b=aUbre4l8r/TL74Ww27sfiZsOzyjtrl3xp2HRrbWVWhPfSRnNmi132iM7sSg/G3XSfh 8MQE/wGXThumq19pPg5TdCQKsGnNAkFYUxFSkcKbxxt0sF6T76tRnL57EFLlebsM4cAO E44oueG6YVNJKNmVtNkTi5B52YAKGXWi6KBJ8vd0Inh89fm1mgkOwUQomSHtlpSQrp73 8+oVLahGsi7nRzPk7OrYPki2pG7X5RB2JbJMb9tKTRT5567HvZaNvKVfEplwN+ekyHQh Mohu7+WVaiq/j/aoMZXGM+lQdfGWeG8tTJCdtgb3oNQajQmhCliwMPkNgbJj+AwQ5OfY 6Jtg==
X-Gm-Message-State: AOAM533yWPC5HQWZKtSt7IQxs7NcoWi91nfjzcLTfaKnpfhytaZd3IBn pQvqTunWEKhA/sbvMQ9Evg2yNb32HtnnDeU1C3k=
X-Google-Smtp-Source: ABdhPJzDv+TzLwGKwSKmDimRrVboNrOqLol0EbStUZNNnpPEE4qyQUbAsQihO0S5xZ/yhe4JqMThCLS4H2RlKcG5V5E=
X-Received: by 2002:a25:f0b:: with SMTP id 11mr27070756ybp.518.1625019259928; Tue, 29 Jun 2021 19:14:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwiFajxuV3E_u7b-f=7DqTHXG_4Y=VLoCsUxknD_mCp1=Q@mail.gmail.com> <00722e06-a385-251c-d95d-2ff67e83f5c1@foobar.org> <CAMm+LwgwwX4zhqqH27FtBEyKRn74BdunswpembR_O6R34vTuSA@mail.gmail.com> <16008.1625010713@localhost> <0100017a5a6c13e7-53cfcee8-b8dd-45b1-9a26-f30f497db3a9-000000@email.amazonses.com>
In-Reply-To: <0100017a5a6c13e7-53cfcee8-b8dd-45b1-9a26-f30f497db3a9-000000@email.amazonses.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 29 Jun 2021 22:14:09 -0400
Message-ID: <CAMm+Lwi25EhWGo-ZdcW+B2wF9fSD94+qMQXi8aUuGYJWfT7ueg@mail.gmail.com>
Subject: Re: What is the long term plan for Internet evolution?
To: Kent Watsen <kent@watsen.net>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bdc67605c5f24705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BRadv8LtCp64ebRVrhdyLFK_-Jk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2021 02:14:28 -0000

And I am sure this has been re-invented multiple times over.

On Tue, Jun 29, 2021 at 8:57 PM Kent Watsen <kent@watsen.net> wrote:

> NETCONF Subscribed Notifications (RFC 8639) over HTTP/2 also does this.
>
> K.
>
>
> > On Jun 29, 2021, at 7:51 PM, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> >
> >
> > Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> >> That is what a transaction is, right. Nope. Many of my transactions have
> >> people in the middle of them making decisions or big compute loads. So
> in
> >> the HTTP world we end up with
> >
> >> < C:Request, S:Ack, [C:Poll, S:Pending,] * C:Poll, S: Response>
> >
> >> That is plain ugly. The pattern I really want is:
> >
> >> < C:Request, S:Ack, S: Response>
> >
> >> There is no need to poll, just respond when finished. That might be
> >> seconds, minutes, days or even years.
> >
> > CoAP supports this.
> >
> >> For telemetry, the pattern I want is
> >
> >> < C:Config, S:Data, S:Data, S:Data, S:Data, S:Data, C:Config, S:Data,
> >> S:Data, ...>
> >
> >> Again, this just doesn't fit onto the TCP or HTTP communication patterns
> >> and it is not really something QUIC is designed for. Sure we could make
> do.
> >> But I choose not to.
> >
> > CoAP Observe does this.
> > CoAP works better without NAT because the NAT closes the subsequent
> S:Data in
> > many cases.
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
> >
>
>

v2.23.0 | Report a Bug | By Email