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

Tim Wicinski <> Thu, 20 May 2021 01:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AD993A2856; Wed, 19 May 2021 18:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wLzgvd7pjcZx; Wed, 19 May 2021 18:50:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A2553A2853; Wed, 19 May 2021 18:50:03 -0700 (PDT)
Received: by with SMTP id x19so22010814lfa.2; Wed, 19 May 2021 18:50:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wn2RlcNAnNDrH8EcjK5kyTB4fF31G/WZkU13sgT16GE=; b=tXpGLSNvl7F4g4NTimpOGPF2x65uMn+Rl6W67fZfKx2pPsOi/yqoBtcUr9jH2hL06I 8rsv2zEtT55jdAnalomg2GwQPKGLTdlAKfg+B7weozkbdWpve8IPCYRpK8jW6IkpNIke qFHWNmwLStxPJngLwvQda9HHeeEB9bWOqqT8JnvfjgkDmOGC4LULQcVn4pq0LD7NjH2U xyWN8WoNflF1NgI3TJAtcaj/itTW9Y2X745SLd6CpWp4jkgdKrdLSW21TdIed7A5/cPw QKdd4ID7HGPnnEdwkEeEQ9MPpV6WbR28UpjgQSkMg/6EvtcvSNgTMciIduLDZN/2NrRa rQ2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wn2RlcNAnNDrH8EcjK5kyTB4fF31G/WZkU13sgT16GE=; b=SdTxk3Du+ghxBwzbtt1KB0l2e5eDcPXHavVc0B777rl09DBVgJly2tSXE+04HykzPH pU5wnU4OP4V+GrO9/6gq08ZHx9YtIdKFXe1HwYzmI2N6om5EyHRUWDccE2iOUnhOjg7f 9LNYa33rF1hZlV82LWvrAeISkXMSk1j7IpBe38fEth4RuIkT3U2Mw+RaMqiZdmqhTwM5 /xTqi0Kp8T53LTzYjh4n4Y8Cgrny7yQH66sKgKM7nQf7GtjZYV+C2gvpma7BmV967VR0 iQsK5WRnoOKBUKCR9nm+HQOu1mYFCTjJuUadg8SbUMrh0A76c/O5QPYRbfQq3PqDfVVS uYgg==
X-Gm-Message-State: AOAM532/V32ONhsjBSPjoIk13U5IJFQkw/EJlkEVOs9jmitS1OuTUwRK b1EcqhdMV1nh98bFNYUWJKxqGu2Y98zbJ0z+2fQaHH000Fg=
X-Google-Smtp-Source: ABdhPJy+lagnUZAa41VYTdVwiSAAKzEEEEAhfWTjCFy5nTOIWkbGXgYyJ++qN5KNSDlYBEKX/2juEjZjXUlhVBJ2Tv8=
X-Received: by 2002:a05:6512:b98:: with SMTP id b24mr1644843lfv.216.1621475400015; Wed, 19 May 2021 18:50:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Wed, 19 May 2021 21:49:48 -0400
Message-ID: <>
To: dnsop <>
Cc: dnsop-chairs <>
Content-Type: multipart/alternative; boundary="0000000000003ae11105c2b929cb"
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, 20 May 2021 01:50:06 -0000


I'd like to circle around as chair and call this discussion illuminating.
I do feel that there is rough consensus to keep with the current format.
The discussion here has gone down the path of wholesale redesign.

We call the WGLC closed for now. The authors have an updated document
to publish, and Ben's current suggestion can be taken into account.

Thanks for the discussion.   I plan on including this thread in the
writeup for the IESG to review.


On Wed, May 19, 2021 at 9:35 PM Ben Schwartz <bemasc=> wrote:

> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpauly=
>> wrote:
>> I like Erik’s suggestion that we solve the issues with parsing by putting
>> more rules and constraints of the set of available characters, etc.
> I don't get the impression that the TLS working group is likely to reach a
> consensus to formally restrict the allowed characters in ALPN values.
> However, there are currently no "problematic characters" in any of the
> registered ALPN values, and it seems very likely to me that there never
> will be.  With that gray area in mind, I have attempted to thread the
> needle with the following proposed change:
>  The key
> sentence is:
> > So long as there are no registered protocol identifiers containing ","
> or "\\", zone file implementations MAY disallow these characters instead of
> implementing the `value-list` escaping procedure.
> I'm sure this is no one's favorite option, but perhaps it is good enough
> to enable us to move forward.
> _______________________________________________
> DNSOP mailing list