Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt

"" <> Wed, 12 July 2023 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B35BC1522AB for <>; Wed, 12 Jul 2023 13:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVlP2adtzY-f for <>; Wed, 12 Jul 2023 13:43:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A25CC151066 for <>; Wed, 12 Jul 2023 13:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mFHl9uQLddYB/evj0QjLZivoGnhywwlT84idOLcQHiA=; b=Brhd8v6+AQWm91YTPVOB+Goe3G MxsYYLRVmHCzJcnu8S35RGKSjo4nn3xfkH91mVU/tC0/lGQQVndwNL8zjXiRjZm/s48Juox9kaBfC kKsq7unWpFwXGCZm8kFNIQU0yFhA2uHS55SZqo66ODh4/YlIHaqK58okuzqJUwQ329K06gJOEEpkq WESfhnqzQ3W+YDT15fhpbsE+nKfKlDdHfCXqVqfajZhyFYkGF17zbSAN+FSvKSSpSRPKC1ZTB9Moc HvVPgqu7nktuDaF3eRxMFXUnUs43pDSPk3OEgCNhRl6Uc3ASkTt+QfnnEHrQ8P1OvwibVCiAffjQV fGNkuSoA==;
Received: from [] (port=1593 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1qJgfl-00Avyv-2C; Wed, 12 Jul 2023 16:42:58 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_1060A18E-CB11-468A-8E51-C908152F1A9D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "" <>
In-Reply-To: <>
Date: Wed, 12 Jul 2023 13:42:41 -0700
Cc: TSVWG <>, Hirochika Asai <>
Message-Id: <>
References: <> <>
To: Daiya Yuyama <>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jul 2023 20:43:04 -0000

Hi, all,

Although this seems of some possible use at some point, it seems like it might be supported by an ExID for now.

Note that it’s also not all that different from the SNO option that has an ExID already for TCP (and there’s no reason ExIDs need to be newly allocated for UDP; they could be reused). E.g.:

The primary purpose of SNO was to decouple the service info from the destination port semantics. This proposal tries to decouple things even further, saying that the port semantics are defined one layer at a time. Although we can start that at UDP (or TCP) with things like SNO, there’s no mechanism I know of to continue that demuxing within other layers, e.g., TLS/DTLS, etc.

Overall, seems like what you want is TAPS but encoded at each protocol layer - how do we get this to work beyond just UDP?


Dr. Joe Touch, temporal epistemologist

> On Jul 11, 2023, at 10:47 AM, Daiya Yuyama <> wrote:
> Dear all
> We have submitted a draft that defines the protocol number option in UDP options. The protocol number option specifies the protocol immediately following the UDP header.
> Currently, the only information about the packet encapsulated in UDP is the port number corresponding to the service. In addition, UDP-based protocols such as QUIC are increasingly used as transport for applications.
> When using such protocols, it is not possible to provide the UDP layer with information about the transport layer protocol that follows the UDP header. The protocol number option provides this information.
> We believe this option would be beneficial for extending the transport protocol with UDP.
> If you are interested in it or have any comments, I really appreciate your feedback or comments.
> Thank you.
> Daiya
> On 2023/07/11 8:43, wrote:
>> A new version of I-D, draft-daiya-tsvwg-udp-options-protocol-number-00.txt
>> has been successfully submitted by Daiya Yuyama and posted to the
>> IETF repository.
>> Name:		draft-daiya-tsvwg-udp-options-protocol-number
>> Revision:	00
>> Title:		Protocol Number Option in UDP Options
>> Document date:	2023-07-10
>> Group:		Individual Submission
>> Pages:		6
>> URL:  
>> Status:
>> Html: 
>> Htmlized:
>> Abstract:
>>    This document defines the protocol number option in UDP options.  The
>>    protocol number option specifies the protocol immediately following
>>    the UDP header.
>>                                                                                   The IETF Secretariat