DNS-SD (Extensions for Scalable DNS Service Discovery) Working Group

Friday November 12 2021 16:00-17:00 UTC (Session III)

IETF Agenda Link

Chairs: Barbara Stark, David Schinazi, Chris Box

AD: Éric Vyncke

Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=dnssd&short=&item=1

Minutes: https://notes.ietf.org/notes-ietf-112-dnssd

Notetakers: Barbara Stark, Jonathan Hui

Agenda

Notes

Administrivia

David Schinazi presented. Slides: Chair Slides

Service Registration Protocol for DNS-Based Service Discovery

Ted Lemon presented. Slides: draft-ietf-dnssd-srp and Sleep Proxy status

Ted skipped straight to Sleep Proxy discussion, since Administrivia already summarized status of other aspects of SRP.

David: What other draft could Sleep Proxy go into?

Ted: There is an expired ID [https://datatracker.ietf.org/doc/draft-cheshire-edns0-owner-option/] that describes Sleep Proxy.

Stuart Cheshire: I think right thing to do is move to another doc. Might want to keep owner options separate. Ted and I thought SRP and Sleep Proxy had sufficient overlap (both using DNS update with lifetime). Agree with Ted now - tying to SRP doc no longer makes sense.

David: Proposal is to leave Sleep Proxy out of SRP and bring in (at later date) via separate draft. Opposition? No-one expressed opposition.
(Esko expresses +1 for leaving out Sleep Proxy on the chat.)

Éric Vyncke: SRP is in WGLC. Wouldn’t such a change require another WGLC?

David: Already extended WGLC by two weeks to specifically ask this. Haven’t seen any objection to removal on the list.

An EDNS0 option to negotiate Leases on DNS Updates

Ted Lemon presented. Slides: An EDNS0 Lease Option for DNS Update

Ted: Do we want to slim down the document so we can publish quickly?

Peter: Would this apply outside SRP use cases?

Ted: Sure, but not required. If options is present, here’s what you do.

Peter van Dijk: Right and vendors might expect to see this feature at some point. Please let dnsops know at some point.

David: Chairs had discussion among DNS WG chairs & ADs (dnsop, dnssd, dprive). Would adopt in DNSSD but doc would be sent to DNSOP.

Peter: Thank you.

Stuart: The lease time for DNS updates is generally useful. When DNS Update was defined it was an alternative to making edits to a zone file. But all edits were permanent. Update lease makes it more suitable for machine-to-machine style communication.

David: Poll - 9 people who have read the draft. 9 people explicitly did not raise their hand. Next step authors to address comments raised during adoption. Discuss more. If not too much contention, then can progress quickly to WGLC. Hopefully can discuss at dnsop at IETF 113.

Advertising Proxy for DNS-SD Service Registration Protocol

Ted Lemon presented. Slides: Advertising Proxy for DNS-SD SRP

David: Poll on who has read the document: 7 read, 6 explicitly did not read.

Esko Dijk: I did send comments by email. Not sure if Ted has had time to read them.

Ted: I don’t think I did. Will double check. Don’t have a lot of time in meeting, but will take a look at your comments offline.

Esko: Main point was that one section (2.3.1.1.) needs to be simplified. Almost too complex to parse when casually reading. Otherwise looks good.

David: Next steps - Ted has some edits to make and address Esko’s comments. Submit revised version and let mailing list know.

Ted: Yes.

David: Existing work seems to have all action items on Ted. Maybe we should focus on existing adopted WG docs before taking on new work.

Ted: Fair enough. Someone (who is in the room) has volunteered to help and perhaps be a co-author.

David: Great idea. Adding a co-author before asking for adoption would give us more confidence that work will be done.

Automatic Replication of DNS-SD Service Registration Protocol Zones

Ted Lemon presented. Slides: Service Replication Protocol

Chris: Thoughts from the WG?

Stuart: Thank you to Ted for bringing this to the WG. But let’s move on.

David: Sounds good. From chairs’ perspective. If you can go through action items and prioritize. It would also be good to add a co-author. My only concern is adding new work does not delay existing work. If we can address that concern, then no issue adopting this work.

Permissionless Advertising and Discovery of DNS-SD Authoritative Zones

Ted Lemon presented. Slides: Discovering DNSSD zones using DNSSD

Stuart: (on slide 4) Idea is instead of multicasting to all devices, client talks to a server using unicast which is much more efficient. Bootstrapping issue is how to identify entity on the network to use.

Ted: What entities are available that can act as that server – there might be more than one.

David: Any questions? Next steps similar to previous draft – encourage you to find a co-author. Using this for Matter?

Ted: Sure.

David: To adopt, implication is that it’s a general purpose specification.

Ted: That’s the intention. Remember I was trying to do homenet naming architecture? That failed because we tried to do too much at once. So now I’m trying to do it piecemeal by defining the building blocks.

David: Makes perfect sense. To adopt, goal would be to have interest between various folks.

Stuart: Makes sense. Thanks to Ted for all the work on authoring docs and implementation. Reason Ted has been working so hard is lots of use for this. Encouraging people outside IETF to engage. Work going on with Thread, which is using SRP to reduce reliance on multicast. Thread is being used by Matter (formerly Project CHIP) in Connectivity Standards Alliance (formerly Zigbee Alliance). Changed name to reflect work on IP-based technologies. Now discussion that we should do the same for Wi-Fi (i.e. using more unicast and less multicast). Actively trying to educate those outside IETF to participate in IETF.

David: Thanks for background and doing work. And bringing in new eyeballs is very good.

A ‘Time Since Registration’ Resource Record for Multicast DNS, draft-tllq-tsr-00

Ted Lemon presented. Slides: A Time-Since-Registered Resource Record for mDNS

David: Same conclusion as other drafts – interesting and in scope. If we thinking advertising proxy has dependency on this, can help bring it in. Would love to see additional co-authors from other affiliations.

Close

David: Thanks so much, Barbara, for everything. Will miss you!