Re: [Doh] re original_transport indicator
"Hewitt, Rory" <rhewitt@akamai.com> Thu, 05 April 2018 20:56 UTC
Return-Path: <rhewitt@akamai.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CECC12D7E8; Thu, 5 Apr 2018 13:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GPqWcJo5qgzq; Thu, 5 Apr 2018 13:56:51 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 C1E2A12D7E4; Thu, 5 Apr 2018 13:56:51 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35Kqcc4001289; Thu, 5 Apr 2018 21:56:42 +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 : mime-version; s=jan2016.eng; bh=a0ZKYv5l0tD4/+ekm3GYFmrqU0zx6HGfB/kkggMuMbo=; b=kULKCi0dB/ehXICCogm4VgxvDx27olXsUwvdkhvTGjWI8FfwxteT+8yL4kVDecnDP+fU aXPa++TiCfkb6DqF9FN2QqoXWTzv7QC3GzF/nmzUvIuxSF3+WWbwvQX1t9b/+AaVVrsF Cm/a/sgY2wxvBtguh37MXSz0KdAbLHSgA+/zktgeg71xIFaMIthzS+WseG9eTV2wVuM+ MJ3ZmgzSVuOanEjzC/gIGarzVWc8S3KboXbShMXi1ASTtpnnlmEz3yBklKq1PPero+Wj uiRhfh1yD4+HBV1boL3OpThd3I4dopReJNmHDm20Sc7/g+auE3hRlA1C0RR0Fc1SDpfj Ww==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g5apc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 21:56:42 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35KpRhl001932; Thu, 5 Apr 2018 16:56:41 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nvcbhx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 16:56:41 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Apr 2018 16:56:41 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Thu, 5 Apr 2018 16:56:40 -0400
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Patrick McManus <pmcmanus@mozilla.com>, Martin Thomson <martin.thomson@gmail.com>
CC: Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>, Ray Bellis <ray@bellis.me.uk>
Thread-Topic: [Doh] re original_transport indicator
Thread-Index: AQHTzSA/Hoab/GGFzky8kAfRAazUvaPypqMA
Date: Thu, 05 Apr 2018 20:56:40 +0000
Message-ID: <fb8387b410234828950a837590aad426@usma1ex-dag1mb3.msg.corp.akamai.com>
References: <CAOdDvNrO0bbSdRn8dzWiFzMx4Wc33yAh0C6SWg+DR4b4XTEmHg@mail.gmail.com>
In-Reply-To: <CAOdDvNrO0bbSdRn8dzWiFzMx4Wc33yAh0C6SWg+DR4b4XTEmHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.9]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_017B_01D3CCE5.EB3A9B20"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , 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-1711220000 definitions=main-1804050211
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050211
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/pjIsFtE7uOXzpeeeq9-3U53JHes>
Subject: Re: [Doh] re original_transport indicator
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 20:56:54 -0000
Good idea - future-proofing is great in theory, but it sounds like there's a lot of non-consensus on the DNSOP side that we might end up adding something that is superseded anyway. Rory From: Patrick McManus [mailto:pmcmanus@mozilla.com] Sent: Thursday, April 5, 2018 1:54 PM To: Martin Thomson <martin.thomson@gmail.com> Cc: Ted Lemon <mellon@fugue.com>; dnsop <dnsop@ietf.org>; DoH WG <doh@ietf.org>; Paul Vixie <paul@redbarn.org>; Ray Bellis <ray@bellis.me.uk> Subject: [Doh] re original_transport indicator Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 6838), I think including this in doh is premature because Media Type registrations can be updated by mechanisms laid out in RFC6838 and in this case such an update could occur without impacting existing DoH deployments. (i.e. it does not need to be future proofed). Therefore the definition of the parameter should accompany the work that makes use of it if a future standards document chooses to go down that path. As a bonus we avoid unused clutter if it doesn't happen. I also get the feeling that there isn't yet strong consensus on the anticipated use case or the exact form it needs to take - we should let that process work itself out separately before registration. I've chatted with Paul, and our recommendation is to remove the original_transport parameter from DoH and encourage dnsop to update the registration if/when a different standard needs to make use of it. thoughts? -Patrick
- [Doh] re original_transport indicator Patrick McManus
- Re: [Doh] re original_transport indicator Hewitt, Rory
- Re: [Doh] re original_transport indicator Martin Thomson
- Re: [Doh] re original_transport indicator Paul Vixie
- Re: [Doh] re original_transport indicator Martin Thomson
- Re: [Doh] [DNSOP] re original_transport indicator Dave Lawrence
- Re: [Doh] media type name, was Re: re original_tr… Tony Finch
- Re: [Doh] re original_transport indicator Davey Song
- Re: [Doh] re original_transport indicator Paul Vixie