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

[Esko Dijk <[e-mail]>]

Great, the new version resolves all my comments.

So with the new text the Server has to support receiving either the 4-byte or 8-byte variant, and a client could be implemented to only support the 4-byte variant (for both send/receive).

Esko

From: Ted Lemon <[e-mail]>
Sent: Thursday, October 6, 2022 17:06
To: Esko Dijk <[e-mail]>
Cc: David Schinazi <[e-mail]>; DNSSD <[e-mail]>
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease

I've made the following changes based on your comments. I think the right thing to do with respect to client and server behavior is to assume that if the sender doesn't send the 8-byte variant, it doesn't support it. Your suggested behavior is probably better in principle, but what we're anticipating here are clients that might be out of date; there's no reason for example for a client to send the 4-byte variant if it supports the 8-byte variant. Similarly, if the server gets the 4-byte variant, most likely the client wouldn't know what to do with the 8-byte variant. If the server sends the 4-byte variant, it doesn't support the 8-byte variant.

diff --git a/draft-ietf-dnssd-update-lease.xml b/draft-ietf-dnssd-update-lease.xml
index 2348c4f..a1bb6d1 100644
--- a/draft-ietf-dnssd-update-lease.xml
+++ b/draft-ietf-dnssd-update-lease.xml
@@ -6,7 +6,7 @@
      symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
   <front>
     <title abbrev='Dynamic DNS Update Leases'>
-      An EDNS0 option to negotiate Leases on DNS Updates
+      An EDNS(0) option to negotiate Leases on DNS Updates
     </title>

     <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
@@ -47,7 +47,7 @@
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <abstract>
-      <t>This document describes an EDNS0 option that can be used by DNS Update requestors and
+      <t>This document describes an EDNS(0) option that can be used by DNS Update requestors and
       DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale
       resource records that have been added by DNS Updates</t>
     </abstract>
@@ -95,7 +95,7 @@

     <section>
       <name>Mechanisms</name>
-      <t>The EDNS0 Update Lease option is included in a standard DNS Update message <xref
+      <t>The EDNS(0) Update Lease option is included in a standard DNS Update message <xref
       target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/>.</t>
     </section>

@@ -103,13 +103,13 @@
       <name>Update Message Format</name>
       <t>
       Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic
-      Update messages <xref target="RFC2136"/>. This update MUST include the EDNS0 OPT RR, as
-      described in <xref target="RFC6891"/>.  This OPT RR MUST include an EDNS0 Option as shown
+      Update messages <xref target="RFC2136"/>. This update MUST include the EDNS(0) OPT RR, as
+      described in <xref target="RFC6891"/>.  This OPT RR MUST include an EDNS(0) Option as shown
       below.  Note that if a TSIG resource record (<xref target="RFC2845"/>) is included to
       authenticate the update, the TSIG RR MUST appear <em>after</em> the OPT RR, allowing the
       message digest in the TSIG to cover the OPT RR.</t>

-      <t>The Update Lease EDNS0 option is formatted as follows:</t>
+      <t>The Update Lease EDNS(0) option is formatted as follows:</t>

 <figure align="center" anchor="lease_opt" suppress-title="true"><artwork align="center"><![CDATA[
 Field Name       Field Type   Description
@@ -170,6 +170,11 @@ KEY-LEASE        u_int32_t    optional desired (or granted)
        Servers MAY return different lease interval(s) than specified by the requestor, granting
        relatively longer or shorter leases to reduce network traffic due to Refreshes, or
        reduce stale data, respectively.</t>
+        <t>Note that both the 4-byte and 8-byte variant are valid on both clients and servers.
+        If a server receives a 4-byte variant, it MUST respond with a 4-byte variant. If a client
+        sends an 8-byte variant, it MUST accept either an 8-byte variant or a 4-byte variant in
+        the response. If it receives a 4-byte variant, it MUST assume that both the key lease and
+        update lease values are the same on the server.</t>
       </section>
     </section>

@@ -200,7 +205,7 @@ KEY-LEASE        u_int32_t    optional desired (or granted)

        <t>The Update Lease option in a Refresh contains the desired new lease on Requests, and
        the actual granted lease on Responses. The LEASE interval indicated in the Update Lease
-       option applies to all resource records in the Update section, except that if a KEY-LEASE
+       option applies to all resource records in the Update section of the Refresh request, except that if a KEY-LEASE
        interval is included as well, that interval applies to any KEY records included in the
        Update section.</t>
       </section>
@@ -209,7 +214,7 @@ KEY-LEASE        u_int32_t    optional desired (or granted)
        <name>Requestor Behavior</name>

        <t>A requestor that intends that its records from a previous update, whether an initial
-       update or a Refresh, MUST send a Refresh message before the lease elapses, or else the records
+       update or a Refresh, remain active, MUST send a Refresh message before the lease elapses, or else the records
        will be removed by the server.</t>

        <t>Requestors SHOULD Refresh resource records after 75% of the original lease has

On Fri, Aug 19, 2022 at 7:17 AM Esko Dijk <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>> On Behalf Of David Schinazi
Sent: Tuesday, August 9, 2022 00:45
To: DNSSD <[e-mail]<mailto:[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