Subject: [dnssd] dnssd WG ietf-93 minutes

From: Ralph Droms <[email-masked]>
Date: Tue, 18 Aug 2015 15:57:43 -0400

...have been posted.  Please review and respond with any comments before the revisions deadline of 9/14.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 Aug 2015 17:22:27 -0400

The minutes are posted here: https://www.ietf.org/proceedings/93/minutes/minutes-93-dnssd

> On Aug 18, 2015, at 3:57 PM 8/18/15, Ralph Droms <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 18 Aug 2015 22:31:25 -0400

> On Aug 18, 2015, at 5:22 PM, Ralph Droms <[email-masked]> wrote:
> 

As far as the DNS Push draft goes, here is a list of comments that I wrote down after listening to the audio. I’m tracking these things but thought I’d send them to the list for others to stay informed in case you weren’t at the meeting or didn’t listen to the audio. Any clarifications or mis-interpretations would be appreciated.

1. Stuart said he wasn’t aware of other DNS long lived connection mechanisms until recently and wanted to incorporate those references into the DNS Push Draft.
	I haven’t listened to the DNS Ops audio yet. There are some long lived references in the draft already so I will try to flush out anything that is missing.

2. Dan Hoffman - Not sure you should tie long-lived-ness to TLS. That might be a mistake.
	I don’t think this is what we’ve done. We have long lived TCP connections and we have TLS for privacy. It’s not likely we could get through a security review without privacy.

3. adoption as a working group document - take to list
	I thought this was settled last time but if we need this, then the chairs need to get it done.

4. Olafur Gudmundsson - long lived connections are very useful in general, do we separate the push from the long lived DNS connections
	This will slow down things a lot. I would prefer to get input from others on long lived connections to make sure they are re-usable as specified but make the document stand-alone so it can progress without other dependencies.

5. Is TLS required? Keepalive document doesn’t reference TLS (draft-ietf-dnsop-edns-tcp-keepalive-02.txt)
	I assumed privacy is required. TLS is a way to achieve privacy. Maybe an advisor from the security area could advise.

6. Ray Bellis - DNSOP work on TCP - Are long lived sessions prone to reset attacks? Look at notes from DNSOP meeting.
	I will explore this.

7. Draft currently says ID has to be zero. Not sure this is a problem but kind of surprising.
	Since we required TCP, the session speaks for itself and the ID is not needed. Rather than make it ambiguous, we made it zero.

Thanks,
Tom