Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD

[Esko Dijk <[e-mail]>]

All,

I have read the draft, and support its adoption into the DNSSD WG. Introducing the lease lifetime plus negotiation looks useful to have, for use cases with dynamic service changes, connectivity changes and intermittent powering on/off of devices.
Also it is required for the SRP to advance.

I do have one review question on Section 5.3 that may be further discussed if this becomes a WG document: it says the server shouldn’t perform the refresh if there is >50% lease time left.  Is this introduced to avoid clients that repeatedly refresh by mistake or by design?
I.e. reduce the motivation a client may have to repeatedly refresh too often.

Looking from a ‘honest’ client perspective:   maybe a client has a good reason to refresh earlier, e.g. it is now awake and will shortly go to sleep and wants to keep the service registration active during that sleep time. (See SRP document for the “sleep proxy” function that would allow sleeping while keeping services active.)   Or maybe the client has just decided that a longer lease time is better and just wants to refresh to communicate the longer lease time to the server at the moment of making this decision (where the decision may be triggered by some human UI actions or by internal state, software update with reboot, etc.)

Best regards
Esko

From: dnssd <[e-mail]> On Behalf Of Chris Box
Sent: Wednesday, August 18, 2021 18:31
To: dnssd <[e-mail]>
Cc: [e-mail]
Subject: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD

WG members,

This email starts a call to adopt https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the DNSSD working group.

What is this? Abstract:
   This document proposes a new EDNS0 option that can be used by DNS
   Update clients and DNS servers to include a lease lifetime in a DNS
   Update or response, allowing a server to garbage collect stale
   resource records that have been added by DNS Updates

Adoption means that formal change control passes from the authors to the working group. All subsequent substantive changes require WG rough consensus. Adoption represents a commitment that the DNSSD WG will spend time on the draft, with the aim of progressing it towards publication.

Note that in theory the draft could fit the charters of both DNSOP and DNSSD, but we're proposing DNSSD as this specific functionality is required as part of draft-ietf-dnssd-srp<https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/> which is already well advanced. The relevant charter text is:

2. To develop an improved, scalable solution for service discovery
   that can operate in multi-link networks, where devices may be
   in neighboring or non-neighboring links, applicable to
   the scenarios above.  The solution will consider tradeoffs between
   reusing/extending existing protocols and developing entirely new
   protocols.

This email is being copied to DNSOP to solicit additional feedback from the expertise there, but note this is NOT a call to adopt into DNSOP.

You should be aware this draft is covered by an IPR disclosure. Details of Apple's licensing terms can be found at https://datatracker.ietf.org/ipr/1236/.

Within DNSSD we are asking two questions:
1) If you have read this six-page draft and are content with it, or would like to amend/discuss it further inside the working group, please speak up now.
2) If you believe that this document is not something the DNSSD working group should be working on, please also say so.

For this call to succeed, we'll need statements of explicit support from people who have read the draft. The document does not have to be perfect, but it needs to be solving a problem the WG wants to solve in a way approximately as described in the draft.

Please send statements in support or against, as responses to this email. This call will be open until 2021-09-03 23:59 UTC.

Thanks,
Chris