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

[Ted Lemon <[e-mail]>]

Thanks to everyone for your reviews of the document. I think I'm done
applying last call review comments. I will post a new version of the
document as soon as I get clearance, but meanwhile if you want to see the
current version it's in the github archive here:

https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease

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

> 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
>>>>
>>>