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

From: Ondřej Surý <[email-masked]>
Date: Thu, 20 Jul 2017 18:45:25 +0200 (CEST)

Hey,

there's one thing I don't really understand from this draft.

Is this useful for DNS at all, or is this targeted at DNS-SD only?

I think this needs some explaining and perhaps a clear cut is needed.
Although it's not mentioned anywhere in the document, the draft makes
much more sense to me, if it would clearly state, this should be only
used in DNS-SD sessions.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: [email-masked]
> To: [email-masked]
> Cc: "dnsop" <[email-masked]>
> Sent: Tuesday, 14 March, 2017 00:44:49
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>        Title           : DNS Session Signaling
>        Authors         : Ray Bellis
>                          Stuart Cheshire
>                          John Dickinson
>                          Sara Dickinson
>                          Allison Mankin
>                          Tom Pusateri
>	Filename        : draft-ietf-dnsop-session-signal-02.txt
>	Pages           : 25
>	Date            : 2017-03-13
> 
> Abstract:
>   The EDNS(0) Extension Mechanism for DNS is explicitly defined to only
>   have "per-message" semantics.  This document defines a new Session
>   Signaling Opcode used to communicate persistent "per-session"
>   operations, expressed using type-length-value (TLV) syntax, and
>   defines an initial set of TLVs used to manage session timeouts and
>   termination.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Jul 2017 12:50:44 -0400

> Is this useful for DNS at all, or is this targeted at DNS-SD only?

I can think of at least one way it would be useful.  Large
authoritatives often have a clear population of query sources that ask
a lot -- the "top talkers".  It would be excellent if those clients
stood up TCP connections and kept them in place because then (1) the
server could treat their TCP connections as long-lived and (2) the
server could treat new UDP packets from those IPs as suspect.  The
current TCP handling makes this mostly suck, and the
session-signalling approach makes it suck less.

But it's certainly another step along the way to DNSbis by accident.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 18:52:45 +0200

For TCP connections, being able to signal session liveness policy is useful
for DNS, not just DNSSD.   It seems likely that DNS Push is useful for
things other than DNSSD.   I think this is generally useful, not just for
DNSSD.   Rather than thinking of this as a DNSSD-specific enhancement,
think of this as an enhancement to section 4.2.2 of RFC1035.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 20 Jul 2017 18:59:42 +0200 (CEST)

> But it's certainly another step along the way to DNSbis by accident.

Would it be useful to make it not "by accident"?

That's why I have a love-hate relationship with TLV inside DNS messages.

I have a couple questions:

a) make DNS over TCP/TLS sessions without TLV suck less?

b) make this draft DNS-SD only, so it can fast forward...

c) use the changed paradigm to work on DNSbis without the accident part?

Cheers,

----- Original Message -----
> From: "Andrew Sullivan" <[email-masked]>
> To: "dnsop" <[email-masked]>
> Sent: Thursday, 20 July, 2017 18:50:44
> Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Jul 2017 13:09:07 -0400

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

I'm starting to wonder whether a bof is needed.  Maybe the IAB's
workshop will produce some fruit?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Fri, 21 Jul 2017 10:02:52 +0200

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Jul 2017 10:22:30 +0200

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.

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.