IETF Logo Mail Archive

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

Tom Herbert <tom@herbertland.com> Thu, 18 July 2019 21:00 UTC

Return-Path: <tom@herbertland.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 99292120B60 for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 14:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 i9GvQorJcMXh for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 14:00:35 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882441208B2 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 14:00:35 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id p15so32081342eds.8 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 14:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fdPduUjFSD+sif35QT48c/25O7wmFh1ehkgHsWAnKyA=; b=m/a67kSWiZgwZDdQZaqmBNd2/rVVSGMGjkQ8ll1ffQcWCbqVweidUWpMzSL5TZOgw3 A3OmAEE5USXYE8DHn3oWvRrP6PV9lBdH4JlU1z3z8+MLjG39IYWiJ6PZ6GiO6RcZc650 XUvsL6pRc7qsSRerFUqa8i7gZXGIojVjfe+fk8iYLKiXjiszzsngxgfdZc3Dpgu0CSD9 9UDKH6srGD6GiqATFvwtHBXlI2AJJffHxaGft525umF1SNZNgtlfQ9dnwQaqjb/mOb99 H3ryP/B7sy0C5obNMYUs2dFAP5oiTPBkOE4ypQjLJO+USw//bdlWXc+5XzitYKkFrlR+ Hzpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fdPduUjFSD+sif35QT48c/25O7wmFh1ehkgHsWAnKyA=; b=PgpW9xU7AcaSQ3mHq5E5J1zOuAqZMB9gH+B4/XgOWhcox7gqboxX+Q14wgYbaTdz9x h2vZMi2JyxPLVj9qc4OcAi73UVS6uSfNQ3Wjvh4xV9O1y3ldcQEOSG6/K/qgrHzGQTWj /E1JJk1++uFtpwIAtHYO9T+SGZHG9LQNw6po42hJzgC8cFKENfoXv4kcWj70y+lvAZ8X 4ofCEtfpOkARBLibk2UY+gJJzrjjA8RXpKwQIp9W45TNCA2wfEz/hrqZDOXxI2lhqtUd WxvvHQlIMXnZjHqrYiJlGaiFOdKHhIYJM/zVkqt7J+YbsvOIS78MJp11cl4rhSi0nJPq 2p0g==
X-Gm-Message-State: APjAAAXx82X+rYS3fK166aRRBhlFa1hz0XeVtThCj/XBhulU5xj17k/O hCnJprkGRs6sfiCpOqY1VvJC3FRgC9Xa5CI3tcw=
X-Google-Smtp-Source: APXvYqzMEGyDf30PlHUbPuWiV1/3fJAlnhu1Tx4EM6lSEFDea9HAslPU24zXTaUbbh3myCi8HuPgR/z7A9tXf14YAdA=
X-Received: by 2002:a17:906:229b:: with SMTP id p27mr35316946eja.266.1563483633981; Thu, 18 Jul 2019 14:00:33 -0700 (PDT)
MIME-Version: 1.0
References: <30c17e9c174f6b0da3ecc6b503a8cb17@strayalpha.com> <CACL_3VGs7j+y5vFNT3OL9OKX8ue4rv-Cxi467KR-vbhnMdx86g@mail.gmail.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> <07A2D215-6B97-4DD6-86EB-44960C1844A5@strayalpha.com> <CALx6S355=vvk1GNe959UfOnERJS6qVE19Xhes78=GHug-KpZFg@mail.gmail.com> <FB5CB7F4-C6E4-4E7A-BA3C-48F3B190D58E@strayalpha.com>
In-Reply-To: <FB5CB7F4-C6E4-4E7A-BA3C-48F3B190D58E@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 18 Jul 2019 14:00:22 -0700
Message-ID: <CALx6S36G3DbTB4+jdbCW3kK830kbErSG14g9SdcujREssBLaTw@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/phoktMaf9XV1N0ariR_dtWEChbA>
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: Thu, 18 Jul 2019 21:00:42 -0000

On Thu, Jul 18, 2019 at 1:51 PM Joe Touch <touch@strayalpha.com> wrote:
>
>
>
> > On Jul 18, 2019, at 1:49 PM, Tom Herbert <tom@herbertland.com> wrote:
> >
> >> On Thu, Jul 18, 2019 at 1:37 PM Joe Touch <touch@strayalpha.com> wrote:
> >>
> >>
> >>
> >>> On Jul 18, 2019, at 10:25 AM, Tom Herbert <tom@herbertland.com> wrote:
> >>>
> >>> Consider that someone invents the compression option a year from now.
> >>> The option cannot be ignored by a receiver since delivering compressed
> >>> data to the application would be jibberish.
> >>
> >> Please see sec 7 of the current draft.
> >>
> >
> > I don't see what in section 7 helps, can you point the specific mechanisms.
> >
> > Tom
>
> Sec 7 says this - and other things- should not be done by options and why.
>
So we can never add a compression option? Or for that matter an
alternate method of fragmentation, or some sort of forward error
correction that might touch the data?  That the reason we don't have
to worry about unknown options that can't be ignored is that we aren't
allowed to create any new options that can't be ignored once the
initial set is published? If I'm interpreting this correctly, it
sounds awfully limiting.

Tom

>

v2.23.0 | Report a Bug | By Email