Re: [dnssd] Please review substantive changes to Update Lease

[Ted Lemon <[e-mail]>]

On Thu, Feb 2, 2023 at 2:40 PM Tim Wicinski <[e-mail]> wrote:

> When sending an initial update, the requestor MUST delay the initial
>>> transmission by a random amount of time across the range of 0-3000
>>> milliseconds, with a granularity of no more than 10 milliseconds. This
>>> prevents synchronization of multiple devices of the same type at a site
>>> upon recovery from a power failure. This requirement applies only to the
>>> initial update on startup: since renews include a random factor as well,
>>> any synchronization that occurs after such an event should quickly
>>> normalize.
>>
>>
>> My personal thought on this, wearing no hats, is to wonder how realistic
>> is 10ms accuracy for a low-power device? I understand the rationale, which
>> is to permit 300 different slots in which the transmission could occur.
>> However I wonder if the granularity ought to be a softer requirement. Views
>> from implementers needed.
>>
>
> I figure folks are also considering the more and more movement to PTP on
> devices in general.
>

What does "PTP" stand for?


> This sentence seems wonky:
>
>  If the requestor uses UDP, the requestor MUST NOT coalesce Refresh
> messages if doing so would cause truncation of the message;
> in this case, the requestor should either send multiple messages should
> use TCP to send the entire update at once.
>
> Maybe "or should use TCP to send the entire update"?
>

Grammar is hard.


> Finally, section 8's security considerations are rewritten and greatly
>> expanded. The commit was
>> https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/pull/19/files.
>>
>> Section 8 <https://rfc-editor.org/rfc/rfc2136#section-8> of [RFC2136
>>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-04.html#RFC2136>]
>>> describes problems that can occur around DNS updates. Servers implementing
>>> this specification should follow these recommendations.
>>> Several additional issues can arise when relying on Update Lease. First,
>>> a too-long lease time is not much different than no lease time: the records
>>> associated with this lease time will effectively never be cleaned
>>
>>
> "Several additional issues can arise when relying on Update Lease."
>
> could this be "when relying on an Update Lease"?
>

Hm, maybe so. I was referring to the document, but that's probably not
correct.


> up. Servers implementing Update Lease should have a default upper bound on
>>> the maximum acceptable value both for the LEASE and KEY-LEASE values sent
>>> by the client. Servers MAY provide a way for the operator to change this
>>> upper limit. We recommend that the default values for these limits should
>>> be 24 hours and 7 days, respectively.
>>> The second issue is that a too-short lease can result in increased
>>> server load and a failure to persist data subject to such a short lease.
>>> Servers implementing Update Lease MUST have a default minimum lease
>>
>>
> This sentence reads odd to me (but this could be me).
>
> The second issue is that a lease which is too short can result in
> increased server load and a failure to persist data for such a lease.
>

OK.

Key management strategy is out of scope for this document, however.
>
> Can we drop the "however"?  It just is.
>

Be or be not. There is no try.

thanks for grinding this out Ted
>

:)