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

[Jonathan Hui <[e-mail]>]

Looks good to me. Thanks for addressing my comments!

--
Jonathan Hui



On Thu, Oct 6, 2022 at 7:53 AM Ted Lemon <[e-mail]> wrote:

> 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
>>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>