From nobody Wed Sep 1 15:15:51 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8293C3A1B5A for ; Wed, 1 Sep 2021 15:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbWyHiOxIc_P for ; Wed, 1 Sep 2021 15:15:43 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E243A1B59 for ; Wed, 1 Sep 2021 15:15:42 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id r26so101548oij.2 for ; Wed, 01 Sep 2021 15:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dmekkPI7tZ1MD+iavE/JbE+6Lodj15nIMo2CegS8w0A=; b=pm8b6JxosTCPxZ5Ohf1rzw+Uv6Qy+MxTP2zpNABevffH99lhIHE7yXix9TzpcRiWEx MPverrlXH9IHGMzb6EDmGaTarVWR4Mh72aCSvqKnwg4kvGhXlFpTfGTQEjtBkewd+TWe Wy6H/6SiuFidZ9O8DPErtNQ2Q6wcr/BnW48RLdx/R7oKZIcnVBgE7xgzmHCyxOl7qWrb 1AnraIgNxaDszGHNupktCgix8ofsrxsSXWps9e+jd+5fUK5XubcYcME023zMKlzNA+7i 8hro+/kvFVEVwpDf6rtnRITkZfO9nfnyiAZlzsxc8GyRr+MGHu3116hyGCnyH0Bz+T38 OhjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dmekkPI7tZ1MD+iavE/JbE+6Lodj15nIMo2CegS8w0A=; b=Sg+iJbgR6sVgzGZQRgeDh3us4bXXgPfWZ63Xi03R6vb68gHVkAFZftQqA/xpWNynlj CqFNT4nGB/EWtxgBg1q0Dr7eer7Nc/1ubGbz+hq1oGrGCWlj4UOPvoSnlRs3MnHXBQZj sbj7PdH6G2T0RNkekUzYNzFXI0PAo1TdgFVIX55ZbcG8gxDz0Q5Bw7sTCigI/B4fz6gc W18E9xb/Vb360etanneADXsw2qbk1r9sUFp//1TiJTpEObhxYXDBFaPZpfE4Z9567CR7 mofyoec/jcrQHtc85BzhsSBGs3sag5Dsx7o+LHkBJLdH5NQsjYB75GJhXnps2pg9ZP5h OlcA== X-Gm-Message-State: AOAM532PGMc0zOqwl8D7407WrvCV/JrhkgB7acJX1wuywQb7vt4sSZfu /UZPzRoRmyTLU1bDqB6i3Yfc23vdH0K4Mm1Hce3Q8g== X-Google-Smtp-Source: ABdhPJxLNn19OYr/pgW9vRn2tZNBK1NVMaOHeN75JxG0Agjrs1mT99MP6zV+3Xbp+0TFcmpsStETUrOh/HOE4P1Dmek= X-Received: by 2002:aca:f386:: with SMTP id r128mr53252oih.168.1630534541462; Wed, 01 Sep 2021 15:15:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Wed, 1 Sep 2021 15:15:30 -0700 Message-ID: To: Chris Box Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000023ce6805caf668bb" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 22:15:49 -0000 --00000000000023ce6805caf668bb Content-Type: text/plain; charset="UTF-8" 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 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 > 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 > --00000000000023ce6805caf668bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read=C2=A0this draft and support its adoption = in DNSSD.

Some comments on=C2=A0draft-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.

<= div>--
Jonathan Hui



On = Wed, Aug 18, 2021 at 9:31 AM Chris Box <chris.box.ietf@gmail.com> wrote:
WG members,

This email start= s a call to adopt https://datatracker.ietf.org/doc/html/draf= t-sekar-dns-ul-03 into the DNSSD working group.

What is this? Abstract:
=C2=A0 =C2=A0T= his document proposes a new EDNS0 option that can be used by DNS
=C2=A0 =C2=A0Update clients and DNS servers= to include a lease lifetime in a DNS
=C2=A0 =C2=A0Update or response, allowing a server to garbage collect = stale
=C2=A0 =C2=A0resource recor= ds that have been added by DNS Updates

Adop= tion means that formal change control passes from the authors to the workin= g group. All subsequent substantive changes require WG rough consensus. Ado= ption represents a commitment that the DNSSD WG will spend time on the draf= t, with the aim of progressing it towards publication.
=C2=A0 =C2= =A0
Note that in theory the draft could fit the charters of both = DNSOP and DNSSD, but we're proposing DNSSD as this specific functionali= ty is required as part of=C2=A0draft-ietf-dnssd-srp=C2=A0whic= h is already well advanced. The relevant charter text is:

2. To develop an improved, scalable soluti= on for service discovery=C2=A0
= =C2=A0 =C2=A0that can operate in multi-link networks, where devices may be<= /font>
=C2=A0 =C2=A0in neighboring or no= n-neighboring links, applicable to
=C2=A0 =C2=A0the scenarios above.=C2=A0 The solution will consider tradeo= ffs between
=C2=A0 =C2=A0reusing/= extending existing protocols and developing entirely new
<= font face=3D"monospace">=C2=A0 =C2=A0protocols.=C2=A0
=C2= =A0 =C2=A0
This email is being copied to DNSOP to solicit additio= nal feedback from the expertise there, but note this is NOT a call to adopt= into DNSOP.

You should be aware this draft is cov= ered by an IPR disclosure. Details of Apple's licensing terms can be fo= und at https://datatracker.ietf.org/ipr/1236/.
=C2=A0 =C2=A0
<= div>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/discus= s it further inside the working group, please speak up now.
2) If= you believe that this document is not something the DNSSD working group sh= ould be working on, please also say so.

For th= is call to succeed, we'll need statements of explicit support from peop= le who have read the draft. The document does not have to be perfect, but i= t needs to be solving a problem the WG wants to solve in a way approximatel= y as described in the draft.

Please send statement= s in support or against, as responses to this email. This call will be open= until 2021-09-03 23:59 UTC.
=C2=A0
Thanks,
C= hris

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--00000000000023ce6805caf668bb-- From nobody Tue Sep 7 01:02:02 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF73A1306 for ; Tue, 7 Sep 2021 01:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.097 X-Spam-Level: X-Spam-Status: No, score=-17.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61DsNtMMAUWz for ; Tue, 7 Sep 2021 01:01:55 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDE73A130E for ; Tue, 7 Sep 2021 01:01:55 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id u11-20020a17090adb4b00b00181668a56d6so1517401pjx.5 for ; Tue, 07 Sep 2021 01:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=L1+88JsK1/dhLGmITg+iu92iO748YzJ7oPJEsrhKahk=; b=AJ/6ygUqfemKyaPOM5P4jRW20GxjFSi7eTxeToq1Wr+EF3Fphb/7/UqZRdB/BhwtD+ qTMvpRq3O03hYxLA9Oifhf1JFmeI5rLVWH73HJzYzcE+EPGSP7SHnOytIVKZIrRb9A3y KGjs5qsyzEf7DAI8iwhx0EK6hWSDwM9trds2C+BTudJYWHbIEXObZBzHLFyZw3jCLQqu 9DxAroMTO9zpuTFtxyw+x5F2jdl+qCCzS/e1gvnD0k2aho6IWIVBIvmIaODH2jYRYvZl sKuwSCofAz9UXnO7BBklSzIkE1BvX14HxRZj0U2uvj51kKO1YJphRLnbfFtpqiNwJ87E qQ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L1+88JsK1/dhLGmITg+iu92iO748YzJ7oPJEsrhKahk=; b=tH5eKqSnmq0rCoA+F2YMkb4BvVAiz9t6o9S/32oivhSHOHl6PTBSQkHKh+nQ7QFBhX IMtrPwvUPqr/NlwNzyAMNDrEUOAtIP9J5ojM/kvwCQhehL6eTTlrSAcau4PbnuJLjigH PpwaegMVryqJBm5zdeZXTswYOIBCzwvqpbFjC7FeiJ9jcqCY6q8vv71lo6vjTEGibye+ 9z3RrjpeMfLKunbsKU08fcpcothDtdEjIpl4MPYEuP6ahNA1yQGfV+VhfPxVtifUbn6O B7OGZ31H9+27qB2Tji8DtCK9ACSnW7f6WVTRf5/3VRWYo08vlTCvASZKfxElTD8qeFDd SXwA== X-Gm-Message-State: AOAM5303hHca3IDyGrVxMoLfTcH+suAmBBBilpkmt1mR2cxSD84DiGGw Xah3yBrQknqAPEbwom3dFsHxGp5N4y7aBY3hOcrW/A== X-Google-Smtp-Source: ABdhPJwaWd2Dsty1hm8+srEd1CrCZJAoaTCt9a6/APuJF2MB4FCNlWTBlSPyHocAJw92uwUcp5jyFYGBn7UctkbSsNE= X-Received: by 2002:a17:903:246:b0:13a:22d1:88b with SMTP id j6-20020a170903024600b0013a22d1088bmr7176246plh.16.1631001712874; Tue, 07 Sep 2021 01:01:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kangping Dong Date: Tue, 7 Sep 2021 16:01:16 +0800 Message-ID: To: Chris Box , dnssd Content-Type: multipart/alternative; boundary="000000000000b9c79e05cb632d02" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 08:02:00 -0000 --000000000000b9c79e05cb632d02 Content-Type: text/plain; charset="UTF-8" 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 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 > 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 >> 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 > --000000000000b9c79e05cb632d02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read this spec draft and support its adoption. It i= s one of the key components for the
"Service Registration Protocol= for DNS-Based Service Discovery" which is used for
connecti= vity protocols like Matter.


BRs,
Kangping


On Thu, Sep 2, 2021 at 6:16= AM Jonathan Hui <jonhui=3D40google.com@dmarc.ietf.org> wrote:
I have read=C2=A0this dr= aft and support its adoption in DNSSD.

Some commen= ts on=C2=A0draft-sekar-dns-ul-03:

Section 3: We sh= ould 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 Chr= is Box <ch= ris.box.ietf@gmail.com> wrote:
WG members,

This email starts a call to ad= opt https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul= -03 into the DNSSD working group.

What is this= ? Abstract:
=C2=A0 =C2=A0This document p= roposes a new EDNS0 option that can be used by DNS
=C2=A0 =C2=A0Update clients and DNS servers to include a = lease lifetime in a DNS
=C2=A0 = =C2=A0Update or response, allowing a server to garbage collect stale=
=C2=A0 =C2=A0resource records that have= been added by DNS Updates

Adoption means t= hat formal change control passes from the authors to the working group. All= subsequent substantive changes require WG rough consensus. Adoption repres= ents a commitment that the DNSSD WG will spend time on the draft, with the = aim of progressing it towards publication.
=C2=A0 =C2=A0
Note that in theory the draft could fit the charters of both DNSOP and DN= SSD, but we're proposing DNSSD as this specific functionality is requir= ed as part of=C2=A0draft-ietf-dnssd-srp=C2=A0which is already= well advanced. The relevant charter text is:

2. To develop an improved, scalable solution for servi= ce discovery=C2=A0
=C2=A0 =C2=A0t= hat can operate in multi-link networks, where devices may be
=C2=A0 =C2=A0in neighboring or non-neighboring = links, applicable to
=C2=A0 =C2= =A0the scenarios above.=C2=A0 The solution will consider tradeoffs between<= /font>
=C2=A0 =C2=A0reusing/extending ex= isting protocols and developing entirely new
=C2=A0 =C2=A0protocols.=C2=A0
=C2=A0 =C2=A0
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.<= /div>

You should be aware this draft is covered by an IP= R disclosure. Details of Apple's licensing terms can be found at https://data= tracker.ietf.org/ipr/1236/.
=C2=A0 =C2=A0
Within DN= SSD we are asking two questions:
1) If you have read this six-pag= e 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 worki= ng on, please also say so.

For this call to su= cceed, we'll need statements of explicit support from people who have r= ead 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 describe= d in the draft.

Please send statements in support = or against, as responses to this email. This call will be open until 2021-0= 9-03 23:59 UTC.
=C2=A0
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
--000000000000b9c79e05cb632d02-- From nobody Tue Sep 7 08:01:13 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89F3A0AFE for ; Tue, 7 Sep 2021 08:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu0A8auCFRTO for ; Tue, 7 Sep 2021 08:01:05 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D533A0B08 for ; Tue, 7 Sep 2021 08:01:05 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id a10so10358869qka.12 for ; Tue, 07 Sep 2021 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=729OpRj2P58LidzpYZgl4WDSZWEATv8hX79olnqGw4k=; b=C4kxGbov+IDf196jf27L7+7Xh0N4Kb6O9mhQh55GpklvpyKlNLEXH8QGNFMlo4VtFY 0rpF7ipCfoy/7JUcd2Rma3J6Qqzyr3Xn1xqKJJKBLSQipd6IPwOhSESWNMq+3yViqIoF +A9nzHU0hMvKzlScHrLbILOsXAoCevgwFimSoF8AMeuSRJCXbF4CRtln9YnfGB+88tD1 9tp+9XUqUtsW/CPiv2VlJZMFio5z8JLnHCM2Wfcw2J1UM6eOkpwCrKTYUnJKHsh+Nf5z en/gZoeqzFfqwqJW2NOft19UzzgM/fJ/XDBSCDNB1rgj8fHrDVamJOzma79kHZbRnI6H djXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=729OpRj2P58LidzpYZgl4WDSZWEATv8hX79olnqGw4k=; b=pxk01PRUIrfPeUniUvWRIKDNeBJgiCORQsHqmkJ7Ii65rYDnD0QsfWshCADOdhXxi3 AqiUDilFIPnS6fgRBGJ+nV+i+lkzS6MOI9snU0K48OMQjXHlUV012swt568U/IHK69s2 +z+IWhTLXIYuogaewJAnGxyOi9xIGyDnqeaCxFl1qKmnNuyV9sD8Z2T4Uysg94+uwsoh s6w0l6BGpEg90ZEI9xy0ZCD2zt/jf6cXm2P4kS+3wsWYW62zy7qajIMfDZaUWQv2Id75 +x781dV20vVLHaMQ378TuKxUomG9CR8JPTKP3U/l2mWRTJolScX0w4IiVmVozmv5QVLC Iiqg== X-Gm-Message-State: AOAM53262y0s3LW5VO6XcQoQPQmxVQLI6ZUpzSwGKUQKHjzwYe2LWQgU rBlpfYftlMO0T8WiQePvppZCWRN/3kRWRmHCywotkLh6 X-Google-Smtp-Source: ABdhPJxH1nBU9l972a5riji3ySwshI6sRUBKxxOUWLcy5I5YvhAO0kHCnacI0wqNF2OWcD0tcpAha78rXCg9t41FnzQ= X-Received: by 2002:a05:620a:318c:: with SMTP id bi12mr16030286qkb.263.1631026863265; Tue, 07 Sep 2021 08:01:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Box Date: Tue, 7 Sep 2021 16:00:52 +0100 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="000000000000cddd2005cb69081b" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 15:01:10 -0000 --000000000000cddd2005cb69081b Content-Type: text/plain; charset="UTF-8" Thanks for the comments on the draft. In total we had six people who said they'd read the draft and supported its adoption, two of which noted some changes they'd like considered. There were no people against adoption. I have now formally adopted the draft into DNSSD. Stuart or Ted could you please re-upload with the name draft-ietf-dnssd-*? We can then begin considering edits that WG members would like to propose. Thanks, Chris --000000000000cddd2005cb69081b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the comments on the draft. In total we had six = people who said they'd read the draft and supported its adoption, two o= f which noted some changes they'd like considered. There were no people= against adoption.

I have now formally adopted the draft= into DNSSD. Stuart or Ted could you please re-upload with the name draft-i= etf-dnssd-*? We can then begin considering edits that WG members would like= to propose.

Thanks,
Chris
--000000000000cddd2005cb69081b-- From nobody Sat Sep 25 11:47:21 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3053A1EC6 for ; Sat, 25 Sep 2021 11:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRNLCsY4N5vL for ; Sat, 25 Sep 2021 11:47:16 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349093A1ECC for ; Sat, 25 Sep 2021 11:47:16 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id az15so13601710vsb.8 for ; Sat, 25 Sep 2021 11:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=xLFxMicu93kfSgylnyT7/dtehcYstTg+hK8G/Rm3URc=; b=V1B0O2S6hv+WwkxfnL7ExybyYHgGult3UKa49T8NzSp4CoBYsBu/vZW9QiBnAJbawQ jPMupQYYda8Oj0vhyQWBd5a45JzivxzGYciAeQKpFi6phmV63ruebiPdmk5NC2+E6+ph A3cXezoYbQ/c0BhRBs8hXRwQZILyY2WsUr0XLZCHT3jqVeF9Bj+iV3hG9pBHenl/I9uT 8/JL6EVDPDGadoOeo6/JboHVJBvXGQ6L+8ffIXiR33ItGe6RuofY7KGMlcMmnnZL9fgY 7jHhsVZW7kpAil1Y1Jm3L9F6QGSTyde7nZlHaTMl8vDAm21+plduTxwdFt7giw5iSWF9 eTRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=xLFxMicu93kfSgylnyT7/dtehcYstTg+hK8G/Rm3URc=; b=I/co7CFv9WoihiRhxUiHnh94AwVTy9aLdIW6i77CxuOkrlGba1kRtja5lUBhCWp8CM Po3K34yiTT65f91PNuQHZAY1dkTEXNyGavS6rzDNLLlAJKnTWhZ+AQTluCIX9cJ/CzOY BLq48gI6Etdnm0nyiuM5jKk9LfF0b8TgUMIzyYs2EzyeAnv1EFomFsQMsEya2S2ww3hp +mzLKr1EryDqClqdfhK8N6K7o0ubD6OUrVfm0iy9T9f6BCmL+yW3XrjYSB6jiCXeaUpn 6eSPEiXK49DKbAew2rpV6JzCOxmf5zm3IUJMqH3MnSRIY8d7d4+E7Sx/gVzzY4Bez1Zd bm4A== X-Gm-Message-State: AOAM5304PAZWeSaEQd4CN3IuOkz9qQVW+rsGRUFrC5/h4FvfWh8LCxkI IMKYaYGInuSHzzEK7PPLuMgzNFJ8HKNqJ2CwDpE/DA1lvwmXkQ== X-Google-Smtp-Source: ABdhPJzC22Ua0XaClprwl0fTRy8iOY9x7hyYKcCunP0uQ5uoWbANfkeosO1HLIkFq2wR7XWnbCZBeb9IDxrpytPJeig= X-Received: by 2002:a67:f2cf:: with SMTP id a15mr7288257vsn.58.1632595634785; Sat, 25 Sep 2021 11:47:14 -0700 (PDT) MIME-Version: 1.0 From: Abtin Keshavarzian Date: Sat, 25 Sep 2021 11:47:04 -0700 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui Content-Type: multipart/alternative; boundary="000000000000e06dc705ccd64ad6" Archived-At: Subject: [dnssd] SRPL: SRP replication (draft-lemon-srp-replication-00) - questions/ideas X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 18:47:19 -0000 --000000000000e06dc705ccd64ad6 Content-Type: text/plain; charset="UTF-8" Hi Ted, I have been reading the SRP replication draft ( https://www.ietf.org/archive/id/draft-lemon-srp-replication-00.html) and the related RFCs (like DSO). Overall in my opinion, the design seems very reasonable and good. There are couple of questions and some thoughts around them that I'd like to sync with you. They are all related to the SRPL Host message. My understanding is that during routine operation, whenever an SRP update message from an SRP client is successfully processed, the peer (which processed it) will embed the SRP update message in an SRPL Host (within an SRPL Host Message TLV) and will send it to all partner peers. This sounds like a good model to me for syncing the peers during routine operation. 1) How can we sync the accepted lease and key lease intervals for the registered entries across SRP servers using SRPL? - The SRP update message itself contains the lease and key lease values, but these are what the SRP client requested (or wished to get). - The accepted lease intervals are included in the SRP update response that the original SRP server peer will send back to the SRP client. - I guess we may need a way to inform the accepted lease intervals from the peer to SRPL partner peers. One way I can think of is to add a new secondary TLV (e.g., SRPL Lease Intervals) as part of SRPL Host message. The other possibility is to assume/require that all SRPL SRP servers use/accept the same lease intervals (I personally prefer the former way better since it adds more flexibility). --------- The other questions are related to the use of SRPL Host messages during initial synchronization. The SRP server should have all the registered service entries in its database but it may not necessarily keep the SRP update messages that registered them. But in the SRPL Host message we want to embed an SRP update message. My first thought was that we can have the SRP server save the last update message from each SRP client, but then services may be registered at different times and in many different SRP update messages. So I guess this may not work in all cases. My next thought was that the SRP server peer should be able to construct an SRP update message based on the info it has, but there are some tricky situations with this. 2) What to do with the signature in the SRP update message? The SRP server does know the public key of the SRP client (host), but it needs the private key to be able to do the ECDSA signing of the message, so cannot sign it. - One way around this is to make the signature optional in the SRP update messages which are embedded in an SRPL Host message. But I am not sure if I like this, since it (kind of) requires special/different treatment of SRP update messages in this case on a partner peer. 3) How to convey the remaining lease times for multiple registered services (from the same SRP client) to the partner peer in the SRPL Host and its embedded SRP update message? - An SRP client may register multiple services at different times (and in different SRP update messages). - So at the time of SRPL initial synchronization, services from the same host/client can have different remaining lease times. - We have "SRPL Time Offset TLV" in an SRPL Host message, but this seems to apply to the host and all the entries. - I guess we may need a way to be able to share the remaining lease times per service entry. One way I can think of (which may address both 2 & 3) is to use the SRPL Host message only during routine operation, and then during initial synchronization we define and use a new type of SRPL message with new TLVs (e.g. an SRPL Service TLV) to include all the info about the host and all of its service(s) in the TLVs. I appreciate your thoughts on these. Thanks, Abtin. --000000000000e06dc705ccd64ad6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

I have been reading the SRP replication dra= ft (https://www.ietf.org/archive/id/draft-lemon-srp-replication-00.htm= l) and the related RFCs (like DSO).

Overall in my opinion, the d= esign seems very reasonable and good.

There are couple of questions = and some thoughts around them that I'd like to sync with you. They are = all related to the SRPL Host message.

My understanding is that durin= g routine operation, whenever an SRP update message from an SRP client is s= uccessfully processed, the peer (which processed it) will embed the SRP upd= ate message in an SRPL Host (within an SRPL Host Message TLV) and will send= it to all partner peers. This sounds like a good model to me for syncing t= he peers during routine operation.

1) How can we sync the accepted l= ease and key lease intervals for the registered entries across SRP servers = using SRPL?

- The SRP update message itself contains the lease and k= ey lease values, but these are what the SRP client requested (or wished to = get).
- The accepted lease intervals are included in the SRP update resp= onse that the original SRP server peer will send back to the SRP client.- I guess we may need a way to inform the accepted lease intervals from th= e peer to SRPL partner peers.

One way I can think of is to add a new= secondary TLV (e.g., SRPL Lease Intervals) as part of SRPL Host message.
The other possibility is to assume/require that all SRPL SRP servers = use/accept the same lease intervals (I personally prefer the former way bet= ter since it adds more flexibility).

---------

The other ques= tions are related to the use of SRPL Host messages during initial synchroni= zation.

The SRP server should have all the registered service entrie= s in its database but it may not necessarily keep the SRP =C2=A0update mess= ages that registered them. But in the SRPL Host message we want to embed an= SRP update message.

My first thought was that we can have the SRP s= erver save the last update message from each SRP client, but then services = may be registered at different times and in many different SRP update messa= ges. So I guess this may not work in all cases.

My next thought was = that the SRP server peer should be able to construct an SRP update message = based on the info it has, but there are some tricky situations with this.
2) What to do with the signature in the SRP update message? The SRP s= erver does know the public key of the SRP client (host), but it needs the p= rivate key to be able to do the ECDSA signing of the message, so cannot sig= n it.

- One way around this is to make the signature optional in the= SRP update messages which are embedded in an SRPL Host message. But I am n= ot sure if I like this, since it (kind of) requires special/different treat= ment of SRP update messages in this case on a partner peer.

3) How t= o convey the remaining lease times for multiple registered services (from t= he same SRP client) to the partner peer in the SRPL Host and its embedded S= RP update message?

- An SRP client may register multiple services at= different times (and in different SRP update messages).
- So at the tim= e of SRPL initial synchronization, services from the same host/client can h= ave different remaining lease times.
- We have "SRPL Time Offset TL= V" in an SRPL Host message, but this seems to apply to the host and al= l the entries.
- I guess we may need a way to be able to share the remai= ning lease times per service entry.

One way I can think of (which ma= y address both 2 & 3) is to use the SRPL Host message only during routi= ne operation, and then during initial synchronization we define and use a n= ew type of SRPL message with new TLVs (e.g. an SRPL Service TLV) to include= all the info=C2=A0about the host and all of its service(s) in the TLVs.
I appreciate your thoughts on these.

Thanks,
Abtin.

<= /div> --000000000000e06dc705ccd64ad6--