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

[Tim Wicinski <[e-mail]>]

Aha Ted - you mean here
https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/issues

(I'm a little slow sometimes)


On Thu, Feb 2, 2023 at 6:01 PM Ted Lemon <[e-mail]> wrote:

> I have added issues in the tracker for the points that you and Chris have
> raised.
>
> On Thu, Feb 2, 2023 at 2:51 PM Ted Lemon <[e-mail]> wrote:
>
>> 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
>>>
>>
>> :)
>>
>