IETF Logo Mail Archive

Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

"C. M. Heard" <heard@pobox.com> Fri, 19 July 2019 03:30 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 E6EED120127 for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 20:30:24 -0700 (PDT)
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 Tk23h2WKpFIZ for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 20:30:23 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96F1120043 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 20:30:23 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 5D52C754DA for <tsvwg@ietf.org>; Thu, 18 Jul 2019 23:30:23 -0400 (EDT) (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=4TUpI34RKyP1mrGTsLW+c0SKfYc=; b=Q3aYGV wv52PaB09/R0LVjlKqZR73p4ExipwNBHGojJCJ2uzMD1uOZJW3SYEKe6CkndiH1O g4JkXXvu2A4fHjeXgvzYFL1Qf2X4DTSWY/5MGKHFQfXE7d53xoMz8LGuz3nmMmjx e0N6vRNCJXY5Wq2oxByd5whjI/JUYTouCqKPs=
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=WgKxry6oSNhyr36hWxLZbr0icDQTId1q cacRrA6PXbPGyzOaYpCY8wKwXUpWMhdAbfyo4RbsocSHz7ZIS8evPQzYrTK1Bmls xAryTHNEAnB49GBVwCzQ6+aAFrlPKdvcYhVlv2pYNS40JUTQAgH0T6oDdpBBUzMX f93yTFraVaY=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 55F69754D9 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 23:30:23 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-io1-f41.google.com (unknown [209.85.166.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id D9ED6754D2 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 23:30:19 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-io1-f41.google.com with SMTP id g20so55487155ioc.12 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 20:30:19 -0700 (PDT)
X-Gm-Message-State: APjAAAWCp/Uk4BbmznS6toCkq72vQv8ltEspEBuicunNGOZADQfzyy+d GnzU8ocDnxdJGZhnsJKAau5qdNy1KAlFudYgIl8=
X-Google-Smtp-Source: APXvYqyeN4DMk/Fw44iMskDsrHjvIKgD4w2KncFCXdrU9cbzGUz6cVXceW7lzYS4wzAbX0+P8CkGG96tipZKeigT0S0=
X-Received: by 2002:a02:c492:: with SMTP id t18mr52950507jam.67.1563507018695; Thu, 18 Jul 2019 20:30:18 -0700 (PDT)
MIME-Version: 1.0
References: <30c17e9c174f6b0da3ecc6b503a8cb17@strayalpha.com> <2f71a292f924a9b8de4227c4bbc2f809@strayalpha.com> <CACL_3VGrF5UnbVsSzZZoy1i57WKiQKBX2T3a16UyEVHY=Kr3XA@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363061EF7A@MX307CL04.corp.emc.com> <CACL_3VE7+3WD3Uzubf8X9uQX9ZYPnZVhXjheUOuL9EfjT1JkGQ@mail.gmail.com> <CALx6S35V-d3Rn_wjrhbHUHgS=_+dVjR4hbMJ0-JBsG-1BuFuZg@mail.gmail.com> <B5CCEF58-38CE-4973-9CFD-002B404E4EF3@strayalpha.com> <CACL_3VEnJoV9N9i59fJXG1Nyt=mMWT7SuB8B=C-Y9a9QLtqP7Q@mail.gmail.com> <BB3FD9A5-8D30-4600-A7A7-DA3030BD34A3@strayalpha.com> <20190718100109.GA86292@clarinet.employees.org> <718EBD34-5B4A-4458-B9B4-0A94C33E019E@strayalpha.com> <CACL_3VGL2irCkZeEcP+9HLBHqtqaMPZM66youUsatzosUu=Aew@mail.gmail.com> <A07EA390-1A3A-4AE9-AFD7-2F22CD4B0E31@strayalpha.com> <CALx6S34oOza3Z4Ymjsp+HLXnSTOKwh+SAQO8mt=a-1AbTTB0GQ@mail.gmail.com> <177233bb33272ce3b64298a005254724@strayalpha.com> <CALx6S36ZBa4Bioj=0KYn7wcFi08VeAg8sHUHLRNGURsrUN673w@mail.gmail.com> <5D30B36D.80409@erg.abdn.ac.uk> <CALx6S37EauLMyeksHJ3iPNjKwLTv5qti_Hf0a2QTdzZoDrarrw@mail.gmail.com> <F1092EE4-16DC-4292-903E-F54A447E6A8D@strayalpha.com> <CALx6S340gCTQiA85iVXwnbA8nU8=nvWnGq7q3jzuG7SuVHv=ag@mail.gmail.com> <DE387BB9-BA9D-447E-9767-FD0428B7F1D7@strayalpha.com>
In-Reply-To: <DE387BB9-BA9D-447E-9767-FD0428B7F1D7@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 18 Jul 2019 20:30:06 -0700
X-Gmail-Original-Message-ID: <CACL_3VHGub1ZkDEKCcT-RU6WiO-Us9XzxHno+hRgDq_h5qZudw@mail.gmail.com>
Message-ID: <CACL_3VHGub1ZkDEKCcT-RU6WiO-Us9XzxHno+hRgDq_h5qZudw@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Tom Herbert <tom@herbertland.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000740a0e058e00582d"
X-Pobox-Relay-ID: 88C17E72-A9D5-11E9-8773-B0405B776F7B-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mc22LQX77U7VORVB_kV4REY5_6g>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
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: Fri, 19 Jul 2019 03:30:25 -0000

Joe, I'm sorry, but I am having a really, really, hard time understanding
why you are pushing back so hard on this.

On Thu, Jul 18, 2019 at 8:03 PM Joe Touch wrote:

> So basically “drop if not supported” has no meaning ALREADY for legacy
>
receivers.
>

A bit encoding "drop if not supported" is not there for the benefit of
legacy receivers.

It's there to make it possible to add future "unsafe to ignore" options
without messing
up option-aware receivers that don't understand the new option.


> Anything further - deeper, or involving state - can still be performed by
> the
>
receiver, at the receiver’s decision already anyway.
>

How is the receiver supposed to make that determination?

And how hard is a totally stateless ignore/discard bit?

Mike Heard

v2.23.0 | Report a Bug | By Email