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

[Ted Lemon <[e-mail]>]

Yeah, theoretically it's possible that there are servers out there that
don't support 8-byte, but there's no way to make them work with clients
that send 8-byte values, and I don't think it's important to allow for
that, since in practice the only server I know of that does that is the one
that comes with mDNSResponder, and I doubt it's in use in a significant
number of installations.

On Wed, Oct 12, 2022 at 9:30 AM Esko Dijk <[e-mail]>
wrote:

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