Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease

[Ted Lemon <[e-mail]>]

To answer your question about battery-operated devices, I think that's
probably something that should be specified elsewhere. E.g. in the Thread
spec we set a minimum and maximum value for the lease limits that a server
is permitted to apply.

On Thu, Oct 6, 2022 at 11:38 AM Ted Lemon <[e-mail]> wrote:

> I've made the following change based on your review:
>
> diff --git a/draft-ietf-dnssd-update-lease.xml
> b/draft-ietf-dnssd-update-lease.xml
> index 88c9cf3..9b35323 100644
> --- a/draft-ietf-dnssd-update-lease.xml
> +++ b/draft-ietf-dnssd-update-lease.xml
> @@ -230,7 +230,9 @@ KEY-LEASE        u_int32_t    optional desired (or
> granted)
>         <t>When sending Refresh messages, the requestor MUST include an
> Update Lease option, as it
>         did for the initial Update. The Update Lease option MAY either
> specify the same
>         intervals as in the initial Update, or MAY use the values returned
> by the server in the
> -       previous Update, whether it was an initial Update or a Refresh.</t>
> +       previous Update, whether it was an initial Update or a Refresh. As
> with Update responses,
> +        the requestor MUST use the intervals returned by the server in
> the response when determining when to
> +        send the next refresh message.</t>
>
>         <section>
>           <name>Coalescing Refresh Messages</name>
>
> On Sun, Aug 21, 2022 at 11:58 PM Kangping Dong <[e-mail]> wrote:
>
>> I have reviewed this document and I think it's ready to publish.
>>
>> Just a small suggestion:
>> We mentioned how servers should handle lease requests in section-4
>> <https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03#section-4>
>> and section-5.3
>> <https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03#section-5.3> with
>> a response including the granted lease(s),
>> but it doesn't say how the client should handle the lease response. IIUC,
>> the client should reset its refresh timer to be fired LEASE_RESPONSED
>> seconds later, but implementers may hesitate in below cases for what lease
>> time they should use for new update messages: If the server returns a
>> shorter lease, should the client use the shorter lease even if it's a
>> battery-backed device and wants to save power?
>>
>> Requiring the client to always respect the server responses works for me,
>> but we probably want to make client behavior clear to make section-5.3
>> complete :)
>>
>>
>>
>> BRs,
>> Kangping
>>
>> On Mon, Aug 22, 2022 at 11:16 AM <g_e_montenegro=
>> [e-mail]> wrote:
>>
>>> Hi folks,
>>>
>>>
>>>
>>> I have read the Update document and I believe it is ready to advance to
>>> the IESG.
>>>
>>>
>>>
>>> Thanks to Stuart and Ted for all the work so far!
>>>
>>>
>>>
>>> Gabriel
>>>
>>>
>>>
>>> *From:* dnssd <[e-mail]> *On Behalf Of *
>>> [e-mail]
>>> *Sent:* Saturday, August 20, 2022 11:32
>>> *To:* [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]
>>> *Cc:* [e-mail]
>>> *Subject:* Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease
>>>
>>>
>>>
>>> I have also reviewed this document in detail and consider it valuable
>>> and ready to publish.
>>>
>>>
>>>
>>> I did notice one typo and one minor grammar issue.
>>>
>>>
>>>
>>> The last line of section 5.2 (just before 5.2.1) includes the word
>>> “initil”. That should be “initial”.
>>>
>>>
>>>
>>> Section 9 (Acknowledgments) includes this sentence:
>>>
>>>    Thanks to Marc Krochmal and Kiren Sekar to their work in 2006 on the
>>> precursor to this document.
>>>
>>> I believe this should be “for their work” not “to their work”.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>>
>>> *From:* dnssd <[e-mail]> *On Behalf Of *Nathan Dyck
>>> *Sent:* Saturday, August 20, 2022 10:50 AM
>>> *To:* Esko Dijk <[e-mail]>; David Schinazi <
>>> [e-mail]>; DNSSD <[e-mail]>
>>> *Cc:* Ted Lemon <[e-mail]>
>>> *Subject:* Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease
>>>
>>>
>>>
>>> *Caution*: This e-mail originated outside Infineon Technologies. Do not
>>> click on links or open attachments unless you validate it is safe
>>> <https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>
>>> .
>>>
>>>
>>>
>>> I’ve reviewed. Looks good to publish
>>>
>>>
>>>
>>> Nathan
>>>
>>>
>>>
>>> -
>>>
>>> Nathan Dyck
>>>
>>> Chief Product Officer
>>>
>>> The Nanoleaf Team
>>>
>>> e: [e-mail] | c: 289-242-0016
>>>
>>>
>>>
>>> Sent from Mobile
>>> ------------------------------
>>>
>>> *From:* dnssd <[e-mail]> on behalf of Esko Dijk <
>>> [e-mail]>
>>> *Sent:* Friday, August 19, 2022 8:17:22 AM
>>> *To:* David Schinazi <[e-mail]>; DNSSD <[e-mail]>
>>> *Cc:* Ted Lemon <[e-mail]>
>>> *Subject:* Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I reviewed this document in detail and have only 1 open (technical)
>>> issue on it, see below.   This is followed by a few minor review comments.
>>>
>>> Based on this, I believe the option is quite useful, and the document is
>>> ready for publication after the open technical issue is resolved by the WG.
>>>
>>>
>>>
>>> Best regards
>>>
>>> Esko
>>>
>>>
>>>
>>> --- Open issue
>>>
>>> 4.2
>>>
>>> Based on the stated requirements in 4, a server developer could assume
>>> the following scenarios are okay:
>>>
>>>    - requester sends the basic Option (lease time only), and the server
>>>    responds with the extended Option (lease / key-lease separately)
>>>    - requester sends extended Option and the server responds basic
>>>    Option.
>>>
>>> A client developer could assume based on the same text that one or both
>>> of these scenarios are not okay / prohibited.
>>>
>>>
>>>
>>> To guarantee interoperability for such cases, we need to say in 4.2
>>> either that a server MAY do this, or alternatively that a server MUST NOT
>>> do this responding with a different option format.  It could be even a rule
>>> that the server can “lengthen” the Option but not “shorten” it.
>>>
>>>
>>>
>>> I don’t have a preference on the solution chosen as long as we pick
>>> something.  Noting that for the client’s point of view, if the server
>>> always responds with the same Option Format it is simpler to implement.
>>>
>>> On the other hand this reduces the flexibility of the server – e.g.
>>> suppose the client asks for 1 week lease (short Option format) and the
>>> server can only grant 27 hours LEASE but can grant 2 weeks KEY-LEASE – then
>>> the server would like to respond with the extended Option format.
>>>
>>>
>>>
>>>
>>>
>>> ---- Minor review comments
>>>
>>>
>>>
>>> General
>>>
>>> EDNS0 vs EDNS(0) – is there a reason for the different spellings?
>>>
>>>
>>>
>>> 5.1
>>>
>>> “The LEASE interval indicated in the Update Lease option applies to all
>>> resource
>>>
>>>    records in the Update section, except that … ”
>>>
>>> -> “in the Update section” may be unclear here. There’s an Update
>>> section in the request, but is there also one in the Response (I assume not
>>> necessarily )?
>>>
>>> -> Easiest here would be to say maybe:
>>>
>>> “The LEASE interval indicated in the Update Lease option applies to all
>>> resource
>>>
>>>    records in the Update section of the Refresh request, except that … ”
>>>
>>>
>>>
>>> 5.2
>>>
>>> “A requestor that intends that its records from a previous update,
>>>
>>>    whether an initial update or a Refresh, MUST send a Refresh message”
>>>
>>> -> grammar error in sentence -that intends what? E.g. is it
>>>
>>> -> “A requestor that intends that its records from a previous update,
>>>
>>>    whether an initial update or a Refresh, *remain*  *active* MUST send
>>> a Refresh message”
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* dnssd <[e-mail]> *On Behalf Of *David Schinazi
>>> *Sent:* Tuesday, August 9, 2022 00:45
>>> *To:* DNSSD <[e-mail]>
>>> *Subject:* [dnssd] WGLC for draft-ietf-dnssd-update-lease
>>>
>>>
>>>
>>> Hi DNSSD enthusiasts,
>>>
>>>
>>>
>>> As promised during our meeting at IETF 114 two weeks ago, we are
>>> starting a Working Group Last Call (WGLC) for
>>> draft-ietf-dnssd-update-lease. As a reminder of our timeline, this document
>>> was adopted by the DNSSD WG in September 2021, folks made comments during
>>> that adoption call, and those comments were addressed by the authors in
>>> July 2022. Additionally, progressing this document is required for us to
>>> publish draft-ietf-dnssd-srp. This WGLC will last for two weeks until
>>> 2022-08-22 at 23:59 UTC. We're interested in hearing whether folks have
>>> read this document and think it is ready for publication. We're also
>>> interested in hearing from folks who think the document isn't ready, or who
>>> see issues that need to be resolved before publication.
>>>
>>>
>>>
>>> The latest draft is available here:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/
>>>
>>>
>>>
>>> Please send responses to the DNSSD list as replies to this email.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> David and Chris
>>> _______________________________________________
>>> dnssd mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>
>>