Minutes IETF111: dnssd
minutes-111-dnssd-00

# 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? Toerless: 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
dvertising 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.