[dnssd] Intdir telechat review of draft-ietf-dnssd-update-lease-08

[Jean-Michel Combes via Datatracker <[e-mail]>]

Reviewer: Jean-Michel Combes
Review result: Ready with Nits

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>