Subject: [dnssd] Provisional agenda for IETF98

From: Tim Chown <[email-masked]>
Date: Tue, 14 Mar 2017 16:20:48 +0000

Hi,

The provisional agenda for IETF98 is included below. Please let Ralph or I know if you have suggestions for changes or additions.

There have been new versions of each draft posted - thanks authors! - so it would be great to get WG review of the documents in advance of the meeting.

The chairs believe that the DNS-SD Discovery Proxy is ready to progress to the IESG, and that DNS Push should be ready for WGLC. The DNS session signalling work is progressing in the dnsop WG, and we believe that is also close to WGLC. So we should soon have the key pieces of our WG charter published.

Our ongoing/future work then includes:
- determining the nature of the proposed DNS-SD Advertising Proxy, for which we have an open discussion slot; there is no draft as yet;
- continuing work on the DNS-SD Privacy and device pairing drafts; Christian will present on these;
- pulling together a BCP on DNS-SD deployment for campus/enterprise networks; we have some material already, but no draft as yet;
- determining how best to apply DNS-SD in unmanaged home networks; Ted has a couple of early drafts in this space which will hopefully help drive productive discussion.

You’ll also have noticed that we’ve updated the WG milestones; apologies for the resulting list spam!

Best wishes,
Tim and Ralph

—

DNSSD WG Provisional Agenda

IETF98, Chicago
Tuesday 28th March 2017
16:40 - 18:40 local time

Chairs’ Introduction (inc. updated milestones) Chairs, 5 mins

DNS Push Notifications Stuart Cheshire, 5 mins
https://tools.ietf.org/html/draft-ietf-dnssd-push-10
(and accompanying https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02 in dnsop WG)

DNS-SD Discovery Proxy Stuart Cheshire, 5 mins
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-06

DNS-SD Advertising Proxy - discussion 20 mins

Privacy Extensions for DNS-SD Christian Huitema, 15 mins
https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01

Device Pairing Using Short Authentication Strings Christian Huitema, 15 mins
https://tools.ietf.org/html/draft-ietf-dnssd-pairing-01

DNS-SD Deployment for campus/enterprise networks - BCP document discussion 20 mins
https://github.com/pusateri/draft-pusateri-hybridproxy-impl/blob/master/draft-pusateri-dnssd-hyp-impl.txt

Simple Homenet Naming and Service Discovery Architecture Ted Lemon, 15 mins
https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00

Stateful Multi-Link DNS Service Discovery Ted Lemon, 10 mins

https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00

Summary of actions and close Chairs, 10 mins

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 19 Mar 2017 13:26:04 -0700

> The provisional agenda for IETF98 is included below. Please let Ralph or I know if you have suggestions for changes or additions.

Thanks Tim. This looks good.

Here is the status as I see it:

1. draft-ietf-dnssd-hybrid (Discovery Proxy) — ready to progress to the IESG.

2. draft-ietf-dnssd-push — ready for WGLC.

3. draft-ietf-dnsop-session-signal — ready for DNSOP WGLC.

Other documents I did not get done by the draft deadline, but really hope to have ready to submit when submissions re-open on Monday 27th. It would not be reasonable to expect people to discuss the content in our Tuesday meeting, but it would be good if I could have a few minutes to draw people’s attention to them.

4. draft-cheshire-dnssd-roadmap — there are many components that make up service discovery, at various levels, and few people really understand how they all fit together. This short overview document is intended to remedy that.

5. Discovery Broker — this is a kind of meta Discovery Proxy. From the outside it looks like a basic Discovery Proxy. Except, it doesn’t get its answers by querying using Multicast; it gets its answers by querying other Discovery Proxies. It has two purposes. One is client efficiency. Instead of a client opening three Push connections to three Discovery Proxies on three different links, the client can open a single Push connection to a Discovery Broker, which has its own connections to the relevant Discovery Proxies, and aggregates the results for the client. The second purpose is infrastructure efficiency. Instead of a thousand clients all opening separate Push connections to a poor little overloaded router on the link, the thousand clients can open Push connections to a big-iron Discovery Broker in the data centre, which has a single connection to the actual Discovery Proxy embedded in the router on the link. That way, the router on the link only has to serve a single client — the Discovery Broker.

