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

[Nathan Dyck <[e-mail]>]

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