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

"C. M. Heard" <heard@pobox.com> Sun, 21 July 2019 03:39 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 0A37F1200C4 for <tsvwg@ietfa.amsl.com>; Sat, 20 Jul 2019 20:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 SZAaGceMhYYd for <tsvwg@ietfa.amsl.com>; Sat, 20 Jul 2019 20:39:19 -0700 (PDT)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679FE12006A for <tsvwg@ietf.org>; Sat, 20 Jul 2019 20:39:19 -0700 (PDT)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 991F816A2D4 for <tsvwg@ietf.org>; Sat, 20 Jul 2019 23:39:17 -0400 (EDT)
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=dQDScfaKpoX1NSTXTPfFgW0Ar2g=; b=M8a7PQ DA7yOMapjZlxeD+SI8dT2GVuhuGmhNqqwCF1e5bn5riXEsIUDbbBSfLUatxvtUwQ 7wBlR/iJ+rjYiItNs6DfnkIPrQ04RHE1VzNklWC3tgUfVDwabW0UOfO0fxkHu5RM zYPnfkAojjfqEYhbTYm01XwD2s2CxWEoKES5A=
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=rmV036PJJd53hn20XHvLWZHQxb4GsXCb 5quvBnWkof8bLcWbdoxuEI2i+K/lB9Z6pOIJx8M4I8+R82Ld4hK5vUMtYhyhsehT 9PavmvU+PdaVwwsR+FiOey4t71eE7R3/G4lNDfWq7s2oO0Ye07kA0glKmWDNMOpo 6q1yROyZ7uI=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 90E5716A2D3 for <tsvwg@ietf.org>; Sat, 20 Jul 2019 23:39:17 -0400 (EDT)
Received: from mail-io1-f49.google.com (unknown [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 2C79016A2D2 for <tsvwg@ietf.org>; Sat, 20 Jul 2019 23:39:17 -0400 (EDT)
Received: by mail-io1-f49.google.com with SMTP id o9so66706835iom.3 for <tsvwg@ietf.org>; Sat, 20 Jul 2019 20:39:17 -0700 (PDT)
X-Gm-Message-State: APjAAAXyiLSKrf5GmuM2d2S9YQTbwmTxRC/7k3ayKJv/wBAXhSrJvtTA QhdDS4mq1xGbsAC5bpmLpjbEywE2f1Ztv48Xlsk=
X-Google-Smtp-Source: APXvYqzxIpomqWNvxMP0XZI4SOnkpK3Fe+UHmQIP1PFcslCC0yB6CxO4A8vvZzy8AR5xwTdrSWD4xHakfYRIRkc6Yvk=
X-Received: by 2002:a5e:9308:: with SMTP id k8mr57148257iom.143.1563680356643; Sat, 20 Jul 2019 20:39:16 -0700 (PDT)
MIME-Version: 1.0
References: <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> <20190720215636.GA66376@clarinet.employees.org> <CACL_3VGbd_91cP2jrOigRc=rt3bOoarmbNqG5ma+iSgf0ABDtw@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363062AB13@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363062AB13@MX307CL04.corp.emc.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Sat, 20 Jul 2019 20:39:03 -0700
X-Gmail-Original-Message-ID: <CACL_3VEOT-fHLc61Ske9AZXb5p11BzB8av3Rart-+XGODDW3tQ@mail.gmail.com>
Message-ID: <CACL_3VEOT-fHLc61Ske9AZXb5p11BzB8av3Rart-+XGODDW3tQ@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 1DD55BD4-AB69-11E9-9D14-46F8B7964D18-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/taCKlSCJIEn74K9ohtswn7GskvE>
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: Sun, 21 Jul 2019 03:39:21 -0000

On Sat, Jul 20, 2019 at 6:49 PM Black, David wrote:
> Still as an individual ...
>
> > What I was actually advocating was that in the presence of any option marked
> > "drop if unknown" there MUST NOT be any legacy data, i.e, such options
> > could not appear in the trailer format. All payload would have to be in the
> > surplus area (which requires the header format). In that case, "drop the
> > packet" and "drop the surplus" would amount to the same thing.
>
> That would "freeze" LITE - if we ever found anything problematic with LITE and
> wanted to replace it with LITE2, that replacement would be prohibited by such
> a requirement.

Forgive me for being thick, but I don't quite get what you are saying. Is this
problem specific to LITE, and in particular LITE in the variant proposed by
Derek? Or would it also be true of other options that affect how the payload
is processed, such as FRAG, AE, and ACS, which are the ones for which I claim
need to be marked as "drop if unknown"? I would imagine that for those a
replacement could be effected with a new option kind (as was done when TCP-AO
replaced TCP-MD5).

Thanks,

Mike