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

[Ted Lemon <[e-mail]>]

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