Subject: [DNSOP] Last Call: <draft-ietf-dnsop-session-signal-10.txt> (DNS Stateful Operations) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 11 Jun 2018 09:20:48 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Stateful Operations'
  <draft-ietf-dnsop-session-signal-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-06-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document defines a new DNS OPCODE for DNS Stateful Operations
   (DSO).  DSO messages communicate operations within persistent
   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
   are defined that manage session timeouts, termination, and encryption
   padding, and a framework is defined for extensions to enable new
   stateful operations.  This document updates RFC 1035 by adding a new
   DNS header opcode and result code which has different message
   semantics.  This document updates RFC 7766 by redefining a session,
   providing new guidance on connection re-use, and providing a new
   mechanism for handling session idle timeouts.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jun 2018 13:36:00 +0200

Hi all,

Are there any implementations of this protocol extension?

Kind regards,

Job

---------- Forwarded message ----------
From: The IESG <[email-masked]>
Date: Mon, Jun 11, 2018 at 6:20 PM
Subject: [DNSOP] Last Call: <draft-ietf-dnsop-session-signal-10.txt>
(DNS Stateful Operations) to Proposed Standard
To: IETF-Announce <[email-masked]>
Cc: Tim Wicinski <[email-masked]>, [email-masked],
[email-masked], [email-masked]

Abstract

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jun 2018 06:09:00 -0700

Yes.   I'm using it right now to implement draft-ietf-dnssd-mdns-relay, and
that implementation is working and interoperating.   I don't know of
another independent implementation yet, unfortunately.

---

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jun 2018 16:28:16 +0200

Dear Ted,

On Tue, Jun 12, 2018 at 3:09 PM, Ted Lemon <[email-masked]> wrote:
> that implementation is working and interoperating.   I don't know of another
> independent implementation yet, unfortunately.

Can you elaborate a bit more? What is the name of the implementation?
This is an implementation in progress? I don't fully understand how
there can be interoperating if there is no other implementation.

I see roughly 150 (!) BCP14  keywords in this draft. Can you specify
for your implementation for each of these normative keywords whether
your implementation is complaint, or not, and if not why not?

Kind regards,

Job

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jun 2018 09:09:52 -0700

The BCP14 keyword compliance question sounds like a worthwhile exercise,
but I can't do it this week.   I'm certainly not deliberately violating the
specification.   As to what implementation it is, it's a modification to
the mDNSResponder code base to support mDNS queries over the mDNS relay
protocol.   I suppose "interoperating" was the wrong choice of words—I have
two different services talking to each other: one is a Discovery Relay, and
the other is a Discovery Proxy.   I'd really like to get some other
implementation to test against—are you volunteering?   :)

On Tue, Jun 12, 2018 at 7:28 AM, Job Snijders <[email-masked]> wrote:

> another

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 12 Jun 2018 13:22:57 -0400

> On Jun 12, 2018, at 10:28 AM, Job Snijders <[email-masked]> wrote:
> 
> Dear Ted,
> 

I did an initial implementation of a client and server for DNS push notifications which is based on Stateful Operations. This code isn’t public and I haven’t looked at it for about 6 months. But it did identify some issues early on in the draft that we corrected for.

Thanks,
Tom

---

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jun 2018 19:27:09 +0200

> I did an initial implementation of a client and server for DNS push notifications which is based on Stateful Operations. This code isn’t public and I haven’t looked at it for about 6 months. But it…

Fortunately whether the code is public or not is not relevant.
However, what is relevant is that (1) it can be demonstrated that the
proposed draft is actually implementable, (2) interoperability can be
demonstrated between the various implementations.

Implementation reports are a good way to present to the IETF what was
implemented. For an extensive specification such as the draft at hand
I am certainly missing some detailed information in this regard.

Kind regards,

Job

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jun 2018 10:41:54 -0700

Implementation reports are indeed good, yes.

On Tue, Jun 12, 2018 at 10:27 AM, Job Snijders <[email-masked]> wrote:

> > I did an initial implementation of a client and server for DNS push
> notifications which is based on Stateful Operations. This code isn’t public
> and I haven’t looked at it for about 6 months. But it did identify some
> issues early on in the draft that we corrected for.
>