Re: [tsvwg] Rregarding soft-state and UDP options

Joe Touch <> Sun, 05 January 2020 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF47A120033 for <>; Sun, 5 Jan 2020 12:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 L1m7Swxb1tcW for <>; Sun, 5 Jan 2020 12:58:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DBE3120020 for <>; Sun, 5 Jan 2020 12:58:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=RaON6cD8K4zNOrijmpuKCHsLEQ4hqwBT81QaNkuRago=; b=HeSybFWaApMnmd45z5b9qfKWJ 6LDeFrhmw5bOEoUAa+IdV/tfCAGuJ6U3RNapkH+djPt7cZBOkFn20CdMBzUwAt6mM607rBpdQbV67 atBvtGscy5A/llegobvHhDl5gcKc4iTMdPe3VuzQO0YKRx/bzWCSuUE6YRsDsqd+XVs9OZ8wnOqEm zYLzwbKZ5lmVu+Acwwo3KehVvR2oymFw1XyuNjWP1ZLFmfiw8BX+uAFo84Grn1Oi1dNLqgSwf/el8 0F/U+4u8b53jZ8Cb6dpymO/O84aAE182AP0DuJwUSQgRpR2wvJVVbOe3O0tQu+tGi6MvL+rCDeImA ejbLdETzA==;
Received: from ([]:50879 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1ioCym-003c0W-0o; Sun, 05 Jan 2020 15:58:36 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sun, 05 Jan 2020 12:58:31 -0800
Cc: Tom Herbert <>, TSVWG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: "C. M. Heard" <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-1.0
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] Rregarding soft-state and UDP options
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jan 2020 20:58:39 -0000

> On Jan 5, 2020, at 12:48 PM, C. M. Heard <> wrote:
> In an earlier quick read I missed this proposal. My apologies for not reading the message carefully and thereby adding unnecessary noise to this discussion.
> Under the assumption that implementations of UDP options will be required to ***recognize*** (but not necessarily to implement) all of the options defined in the initial version of the specification, this proposal will accomplish the goal that I had in mind when I proposed to subdivide the Option Kind space into two ranges, one for options that do not affect the handling of user data ("this option is safe to ignore") and another for options that do affect the handling of user data. ("this option is not safe to ignore").
> I would suggest that the semantics of the prefix should be "if you don't recognize the following option, don't deliver the accompanying payload data to the user".

As I just posted, at best it would mean “if the following option is not recognized, drop all options”. It should never mean anything else.

Any application that cannot tolerate zero-length messages should never use those options. Any app that handles zero-length options should then work on hosts that support or do not support options that way.

> I'm open to discussion as to whether a socket read should signal a zero-length datagram and whether delivery of other options in the packet should be suppressed

Now you’re getting into issues we cannot; it’s all or nothing:

- all options in the regular space MUST individually be ignored if not supported
- options in the 253-codepoint space would then cause the options - as a whole - to be dropped
	if you just wanted the option to be dropped, then the regular code point space would have been sufficient

Again, we cannot cause the PACKET to be dropped. If the packet contains regular data, it MUST be delivered to the application.

It is up to the receiving application to decide what to do. A receiving app that wants to enforce authentication would drop the packet THEN. UDP cannot.

> I'll note in passing that the prefix could appear in front of the experimental option code point in order to indicate an experimental option that is not safe to ignore.

As noted in the proposal, this would a a *separate* code point space, but agreed, there would be an experimental value there too.