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

Petr Špaček <> Thu, 10 August 2017 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AB05126E3A; Thu, 10 Aug 2017 04:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dy5VivbSTM0V; Thu, 10 Aug 2017 04:28:31 -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 9A9791320BB; Thu, 10 Aug 2017 04:28:31 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a] (unknown [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a]) by (Postfix) with ESMTPSA id CB4BB622C0; Thu, 10 Aug 2017 13:28:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1502364510; bh=dla9eyO95IPRwlSSng230rBoFd2OvR7sVBFIvXPQ/28=; h=From:To:Date; b=mGONFtNXMzIAOubfuXz0l6WLMXh9oMxngjf5EzvSA2m4z7ODnaRnAvR0aiDU5QAIt mnXExok9q4+25ynr6VArgOIW93hnbTiSit1H90LUDeAR5TjPzSPVt0RdD+w+juL5j5 XnPHRudcmDPjZ/FqU4Bxz0DRKfxonBlU8i8dyBu8=
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
To: Ted Lemon <>, dnsop WG <>
Cc: "" <>
References: <> <> <> <> <> <> <>
Organization: CZ.NIC
Message-ID: <>
Date: Thu, 10 Aug 2017 13:28:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
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: Thu, 10 Aug 2017 11:28:34 -0000

Hello Ted and dnsop,

and sorry for delayed answer (below). Your message forced me to think
more about the draft, this time without focus on the wire format.

Spoiler alert: I still do not like the proposal in its current form.
Please see below.

On 21.7.2017 10:22, Ted Lemon wrote:
> 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 proposal.
> 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 is.

Okay, I can see what you mean - there surely are various levels of
complexity and protocol changes proposed in the last years for dnsop.

However I disagree that adding session signalling to DNS is less
significant change than e.g. multi-query/repose proposals.

As you said, session signalling is a "control plane for DNS", which is a
very new thing. Keeping (IMHO significant) wire format issues aside,
adding a control plane to DNS is in my eyes a significant new
development and should be treated as such.

> 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.

Maybe one of the problems is that the current draft mixes three
things in a single document:
- The new wire format,
- DNS control plane,
- Session signaling functionality over the control plane.
This is probably making things way harder to explain to non-authors than

These really are separate things. I can imagine that control plane
and potentially its wire format can be together in one document (but I'm
still not convinced that the a wire format is necessary), but session
signaling functionality itself should be certainly separate from that.

Let's keep discussion about the wire format for later, there is even
more significant issue ahead of us:

> 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.

The problem is that current proposal is creating some generic "control
DNS plane" as by-product of session signaling functionality, as we were
discussion during dnsop session.
(References: "Totally flexible format" & "Concerned with embedding DNS
messages in TLVs" in [2].)

I believe that we really should not invent such generic mechanisms as

If a WG agrees that a generic DNS control plane is needed, then it needs
to be carefuly designed and described, including problem statement and
analysis related to current and potential new transports. These are
compleretely missing now.

Moreover, the dnsop is specifically chartered to subset of possible
changes [1] to the DNS protocol:

4. Publish documents  to address operational issues with the DNS
    protocols by  extending or performing protocol maintenance
    on them.  Act as  focal-point for operator discussion and provide
    advice to the Ops ADs and other WGs on EDNS0 options,  new
    RRTYPEs, DNSSEC,  record synthesis, or other mechanics of
    extending DNS to support other applications.

5. Serve as a home for drafts that document the problem space
   around existing or new DNS issues.  The group, with the advice
   and consent of the responsible AD in coordination with other areas,
   will then decide whether these  issues belong in DNSOP  under
   the existing charter and, if not,  will work with the authors and
   appropriate ADs to determine the proper place for the work to be
   carried out.

For me, adding control plane is just stretching this definition too far.
If session signaling is covered by this charter then we must admit
that dnsop can do anything it wants to the DNS protocol.



If there is a need for a "DNS control plane" then it should be enginered
as such and not invented as by-product of something else.

Yes, it is a lot of work. And yes, it should start with problem
statement for control plane (in general) and continue from there.

I hope it explains why I still do not like the current proposal.
Thank you for your attention.

Petr Špaček  @  CZ.NIC

> 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?