[tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt

Tom Herbert <tom@herbertland.com> Mon, 08 July 2019 15:06 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 122551202B2 for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 08:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Level:
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 JoQ8nni5ot9Y for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 08:06:38 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 89362120247 for <tsvwg@ietf.org>; Mon, 8 Jul 2019 08:06:02 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id v15so8231266eds.9 for <tsvwg@ietf.org>; Mon, 08 Jul 2019 08:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wNKdTBupdifdsItXgYmgkG3jby14EpZ0YS6kIauOm34=; b=prd/AxgN9qUawF+erreYGhCTZ8mbblTt0p9SvdCWHjNY9+WDTPY1Tz1BJZenbxWqnT qRn3CMVLClhHTpvjxB2O1nK0CvVywtEtBDNAabnW9R61+EyRpRp/SEbFDJPbLDCcNdny F2o9/PveiPcq+j9wyv+HM57OZuNVB8LyztrhzHBDR8aqG2Ha4nkBRpy9I75WNkEE4RjE BPGoMP7xzfEKyl/2OuFZe7o1pycHkmTwAZBb+xVHgenNKVTom9bBivOVlvadW8V8vzcQ ut2QwhUDifcWutMEobF5xTcrZNFX5wHjuqqlum3UI+kAUR9WK6vbvfCjHBIHs1Ry89dG dERQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wNKdTBupdifdsItXgYmgkG3jby14EpZ0YS6kIauOm34=; b=lQXIOvwSSxxb4AtGjZZtjU6T2Fc8pwaryOVzvEU0qL/REmvTt2DktNbeYAgh17Fxs8 KMraH24M1wboJNvBiO7DQ5RPObur590QO7Ip7vyO2RfrurO62YvdBnQVOmEePGs6WcV0 NZ8xGfKlYrBqMM05MvDnLvTrjt08hVAxUSf3OCE1V5Utnt9OIYxXlNir9dG+pU9ZK+Qp ACkfN6XRjICCh3dlkrbGRwOi9WHyOM3O5OZpmDlwEdJW4ciTv30V0akLdRFl+2raUpGs Bz4Fr2I9kjGNx4970qmrO1F4h7dx8xIXOx+0oIDFgu/gJqfJGGD8ZxonIvae1/L7+Svk UxxA==
X-Gm-Message-State: APjAAAXV8TGBrHy+jr3jft75eEctHbJRQIXClZP2aswPYwwnQk5NFq2i B+niKPsetHla5wWqMne9G0ane6nWD5TY7+3pGntsvdbwGf4=
X-Google-Smtp-Source: APXvYqynMIUGwfuf4DFAAfpg/S2zONWGqBMG9jynhZXkn1tG4J6MD9g0jqeKg2yC5OGFEccPfgC5GvMT4D1vJx8L6zo=
X-Received: by 2002:a17:906:85d7:: with SMTP id i23mr16848987ejy.119.1562598360432; Mon, 08 Jul 2019 08:06:00 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 8 Jul 2019 08:05:49 -0700
Message-ID: <CALx6S36-WfCs_BW5iGQzoZHq6HBsLMyEDagkMOmg8VgvEWWeew@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MONL2Epsl3xGtIm5Kb7hIRMlLx0>
Subject: [tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt
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: Mon, 08 Jul 2019 15:06:48 -0000

Hello, I have a comment about the discussion of protocol ossification.
>From the draft:

"A reliance on the presence and semantics of specific header
information  leads to ossification, where an endpoint could be
required to supply a specific header to receive the network service
that it desires.  In some case this could be benign or advantageous to
the protocol"

I am dubious about any statement that protocol ossification of
transport layer by middleboxes is a good thing. There are too many
examples where protocol ossification has impeded or prevented
deployment of IP protocols or features (QUIC, MPTCP, TFO, SCTP, EH,
etc.). Yes, we need to take effects of protocol ossification into
consideration when deploying a new end to end protocol or features,
but that is for practicality and not by choice. IMO, protocol
ossification is something we have to work around and undo, not a
principle to embrace.

If there is some case that is "benign or advantageous to the protocol"
then please provide a _specific_ example. And if such a case exists
then I'd expect there would be general consensus that the protocol
definition was wrong in the first place to have allowed so much
extensibility and that the ossification should be standardized in the
protocol specification.

Tom