IETF Logo Mail Archive

Re: [Teep] TEEP breaking OTrP compatibility consensus

"Salz, Rich" <rsalz@akamai.com> Mon, 05 August 2019 05:30 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BB5120043 for <teep@ietfa.amsl.com>; Sun, 4 Aug 2019 22:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 Zs0BcL1-uvCl for <teep@ietfa.amsl.com>; Sun, 4 Aug 2019 22:30:13 -0700 (PDT)
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 61430120018 for <teep@ietf.org>; Sun, 4 Aug 2019 22:30:13 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x755Rmol011655; Mon, 5 Aug 2019 06:30:10 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=8nnmdHdce3ymVkERFp1+s9C3mcMnuMcQ8jyBbCSKjX0=; b=RiI8zsiTcOr4H4IakLd2k4KYhnEacVJ0Nl89DUq7cYiBo7jL0I/2rZFc0GUgPe/9tfa+ S56mBCIarXOI0N7ONQfK/QEQrRwVMQSGriZ3RDuIPDXEwHmB5ySkJRaP7528zoKrSoke Zq80LyodFLIfjLUkQKCj7Y0GsN0NRKXR1/TrERteqaS52rtTwlR2zkZN1+sDOkp8f+dT eBMstGhsW8Le8/r9irpyfOaM5ZCtMmAF13vch9BNtKun3xtgWDwaSXg0AtvPtSp9FmPA ghv8B2LOO4h6rlHDvQd+NHsB9ae+nrrFXTvTvr9+awHxJ12JXpzu4XQSbuAvlNNgHG+8 Sg==
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2u52agqp3y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Aug 2019 06:30:10 +0100
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x755HK0B011888; Mon, 5 Aug 2019 01:30:08 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2u55kw33xy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Aug 2019 01:30:08 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 01:30:07 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Mon, 5 Aug 2019 01:30:08 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "teep@ietf.org" <teep@ietf.org>
CC: "ncamwing@cisco.com" <ncamwing@cisco.com>
Thread-Topic: [Teep] TEEP breaking OTrP compatibility consensus
Thread-Index: AQHVSl5I4dCtYdRaLESRpBJV5WLDRqbr170AgABRbwD//9/EAA==
Date: Mon, 05 Aug 2019 05:30:06 +0000
Message-ID: <D3D5F7A7-EB18-4757-A013-5F71F78EFB18@akamai.com>
References: <5FDD8324-4F4E-4486-A086-C4E778B8AE39@cisco.com> <TY1PR01MB16448C27C596FC43027D5F12D8DA0@TY1PR01MB1644.jpnprd01.prod.outlook.com> <2A557EC8-4FD4-43B5-9DA1-2C854414B8E4@dell.com>
In-Reply-To: <2A557EC8-4FD4-43B5-9DA1-2C854414B8E4@dell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.163]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0EA33E988313784283E6B6054F1A1491@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-05_02:, , 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=517 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908050059
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-05_02:2019-07-31,2019-08-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 mlxscore=0 impostorscore=0 phishscore=0 adultscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 mlxlogscore=486 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908050061
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/oKhT9gEBjYDXxC6KbnBjufZRVxM>
Subject: Re: [Teep] TEEP breaking OTrP compatibility consensus
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 05:30:14 -0000

>    I am also for breaking compatibility but I would prefer to change the name of the draft not just adding -v2 to the name.

Same here.

We saw similar confusion with the base ACME spec, which is used by LetsEncrypt, and the IETF version. QUIC also re-used the name, but the confusion there was much more tractable because the base implementation is pretty much controlled by one party, who has been very careful to label things as IETF QUIC and gQUIC, for example.

v2.23.0 | Report a Bug | By Email