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>