Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 04 November 2019 10:11 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 AF79412010E; Mon, 4 Nov 2019 02:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 qgDVKvYdZw9c; Mon, 4 Nov 2019 02:11:40 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157FE1200F6; Mon, 4 Nov 2019 02:11:40 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AEC2A25A28; Mon, 4 Nov 2019 11:11:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572862298; bh=sLBLDSWPKfvwcsVlqPvlAWYgYqCo8RfCWZcf7cjN22w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ePIgQhst3xSKmykl2Dbue/SublFCwpBc5VuERciNYbw/Ydv6Eejat7zLgMl7SPNNL YX9TA7n9feRd3z7yfKn63Lr3g3W9nLutlLNXr7fSyHRyLQDo14CfFsDiIZKVkGzWZz PBr0XqjhgL1rAWFtIm3TDo3J7zxJ3yFO2EYcuUqI=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNDiP7z60Cpq; Mon, 4 Nov 2019 11:11:38 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Nov 2019 11:11:38 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 11:11:26 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Sebastian Moeller <moeller0@gmx.de>
CC: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Jonathan Morton <chromatix99@gmail.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
Thread-Index: AQHVkujPHAgC8VHHbkilSp+8bjFG+ad6qTAAgAAIR4CAABVRMA==
Date: Mon, 04 Nov 2019 10:11:25 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DAB93@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> <5DBFDF26.5080101@erg.abdn.ac.uk> <BA2535E8-E7D9-430C-897C-DEAAFBC351A8@gmx.de> <5DBFF245.1040300@erg.abdn.ac.uk>
In-Reply-To: <5DBFF245.1040300@erg.abdn.ac.uk>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Qp_OcCWLA-dw-J8x0dO3fLLEUi8>
Subject: Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 10:11:42 -0000

> Because, that is why the WG publishes EXP RFCs.
> 
> My own understanding, is that to publish a PS update to TCP, it is good
> to have deployment experience.

In this context, it makes sense to read the exact wording of RFC 7127:

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.

In general, there is no strict formal requirement for implementation or operational experience for a PS. But TCP is a core Internet protocol, i.e., the third quoted paragraph may apply. The TCPM working group has in several cases concluded that running an experiment first would be reasonable.

In some of these cases, there is now implementation and operational experience. In those cases, doing the PS is mostly a matter of WG energy...

Michael