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

[Ted Lemon <[e-mail]>]

I've updated the text as follows:

diff --git a/draft-ietf-dnssd-update-lease.xml
b/draft-ietf-dnssd-update-lease.xml
index 05f2b81..2348c4f 100644
--- a/draft-ietf-dnssd-update-lease.xml
+++ b/draft-ietf-dnssd-update-lease.xml
@@ -106,7 +106,7 @@
       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
       below.  Note that if a TSIG resource record (<xref
target="RFC2845"/>) is included to
-      authenticate the update, the TSIG RR should appear <em>after</em>
the OPT RR, allowing the
+      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>
@@ -184,14 +184,14 @@ KEY-LEASE        u_int32_t    optional desired (or
granted)
        <name>Refresh Message Format</name>

         <t>Refresh messages are formatted like Dynamic Update Leases
Requests and Responses (see
-        <xref target="update"/> "Update Message Format"). The Refresh
message should be
+        <xref target="update"/> "Update Message Format"). The Refresh
message is
         constructed with the assumption that the result of the previous
update or Refresh is
-        still in effect. The Refresh message should, in the case that the
records added in a
+        still in effect. The Refresh message will, in the case that the
records added in a
         previous update were for some reason garbage collected, result in
those records being
         added again.</t>

-       <t>The Refresh message should not include any update prerequisites
that would, if the state
-       produced by the previous update or Refresh is still in effect,
fail. The update should not
+       <t>The Refresh message SHOULD NOT include any update prerequisites
that would, if the state
+       produced by the previous update or Refresh is still in effect,
fail. The update SHOULD NOT
        be constructed to fail in the case that the state produced by the
previous update or Refresh
        has for some reason been garbage collected.</t>

@@ -238,7 +238,7 @@ KEY-LEASE        u_int32_t    optional desired (or
granted)
          the server, including those not yet close to expiration, so long
as at least one
          resource record in the message has elapsed at least 75% of its
original lease. If the
          requestor uses UDP, the requestor MUST NOT coalesce Refresh
messages if doing so would
-         cause truncation of the message; in this case, multiple messages
or TCP should be
+         cause truncation of the message; in this case, either multiple
messages or TCP SHOULD be
          used.</t>

          <t>Requestors SHOULD NOT send a Refresh messages when all of the
records in the
On Wed, Aug 17, 2022 at 1:48 PM Jonathan Hui <jonhui=
[e-mail]> wrote:

> I have reviewed the latest version of this document
> (draft-ietf-dnssd-update-lease-02) and believe it is ready to publish (with
> some minor nits noted below).
>
> The OpenThread implementation of SRP includes the Update Lease option and
> is up-to-date with the latest draft. It is being used by a number of
> community members, especially those implementing Matter. I am not aware of
> any open issues regarding usage of the Update Lease option.
>
> Minor comments:
>
> Section 4: "the TSIG RR should appear _after_", should this be normative
> "SHOULD"?
>
> Section 5.1: many statements with non-normative "should", should these be
> normative "SHOULD"?
>
> --
> Jonathan Hui
>
>
>
> On Mon, Aug 8, 2022 at 3:45 PM David Schinazi <[e-mail]>
> wrote:
>
>> 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
>>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>