IETF Logo Mail Archive

RE: What CSRs Do

"Lubashev, Igor" <ilubashe@akamai.com> Fri, 22 November 2019 04:03 UTC

Return-Path: <ilubashe@akamai.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 BAEB4120025 for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 20:03:06 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Dx79Ii3rPm5E for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 20:03:05 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 3887D12008C for <quic@ietf.org>; Thu, 21 Nov 2019 20:03:05 -0800 (PST)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAM402uN022733; Fri, 22 Nov 2019 04:03:04 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gR1j6HgiuVGkKPl9XFiQDoHgpbxzMTxPbWgf0PlmQ5o=; b=YFCWfCRAcjN4rb0L7m5YNz3j6JbCuRiya5xE39qE0KdbNKrhVcNhF6xW2yXjLtodnIuL iEgRBhe+XyqmMPT8f/+o+1fM8HgQlwITxNlsQoC8PJFWlJD4rGmfplvVSWtpW1s1Om8M opI2F9cYWNBLlG9lrP7fO7fKAZh4R98mjQ7oY0ZDhEosEy0oXCATvmgxAY70vFoPlaug Dm0QXNW1JoCsyu9cirj5HZm3YiV/IrR1+MVQejj0ifSfscs2uQEN0qcX+2R32skqESPR YU7ED55zFjOztGJy0cj/2LV9riMS77ep/rG9wFA1TPIv5M5KFV50H2Hd/9NJrrCSImP8 Yw==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2we3gh94p4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 04:03:04 +0000
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAM42WE6015219; Thu, 21 Nov 2019 23:03:02 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint7.akamai.com with ESMTP id 2wadb56fmu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 23:02:53 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 22:02:38 -0600
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 22:02:38 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Frode Kileng <frodeki@gmail.com>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: What CSRs Do
Thread-Topic: What CSRs Do
Thread-Index: AdWeiLnP74voAASmTy29ATmkahTsZQANieYAAAFSQgAAAxM6gP//nbXWgABu3gCAA57FAIAA3FUAgABaDtA=
Date: Fri, 22 Nov 2019 04:02:37 +0000
Message-ID: <4aaf3c3ddd4344928a37922cdc0c3667@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <BL0PR11MB3394D769128DEFEEFBC3CA71904C0@BL0PR11MB3394.namprd11.prod.outlook.com> <0cf4d3ad-0f64-0ae4-2d95-77a39f40639d@tele.no> <20191119042904.GC5602@1wt.eu> <4003626d-8966-6772-7df0-e76549320430@gmail.com> <1574144751435.15844@akamai.com> <bc0cf83f-16d6-3200-5d6e-091311ccf9a7@tele.no> <7268_1574344734_5DD6981E_7268_134_1_1574344750.3872.4.camel@orange.com> <ff683bc6-6b10-8720-8e18-b448bb0dfd21@gmail.com>
In-Reply-To: <ff683bc6-6b10-8720-8e18-b448bb0dfd21@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.217.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-21_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911220035
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-21_07:2019-11-21,2019-11-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 malwarescore=0 adultscore=0 mlxscore=0 bulkscore=0 clxscore=1015 mlxlogscore=999 suspectscore=0 phishscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911220034
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/y5tPkCJeJJplwm9CbUKU9hFNu08>
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: Fri, 22 Nov 2019 04:03:07 -0000

Frode, Alex,

The unhelpful discussion of tone or word choice aside, I think that both of you make valid points.  I've heard similar views on both sides from multiple people.

I would repeat what I said yesterday in MOPS.  QUIC header encryption is a significant change in the way transport works, and we have no experience operating it at a scale where it is more than a single-digit percentage of Internet traffic.  Some people believe that they need new tools; others believe that they do not.  A lot of effort went into QUIC to ensure it will continue to evolve.  So the best thing we can do is to give the tool to people who claim they need it and see if it gets used.  If the tools remains largely unused, it will naturally disappear from QUIC (it will be a negotiated extension after all!). 

- Igor

> From: Frode Kileng <frodeki@gmail.com>
> 
> On 21/11/2019 14:59, alexandre.ferrieux@orange.com wrote:
> > To *lack* these sources, one might be incompetent, as you are
> > suggesting many people are. Alternatively, one might simply care about
> > a long end-to-end path with several responsibility boundaries, which
> > by definition are opaque. In this case, as Igor said, the
> > upstream/downstream location is absolutely crucial.
> 
> 
> When in https://github.com/quicwg/base-drafts/issues/3189 stating that
> "Shipping v1 without loss observation support would undermine day-to-day
> network maintenance work in at least that part of the ecosystem", naming a
> list of "supporters" and "The list is growing daily", I do think in all fairness it is
> important to indicate that this view is not necessarily an universal truth and a
> view is supported by everyone in "this part of the ecosystem". And that it
> should be possible to indicate this, giving a rationale and without being
> accused for claiming someone is "incompetent".
> 
> frodek

v2.23.0 | Report a Bug | By Email