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

[Ted Lemon <[e-mail]>]

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