6. Sleep Proxy — Apple has shipped this for years; I need to document it. It’s basically DNS Update, plus garbage collection, plus Wake-on-LAN magic packet. Simple, but should be documented.

7. Advertising Proxy — this allows a device, with appropriate security, to advertise services via multicast service discovery, on a physical link to which the device is not directly attached. It has applicability for mesh networks like 6LoWPAN, where the trusted devices are conceptually part of the network, but can’t themselves use multicast. There have been efforts to support multicast on mesh networks, but this may be an overly heavyweight solution if there’s a better way to advertise services without requiring the mesh to support multicast in its full generality. It’s basically Sleep Proxy without the Wake-on-LAN magic packet.

8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”

Stuart Cheshire

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 20 Mar 2017 10:07:50 +0200

> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confes…

I have thought quite a bit about this over the years (less recently, as I am mostly working on non-IETF stuff).

I am not very fond of discovery proxies talking with each other; you wind up with O(N^2) connections given N links. 

Instead, I would probably do this as function of discovery broker; either

a) it provides rewritten information to its clients (somewhat fishy, as if mdns info contains computer-42, and there is another computer-42, you would wind up with e.g. computer-42-2 for one of them)

b) discovery broker <> discovery proxy action is actually bidirectional, and DB can tell DP to force client to rename.

Either design is relatively simple given devices that do not move. 

However, in presence of moving devices, I am somewhat uncertain on what is the correct way; as device moves, it gets new IP address, so how to correlate that X.link1.example.com is actually X.link2.example.com? I can think of few obvious heuristics but given recent work in IPv6 address pseudorandomization per link, they seem error prone and therefore not advisable. Therefore I am currently leaning towards design

c) DB just shows (DNS-SD) services, even if they are duplicate (omitting extra ones?), and they point to host names on various links that may not be unique. In other words, just omit conflict resolution across links.

or even

d) DB just shows (DNS-SD services) for each link; based on cursory reading of RFC 6763, nothing prevents PTR _http.tcp.example.com => site on X._http._tcp.link1.example.com

I am not quite sure if d) is valid, but at any rate, I am really leery of options a and b currently due to how they interact (or actually do not interact _well_) with moving hosts.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 08:18:09 -0400

It might be useful to collect some operational data on this.   My experience is that "duplicate" devices are always the same device appearing either sequentially or simultaneously on two different links.   Defending the name therefore has the effect of causing the device to constantly rename itself, so that it never has a stable name.   This really sucks from a usability perspective.   Having the service simply mark duplicate names, rather than defending them, seems more likely to work.   This is what we suggest in the simple homenet naming architecture draft.

> On Mar 20, 2017, at 4:07 AM, Markus Stenberg <[email-masked]> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 Mar 2017 17:14:17 +0000

Hi Stuart,

> On 19 Mar 2017, at 20:26, Stuart Cheshire <[email-masked]> wrote:
> 

Ralph and I agree, and will be acting on this very soon. One of us will need to do the shepherd writeup. I recall there is the discovery proxy IPR disclosure we need to include.

> Other documents I did not get done by the draft deadline, but really hope to have ready to submit when submissions re-open on Monday 27th. It would not be reasonable to expect people to discuss the…

You have 20 minutes at present. We may be able to raise that a little.

> 5. Discovery Broker — this is a kind of meta Discovery Proxy. From the outside it looks like a basic Discovery Proxy. Except, it doesn’t get its answers by querying using Multicast; it gets its ans…

OK, this is interesting. It touches on both the efficiency issues that were raised previously in the WG, and also the work that Ralph and Tom are doing on enterprise best deployment practices. 

> 7. Advertising Proxy — this allows a device, with appropriate security, to advertise services via multicast service discovery, on a physical link to which the device is not directly attached. It ha…

This is what Ralph and I reserved the 20 mins for.  But if we can get WG feedback on each topic you’ve raised, that would of course be great.
> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confes…

This overlaps with previous discussions of course, and what Ted has spoken on previously.  We don’t really have a good answer for this yet. 

Tim