Telechat Review of draft-ietf-dnssd-update-lease-08
review-ietf-dnssd-update-lease-08-intdir-telechat-combes-2023-07-28-00
review-ietf-dnssd-update-lease-08-intdir-telechat-combes-2023-07-28-00
Hi, I am an assigned INT directorate reviewer for draft-ietf-dnssd-update-lease-08. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>. Based on my review, the document IS ready to go to IETF Last Call and therefore CAN be forwarded to the IESG The following are minor issues (typos, misspelling, minor text improvements) with the document: 1. Introduction Dynamic DNS Update [RFC2136] allows for a mapping from a persistent hostname to a dynamic IP address. This capability is particularly beneficial to mobile hosts, whose IP address may frequently change with location. However, the mobile nature of such hosts often means that dynamically updated resource records are not properly deleted. Consider, for instance, a mobile user who publishes address records via dynamic update. If this user moves their laptop out of range of the Wi-Fi access point, the address record containing stale information may remain on the server indefinitely. An extension to Dynamic Update is thus required to tell the server to automatically delete resource records if they are not refreshed after a period of time. <JMC> It is a bit strange (especially, IIRC, when one of the authors is a former dhc WG chair :)) there is no mention at all on the fact the DNS update job could be already done, at least for the “IPv4 world”, by the DHCP server assigning the IP address to a device: the DHCP server is aware of the end of the lease and should be able to update – in fact to delete, the data in the DNS server if needed. </JMC> <snip> 4.2. Requestor Behavior DNS Update requestors MUST send an Update Lease option with any DNS Update that is not intended to be present indefinitely. <JMC> s/DNS Update requestors MUST send an Update Lease option with any DNS Update that is not intended to be present indefinitely./DNS Update requestors implementing the Update Lease option MUST send an Update Lease option with any DNS Update that is not intended to be present indefinitely. This is to avoid that any device MUST use (i.e., implement) this option when doing a DNS update, even if this device has already the capability to manage efficiently the information (e.g., DHCP server as explained in my previous comment). </JMC> <snip> Note: the reason for the 3000ms (three second) random interval as opposed to some other random interval is to allow for enough time to meaningfully spread the load when many devices renew at once, without delaying so long that the delay in discovery of devices becomes obvious to an end user. A 3-second random delay means that if there are for example 100 devices, and the random number generator spread is even, we would have one renewal every 30ms. In practice, on relatively constrained devices acting as SRP servers, we are seeing the processing time for an SRP registration taking on the order of 7ms, so this seems reasonable. <JMC> SRP: acronym not defined </JMC>