# DNSSD WG at IETF 111 21:30-22:30 UTC Tuesday Session II Room 4 Chairs: - Barbara Stark - David Schinazi AD: Éric Vyncke Note taker - Stuart Cheshire Jabber relay - David Schinazi (though we just relay meetecho chat now) ## Agenda - Administrivia and Status Update: dnssd Chair slides (5 minutes) - DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) * Toerless Eckert, 5 minutes * [draft-eckert-anima-grasp-dnssd](https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/) - Service Registration Protocol for DNS-Based Service Discovery * Ted Lemon * [draft-ietf-dnssd-srp](https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/) - Advertising Proxy for DNS-SD Service Registration Protocol * Ted Lemon * [draft-sctl-advertising-proxy](https://datatracker.ietf.org/doc/draft-sctl-advertising-proxy/) - SRP replication protocol - DNS-SD zone discovery using mDNS - Chairs Wrap-up and AOB (10 minutes) ## Minutes ### Administrivia and Status Update [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-dnssd-chair-slides-01) David presented. The agenda was not bashed. ### DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-dnssd-anima-dns-sd-compatible-services-auto-configuration-00) Toerless Eckert presented Stuart: Is this is using the RFC 6335 list of service type names? Toerless: Yes, intent is to use existing registry. Stuart: If that is the case then the syntax is incorrect. It should have underscore. Toerless: In service registry it just says "printer". IANA doesn't say to add other text to the string. Stuart: Agreed. As long as the encoding is clearly specified, it doesn’t need to be the same as DNS SRV records. Ted: Is the idea to use a translation service or will this use the DNS protocol? Toerless: We already have a new protocol but we don't need to create a new registry. You can see concrete instantiation in existing DNS-SD libraries. Ted: Why create a new protocol? T oerless: I'm only showing here the objectified parameters and not the actions that are defined in the protocol. ANIMA was using mDNS. There is experience in that and we explain why it's not a good thing to do that. ANIMA supports multi-hop forwarding with loop protection (which, by design, DNS-SD over Multicast DNS does not) and without requiring any network infrastructure (such as Ted Lemon’s Service Registration Protocol, which assumes the presence of a Service Registry reachable somewhere on the network.) ### History of DNS-SD [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-dnssd-dns-sd-history-srp-advertising-proxy-and-more-00), slides 1-19 ### Service Registration Protocol for DNS-Based Service Discovery (SRP) and Advertising Proxy for DNS-SD Service Registration Protocol [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-dnssd-dns-sd-history-srp-advertising-proxy-and-more-00) Starts with a hisory of DNS-SD and how we got here in slides 1-19. Slides 20-23 discuss SRP and Advertising Proxy. Will start WGLC for [Service Registration Protocol](https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp) The poll for starting WGLC showed 6 people in favor and 2 purposeful non-hand-raises. Will do call for adoption for [Advertising Proxy](https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy) The poll for adopting had 8 raised hands and no non-raised hands. The chairs will consult with the AD for what to do about the expired (but referenced by SRP) draft [Dynamic DNS Update Leases](https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul). It may be AD sponsored or it may fit within DNS-SD (with re-charter?). The chairs will ask for dradr-sekar-dns-ul to be reviewed by dnssd WG to get better sense of what WG thinks of it. ### SRP replication protocol and DNS-SD zone discovery using mDNS [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-dnssd-dns-sd-history-srp-advertising-proxy-and-more-00), slides 24-35 Toerless: Maybe your problems are solved with the newer better Wi-Fi APs? Ted: No. mDNS relies on everyone being able to hear multicast. I don't think this is a super-heavy lift for enterprise devices. But maybe more for home network devices. Stuart: I want to add something about this. There are enterprise APs that do that. They completely break Multicast DNS. A reason is because of some of the efficiency mechanisms in Multicast DNS. Multicast DNS devices listen for each other’s packets to keep their caches up to date without excessive polling. If a device hears a query but not the corresponding reply, it deletes that data from its cache. This means that when one person prints a document, the printer then disappears for everyone else on that network segment. Somehow these enterprise vendors continue selling this feature without noticing that it totally fails to work. Ted: Their customers do notice that these enterprise access points break Multicast DNS. It’s one of our biggest sources of bug reports.