Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Mark Andrews <marka@isc.org> Thu, 26 September 2019 23:31 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD2712000F for <dnsop@ietfa.amsl.com>; Thu, 26 Sep 2019 16:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 HgoT0LsZoCmM for <dnsop@ietfa.amsl.com>; Thu, 26 Sep 2019 16:31:21 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 626BF12006B for <dnsop@ietf.org>; Thu, 26 Sep 2019 16:31:21 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0696D3AB000; Thu, 26 Sep 2019 23:31:19 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CE5C816000A; Thu, 26 Sep 2019 23:31:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B4585160087; Thu, 26 Sep 2019 23:31:18 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4I3AkSL6D8mA; Thu, 26 Sep 2019 23:31:18 +0000 (UTC)
Received: from [10.122.213.245] (unknown [120.17.138.218]) by zmx1.isc.org (Postfix) with ESMTPSA id 24CA016000A; Thu, 26 Sep 2019 23:31:18 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-98940992-B58E-4E3E-91C9-C5044597CD0A
Content-Transfer-Encoding: 7bit
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 27 Sep 2019 09:31:15 +1000
Message-Id: <D80EC72D-C8E4-4D4F-999C-C7AC026F3BBA@isc.org>
References: <d9e82dfe-3298-187d-cc17-a2219b955110@nic.cz>
Cc: dnsop@ietf.org, =?utf-8?Q?Jan_V=C4=8Del=C3=A1k?= <jv@fcelda.cz>
In-Reply-To: <d9e82dfe-3298-187d-cc17-a2219b955110@nic.cz>
To: =?utf-8?Q?Vladim=C3=ADr_=C4=8Cun=C3=A1t?= <vladimir.cunat+ietf@nic.cz>
X-Mailer: iPhone Mail (17A844)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0FRAOh67H31nqAjSZTcvLImb26Q>
Subject: Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 23:31:25 -0000

Implementing the encoder isn’t hard but it needs to be clearer that there are specific encodings. It is easy to miss this. I did initially.

-- 
Mark Andrews

> On 26 Sep 2019, at 20:41, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> 
>> On 9/26/19 12:30 PM, Jan Včelák wrote:
>>> The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key types.  For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be expressed as "key2=\031\067".  This encoding may not be convenient, but hopefully it will reduce the burden of supporting new parameter types.
>> I agree we need generic encoding. There is a way to express unknown
>> record types (https://tools.ietf.org/html/rfc3597#section-5) and the
>> syntax used there is more compact than what you propose. It uses hex
>> strings instead of escaped decimal values. However its clumsy to work
>> with records in that syntax and you proposal is better in that sense.
> I'm curious, Is there much motivation for a bit more compactness of the *presentation* format?  I consider its design primarily meant for humans.
> 
> 
>> I think this may become the most complex record type we have in DNS so
>> far. None of the existing registered record types contain a list of
>> key-value pairs of arbitrary length. Given that there is also a
>> registry for key types involved it will be fun to implement the
>> encoder/decoder. But we will have to deal with it. I'm interested in
>> what others in this working group think.
> I think we should get "implementation experience" from multiple parties at least before publishing the RFC (though that's a point far ahead, I suppose).
> 
> --Vladimir
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop