Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD

I have read this spec draft and support its adoption. It is one of the key
components for the
"Service Registration Protocol for DNS-Based Service Discovery" which is
used for
connectivity protocols like Matter.

BRs,
Kangping

On Thu, Sep 2, 2021 at 6:16 AM Jonathan Hui <jonhui=
40google.com@dmarc.ietf.org> wrote:

> I have read this draft and support its adoption in DNSSD.
>
> Some comments on draft-sekar-dns-ul-03:
>
> Section 3: We should update the reference to RFC 2671 to RFC 6891.
>
> Section 4: The OPT RR format table seems inconsistent with RFC 6891 (e.g.
> the CLASS/MTU value).
>
> Thanks.
>
> --
> Jonathan Hui
>
>
>
> On Wed, Aug 18, 2021 at 9:31 AM Chris Box <chris.box.ietf@gmail.com>
> wrote:
>
>> WG members,
>>
>> This email starts a call to adopt
>> https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the
>> DNSSD working group.
>>
>> What is this? Abstract:
>>    This document proposes a new EDNS0 option that can be used by DNS
>>    Update clients 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
>>
>> Adoption means that formal change control passes from the authors to the
>> working group. All subsequent substantive changes require WG rough
>> consensus. Adoption represents a commitment that the DNSSD WG will spend
>> time on the draft, with the aim of progressing it towards publication.
>>
>> Note that in theory the draft could fit the charters of both DNSOP and
>> DNSSD, but we're proposing DNSSD as this specific functionality is required
>> as part of draft-ietf-dnssd-srp
>> <https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/> which is
>> already well advanced. The relevant charter text is:
>>
>> 2. To develop an improved, scalable solution for service discovery
>>    that can operate in multi-link networks, where devices may be
>>    in neighboring or non-neighboring links, applicable to
>>    the scenarios above.  The solution will consider tradeoffs between
>>    reusing/extending existing protocols and developing entirely new
>>    protocols.
>>
>> This email is being copied to DNSOP to solicit additional feedback from
>> the expertise there, but note this is NOT a call to adopt into DNSOP.
>>
>> You should be aware this draft is covered by an IPR disclosure. Details
>> of Apple's licensing terms can be found at
>> https://datatracker.ietf.org/ipr/1236/.
>>
>> Within DNSSD we are asking two questions:
>> 1) If you have read this six-page draft and are content with it, or would
>> like to amend/discuss it further inside the working group, please speak up
>> now.
>> 2) If you believe that this document is not something the DNSSD working
>> group should be working on, please also say so.
>>
>> For this call to succeed, we'll need statements of explicit support from
>> people who have read the draft. The document does not have to be perfect,
>> but it needs to be solving a problem the WG wants to solve in a way
>> approximately as described in the draft.
>>
>> Please send statements in support or against, as responses to this email.
>> This call will be open until 2021-09-03 23:59 UTC.
>>
>> Thanks,
>> Chris
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>