RE: Opsdir last call review of draft-ietf-quic-manageability-14

"MORTON JR., AL" <acmorton@att.com> Wed, 16 March 2022 19:23 UTC

Return-Path: <acmorton@att.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2E13A064F; Wed, 16 Mar 2022 12:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 8_4rLsa7LpDx; Wed, 16 Mar 2022 12:23:34 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9103A0658; Wed, 16 Mar 2022 12:23:34 -0700 (PDT)
Received: from pps.filterd (m0288870.ppops.net [127.0.0.1]) by m0288870.ppops.net-00191d01. (8.17.1.5/8.17.1.5) with ESMTP id 22GIjbC8001838; Wed, 16 Mar 2022 15:23:30 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288870.ppops.net-00191d01. (PPS) with ESMTPS id 3etxqg74jb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Mar 2022 15:23:30 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 22GJNSDA020627; Wed, 16 Mar 2022 15:23:29 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 22GJNPid020526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Mar 2022 15:23:25 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 11D8D16A5B9; Wed, 16 Mar 2022 19:23:25 +0000 (GMT)
Received: from MISOUT7MSGEX2AA.ITServices.sbc.com (unknown [135.66.184.199]) by zlp27125.vci.att.com (Service) with ESMTP id D7F5116A59F; Wed, 16 Mar 2022 19:23:24 +0000 (GMT)
Received: from MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) by MISOUT7MSGEX2AA.ITServices.sbc.com (135.66.184.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.18; Wed, 16 Mar 2022 15:23:24 -0400
Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.18 via Frontend Transport; Wed, 16 Mar 2022 15:23:24 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.100) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Wed, 16 Mar 2022 15:23:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fc55iLH7PD53bXZaxPghLt3Q8ZHqSydBZIj0lJC2CWX41EYHhWchgUqg+BegRVr7rSlk8iYxFn0xgKCERkoUTsUHB/MosCX+T19eY5gYXcup5XNvTWveZYfDYoqE9Yyz/yxFneMuCXGkNS/IldxUR0jO8nsJM/+PEo2ORlE3SFHqi1tKhtq9FbatRJ7ljk5aHPOb5hImDhKQ8rx9qFog4tM9zeSz+bvIll+qazdsNS7Y8ev5Z63fCujbas1gvFZRrKdaoz97MvRQNsGW9+sHgJveFcn0JG3v+rhqknBPJ/DbwxnVcyP6NNKOi/9L4HuZnZTZePZW58GHY+gG2dTxeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8buEPbQB2M559fcyQq+Oh3ro6XSK6GTBhjByVfMrUsk=; b=BlKn5Z4ihg8KM7525THcBsAUuaYMZCE4sW/+YSUPZ7f5f4aoYtu751aEYxneFywWhCwN5Qh/EOYk9GpyXwFlPyNwJT2PRAW2wrgqfPU931EkerPWktMQg1+vJH0/k5bI5Fl8uaWXPTF0FIduY86LLaiwcMWrritZQun034GtCZmfHXqQlmhlH32UhNVDNPrEVVE5TpnMQpy1g9mucHs/MLoh1zyyWTwYw2ZoHR4eD1QP8a94RTkDMYTE0c1kQGKpi3VbEblw8cs1rIyHPvGyQ0P58H7ktuiEt0gwqHFHVX1JRtH7HkVVmD9Ni8Dfx69HIoVbRqK9c+P1Y3h7H0llbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8buEPbQB2M559fcyQq+Oh3ro6XSK6GTBhjByVfMrUsk=; b=mO6I5XkJTg3pyrclMIx7Fj3j+Snskk+NpzVhAbtta1YfmZUP3xQ8KZxLTzhxvUJl5jsAstW6xbqcHvJ8WSJlzdcsVAFqXtN3csJqPMVXZZb4oFutttOWiCaDm50MT0qfSEGEn6SEth7R6OxpTCoyEbsv8DcF1bLo3Ph09Zrz7q4=
Received: from DM8PR02MB7973.namprd02.prod.outlook.com (2603:10b6:8:12::9) by BYAPR02MB5495.namprd02.prod.outlook.com (2603:10b6:a03:95::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.26; Wed, 16 Mar 2022 19:23:10 +0000
Received: from DM8PR02MB7973.namprd02.prod.outlook.com ([fe80::3dda:94c1:82cc:128a]) by DM8PR02MB7973.namprd02.prod.outlook.com ([fe80::3dda:94c1:82cc:128a%4]) with mapi id 15.20.5061.028; Wed, 16 Mar 2022 19:23:08 +0000
From: "MORTON JR., AL" <acmorton@att.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-quic-manageability.all@ietf.org" <draft-ietf-quic-manageability.all@ietf.org>, "quic@ietf.org" <quic@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Subject: RE: Opsdir last call review of draft-ietf-quic-manageability-14
Thread-Topic: Opsdir last call review of draft-ietf-quic-manageability-14
Thread-Index: AdggNpsvC4XiX/liSmSPxtbxuobGvgG9Sw6AATXYhEAAaJAnAAC/IODgAiqHLAAABOiygA==
Date: Wed, 16 Mar 2022 19:23:08 +0000
Message-ID: <DM8PR02MB7973BBE35F26700D004BF9A3D3119@DM8PR02MB7973.namprd02.prod.outlook.com>
References: <CH0PR02MB7980CA04E5EADBF6D25AD8F2D3319@CH0PR02MB7980.namprd02.prod.outlook.com> <D82872C2-4C79-45AB-92F1-9F27B324ADE0@ericsson.com> <CH0PR02MB79803C4AF8ED0F28A5F81D30D3009@CH0PR02MB7980.namprd02.prod.outlook.com> <5224BCAC-B8EC-4150-B3B1-5735056BC54C@ericsson.com> <CH0PR02MB798003A25A1C96D02F1FE525D3069@CH0PR02MB7980.namprd02.prod.outlook.com> <346C0025-B1CB-4CAF-BB23-A7E09D79E9B5@ericsson.com>
In-Reply-To: <346C0025-B1CB-4CAF-BB23-A7E09D79E9B5@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c3ea2831-5135-4d01-e7f2-08da0782673c
x-ms-traffictypediagnostic: BYAPR02MB5495:EE_
x-microsoft-antispam-prvs: <BYAPR02MB5495509640E65272C641E6E9D3119@BYAPR02MB5495.namprd02.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xVxWFVAxHQBJ6acV0hYhnBx1bGFZZ7Cj6BREAGe73PGZ9QDKz/umzEavMXejapYX5ylWMLUW197sx6P9F2h1Peoso7OkxXLXiwG969w782uAbUth3ECZxJTRAZEUQSvw0PJsg5q/AFJUI+LPBHDYhCu2ryAQXlEzPpkSvyQ+NgsCgAzlRCIq83/Y9W2R+YSPwPa0Nx6UxKSzt2i/lZRKJ4YQfO8YcDSnwyx2wxrxIVQGTBpPL6n1QroKbYNpvZYCfGHWY1v1PyJ4Gjx6TT0pDgKsQT11NFDgdkCs1ALGXQYHke7xkf9+QVRfaNWT8Utl7oJyktNKOIcpKTVjinLcoK7ov6/bONSCizQgZsvqT/pXN06DODrW8YelUe6TJYJP5ca7tBErY92OkWZZWcr8WTIWbZ8RlcKeLuQvx+hwADjScuu2tA0OGtFfKp4H/W3ypBVZOsc/wORZ4mzCF3Kl0pPjDhYCXbRUV9aOhpgqptKDs0Qz3HCArXJS5OmExp/ae+1cxolsv3lG5NjwtCgjlXlzSjgykRRUMd9FSF46eLufZGz5/Mjbbv1qtTdMD6xKOiKy1HXeMlRS/TkXC8/Vk/29YKn8ikqNY3gu7cwOLPUbivZSalXMp7qGz8aRMSz+OEGDFl14DklfLwwXgIhVRY0XnzWFe12ln8SU+YT1kdPod3SNZUDJ0deo22rxuX7GwLgrZXrY1nzPuhwcCD5grmlNvmzM2lMLvnTTGJkuGBKkkxxftZ9DUHx2YBJnVXcFvZTIuV/w9JMwb6BJrCgacb9RMX+G1tw/rC9Vv6vvU5E=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR02MB7973.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6916009)(54906003)(82960400001)(316002)(2906002)(33656002)(55016003)(66946007)(76116006)(508600001)(38070700005)(71200400001)(966005)(66476007)(30864003)(5660300002)(8936002)(52536014)(38100700002)(64756008)(66446008)(4326008)(8676002)(122000001)(66556008)(82202003)(86362001)(6506007)(9686003)(7696005)(66574015)(83380400001)(53546011)(186003)(26005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: s6L12GuIirbWFNUjXHLwrsK8nhpLn6VT8awYqyWQt5GDBgFtlMIYfRFdu3dMffnpZz5Prlgi1DoPzBY/khXrEkyD3LwTW8oOGfEZ3Lrr3FpJxYQ0MklLn/UyMlDVOUWMD0qLIRK5nihIGi7NnUdRbcdQwoN+qHp9SBAmDQqHC9Sj8Ubr5vbyy65mMA4X3lEhqWzCfV5l68tsEHuDCzczfe7Vzi2qzjmhSOPrlRT3XglpFLpIVi2jFjqAy6WEmX103/GLcAEllPCqAx8wv7Qv+MR7r1kNOssE/1iXFYKc7l5f8Rwld3T0r7hkj1fUyeM6kRsaboO8B8G7Jaa7MxfQ+S037OIFDLg2KIH50onPT8ETxJ1sta2Vl+RkLX5JC2+oc2mJuvPxLMkmZkPlcbGTIu2SFtCi2MetEfQQiafOfcifIo+cfOxAveDYGeaX50yu7M1wI5djphP55c9kVixk2QxVxJss9eJDRRCNNUALNEvXML7RUxOQxiuVddF53ehs0nA2/JFA4gnnH104xuAsVi0SoKC1Ub92s4chBDm/6USmooz67sMlvNRwx7wNik02fuYL9nVrgTp8aLw2mq/LZEhn6fKYmplB7dH16qcNhLKxw3gCrrsV9N0GIEA33epgnaEZQHN/4qqZWkZgdFagN54QHJc5/xFqcTPcW8aErerfNYmfQr1Wt/8rITNA9EtG5KcTLCiemYinUg+Wfq8w+IsfuRxNHtYbRhDIX1RrDBFAsAivT0TpWEhlweNXXuMVPmDMR5AFRJej7KdtgpEgWKrgfPMsQxg3wGFPOawFlWa0TgpR/adkCikOid6wpjf4H/kUna7b74hufw+CSHjwJ+mTLY9HfQurRwBvC3l4smJAwAQ5n4j5cjmNFMHbbMk2ea7h9nkvGl0K7VofWQhr6UrHLglppHx7Am/Vt9g1/syGScJ2uGc+XtTdlMesZyY2axyXNJzwFirdZq5cmrxR0t3RteHN9+2KDlWiDyT02DpHJvVElFj+FHUXA2DWVThuI8J23cONUQsbYUZLelIkpxxRQLZW2R6vLpvi7Ma2fWE92RPz7CpRFotvThuin0EwB6yMReqSaVQoLORi8bP2c4HAXBWXT2ps1NEWQe73pO9L1Yv4GzFvQ0YS8WO7TDufFcw8xEcplScCesFF2ojwgeRsE0qSmEsBNfqp4TULIdLP5Vi+SwgdS5Ccz6ENExoPhu3DvljMizhrvQ8+ocJMMsiQZN6a7vZPQKKNBS5Z8fXYn+pNihFrdIl6II0QBUnGWgtqst0qMKS+2PQyVIvzZnf+nkLixJh4O3ncH7yaPgowv2bJR6vG1YwTycIa0ldxAX6Q68Vguaw5qKtCD12SP6tNqKEz2qhNUlO3Vrordsfoil9KO0OHp6iikuI9vnFLF83QYc+iG2OY8CBiYtu9WtPqPP46jR4NZok5KQvEDew=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM8PR02MB7973.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c3ea2831-5135-4d01-e7f2-08da0782673c
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 19:23:08.4284 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YgLW+uC6pud3tV6e/nEIWxdHTucDsc0/uji8Hpl18heG+lfL6hGmz3LFNhfFWMEE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5495
X-TM-SNTS-SMTP: D25C58179DF91DD8533676AC8640086EC0E003B7567EAC3DCD28366FEE5C37322
X-Proofpoint-GUID: 9TpF1MyIqK0R9-sAseT2mdGOgWuy9VPY
X-Proofpoint-ORIG-GUID: 9TpF1MyIqK0R9-sAseT2mdGOgWuy9VPY
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-16_09,2022-03-15_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1011 adultscore=0 phishscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203160115
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1sIc-s93NXPPx2M6mVZE9mFan7o>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2022 19:23:41 -0000

Hi Mirja,

> -----Original Message-----
> From: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> Sent: Wednesday, March 16, 2022 10:40 AM
> To: MORTON JR., AL <acmorton@att.com>
> Cc: last-call@ietf.org; draft-ietf-quic-manageability.all@ietf.org;
> quic@ietf.org; ops-dir@ietf.org
> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
> 
> Hi Al,
> 
> as you might have seen we merged the remaining PRs and submitted a new version
> last week.
> But unfortunately, I don't think we were able to address your comment below
> fully.
> 
> Regarding use of version number I believe the text in the draft reflects the
> group consensus, so we only made my editorial change to make if clearer.
[acm] 
Your draft and WG consensus discourages use of the version field for admission purposes.
This is a question of whether any WG should state a consensus that expressed a *policy* for network managers and operators in an IETF RFC. If the same intent was stated as a conclusion reached by the WG, it would be far more palatable, and I offered alternative text as an example.

So, let's consider this issue as needing further discussion in a wider venue.
 
> 
> Regarding when the handshake fails, I'm not sure if it would be correct to say
> anything more here. You can always just not see some of the packets on the
> path, or the handshake could even change with a new version or an extension I
> guess. Again I'm also not really sure what to do with that information either.
> If you don't see any further packets flowing at any time, incl. right after
> the handshake, something went either wrong or the transmission is just done.
> It's really hard to make any assumption from the network here.
[acm] 
The case I cited was an operator that wants to support QUIC, and wants to identify when QUIC setup fails and how frequently failure occurs, to support analysis and troubleshooting and properly manage their network. I also note the dependency on knowing the version number in your paragraph above (when attempting to understand the handshake), as hint to accomplishing this management goal (by relating the version to a published specification). 

I think that a supporting operator (like the one above) is the most-likely reader of your memo, so it will help them to add a few sentences about non-Figure 1 handshakes. Even if the sentences are something like this (based on what you said above):

	If the handshake in Figure 1 is truncated or missing packets, many actual outcomes are possible (and not necessarily handshake failure). The end-points may have switched to a different version and handshake, switched to a different path, implemented fallback, terminated the attempt as the end-points intended, or other outcome. 
-=-=-=-=-=-=-=-=-=-

Over time, observers will likely develop heuristics to mitigate these uncertainties and draw probable conclusions (like they did with TCP), but you don't need to add that aspect. Just indicate the possibilities and try to improve the manageability of QUIC.

Al

> 
> Mirja
> 
> 
> 
> On 05.03.22, 17:02, "MORTON JR., AL" <acmorton@att.com> wrote:
> 
>     Hi Mirja, thanks for your replies and PRs.
>     please see replies below, I clipped discussions we have closed.
>     Al
> 
>     > -----Original Message-----
>     > From: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
>     > Sent: Tuesday, March 1, 2022 1:49 PM
>     > To: MORTON JR., AL <acmorton@att.com>
>     > Cc: last-call@ietf.org; draft-ietf-quic-manageability.all@ietf.org;
>     > quic@ietf.org; ops-dir@ietf.org
>     > Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
>     >
>     > Hi Al,
>     >
>     > thanks again! See below!
>     >
>     > On 27.02.22, 19:50, "MORTON JR., AL" <acmorton@att.com> wrote:
>     >
>     > [snip]
>     ...
>     >     [acm] I see that there was additional editing since you wrote last
> Monday,
>     > so I made a comment and suggestions on GitHub.
>     >
>     > [MK] Thx! Added you suggestions!
>     >
>     > [snip]
>     >
>     >
>     >     >     >
>     >     >     >     2.8.  Version Negotiation and Greasing
>     >     >     >
>     >     >     >     ...
>     >     >     >        QUIC is expected to evolve rapidly, so new versions,
> both
>     >     >     >        experimental and IETF standard versions, will be
> deployed
>     > on the
>     >     >     >        Internet more often than with traditional Internet-
> and
>     >     > transport-
>     >     >     >        layer protocols.  Using a particular version number
> to
>     > recognize
>     >     >     >        valid QUIC traffic is likely to persistently miss a
>     > fraction of
>     >     > QUIC
>     >     >     >        flows and completely fail in the near future, and is
>     > therefore
>     >     > not
>     >     >     >        recommended.
>     >     >     >     [acm] Where "valid traffic" is the focus, I agree, let
> it
>     > flow.
>     >     >     >     But the Operator's focus may instead be "admissible
> traffic",
>     > where
>     >     >     >     experimental traffic is not wanted or allowed. IOW, only
>     > traffic
>     >     > that is
>     >     >     >     understood to conform to <RFC list> shall pass, because
>     > "Active
>     >     > Attacks are
>     >     >     >     also Pervasive", to put a different spin on 7258. [acm]
> See
>     > also the
>     >     > comment in
>     >     >     >     3.4.1.
>     >     >     >
>     >     >     > [MK] This is not about experimentation.
>     >     >     [acm]
>     >     >     OK, let's just say unexpected traffic.
>     >     >
>     >     >     > The expectation is that QUIC versions
>     >     >     > will change often, e.g. we already have a draft for a new
> version
>     >     > adopted in
>     >     >     > the group and there might be another RFC some time this
> year. So
>     > if you
>     >     >     > "manually" have to allow for new versions in all your
> equipment
>     > that
>     >     > will
>     >     >     > delay deployment of new versions (or even hinder them
> because
>     > there is
>     >     > always
>     >     >     > one box that doesn't get updated). Therefore we strongly
> recommend
>     > to
>     >     > not use
>     >     >     > the version to filter QUIC traffic. Is that not clear enough
> in
>     > the
>     >     > text?
>     >     >     >
>     >     >     >        In addition, due to the speed of evolution of the
>     >     >     >        protocol, devices that attempt to distinguish QUIC
> traffic
>     > from
>     >     > non-
>     >     >     >        QUIC traffic for purposes of network admission
> control
>     > should
>     >     > admit
>     >     >     >        all QUIC traffic regardless of version.
>     >     >     [acm]
>     >     >     I think it is clear, and at the same time, it is aspirational
> for
>     > many
>     >     > networks.
>     >     >     This sentence informs, but then strays into policy.
>     >     >
>     >     >     Maybe this will work:
>     >     >           ...devices that attempt to distinguish QUIC traffic from
> non-
>     >     >            QUIC traffic for purposes of network admission control
> should
>     > not
>     >     > rely
>     >     >            on the version field alone.
>     >     >
>     >     > [MK] I think your proposal is not correct because the whole point
> is
>     > that you
>     >     > really should not use the version field _at all_. I know that
> people
>     > will
>     >     > still do that, but I think we should at least spell it out clearly
> here
>     > that
>     >     > this is problematic and hinders evolution.
>     >     [acm]
>     >     Evolution is what happens when a succeeding RFC is approved.
>     >     Experimentation is the many months between approvals.
>     >
>     >     	...devices that attempt to distinguish QUIC traffic from non-
>     >          QUIC traffic for purposes of network admission control
>     >     *** should admit all QUIC traffic regardless of version.***
>     >     The last phrase attempts to define operator policy.
>     >     Don't do that.
>     >     The version field exists. It's specified in a standard.
>     >     If you simply say,
>     >     "The version field will change in the future." no one will be
> surprised.
>     >
>     > [MK] Okay I got your point about policy. However, this document is meant
> to
>     > provide guidance/recommendations to operators. I also see now that this
> in the
>     > "background" part which is also rather to explain QUIC than give
>     > recommendations. However, I think this is actually one of the essential
>     > recommendations of the document, so I would like to still spell this out
>     > clearly and as early/often as possible. I tried a slightly different
> wording
>     > in a new PR on github. Is that any better?
>     >
>     >
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334-
> 501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-
> 16c2148a7129&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fgithub.com*
> 2Fquicwg*2Fops-
> __;JSUlJSUlJSUlJQ!!BhdT!iHzaYKyN6pGji70tbHntNd77OXfIU4uuz7yrrrdyIBk1xF8H4AbY4b
> Yu77k6OuH_qZ54CWUksfGvL7zx23VlQpdp$
>     > drafts/pull/459/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn-
>     > 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqHssizC$
>     >
>     [acm]
>     Not yet. Maybe we can compose your message to operators *without* making
> it sound like you are trying to set policy.  I suggested text in the PR like
> this:
> 
>     Developers would prefer admission of all QUIC traffic regardless of
> version in order to support continuous version-based evolution. However, all
> parties understand the value of versions with a corresponding, fully-approved
> standard.
> 
>     >
>     >     >
>     >     >     >
>     >     >     >     [acm] I was hoping to see a description of fallback to
> TCP (I
>     > see
>     >     > that fallback
>     >     >     >     is mentioned briefly at the end of section 4.2., and
> later,
>     > fail
>     >     > over and
>     >     >     >     failover. pick one...)
>     >     >     >
>     >     >     >     How can Network Operators observe when a QUIC setup has
>     > failed, and
>     >     > the
>     >     >     >     corresponding TCP fallback connection(s) succeeded?
>     >     >     >
>     >     >     > [MK] There is no unified way how and if fallback is
> implemented.
>     >     > However, why
>     >     >     > do you think a network operator would need that information?
>     >     >     [acm]
>     >     >     To affirm that their admission policy is working properly, for
> one
>     > reason.
>     >     >
>     >     > [MK] However, there is really no guarantee that all QUIC will have
> a
>     > fallback.
>     >     > Without further knowledge about what higher layer service the QUIC
>     > transport
>     >     > carries, I don't think you can make any assumption about fallback.
> If
>     > you want
>     >     > to support evolution, you need to support QUIC and not rely on any
>     > potentially
>     >     > fallbacks.
>     >     [acm]
>     >     I chose example carefully: the operator wants to support QUIC, but
> has
>     > reports that QUIC setup is failing and needs to make measurements to
> gather
>     > symptoms & info. Experience will indicate the circumstances where QUIC
> setup
>     > failure is accompanied by fallback, and other possibilities. Repeated
>     > experiences become heuristics for passive observation.
>     >     No assumptions necessary.
>     >     Has QUIC setup failed if the exchanges in Figure 1 are incomplete?
>     >     I think there might be a yes or no answer...
>     >     If no, then the passive observation procedure will mostly be
> governed by
>     > heuristics.
>     >
>     > [MK] I think I lost the point now. If QUIC fails even if there is a
> fallback,
>     > that's still not great because the original intention was obviously to
> use
>     > QUIC. Is there anything we need to say in the draft that is missing?
>     [acm]
>     Without getting into fallback in any way,
>     Help the operator determine when a QUIC setup has failed by providing a
> little more info.
>     It would be useful to know:
>     What QUIC messages would accompany a QUIC setup failure? (other than those
> in Figure 1)
>     OR
>     A statement like:
>     If the exchange in Figure 1 is incomplete, then the QUIC setup has failed.
>     (IF that is true)
> 
> 
>     >
>     >     >
>     >     >     >
>     >     >     >     Is there a reference available with this info, to save
> effort
>     > here?
>     >     >     >
>     >     >     > [MK] As I said this is rather implementation specific, so I
> would
>     > say
>     >     > no.
>     >     >     >
>     >     >     >     ...
>     >     >     >
>     >     >     >     3.4.1.  Extracting Server Name Indication (SNI)
> Information
>     >     >     >
>     >     >     >     ...
>     >     >     >
>     >     >     >        Note that proprietary QUIC versions, that have been
>     > deployed
>     >     > before
>     >     >     >        standardization, might not set the first bit in a
> QUIC long
>     >     > header
>     >     >     >        packet to 1.  However, it is expected that these
> versions
>     > will
>     >     >     >        gradually disappear over time.
>     >     >     >     [acm]
>     >     >     >     And some networks may prefer not to admit experimental
>     > traffic. The
>     >     > goal of the
>     >     >     >     experiment may be problematic for the network operator
> and/or
>     > their
>     >     >     >     subscribers. I think this is legitimate operator
> behavior, and
>     > worth
>     >     > a few more
>     >     >     >     words in the draft.
>     >     >     >
>     >     >     > [MK] To be honest I don't understand this point. How would
> an
>     > operator
>     >     > even
>     >     >     > know if an experiment would be problematic or no? QUIC is
> fully
>     >     > encrypted.
>     >     >     > Versioning is only one extension mechanism. So basically
> even if
>     > you see
>     >     > the
>     >     >     > same version number, the QUIC behind that could behave very
>     > differently
>     >     >     > depending on which extensions are used and because of the
>     > encryption,
>     >     > there is
>     >     >     > no chance for the operator to know about this. Is this not
> clear
>     > in the
>     >     >     > document? Do we need to state this more clearly?
>     >     >     [acm]
>     >     >     First, let's say s/experimental/unexpected/ or
>     > s/experimental/proprietary/
>     >     >     Then, I'm responding to your reply more than the paragraph in
> the
>     > draft
>     >     > now:
>     >     >     Network operators are also end users, and often act on their
>     > subscriber's
>     >     > behalf. Observations are not strictly limited to mid-points, where
>     > encryption
>     >     > is present.
>     >     >     Harboring old notions of what operators cannot do will not sit
> well
>     > with
>     >     > your audience...
>     >     >
>     >     >     So, (in the paragraph above) you've informed operators that
> some
>     >     > proprietary QUIC versions remain in use as of this writing.
>     >     >     But traffic that doesn't conform *might* be considered
> nefarious.
>     > That's
>     >     > all. It's a message for everyone involved.
>     >     >
>     >     > [MK] I think the point is actually rather that we want to say
> here: if
>     > you
>     >     > don't support these old versions that will not be a problem in the
> near
>     >     > future.
>     >     [acm]
>     >     Ok, say that in the draft, please.
>     >
>     > [MK] Okay started a PR on github. Is that more clear now?
>     >
>     >
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334-
> 501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-
> 16c2148a7129&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fgithub.com*
> 2Fquicwg*2Fops-
> __;JSUlJSUlJSUlJQ!!BhdT!iHzaYKyN6pGji70tbHntNd77OXfIU4uuz7yrrrdyIBk1xF8H4AbY4b
> Yu77k6OuH_qZ54CWUksfGvL7zx23VlQpdp$
>     > drafts/pull/460/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn-
>     > 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqkDVmpL$
>     >
>     >
>     [acm]
>     I'm ok with this one, thanks.
> 
>     >
>