Re: [tsvwg] Rregarding soft-state and UDP options
"C. M. Heard" <heard@pobox.com> Sun, 05 January 2020 20:48 UTC
Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E651812004F for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 12:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 oNrE-dJFRMzW for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 12:48:55 -0800 (PST)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8173E120020 for <tsvwg@ietf.org>; Sun, 5 Jan 2020 12:48:55 -0800 (PST)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id C097B43D30 for <tsvwg@ietf.org>; Sun, 5 Jan 2020 15:48:54 -0500 (EST) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=wWSQiyBUQLqB6aytHHaQdmjIEb0=; b=SqVxai e+jYmuefMGtlweiQnlIKk1bjjfiaRifWunQrxTsvp5qIcCawmPEvQ1x5+hGO+x/0 jPZ1yfhPgl39dchjdAFOGjpRnDbENHiIuRRl0QPyiq/IUOBOgpSU2ejvLY3O0pA7 0SfSLNtpug4w20nVxOK0k0nPsVi1TkW6bWr8A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=vZ4BtcotTFTg5rDrsKWdZ34dkTzVZyz+ vDfihp6WG4RFFX9GIFq9ChCGKbAXnyWEx70mSOTsUMlZQuU8rGtEXE6OwV6g+/b1 jxkR2WDAQRSQbNhlA5AjfyREmkJ6pkBxtM0aIpLlL70IVrnpNzHkU6OOeZjQz479 9Kz6up6bi50=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A9EEE43D2E for <tsvwg@ietf.org>; Sun, 5 Jan 2020 15:48:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: from mail-io1-f42.google.com (unknown [209.85.166.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 12C8543D2C for <tsvwg@ietf.org>; Sun, 5 Jan 2020 15:48:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: by mail-io1-f42.google.com with SMTP id c16so16816395ioh.6 for <tsvwg@ietf.org>; Sun, 05 Jan 2020 12:48:54 -0800 (PST)
X-Gm-Message-State: APjAAAXcZB4erYwZwdbdu7VvkFMXUxpD6PpTMBL4ivzLVgCMCfOI6rsv HNT6E+rWYQYWrBaR5VdOJ+fuflJFGlyfm+VtM24=
X-Google-Smtp-Source: APXvYqwSmk3ofeFZwnR48mtdzxPD8zY8bG1t0ObMgOgFuyfQEk3EFfKYUtKSV8PSxm6BwEhyvVjCv6l6uEYT+hPTaUM=
X-Received: by 2002:a6b:d20c:: with SMTP id q12mr64408283iob.143.1578257333555; Sun, 05 Jan 2020 12:48:53 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S36227JnMkaZtPUvJoY5Pw-rQgy2R6tqt1PF_L=bgCjxCA@mail.gmail.com> <85C8C994-3FEA-4DF4-8C46-75CB205D09EA@strayalpha.com> <CALx6S34EfhcthoG4Qtr0JtfsdqQPr-2=havTvq_7nh9K8XDhJA@mail.gmail.com> <5E21B9BD-3148-43C9-BCB8-E6F5DFCE69C3@strayalpha.com>
In-Reply-To: <5E21B9BD-3148-43C9-BCB8-E6F5DFCE69C3@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 05 Jan 2020 12:48:40 -0800
X-Gmail-Original-Message-ID: <CACL_3VHOuzc9nCtac6_-NpoJnLr=PSS3wE2SzGUsEVNA9qyN8A@mail.gmail.com>
Message-ID: <CACL_3VHOuzc9nCtac6_-NpoJnLr=PSS3wE2SzGUsEVNA9qyN8A@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Tom Herbert <tom@herbertland.com>, TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb1a4f059b6aab74"
X-Pobox-Relay-ID: C9225FB0-2FFC-11EA-914C-D1361DBA3BAF-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Jf31X-sbFA1ys09El57xP9LB2uU>
Subject: Re: [tsvwg] Rregarding soft-state and UDP options
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jan 2020 20:48:58 -0000
On Fri, Jan 3, 2020 at 8:36 PM Joe Touch <touch@strayalpha.com> wrote: > Lost in this discussion has been an example to motivate the need for “drop > if not supported”. > [ ... ] > Right now, until there is consensus otherwise, there isn’t justification > to waste half the code point space on hypotheticals. However, there’s no > reason not to assign ONE code point for such use, e.g., as follows: > > option 253 — defined as a prefix to “required options” code > points, the next byte defines that code point > (these would be assigned as needed and have no relation to the UDP > option code point values) > > That way there’s support for the *remote* possibility that this feature > can be useful without wasting space needlessly - and, as importantly, > avoiding the impression that “flipping a bit” can change any option from > “optional” to “required”. > 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". 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. 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. Thanks, Mike Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- [tsvwg] Comments on ietf-106-tsvwg-udp-options C. M. Heard
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options Joe Touch
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options C. M. Heard
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options Tom Herbert
- [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert