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

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Thu, 26 September 2019 10:40 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 65964120899 for <dnsop@ietfa.amsl.com>; Thu, 26 Sep 2019 03:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.995
X-Spam-Level:
X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 AB1Ed-wvuzVA for <dnsop@ietfa.amsl.com>; Thu, 26 Sep 2019 03:40:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 83AC11208A6 for <dnsop@ietf.org>; Thu, 26 Sep 2019 03:40:55 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:e767:ca28:dd33:bada] (unknown [IPv6:2001:1488:fffe:6:e767:ca28:dd33:bada]) by mail.nic.cz (Postfix) with ESMTPSA id C4192140DC2; Thu, 26 Sep 2019 12:40:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1569494452; bh=9pXHD7oNYUYXFdLHXhUmHD6xAWn5FomUrc/S3N7FDRk=; h=To:From:Date; b=ZCnTgYmaP7elW7GaZ7WyJqV3PaZI5b1fdxi40bxjKKk6Or8b0NOWg+k5V3ffoeq3w u/4AC3wNTR3DgN/HAKC3hdjmJpHs3g7TciAMA/+s6052yqGA51kgEKUFbo+lBYZdkl CO0gawZ6duPcptd0YeGi2Ijb3W5JIdGJYHvQmx/g=
To: dnsop@ietf.org
Cc: Jan Včelák <jv@fcelda.cz>
References: <156927967091.17209.1946223190141713793.idtracker@ietfa.amsl.com> <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com> <CAM1xaJ8cs7OuxMm17o_Te4AW0uv+vdmiCSwD1zH+nzGFV==oAw@mail.gmail.com> <CAHbrMsCBp95a9pBTJ=DQSd+6S=bFc7ogOtwpYpcCe+nyhsao8A@mail.gmail.com> <CAM1xaJ-ivNGO+hpiwf+ZFR0=um-2iGUe1TJGjc55-bqg8zS8Bg@mail.gmail.com>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <d9e82dfe-3298-187d-cc17-a2219b955110@nic.cz>
Date: Thu, 26 Sep 2019 12:40:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAM1xaJ-ivNGO+hpiwf+ZFR0=um-2iGUe1TJGjc55-bqg8zS8Bg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------93AE4170076647106C1F08E9"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F6nNMDHQNRq0UALZ8Nzx2nAO4a0>
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 10:40:59 -0000

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