Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

Ted Lemon <> Fri, 21 July 2017 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 262D4131935 for <>; Fri, 21 Jul 2017 01:23:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pdl617flU9Q9 for <>; Fri, 21 Jul 2017 01:23:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FBB1131CE6 for <>; Fri, 21 Jul 2017 01:23:11 -0700 (PDT)
Received: by with SMTP id s70so21644211pfs.0 for <>; Fri, 21 Jul 2017 01:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+/KcM41D17Yi0aquYueT4ZaxdXgGl9UOKloL/OgVZU=; b=AD39bfWB91JodICllAAdY+qnwpssV5kjYmsFOWKKbZaVqCoDtlu0P0J8Fzmslkg2na O+tq3qKvxEt8CxAlkA/A40z8LlRA15/Ju6EvoSD1lcOyIZ/LC7sIn2cb2aePTTddc0x3 2i7OF9Qo/MQD1O11K5vTbPkKO1ZCrKHMS5s6KbKdxSRndNL6a0S510BN/AjgydXEejXr DYKgbYq07l9MimIL3+JRXrX8iFrrpaALWuTyHZIg6hIA4eX7alA+uOiCRzysgif1WQ1v hwSXmeIwNeH8Sr2qsBenT3a9PwJ4vw3EN14nzm8HvtfqsLFCMgfW81Zz4hEzIDMz4k2D O24A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u+/KcM41D17Yi0aquYueT4ZaxdXgGl9UOKloL/OgVZU=; b=rZxostpQ5+6J+4HX1gzUX0YN43LCpuwgBEjGz+39QrweZCmJgAv8/fCGfYchhXGeVh cgH49ABAlDznfI/mpnPAzAj6LkNAoYQREEqRnEGS465BQ5VaN7k8dJEoZJDLrvgZ1jsC /KJ3HrKIcx4iVclsU4FQ4CibS9/UDnMLb96D+Wc2HsjWaW1ZzszQR5+ZDdVgD3UMGdqV 8nUtN9b6i4jiAKwnerQEwsj37fSuN3vk3Ryrtq0Id3alZNGeMi242/c8N2uBU4Kwgz6k lvIHGK6OOO7bzaZMgeo9idiSK2SOo5gOM6QZVp3cAMQb5FxBH8BAWLnzuO9ovSWruhTN QuaA==
X-Gm-Message-State: AIVw1138CZHe6k2wPc4WaqWvFwTiXw69BK+muVk19f4NbwpEE7/92lLO Frj6YtmzkI3QNp5OKPMENpN6uLnsMRbp
X-Received: by with SMTP id b84mr6876099pfd.216.1500625390493; Fri, 21 Jul 2017 01:23:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Jul 2017 01:22:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Ted Lemon <>
Date: Fri, 21 Jul 2017 10:22:30 +0200
Message-ID: <>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Cc: dnsop WG <>
Content-Type: multipart/alternative; boundary="001a1143ccc45781140554cf9314"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jul 2017 08:23:14 -0000

I am hearing from a number of people that this is "a new protocol" and
hence requires careful thought and perhaps a new working group, along with
the associated delay.   I do not _entirely_ disagree with this position,
although it would be really inconvenient from my perspective.

However, I would like to point out that the objection "it is a new
protocol" is not a technical objection.  Also, the same objection can
actually much more justly be raised against several other proposals that
were brought before the working group.   For example, the multiple RRtypes
proposal, the multiple responses proposal, and the extended error codes

All of these define new protocol, in ways that are in, like session
signaling, backward-compatible with the existing protocol.   The other
proposals are actually much more significant changes than session signaling
is, in terms of what they actually do, as opposed to what their wire format

And as for a new DNS wire format, which I also think would be a good idea,
this is pretty clearly *not *what session signaling is.   How would you do
a DNS query with session signaling?   In what way would it be an
improvement over the existing query format?   It's possible that a new wire
format can be built on top of session signaling, but session signaling
doesn't build a new wire format, and if we choose to do session signaling,
that doesn't preclude doing a different wire format for queries later.

Session signaling is just a control plane for DNS.   It's useful.   I would
like to see it done sooner rather than later.   If we are not going to do
it sooner rather than later, I would like the reason to be something more
than vague unease about walking backwards into a new wire format.

On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček <> wrote:

> On 20.7.2017 19:09, Andrew Sullivan wrote:
> > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
> >>> But it's certainly another step along the way to DNSbis by accident.
> >>
> >> Would it be useful to make it not "by accident"?
> >
> > Yes.  That was basically the point I was trying to make at the
> > beginning of today's session, about overall analysis.
> >
> >  > b) make this draft DNS-SD only, so it can fast forward...
> >>
> >
> > I'm not keen on this.
> >
> >
> >> c) use the changed paradigm to work on DNSbis without the accident part?
> Yes please!
> My main opposition comes from fact that current session signaling draft
> "accidentaly" defines new protocol which is using the old DNS-RFC1035 as
> "transport".
> I would welcome DNSbis effort with clear cut. Here please note that
> clear cut does not mean that RR format and data, for example, has to be
> incompatible!
> It is still possible to share big chunks of specifications (like RR
> definitions, namespace, etc.) but define a DNSbis protocol which is
> clearly distinguishable from the old DNS.
> Petr Špaček  @  CZ.NIC
> > I'm starting to wonder whether a bof is needed.  Maybe the IAB's
> > workshop will produce some fruit?
> _______________________________________________
> DNSOP mailing list