Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

"libor.peltan" <> Thu, 13 May 2021 10:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB5593A08D6 for <>; Thu, 13 May 2021 03:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CGMMlZBNn28H for <>; Thu, 13 May 2021 03:56:03 -0700 (PDT)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA1883A08D4 for <>; Thu, 13 May 2021 03:56:02 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 25132140AF4; Thu, 13 May 2021 12:55:59 +0200 (CEST)
To: Ben Schwartz <>, Brian Dickson <>
Cc: dnsop <>, John Levine <>, Joe Abley <>, Eric Orth <>
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <>
From: "libor.peltan" <>
Message-ID: <>
Date: Thu, 13 May 2021 12:55:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F3FD94C887F8C86C7B1B7BB6"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 May 2021 10:56:07 -0000

Hi all,

just my comment:

> Perhaps complexity is subjective.  The important thing is that the 
> standard be reasonably implementable.  I hope that the list of 
> published implementations [3] will serve as convincing evidence that 
> the current draft is sufficient in that regard.
> --Ben
I agree that complexity is subjective. I have no problem implementing 
complex procedures. But more complexity means more probability for bugs 
(and even security issues).

Currently, the authoritative server (while transforming presentation to 
wire format), MUST:

  - sort the SvcParams by key
  - verify their uniqueness
  - deal with list of fields nested in other fields (this includes the 
discussed comma escaping)

and the client MUST:

  - verify that SvcParams are sorted and unique
  - deal with list of fields nested in other fields (at least that 
various "lengths" match)

In the concurrent proposal, the sorting and deduplication will be "for 
free", because DNS ensures this, and each RData would consist on just 
one list of values, much easier to handle.

On the other hand, the client would have to group several RData (already 
sorted) to get all info, and believe they're all there (as Brian pointed 
out, it has to anyway). And it would cost more bandwith due to DNS 
overhead -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).

Have I summarized the pros/cons of both approaches well enough?