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

"C. M. Heard" <> Wed, 12 July 2023 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53D34C1524B2 for <>; Wed, 12 Jul 2023 10:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZSqp_DoSeBpg for <>; Wed, 12 Jul 2023 10:51:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4303C14CE3F for <>; Wed, 12 Jul 2023 10:51:03 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 766C91B5F0D for <>; Wed, 12 Jul 2023 13:51:02 -0400 (EDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed;; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=rUR5AQMCsGEpBVmkOzOsSHJ7YI8PK5uy 6JRU3Ap0KPM=; b=ZHWZtlfyao3NeRglWQoTu2MLPhDpSkHldAKgjIFeZEt4rbh0 kefDU6GreOC1ACI/5QAH/jIreQUXMJGHHPeEU8vwxYNj+mzIBBhbz4cKdL28geQw ffB3Gepf7+pzn99KTZGtS1eKGZitq4zGOWcyEEgLB3ayZj7PGhrL+lVNEo4=
Received: from (unknown []) by (Postfix) with ESMTP id 6E0AD1B5F0C for <>; Wed, 12 Jul 2023 13:51:02 -0400 (EDT) (envelope-from
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E12881B5F0B for <>; Wed, 12 Jul 2023 13:51:01 -0400 (EDT) (envelope-from
Received: by with SMTP id 2adb3069b0e04-4fba1288bbdso10926335e87.1 for <>; Wed, 12 Jul 2023 10:51:01 -0700 (PDT)
X-Gm-Message-State: ABy/qLaUIhO3wY0Y8RYRBRvkC3Dd0kvgfak/qP6YKELNWgUEG2FclDH0 dHpHnK2S268EQH1SWMtIygIqvhmAoW2cA7ueD/A=
X-Google-Smtp-Source: APBJJlHxW+Co6LTm0gPBlv4nk17X02g8hvePoOkSd7p6xe0vLIrLbe8Ev8NvTTmkmuekiq2hoSOMOhZbfIZR6udUvkw=
X-Received: by 2002:a19:7113:0:b0:4f9:567a:7a59 with SMTP id m19-20020a197113000000b004f9567a7a59mr16759658lfc.30.1689184260705; Wed, 12 Jul 2023 10:51:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "C. M. Heard" <>
Date: Wed, 12 Jul 2023 10:50:48 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Daiya Yuyama <>, Gorry Fairhurst <>
Cc: Hirochika Asai <>, TSVWG <>
Content-Type: multipart/alternative; boundary="000000000000d1d1e606004ddb39"
X-Pobox-Relay-ID: AA6E3F9C-20DC-11EE-99ED-C65BE52EC81B-06080547!
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 17:51:09 -0000

On Wed, Jul 12, 2023 at 8:42 AM Gorry Fairhurst wrote:
> On 11/07/2023 18:47, Daiya Yuyama wrote:
> > 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.
[ ... ]
> Thanks Daiya for this submission. This draft sounds like it could be
> helpful in some cases.

The intent of this option is to supplement the UDP destination port
in identifying an upper layer protocol, but I question how useful this
can actually be, given (a) that no UDP implementation is required to
process or understand UDP options at all. and (b) implementations that
do support UDP options are not required to implement any options
beyond those listed in Section 8 of draft-ietf-tsvwg-udp-options as
must-support options. Based on those considerations, it seems to me
that the UDP destination port will have to be relied upon in any case,
making it unclear what benefit the protocol number option would have.

I could be persuaded otherwise if presented with a concrete use case
where the protocol number options would actually help, even though there
is no general assurance that the receiving endpoint will understand it.

Mike Heard