[Int-area] [IntArea] FYI: [arch-d] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

Toerless Eckert <tte@cs.fau.de> Mon, 15 November 2021 17:18 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DD3A0D7C; Mon, 15 Nov 2021 09:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-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 Rg78YRJHI2C2; Mon, 15 Nov 2021 09:18:11 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 AB4493A0E96; Mon, 15 Nov 2021 09:18:07 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 3F7E0548064; Mon, 15 Nov 2021 18:18:02 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2C1C64E9DCA; Mon, 15 Nov 2021 18:18:02 +0100 (CET)
Date: Mon, 15 Nov 2021 18:18:02 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: int-area@ietf.org
Cc: draft-arkko-iab-path-signals-collaboration@ietf.org
Message-ID: <YZKWSt3EoOqUaLNT@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/SV0e6HgBX8TJRSHEZJO-M-nF_VI>
Subject: [Int-area] [IntArea] FYI: [arch-d] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 17:18:14 -0000

Dear Int Area WG.

I wanted to bring attention to subject draft which was recently posted by its IAB
authors, but only to architecture-discuss as its primary discussion list and
panrg as the current most likely research adjacency.

If we want to see work adjacent and following up from this effort, i think IntArea
is not the worst of possible WG places for that role, of course nonwithstanding
very specific protocol proposal that would have to go to a specific WG (e.g.:
type of HPv6 HBH to carry any app/network interaction if such an option was of interest).

For a good primer about onpath network / application interaction from the past, i also recommend
RFC9049, nonwithstanding that i do not agree with all it says and that it is
far from complete, not mentioning many interesting proposals made in the past in the
IETF including BOFs for SPUD/PLUS, some of which is also documented through past
IAB workshops.

So, please chime into the discusson about that work with your input, and if you
think there is any IETF followup from that work you are interested to collaborate on,
i would be happy to hear about it, and maybe int-area is a good first place to discuss.

Cheers
    Toerless

P.S.: I am ineresting in this, because I also did work on app/network interactions in the
past although primarily on shipping vendor products. Success in IETF was impossible
beack then, because when we brought out work back then to INTAREA, there was IMHO no
good balanced technical discussion, but instead the privacy argument was used overwhelmingly.
Some of the drafts from back then:

  draft-martinsen-mmusic-malice
  draft-eckert-intarea-flow-metadata-framework
  draft-zamfir-tsvwg-flow-metadata-rsvp