From nobody Wed Oct 13 11:49:01 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 AFFC23A09BE for ; Wed, 13 Oct 2021 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 5iVv3mbrZFmb for ; Wed, 13 Oct 2021 11:48:54 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 1A3163A097C for ; Wed, 13 Oct 2021 11:48:53 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id l7-20020a0568302b0700b0054e40740571so5064051otv.0 for ; Wed, 13 Oct 2021 11:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A0SsbwuduqttMOQhslm7t9oMvQeV3LB9PlqElCQfjLs=; b=SfKOq0jD0Ep0Dbjr/Yu1k7yLeeG3RmPsBB1TxU5s8OE497D7MNZ3yU19arcEfUmEtz ZTrpRlEgrSmLXINilTzX6GLuYSl7YUwaaDLfc34unvoUrX5F4Ka7ug8IxYBR8bdoI5EV uyMEnO5Urm+4Vty0WY+TbRWUjMMKnPfDfUhUam5j+EPX3YQ2UdQRoSWRiX3Q0aPsU5p1 M5l/488GuHuRjk/V9WaoJp0/aymsP09zSdm5bwzF/G6ra5/SwI4yNDmMTYm0JZyHBmXd 8WP6WXIyzU0Y4rRQri/uDngR0ITfgU5TchHy+Z3PNpxDa5DxmRhlX8ueN1D8slO/4eY9 eQeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A0SsbwuduqttMOQhslm7t9oMvQeV3LB9PlqElCQfjLs=; b=xF53cEJUJc/W+zLtZzL43edPV3dRA/cStVWILXu4NnX61HSgpDkQ32Zp91d4o3G62j fz0gL1veZ5eeowxF5PAClArH+ndocstjNi+IgTJOOJudf38J2WVzbAODJU5vNINNU7hU wBdhE2Z0fH4lslAa9BnvztSdBojv0SL3z7v6k79NijM633Uu9uKCew02VXVwq38inlRA CSPOQdFSahDa8MchLmTCDJh2h16BpTpxqQ5+Tg9Mr4NsP9nhAYaZ+4xr17DoNf+cOrEc nPWNM4RK6C4rf2Q1LSaKwIFCSq3DPujlvDRuJXiYxAVMZNClJPBXz9evPRv6EyD2gkF7 46uQ== X-Gm-Message-State: AOAM5322/J9OFOW71SSQHq6SlpC9FFWC3h2YcbGHxbRQmvk0q8er+spX dcVXW6X1FSPDXBe5mPysvCRieLVCPMHxhLWGWmfYDWcw6RssUw== X-Google-Smtp-Source: ABdhPJw0nZFm6X8NDpqKlAdnG/5T5gtlna/IUL+WzlNTp7VxcNN2bCG96z5EbugDsQ62FuVkZlP8jPyqHctKmV5xQkU= X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr713822otb.309.1634150933098; Wed, 13 Oct 2021 11:48:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Wed, 13 Oct 2021 14:48:16 -0400 Message-ID: To: Abtin Keshavarzian Cc: DNSSD , Jonathan Hui Content-Type: multipart/alternative; boundary="000000000000e083d505ce406992" Archived-At: Subject: Re: [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: Wed, 13 Oct 2021 18:48:59 -0000 --000000000000e083d505ce406992 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 25, 2021 at 2:47 PM Abtin Keshavarzian wrote: > 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). > 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. > I think this is correct=E2=80=94we need a lease time secondary TLV. If the = server policy restricts the lease to a smaller value, I think we just have to accept the value that the original server accepted. 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 priva= te > 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. > I think the answer here is to keep all of the messages that have affected the current set of registrations for a specific host. I've done a sample implementation of this, and it seems straightforward=E2=80=94whenever we ge= t an update, we reference the message both from the host and from the instances; when an instance is deleted for whatever reason, that message is dereferences, and at some point all the instances created by that message are removed, at which point the message is collected. So at any time if we want to replicate the full state of an SRP client to another SRP server during synchronization, we just send all the messages we received, in order= . We probably want to include a time offset and accepted lease times in the messages, rather than relying on TLV ordering to say which time goes with which update message. 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 TLV= s > (e.g. an SRPL Service TLV) to include all the info about the host and all > of its service(s) in the TLVs. > I think if we include accepted lease information as you suggested with each update message, that solves this problem. Thanks for doing this work=E2=80=94it's really helpful to have another impl= ementor noticing the things I missed. I completely forgot about the "multiple updates" issue! --000000000000e083d505ce406992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 25, 2021 at 2:47 PM Abtin Kes= havarzian <abtink@google.com>= ; wrote:
I have been reading the SRP replication draft (h= ttps://www.ietf.org/archive/id/draft-lemon-srp-replication-00.html) and= the related RFCs (like DSO).
1) How can we sync the accepted lease and = key lease intervals for the registered entries across SRP servers using SRP= L?

- 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 gues= s 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 secondar= y TLV (e.g., SRPL Lease Intervals) as part of SRPL Host message.
<= /blockquote>

I think this is correct=E2=80=94we need a l= ease time secondary TLV. If the server policy restricts the lease to a smal= ler value, I think we just have to accept the value that the original serve= r accepted.

2) What t= o 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 b= e 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 mes= sages which are embedded in an SRPL Host message. But I am not sure if I li= ke this, since it (kind of) requires special/different treatment of SRP upd= ate messages in this case on a partner peer.
I think the answer here is to keep all of the messages that hav= e affected the current set of registrations for a specific host. I've d= one a sample implementation of this, and it seems straightforward=E2=80=94w= henever we get an update, we reference the message both from the host and f= rom the instances; when an instance is deleted for whatever reason, that me= ssage is dereferences, and at some point all the instances created by that = message are removed, at which point the message is collected. So at any tim= e if we want to replicate the full state of an SRP client to another SRP se= rver during synchronization, we just send all the messages we received, in = order.

We probably want to include a time offset a= nd accepted lease times in the messages, rather than relying on TLV orderin= g to say which time goes with which update message.

3) How to convey the remaining lease times f= or multiple registered services (from the same SRP client) to the partner p= eer in the SRPL Host and its embedded SRP update message?

- An SRP c= lient may register multiple services at different times (and in different S= RP update messages).
- So at the time of SRPL initial synchronization, s= ervices 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 n= eed a way to be able to share the remaining lease times per service entry.<= br>
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 initia= l synchronization we define and use a new type of SRPL message with new TLV= s (e.g. an SRPL Service TLV) to include all the info=C2=A0about the host an= d all of its service(s) in the TLVs.

<= div>=C2=A0I think if we include accepted lease information as you suggested= with each update message, that solves this problem.

Thanks for doing this work=E2=80=94it's really helpful to have anoth= er implementor noticing the things I missed. I completely forgot about the = "multiple updates" issue!=C2=A0
--000000000000e083d505ce406992-- From nobody Wed Oct 13 14:06:18 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 A55223A0BA0 for ; Wed, 13 Oct 2021 14:06:15 -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 m0ouiDmSBTAJ for ; Wed, 13 Oct 2021 14:06:10 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 3775E3A0B9F for ; Wed, 13 Oct 2021 14:06:10 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id i22so7249787ual.10 for ; Wed, 13 Oct 2021 14:06:10 -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 :cc; bh=9Z8JzFEJ0UOYVTkKTowBFZ8+2LW/QbYuJR4GwYWP8A4=; b=Amw8FaTQ0lPFwW6JTUwmYIIGWLxeYmU5fbMLsihnqGyqsiN/gftDS3I9Db2IeGFrx6 etUPGRpMiyaxtKL8besyfaZl9LoOxo53TWG+gJgQrRWsv2sOuF4m0Bb9WEwOgTZeyQZD RLSGPBu8MKzKRuXJu/lkn4sJEN6UDZb0ztrjfl3w5fQ9A5CLmS5mgmiGpGBC7nV83i7a e0Xh7QYbsmdQrhFQ/yCxgynWjTVwx1qHgkheTNra51KUnJR2BNlXqAk7uSB36VZLrq2N yCQH3m2xTMTf+gDK+Wr7zbQx/8A5RJBmMWI0tQoPI/N7B0zasvAUYpeCCCLj24Am5UK5 jFdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Z8JzFEJ0UOYVTkKTowBFZ8+2LW/QbYuJR4GwYWP8A4=; b=7iysPHaYyA+W3COpNkJIhbKpd91AG0teKG/keVsbUv/hSIHBEJ0rlOhZGwt9gA5nS3 yc2qQLtT1q5hTJ29Nm8CQkO2oi6R3SJzo2vh1ySEc++2FzPejAxI9g0ZHJTJAUvt6PiM I9QWi9jtr5ug4sFt1miAm1kNrNP4qopctyyiAn7NSDvX43joVJwprBABmWnjYIbPFuQz VCa/Qu8B9N3BmQksBx0ofgek1M0Iv63FwbV5+RfOR7u30b6zolwjeCs4zlCR2/NhwnXg yTEn5V5k2qTMYNzFGMiSAXlfdUrmNNY/gJ9A2nYh6DE1FaMAs6JQU6sCXNJyxiFucbhi bASA== X-Gm-Message-State: AOAM531uoIjFW1XqI1ZmgGAyvODM6w0CR5Q9jWLmBfBJDOuQsdsiSZ1e 4jZcCn3Wk7hchBoeCrc3UIT6i68aIUOVaCDVh1EVMA== X-Google-Smtp-Source: ABdhPJybtTpc9p3A49E724sFNZIOrqnE/ZcuEwF10BARLXfuUdGC1v0FajCBBChoHNJPhtqELwR1hRmFlFchObZaeK8= X-Received: by 2002:a05:6102:3a10:: with SMTP id b16mr2481045vsu.9.1634159167691; Wed, 13 Oct 2021 14:06:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abtin Keshavarzian Date: Wed, 13 Oct 2021 14:05:56 -0700 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui Content-Type: multipart/alternative; boundary="000000000000b2b82c05ce425476" Archived-At: Subject: Re: [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: Wed, 13 Oct 2021 21:06:16 -0000 --000000000000b2b82c05ce425476 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ted. I agree and I think it all makes sense and good. So we can change the SRPL Host Message TLV to have the following info: - Timeout field (`uint32_t`) (similar to Timeout TLV) - Two `uint32` fields for Lease and KeyLease (accepted intervals by server). - Followed by "SRP Update message" itself. Few smaller things to sync on: In the SRPL Hostname TLV we assume the value (host name) is full DNS name encoded in DNS wire format. Related to DSO Inactivity timeout. In SRPL we use the default values (15 sec). But I think we assume that once we establish an SRPL session, it is considered as an active ongoing operation (i.e., DSO session will stay open and practically the inactivity timeout is always cleared). Does it make sense? Thanks, Abtin. On Wed, Oct 13, 2021 at 11:48 AM Ted Lemon wrote: > On Sat, Sep 25, 2021 at 2:47 PM Abtin Keshavarzian > wrote: > >> 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). >> 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. >> > > I think this is correct=E2=80=94we need a lease time secondary TLV. If th= e server > policy restricts the lease to a smaller value, I think we just have to > accept the value that the original server accepted. > > 2) What to do with the signature in the SRP update message? The SRP serve= r >> does know the public key of the SRP client (host), but it needs the priv= ate >> 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 updat= e >> messages which are embedded in an SRPL Host message. But I am not sure i= f I >> like this, since it (kind of) requires special/different treatment of SR= P >> update messages in this case on a partner peer. >> > > I think the answer here is to keep all of the messages that have affected > the current set of registrations for a specific host. I've done a sample > implementation of this, and it seems straightforward=E2=80=94whenever we = get an > update, we reference the message both from the host and from the instance= s; > when an instance is deleted for whatever reason, that message is > dereferences, and at some point all the instances created by that message > are removed, at which point the message is collected. So at any time if w= e > want to replicate the full state of an SRP client to another SRP server > during synchronization, we just send all the messages we received, in ord= er. > > We probably want to include a time offset and accepted lease times in the > messages, rather than relying on TLV ordering to say which time goes with > which update message. > > 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 i= n >> 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 time= s >> 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 TL= Vs >> (e.g. an SRPL Service TLV) to include all the info about the host and al= l >> of its service(s) in the TLVs. >> > > I think if we include accepted lease information as you suggested with > each update message, that solves this problem. > > Thanks for doing this work=E2=80=94it's really helpful to have another im= plementor > noticing the things I missed. I completely forgot about the "multiple > updates" issue! > --000000000000b2b82c05ce425476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ted.

I agree and I think it all makes sense = and good.

So we can change the SRPL Host Message TLV to have the fol= lowing info:
  • Timeout field (`uint32_t`) =C2=A0(similar to Timeou= t TLV)
  • Two `uint32` fields for Lease and KeyLease (accepted interva= ls by server).
  • Followed by "SRP Update message" itself.

Few smaller things to sync on:

In the SRPL Hostname TLV = we assume the value (host name) is full DNS name encoded in DNS wire format= .

Related to DSO Inactivity timeout. In SRPL we use the default valu= es (15 sec). But I think we assume that once we establish an SRPL session, = it is considered as an active ongoing operation (i.e., DSO session will sta= y open and practically the inactivity timeout is always cleared).

D= oes it make sense?
Thanks,
Abtin.

On Wed, Oct 13, 20= 21 at 11:48 AM Ted Lemon <mellon@fug= ue.com> wrote:
On Sat, Sep 25, 2021 at 2:47 PM Abt= in Keshavarzian <= abtink@google.com> wrote:
I have been re= ading the SRP replication draft (https://www.ietf.or= g/archive/id/draft-lemon-srp-replication-00.html) and the related RFCs = (like DSO).
1) How can we sync the accepted lease and key lease interval= s for the registered entries across SRP servers using SRPL?

- The SR= P update message itself contains the lease and key lease values, but these = are what the SRP client requested (or wished to get).
- The accepted lea= se 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 wa= y to inform the accepted lease intervals from the peer to SRPL partner peer= s.

One way I can think of is to add a new secondary TLV (e.g., SRPL = Lease Intervals) as part of SRPL Host message.
<= br>
I think this is correct=E2=80=94we need a lease time secondar= y TLV. If the server policy restricts the lease to a smaller value, I think= we just have to accept the value that the original server accepted.
<= div>
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.

I think the answer here is to keep all of the me= ssages that have affected the current set of registrations for a specific h= ost. I've done a sample implementation of this, and it seems straightfo= rward=E2=80=94whenever we get an update, we reference the message both from= the host and from the instances; when an instance is deleted for whatever = reason, that message is dereferences, and at some point all the instances c= reated by that message are removed, at which point the message is collected= . So at any time if we want to replicate the full state of an SRP client to= another SRP server during synchronization, we just send all the messages w= e received, in order.

We probably want to include = a time offset and accepted lease times in the messages, rather than relying= on TLV ordering to say which time goes with which update message.

3) How to convey the remaining lease times for multiple registered serv= ices (from the same SRP client) to the partner peer in the SRPL Host and it= s embedded SRP update message?

- An SRP client may register multiple= services at different times (and in different SRP update messages).
- S= o at the time of SRPL initial synchronization, services from the same host/= client can have different remaining lease times.
- We have "SRPL Ti= me 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 sha= re 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=C2=A0about the host and all of its service(s) in = the TLVs.

=C2=A0I think if we inc= lude accepted lease information as you suggested with each update message, = that solves this problem.

Thanks for doing this wo= rk=E2=80=94it's really helpful to have another implementor noticing the= things I missed. I completely forgot about the "multiple updates"= ; issue!=C2=A0
--000000000000b2b82c05ce425476-- From nobody Wed Oct 13 14:32:42 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 32A883A0CCC for ; Wed, 13 Oct 2021 14:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 7Wwo3tgCqUKQ for ; Wed, 13 Oct 2021 14:32:30 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 775433A0D56 for ; Wed, 13 Oct 2021 14:32:22 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id x33-20020a9d37a4000000b0054733a85462so5507669otb.10 for ; Wed, 13 Oct 2021 14:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fAJqWozFQZRum7IFe18tYvoFwhIjy5YOv34DN0iphRE=; b=ixfXMZ1kCsxwO9etmhH8Qc+efvnxTiejM5G9oHRYajP5aunVTmSRItj2p03Sqpn1kv t+eqWSwTnLe3rZ5MzIG2tS+greeJIOjLerdIlQ40g7yuTBvaUVoBJi75baGRidcuc6wO 1N8r1F9kbIl7kQWYpfO/pJAFbPjgyQQIlbQY9rF3nd90xDB4f24exN2wKM+BpDkjks5j ChFodz1CUKubN4lep6jF8zTnna8RbjKePluHWjCDjV9GDCzQnBkQrLfbX4E5J2C+LpF+ bRnRv2EetS0Xs14Z/m60+APuJiM4v2rfK7GqtUkBBlsB9pFL/LTwJrlaid8r2QtDZZG6 A5Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fAJqWozFQZRum7IFe18tYvoFwhIjy5YOv34DN0iphRE=; b=Pnlu5gMb/8YQDjg8r7HUnrlfYp7uaF5tGojrPwHGxvxxiQezP5lRi7j6DWpDx2eKiB 8BT+qoCySYh9E4WshAMknBP6i+nxD+aCQ6LzHstmO/ZKJR0YsUWxYV+RSs3/eWNbIFxr JXvMNQGdH46FkvU46vIZqs0vB3DLZogmJWtbr21OQtbWeCE2ROnNHn2v1SjTxGKW9JAL wcaN/WFtKk2Mk0ZKYoJqxcsd9eWiCqeIpudhOLRjO1UH/xySFxk5PeSk7PqyGUoPlAr9 Uibdvz3tHPU2Jy6DaMOqw5a46qchlTYPJMv6t0r3ggJhZsGexXBA9SStUOMeB3McoTTc cDog== X-Gm-Message-State: AOAM532BrVpHJAUOzth5p48ThXSCvDnrlPHjrJ2AybS8U8O7QJRYRzSg 43GGPYZT8nnWJJOhf6g4B39Z+3GygS6gaQ/48Ws6VA== X-Google-Smtp-Source: ABdhPJzPoJb7sXRDk91Lylwce6aVTZz4CYy0XhBMbH9uxBqSWDqVz0+f12yoMM+U3GNsxYWVHET7fQQw/pdV976sGkw= X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr1357980otb.309.1634160741296; Wed, 13 Oct 2021 14:32:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Wed, 13 Oct 2021 17:31:45 -0400 Message-ID: To: Abtin Keshavarzian Cc: DNSSD , Jonathan Hui Content-Type: multipart/alternative; boundary="0000000000007dc01005ce42b20e" Archived-At: Subject: Re: [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: Wed, 13 Oct 2021 21:32:37 -0000 --0000000000007dc01005ce42b20e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2021 at 5:06 PM Abtin Keshavarzian wrote: > So we can change the SRPL Host Message TLV to have the following info: > > - Timeout field (`uint32_t`) (similar to Timeout TLV) > - Two `uint32` fields for Lease and KeyLease (accepted intervals by > server). > - Followed by "SRP Update message" itself. > > Yup. Few smaller things to sync on: > > In the SRPL Hostname TLV we assume the value (host name) is full DNS name > encoded in DNS wire format. > Yes, I should have specified that. :) > Related to DSO Inactivity timeout. In SRPL we use the default values (15 > sec). But I think we assume that once we establish an SRPL session, it is > considered as an active ongoing operation (i.e., DSO session will stay op= en > and practically the inactivity timeout is always cleared). > Yes. That should also be made explicit. I realized just now that it's probably worth making clear that if we have an update that adds an instance, and then later the instance is removed, but the instance was added along with an instance that /wasn't/ removed, we need to keep the message that removed the instance as well as the message that added it, until the original instance expiry time. Right now my instance deletes these records as soon as the host lease expires, but this is incorrect=E2=80=94it should be saving them until the key lease expires. --0000000000007dc01005ce42b20e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 13, 2021 at 5:06 PM Abtin Kes= havarzian <abtink@google.com>= ; wrote:
So we can change the SRPL Host Message TLV to have the following info:<= br>
  • Timeout field (`uint32_t`) =C2=A0(similar to Timeout TLV)
    • Two `uint32` fields for Lease and KeyLease (accepted intervals by server)= .
  • Followed by "SRP Update message" itself.
Yup.

Few smaller things to sync on:

In the SRPL Hostname TLV we assume= the value (host name) is full DNS name encoded in DNS wire format.

Yes, I should have specified that. :)
=C2=A0
Related to DSO Inacti= vity timeout. In SRPL we use the default values (15 sec). But I think we as= sume that once we establish an SRPL session, it is considered as an active = ongoing operation (i.e., DSO session will stay open and practically the ina= ctivity timeout is always cleared).=C2=A0

=
Yes. That should also be made explicit.

I rea= lized just now that it's probably worth making clear that if we have an= update that adds an instance, and then later the instance is removed, but = the instance was added along with an instance that /wasn't/ removed, we= need to keep the message that removed the instance as well as the message = that added it, until the original instance expiry time. Right now my instan= ce deletes these records as soon as the host lease expires, but this is inc= orrect=E2=80=94it should be saving them until the key lease expires.
<= div>=C2=A0
--0000000000007dc01005ce42b20e-- From nobody Wed Oct 13 16:03:58 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 1E8CB3A1385 for ; Wed, 13 Oct 2021 16:03:55 -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 mPyM2FJ3CdZU for ; Wed, 13 Oct 2021 16:03:47 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 959883A1382 for ; Wed, 13 Oct 2021 16:03:46 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id h4so7851175uaw.1 for ; Wed, 13 Oct 2021 16:03:46 -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 :cc; bh=2y4a32QSGigMIYYxJKr52+UpkGshzay41GXh09B2G04=; b=BNCX8pZMliwvSG5I7l42dg/qfaGKsxGT3+YQBkLMYhHQQxcxXr3kCkpqCnNUai45L6 y8zzH7u8uzTXqMWsr7D4PuLv4E3EYjhf6S8G+W8/dGKDFr3DDuxfp/hYS/PgwdFSQKGI PkHx83Ffr8UpEY1hoH6iJ7jHcywPwhbJqS8XH76IycG/JBo3VGdmQir40tkQfFRZEhak WYs2ckqs2uZcxBcBks++7gMzW0573jT6pJHEShMA7VXj03WIBqQXnt/xqPpwjKTMExXO DmvhehX5uPGcKkpitE/xC0vMMT0iJ2tG8xJUeG7Za+9QDcyWrWMgBuxXw57GRrHGKyWG B0GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2y4a32QSGigMIYYxJKr52+UpkGshzay41GXh09B2G04=; b=hESYgjBcsskubgCkaB+JYuyaDT0jNu+XnijnJ9ugYebO3FxzNhzpaj8fNzeD0whytA 3p7rDDwL2JMR3/LNXHCpFfn6qIHO7aytb1Z5YWKh4p2BqVSFs3zRVUGOUC4Q+dHNlTtC 8eKTwNRTt6W+rFxpa8lyWKDIuB6LwuUAhLTrsu9r5AbcP9K1zX4I1Ci0CdUaJ3cug/sM if+8o0P9gDQXUltSMIKbkp85Dwz+iyXOqZKwd7mZH3Mz59B2Yz2lhZAr2diptGxfBiRn s+WBkSSyH5b5Bzfzrd7JgtwnertvemfYE88FiwsVNGMux5dFQLPKKIePjam5A9ioGkxn c5sQ== X-Gm-Message-State: AOAM532at3BGq4HWu7hJ8xHVhnbHOL0/HIhVV5WabriZFGCO9RhFuSVx gf9WkQo+HgOFGgGX11Naxujh1R54NajZo+qFq09kbtT0GGeDzQ== X-Google-Smtp-Source: ABdhPJw9tF5odCUKj23yM/hnscv8paayw+7y7Np+8yS+l9IDzX3MZQtCM6JT9mXdCIyzI1Kifx0pukj0IToXlrWXmz4= X-Received: by 2002:a67:1047:: with SMTP id 68mr2422059vsq.39.1634166224992; Wed, 13 Oct 2021 16:03:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abtin Keshavarzian Date: Wed, 13 Oct 2021 16:03:34 -0700 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui Content-Type: multipart/alternative; boundary="00000000000058ba1e05ce43f971" Archived-At: Subject: Re: [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: Wed, 13 Oct 2021 23:03:55 -0000 --00000000000058ba1e05ce43f971 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I realized just now that it's probably worth making clear that if we have > an update that adds an instance, and then later the instance is removed, > but the instance was added along with an instance that /wasn't/ removed, = we > need to keep the message that removed the instance as well as the message > that added it, until the original instance expiry time. Right now my > instance deletes these records as soon as the host lease expires, but thi= s > is incorrect=E2=80=94it should be saving them until the key lease expires= . I agree. Good point. On Wed, Oct 13, 2021 at 2:32 PM Ted Lemon wrote: > On Wed, Oct 13, 2021 at 5:06 PM Abtin Keshavarzian > wrote: > >> So we can change the SRPL Host Message TLV to have the following info: >> >> - Timeout field (`uint32_t`) (similar to Timeout TLV) >> - Two `uint32` fields for Lease and KeyLease (accepted intervals by >> server). >> - Followed by "SRP Update message" itself. >> >> Yup. > > Few smaller things to sync on: >> >> In the SRPL Hostname TLV we assume the value (host name) is full DNS nam= e >> encoded in DNS wire format. >> > > Yes, I should have specified that. :) > > >> Related to DSO Inactivity timeout. In SRPL we use the default values (15 >> sec). But I think we assume that once we establish an SRPL session, it i= s >> considered as an active ongoing operation (i.e., DSO session will stay o= pen >> and practically the inactivity timeout is always cleared). >> > > Yes. That should also be made explicit. > > I realized just now that it's probably worth making clear that if we have > an update that adds an instance, and then later the instance is removed, > but the instance was added along with an instance that /wasn't/ removed, = we > need to keep the message that removed the instance as well as the message > that added it, until the original instance expiry time. Right now my > instance deletes these records as soon as the host lease expires, but thi= s > is incorrect=E2=80=94it should be saving them until the key lease expires= . > > --00000000000058ba1e05ce43f971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realiz= ed just now that it's probably worth making clear that if we have an up= date that adds an instance, and then later the instance is removed, but the= instance was added along with an instance that /wasn't/ removed, we ne= ed to keep the message that removed the instance as well as the message tha= t added it, until the original instance expiry time. Right now my instance = deletes these records as soon as the host lease expires, but this is incorr= ect=E2=80=94it should be saving them until the key lease expires.

I agree. Good point.=C2=A0

On Wed, Oct 13, 2021= at 2:32 PM Ted Lemon <mellon@fugue.= com> wrote:
On Wed, Oct 13, 2021 at 5:06 PM Abtin = Keshavarzian <abt= ink@google.com> wrote:
So we can change = the SRPL Host Message TLV to have the following info:
  • Timeout fi= eld (`uint32_t`) =C2=A0(similar to Timeout TLV)
  • Two `uint32` fields= for Lease and KeyLease (accepted intervals by server).
  • Followed by= "SRP Update message" itself.
Yu= p.

Few smaller things to sync on:

In the SRPL Hostname T= LV we assume the value (host name) is full DNS name encoded in DNS wire for= mat.

Yes, I should have specified= that. :)
=C2=A0
Related to DSO Inactivity timeout. In SRPL we use t= he default values (15 sec). But I think we assume that once we establish an= SRPL session, it is considered as an active ongoing operation (i.e., DSO s= ession will stay open and practically the inactivity timeout is always clea= red).=C2=A0

Yes. That should also be = made explicit.

I realized just now that it's p= robably worth making clear that if we have an update that adds an instance,= and then later the instance is removed, but the instance was added along w= ith an instance that /wasn't/ removed, we need to keep the message that= removed the instance as well as the message that added it, until the origi= nal instance expiry time. Right now my instance deletes these records as so= on as the host lease expires, but this is incorrect=E2=80=94it should be sa= ving them until the key lease expires.
=C2=A0
--00000000000058ba1e05ce43f971-- From nobody Wed Oct 13 18:44:26 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 3ADF83A177C for ; Wed, 13 Oct 2021 18:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 jfqr21wWirW5 for ; Wed, 13 Oct 2021 18:44:20 -0700 (PDT) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 CFA133A177B for ; Wed, 13 Oct 2021 18:44:20 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id r1-20020a4a9641000000b002b6b55007bfso1404978ooi.3 for ; Wed, 13 Oct 2021 18:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=IKIWhgTFDorRiJo2rirgkZ61sRIDyzKvsKx6WVdW3FQ=; b=B8wdBoA+HkIE9dd0MqZKah/a1MCWMR5WilNq8jkDYMg/VQI4ED6039tbfCWOKX42cb ROOmfeky5JvT/WHI3m5lOc5l8nTbUB3owibf09Qa2rOJserfmmWtZwF7UYWOMhReBfd4 UwHNX4Ab4sfpBl4qjQF9jpv6auMCSiNL3BRDMTDExpjmNod7KWFRWGWbfS5RaBRaT6GY b0U7KaKeY2ieNPwhhstkeAoXd3KVI75IwcfQX6+o+H+1aMSTK87NlAOZyxGsc4xvMTJk vvz+ORY1A+P4h0huJyltjHTM3l/DlkmJ8mDCek0Jgo0CdpgHvLQSv0KifppNf4eoMy/m tCxg== 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; bh=IKIWhgTFDorRiJo2rirgkZ61sRIDyzKvsKx6WVdW3FQ=; b=DZbJ91PZp8959yi14PpZPK0Hpd652G6r62QFFKTPYQPrZdcikprEoBKQUoBroFVlIn ezlr+E/LYpxHTfPtRJGU8oUABaunNM9Vf0eKvPrniUsAnKvyToi26z2jfg0dMbBMDPvd JCD5TIVxMaxegPUXy5qHl7IfYw7S/sMWzWOh2SaWIZYzmtiB796LpJZ6d6pCnwqIEcXx lXNwJKzsbKkuUkxTKj+njeUFLthtD5C8f8ppC4LrxjepT8hu+jI+xGldAf6M/2H7EgvL f/W0azlmLUEZ5YhV+bm8YuOPTBY+X4hzMWUmtrVHqYE1iff1eOKGmgX9FiEZU4vBwWOI kLRw== X-Gm-Message-State: AOAM532nkByhJbJf/7eQd1izf27ooxhU94FpTYiAJmwnQTY6oP13sxTF O2ivqnFxRmpza0xEwOxlrogrmbytassujpm7sjeNc2v87ELsrw== X-Google-Smtp-Source: ABdhPJz5fJO6XYPDw1Z3Xb2JmU8YmzEI9+AOnDlj3fiCB7qywEcZpfQ8ghiTS87WtN/Yf3IVmxD8R+/RiJ8bJ9tiXec= X-Received: by 2002:a4a:c993:: with SMTP id u19mr1951899ooq.31.1634175857633; Wed, 13 Oct 2021 18:44:17 -0700 (PDT) MIME-Version: 1.0 From: Ted Lemon Date: Wed, 13 Oct 2021 21:43:42 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000007ebb7505ce46372e" Archived-At: Subject: [dnssd] A bit more on subtypes in the SRP document 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: Thu, 14 Oct 2021 01:44:23 -0000 --0000000000007ebb7505ce46372e Content-Type: text/plain; charset="UTF-8" I've been doing the implementation for subtypes, and I think there needs to be some additional clarifying text. It turns out to be really complicated on various levels to support adding and removing individual subtypes. So I would like to add text that restricts subtype updates roughly as follows: Updates for service instances and their subtypes are considered as a whole: deletes of individual subtypes are not permitted. An update of a service instance replaces whatever subtypes may have previously been present with the subtypes in the update. The reason for this is that there's little utility to allowing edits. A service presumably knows its subtypes, and so it's easier for the service to update them atomically rather than trying to keep track of what was sent previously. Allowing for editing of subtypes would make SRP replication really, hard to get right. I say this having embarked upon an implementation and then backing it out because it was just spiraling. --0000000000007ebb7505ce46372e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been doing the implementation for subtypes, and I= think there needs to be some additional clarifying text. It turns out to b= e really complicated on various levels to support adding and removing indiv= idual subtypes. So I would like to add text that restricts subtype updates = roughly as follows:

Updates for service instances and th= eir subtypes are considered as a whole: deletes of individual subtypes are = not permitted. An update of a service instance replaces whatever subtypes m= ay have previously been present with the subtypes in the update.
=
The reason for this is that there's little utility to al= lowing edits. A service presumably knows its subtypes, and so it's easi= er for the service to update them atomically rather than trying to keep tra= ck of what was sent previously. Allowing for editing of subtypes would make= SRP replication really, hard to get right.

I say = this having embarked upon an implementation and then backing it out because= it was just spiraling.
--0000000000007ebb7505ce46372e-- From nobody Wed Oct 13 22:01:31 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 431513A12A4 for ; Wed, 13 Oct 2021 22:01:28 -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 PjnO1H9iYUxg for ; Wed, 13 Oct 2021 22:01:22 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 E60D33A12A0 for ; Wed, 13 Oct 2021 22:01:21 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i189so2309416ioa.1 for ; Wed, 13 Oct 2021 22:01:21 -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 :cc; bh=hX8fbMP0ycj7FNoYzZKe5Y/SQI3VPuucsilOSNNxVMc=; b=javCixZyzYWGrKbZhlkx+oBu/8FpYg/hJkBo4pbV2+t302WcQElB65Y64F7u18grep quYtW2SlBAPx+49kjzHLpFj5ruRTh8utNYHnyn5ru56WhMSBU2aPzVdxnWW6BCPoNSFh Ce/llabCLCS7njUWShA3yC+X8OP6sY4wi/Fq1LGLMlNZWNyV1t//umDjMQtwgETEnoMf Zn0w96kBgJ0+JH+M67uwNLgcAuT4FASHQjg9XhXcJt89TCJvdDLsl90Su966zwsncU1q iaxd4NBjqaGx272p4zxWagxBRkAsKjiNQnRnpZykYUoQzS04CIEDWOtklerJwB1uKogw hCzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hX8fbMP0ycj7FNoYzZKe5Y/SQI3VPuucsilOSNNxVMc=; b=Lg05GR2cgxmZZISNRrBsuxwgLAWy5jnmvRZ+hSaYxpzuX1gUSJYMnQCjiR3WSi2olf KCpaIq5nAVs/b2f9uUXu6wIEMYfkAuHM3b1SKIDw+R6OUsby1vVn1EDJ56yPoqVxlK/R GrdiLYUFbVBoodK+6hIhSbaMg2huUE+hLXEicuBk26QUJayj3dGXYBJfWTeVzOYsWcXo pbYl1tVFUzk+WfFVjvF5dzQ1QDwBM6gOiM8s1VLgulLJA8CKgTutBJ6mdqTpgYUistAr unBC7Jw6hH3bFCsTVepQZmeS5S+SmSfOXkOX29E4vZZ01LGJ+e9zGbgm9WhuMoFDlU1v 8DNg== X-Gm-Message-State: AOAM5323PjYRP25ZWzscQJfv5t1L8CQTqtvDUuXj2PPAMAuUdoE3xP3z HBSiNdxNgUEfGM5nmGf0nx4FsTfUWCudRUSerpUfSg== X-Google-Smtp-Source: ABdhPJz8ely9AvGh9Ei0ott3AOSCdaQzWk1ZOT7jBj97HveP37dC1H/u9MUbAi66pDc5ddI7af8MAi71h/xo6XdxLlo= X-Received: by 2002:a5d:9493:: with SMTP id v19mr820328ioj.34.1634187678694; Wed, 13 Oct 2021 22:01:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Wed, 13 Oct 2021 22:01:07 -0700 Message-ID: To: Ted Lemon Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000161ab105ce48f8ab" Archived-At: Subject: Re: [dnssd] A bit more on subtypes in the SRP document 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: Thu, 14 Oct 2021 05:01:28 -0000 --000000000000161ab105ce48f8ab Content-Type: text/plain; charset="UTF-8" This makes sense to me. I was actually thinking through how one might handle subtype edits in the context of SRP replication earlier today. Requiring atomic updates will certainly simplify the implementation. -- Jonathan Hui On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon wrote: > I've been doing the implementation for subtypes, and I think there needs > to be some additional clarifying text. It turns out to be really > complicated on various levels to support adding and removing individual > subtypes. So I would like to add text that restricts subtype updates > roughly as follows: > > Updates for service instances and their subtypes are considered as a > whole: deletes of individual subtypes are not permitted. An update of a > service instance replaces whatever subtypes may have previously been > present with the subtypes in the update. > > The reason for this is that there's little utility to allowing edits. A > service presumably knows its subtypes, and so it's easier for the service > to update them atomically rather than trying to keep track of what was sent > previously. Allowing for editing of subtypes would make SRP replication > really, hard to get right. > > I say this having embarked upon an implementation and then backing it out > because it was just spiraling. > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000161ab105ce48f8ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This makes sense to me. I was actual= ly thinking through how one might handle subtype edits in the context of SR= P replication earlier today. Requiring atomic updates will certainly simpli= fy=C2=A0the implementation.

--
Jonathan Hui


<= /div>
O= n Wed, Oct 13, 2021 at 6:44 PM Ted Lemon <mellon@fugue.com> wrote:
I've been doing the implementati= on for subtypes, and I think there needs to be some additional clarifying t= ext. It turns out to be really complicated on various levels to support add= ing and removing individual subtypes. So I would like to add text that rest= ricts subtype updates roughly as follows:

Updates for se= rvice instances and their subtypes are considered as a whole: deletes of in= dividual subtypes are not permitted. An update of a service instance replac= es whatever subtypes may have previously been present with the subtypes in = the update.

The reason for this is that there'= s little utility to allowing edits. A service presumably knows its subtypes= , and so it's easier for the service to update them atomically rather t= han trying to keep track of what was sent previously. Allowing for editing = of subtypes would make SRP replication really, hard to get right.

I say this having embarked upon an implementation and then = backing it out because it was just spiraling.
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000161ab105ce48f8ab-- From nobody Thu Oct 14 10:03:05 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 8700D3A1753 for ; Thu, 14 Oct 2021 10:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 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, 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 WzjW0IweUr9r for ; Thu, 14 Oct 2021 10:02:58 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 81FBD3A174D for ; Thu, 14 Oct 2021 10:02:58 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id f3so12639481uap.6 for ; Thu, 14 Oct 2021 10:02:58 -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 :cc; bh=Nxk/MHt91iGvT37ZOWJYiqNdzoCEYB6SUYX87VQMblQ=; b=bZuhXgMrvnZ7RFVtx2uC3zNzDKh5P/m3jIhk6qNpaC8iNnsN1Qc1IXApsDBAyTf38g RAhr8Dbmfy8moSk0OKsMRhwDE3N7Esq12Y+Wm59eWIUgvHstRxEo2MR3yECQZN5HFGdk qqp/71vDbN0lnyvkrlc6Hg7TPeNeLbpZ2031FrYr9hy7XJSmnB6TqUdoVtQKkWCzgMJd 4Va5fCf5TsLTY9+Ih0c4o85TU4yju8nJJCG93l8j0D5cPrqErJKN1II7ZpM4jQVlazad ri+mnqGiTCC0euanaeUdukmFB/HCI2EnZe38VoBYqlC41AcIRXyXmShZx5GI+YVeIdGv cQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nxk/MHt91iGvT37ZOWJYiqNdzoCEYB6SUYX87VQMblQ=; b=F7rGc07BMrIek0pYl9t40h6asPStAbW+zMOpRm9xUAIBjtmG8IwJ8Wvm8fGUGG5nx3 O4fneDNZefosJAkgpR47HjXjNHVV6XM0Js+diqzDa7GeC5/+uClI0moSp2Jk8HdZzLY1 XBMOWJhC38ZQ9buZJl4euG/MsuziHR47tgsF1/UPPGdta70aYQMZ/V52dITntSlZtd7B 1i8dZlsMCIsU8/421dzEadoylSYX5/moztgkWlCA1CbWfUaqkky4q+/M+OTc73LgmDtS Fr4sNwRmeNRl8Q0DvugIHQ7SvfMCf+kEgATVzyk0MltjuZgV9TapFdoobEjjGBBjP6AG LSOg== X-Gm-Message-State: AOAM531oR3evIcdkfnkPrP/g8lZIKYa+f2f7PCR+UnrOcf+JA1W/1zWg 4bdOOC6nXs3HHzIrpZPluPb0UQLM0uXZC3pGeU9+vLKhtH4gmg== X-Google-Smtp-Source: ABdhPJx1uebtL0W2jOPe/e4S4GE/jxnd5IL2Qk710v+jkpbJbwUBScCq63T3UOSGAQfWd3yOccm8F69nb6gO2XnMNWQ= X-Received: by 2002:a67:1047:: with SMTP id 68mr7503586vsq.39.1634230974486; Thu, 14 Oct 2021 10:02:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abtin Keshavarzian Date: Thu, 14 Oct 2021 10:02:43 -0700 Message-ID: To: Jonathan Hui Cc: Ted Lemon , dnssd Content-Type: multipart/alternative; boundary="000000000000b879ba05ce530caa" Archived-At: Subject: Re: [dnssd] A bit more on subtypes in the SRP document 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: Thu, 14 Oct 2021 17:03:04 -0000 --000000000000b879ba05ce530caa Content-Type: text/plain; charset="UTF-8" I fully agree. Treating service instances and their subtypes as a whole makes sense to me (helps simplify not only the SRP client implementation, but the replication logic as well). Abtin. On Wed, Oct 13, 2021 at 10:01 PM Jonathan Hui wrote: > This makes sense to me. I was actually thinking through how one might > handle subtype edits in the context of SRP replication earlier today. > Requiring atomic updates will certainly simplify the implementation. > > -- > Jonathan Hui > > > > On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon wrote: > >> I've been doing the implementation for subtypes, and I think there needs >> to be some additional clarifying text. It turns out to be really >> complicated on various levels to support adding and removing individual >> subtypes. So I would like to add text that restricts subtype updates >> roughly as follows: >> >> Updates for service instances and their subtypes are considered as a >> whole: deletes of individual subtypes are not permitted. An update of a >> service instance replaces whatever subtypes may have previously been >> present with the subtypes in the update. >> >> The reason for this is that there's little utility to allowing edits. A >> service presumably knows its subtypes, and so it's easier for the service >> to update them atomically rather than trying to keep track of what was sent >> previously. Allowing for editing of subtypes would make SRP replication >> really, hard to get right. >> >> I say this having embarked upon an implementation and then backing it out >> because it was just spiraling. >> _______________________________________________ >> 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 > --000000000000b879ba05ce530caa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I fully agree.=C2=A0
Treating service instances an= d their subtypes as a whole makes sense to me=C2=A0 (helps simplify=C2=A0no= t only the SRP client=C2=A0implementation, but the replication logic as wel= l).=C2=A0
Abtin.

On Wed, Oct 13, 2021 at 10:01 PM Jonath= an Hui <jonhui=3D40google= .com@dmarc.ietf.org> wrote:
This makes sense = to me. I was actually thinking through how one might handle subtype edits i= n the context of SRP replication earlier today. Requiring atomic updates wi= ll certainly simplify=C2=A0the implementation.

=
--
Jonathan Hui
=


On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon &= lt;mellon@fugue.com> wrote:
I've been doing the implementation for subtypes, and I t= hink there needs to be some additional clarifying text. It turns out to be = really complicated on various levels to support adding and removing individ= ual subtypes. So I would like to add text that restricts subtype updates ro= ughly as follows:

Updates for service instances and thei= r subtypes are considered as a whole: deletes of individual subtypes are no= t permitted. An update of a service instance replaces whatever subtypes may= have previously been present with the subtypes in the update.
The reason for this is that there's little utility to allo= wing edits. A service presumably knows its subtypes, and so it's easier= for the service to update them atomically rather than trying to keep track= of what was sent previously. Allowing for editing of subtypes would make S= RP replication really, hard to get right.

I say th= is having embarked upon an implementation and then backing it out because i= t was just spiraling.
_______________________________________________
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
--000000000000b879ba05ce530caa-- From nobody Thu Oct 14 20:30:12 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 03E653A1835 for ; Thu, 14 Oct 2021 20:30:11 -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 9j9m6DWClclf for ; Thu, 14 Oct 2021 20:30:06 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 933E53A182F for ; Thu, 14 Oct 2021 20:30:06 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id np13so6266578pjb.4 for ; Thu, 14 Oct 2021 20:30:06 -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 :cc; bh=nWUmlBEM9r9/5kP7HuIttIKbwl+dbeujfDkoaJSorhA=; b=RBCKazfiS1FrYW7WPAw5Wg8qKZUOOFO4AMK4ARyLvFuescia4N7b2/4TptLLkqEOHn AB15jMlXb9JfC59v3++gkcFDVpm3jm9x6A0xnDuDX8cZvyBshVXF+Y/rF3NqhTi41RA/ f0YhvjHJHD/gdfdf87OakIaAtznM1wO+c9YX+Uthpzu1ktU29xI32YpDvoba1ICFWky6 mZJEM5kDymOn7Vs4uphgnUK95OmQzkbpdIQ69UnsEJVQbj0ZZdX3NJrgWbRivr3Ma0uw DWQnCDpvLVoQg+HVICVfLvTAJjx1EVAD/LxXITBYWG3Ts8orQtGCN0ipYHmqY2Q3IffI KlrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nWUmlBEM9r9/5kP7HuIttIKbwl+dbeujfDkoaJSorhA=; b=NglQmVIJ1n1gGupQr89V0AXo2sSnSZSCvvR30rgE/EE3kvCCZ7CtYZ+BwZw3BP07sz hNi5D/QuF1G359+lFa7qXDsWPsGB4MAyb0Z5HdEcamJzHtAyL8D0GRopgPJ+ZPoNkmG1 EPUqWWbZiiVU0OTaZW98v0hpm4YARI9h6qfai4BBOsopLEyviQlI26sLfm1Wfq7eijwd G9veZ7yTo867bELTWC8+SPA3VXpiwKP9Igm/Xg78ABl5dsP3wCVthU+Fq4oiEawp8sW8 SVnxd215Szacgy7K5XsH0ndYfxsAYl54RWaCdmE91R5XQ9eKLsxKd7ld3ZJGgnpzYmDE GiHw== X-Gm-Message-State: AOAM533VyUnkFx8vxmLUro+FIEc4tJ4B2j4vdfpfFyHbgMPwzNi+rTe4 Nx+SpkU4FICUGvTgqKMp1XvzwujVrTceRSK2p3tb0VgWqQ9i7ERtX7Y= X-Google-Smtp-Source: ABdhPJzxl4RbaTV2fGb+hfeYF1z9gIXeOq8EtXLuzh+U133Dr97HA9Ibi2YAm3Lcpx0mDqheVmIwyjov69/SiC6Yv3Q= X-Received: by 2002:a17:90b:3a81:: with SMTP id om1mr15375989pjb.184.1634268605124; Thu, 14 Oct 2021 20:30:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kangping Dong Date: Fri, 15 Oct 2021 11:29:29 +0800 Message-ID: To: Abtin Keshavarzian Cc: Jonathan Hui , dnssd , Ted Lemon Content-Type: multipart/alternative; boundary="000000000000addd1905ce5bcf9a" Archived-At: Subject: Re: [dnssd] A bit more on subtypes in the SRP document 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: Fri, 15 Oct 2021 03:30:11 -0000 --000000000000addd1905ce5bcf9a Content-Type: text/plain; charset="UTF-8" Agree, though the OpenThread SRP server is implemented to support updating individual subtypes :) BRs, kangping On Fri, Oct 15, 2021 at 1:03 AM Abtin Keshavarzian wrote: > I fully agree. > Treating service instances and their subtypes as a whole makes sense to > me (helps simplify not only the SRP client implementation, but the > replication logic as well). > Abtin. > > On Wed, Oct 13, 2021 at 10:01 PM Jonathan Hui 40google.com@dmarc.ietf.org> wrote: > >> This makes sense to me. I was actually thinking through how one might >> handle subtype edits in the context of SRP replication earlier today. >> Requiring atomic updates will certainly simplify the implementation. >> >> -- >> Jonathan Hui >> >> >> >> On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon wrote: >> >>> I've been doing the implementation for subtypes, and I think there needs >>> to be some additional clarifying text. It turns out to be really >>> complicated on various levels to support adding and removing individual >>> subtypes. So I would like to add text that restricts subtype updates >>> roughly as follows: >>> >>> Updates for service instances and their subtypes are considered as a >>> whole: deletes of individual subtypes are not permitted. An update of a >>> service instance replaces whatever subtypes may have previously been >>> present with the subtypes in the update. >>> >>> The reason for this is that there's little utility to allowing edits. A >>> service presumably knows its subtypes, and so it's easier for the service >>> to update them atomically rather than trying to keep track of what was sent >>> previously. Allowing for editing of subtypes would make SRP replication >>> really, hard to get right. >>> >>> I say this having embarked upon an implementation and then backing it >>> out because it was just spiraling. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000addd1905ce5bcf9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree, though the OpenThread SRP server is implemented to support updating individual=C2=A0subtypes :)


BRs,
kangping

On Fri, Oct 15, 2021= at 1:03 AM Abtin Keshavarzian <abtink=3D40google.com@dmarc.ietf.org> wrote:
I fully agree.= =C2=A0
Treating service instances and their subtypes as a whole mak= es sense to me=C2=A0 (helps simplify=C2=A0not only the SRP client=C2=A0impl= ementation, but the replication logic as well).=C2=A0
Abtin.<= /div>

On Wed, Oct 13, 2021 at 10:01 PM Jonathan Hui <jonhui=3D40google.com@dmarc.ie= tf.org> wrote:
This makes sense to me. I was = actually thinking through how one might handle subtype edits in the context= of SRP replication earlier today. Requiring atomic updates will certainly = simplify=C2=A0the implementation.

--
Jonathan Hui



On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon <mellon@fugue.com> wrote:=
I've been doing the implementation for subtypes, and I think there ne= eds to be some additional clarifying text. It turns out to be really compli= cated on various levels to support adding and removing individual subtypes.= So I would like to add text that restricts subtype updates roughly as foll= ows:

Updates for service instances and their subtypes ar= e considered as a whole: deletes of individual subtypes are not permitted. = An update of a service instance replaces whatever subtypes may have previou= sly been present with the subtypes in the update.

= The reason for this is that there's little utility to allowing edits. A= service presumably knows its subtypes, and so it's easier for the serv= ice to update them atomically rather than trying to keep track of what was = sent previously. Allowing for editing of subtypes would make SRP replicatio= n really, hard to get right.

I say this having emb= arked upon an implementation and then backing it out because it was just sp= iraling.
_______________________________________________
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
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000addd1905ce5bcf9a-- From nobody Thu Oct 14 20:36:33 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 2BCD23A182F for ; Thu, 14 Oct 2021 20:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 qrmGhNr8NBhO for ; Thu, 14 Oct 2021 20:36:22 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 A6A6E3A1835 for ; Thu, 14 Oct 2021 20:36:22 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id w12-20020a056830410c00b0054e7ceecd88so11129258ott.2 for ; Thu, 14 Oct 2021 20:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uIeOdnDUzKCWyrkBTwWJYf+fRdw+ghrvMxkYQ8eXvWo=; b=Ucm6TW9FzpNg8aFRT4dfDDOBlWD4/fs8oCYRY9Vp/XHJ1BbHF4wtvcCE/1lkVH3AIg eicnHFfeqy6Vft/QpXisVPsGDTKf9wdGv7cSRAd8h/fEd8JHpnMIW1TIgtKKddNI1KK9 25AP1aYuIkEAC9WVDYIiHhNuMBcqIT11Lo6Y0xHbva+MXu7t1GPG+VCn6FuEHrUE9rTD bhLb1xky6TUrkn2iidvXGpbLc6AsSjSQaYAShLB5pPL1U8dTBjFkgAfIS/VPbzLkkxNq 8Z0k06vI7ajf7XZmbE5fAwRUqDYyG4X9as8pTgY2Et1gZ5LKdGLCSDAOrO8nKrU9Qj1I Q2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uIeOdnDUzKCWyrkBTwWJYf+fRdw+ghrvMxkYQ8eXvWo=; b=6L09N1rSWkRbugV8preBxHRiWtaTHnQ2iCL2gATlfDfs3RWp6SpugB2XLlS1vkRS8X wUdbx7iUioYm0PlELsxb74TTeMt2B42TA03MUmLhOr28NRjjwJzsGfdebZ7UsbEoiMtu WBAlvPo6PJBSn6lD5swgDy0fQRj63wYkwmONviPHTpQg0lWRfljtP2GyY8rYygH+vHSj gsXtN3vvURl/fNO+pXDlkjrxmN4sdx7pXBQeuQsX5Onp2gbogDrG+ex3Uv7jcDDuy/bQ Skq5xSmFHUEnsyLJ0fnTTzPZBOkUKvZsYjB1V0vu6eqdiWeK7b7uJBQvv9FhQ5WS0yKh lARw== X-Gm-Message-State: AOAM533+5uJTv7+EM0euYPzvvHwGYMZrtRO2qvVZo7yVjJQx/n8yP+H+ POQskwneUjha5aNJw/Zztozr68dHjhmYqP49Oi+7ow== X-Google-Smtp-Source: ABdhPJxE08HnY29na0uvQisvtQ50pQTE+HDDP/+4GN8AY07oZRlIKKygwPXpf8VXzSo02iKiiKiN7tESriJS4iy1hCY= X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr5841810otb.309.1634268981341; Thu, 14 Oct 2021 20:36:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Thu, 14 Oct 2021 23:35:45 -0400 Message-ID: To: Kangping Dong Cc: Abtin Keshavarzian , Jonathan Hui , dnssd Content-Type: multipart/alternative; boundary="00000000000019be6505ce5be6cc" Archived-At: Subject: Re: [dnssd] A bit more on subtypes in the SRP document 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: Fri, 15 Oct 2021 03:36:29 -0000 --00000000000019be6505ce5be6cc Content-Type: text/plain; charset="UTF-8" Yes, supporting it in the server isn't too bad until you start thinking about how to do replication. Then it gets a bit painful, unless you just get rid of the SRP trust model, which I would prefer not to do. On Thu, Oct 14, 2021 at 11:30 PM Kangping Dong wrote: > Agree, though the OpenThread SRP server > > is implemented to support updating individual subtypes :) > > > BRs, > kangping > > On Fri, Oct 15, 2021 at 1:03 AM Abtin Keshavarzian 40google.com@dmarc.ietf.org> wrote: > >> I fully agree. >> Treating service instances and their subtypes as a whole makes sense to >> me (helps simplify not only the SRP client implementation, but the >> replication logic as well). >> Abtin. >> >> On Wed, Oct 13, 2021 at 10:01 PM Jonathan Hui > 40google.com@dmarc.ietf.org> wrote: >> >>> This makes sense to me. I was actually thinking through how one might >>> handle subtype edits in the context of SRP replication earlier today. >>> Requiring atomic updates will certainly simplify the implementation. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon wrote: >>> >>>> I've been doing the implementation for subtypes, and I think there >>>> needs to be some additional clarifying text. It turns out to be really >>>> complicated on various levels to support adding and removing individual >>>> subtypes. So I would like to add text that restricts subtype updates >>>> roughly as follows: >>>> >>>> Updates for service instances and their subtypes are considered as a >>>> whole: deletes of individual subtypes are not permitted. An update of a >>>> service instance replaces whatever subtypes may have previously been >>>> present with the subtypes in the update. >>>> >>>> The reason for this is that there's little utility to allowing edits. A >>>> service presumably knows its subtypes, and so it's easier for the service >>>> to update them atomically rather than trying to keep track of what was sent >>>> previously. Allowing for editing of subtypes would make SRP replication >>>> really, hard to get right. >>>> >>>> I say this having embarked upon an implementation and then backing it >>>> out because it was just spiraling. >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > --00000000000019be6505ce5be6cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, supporting it in the server isn't too bad until y= ou start thinking about how to do replication. Then it gets a bit painful, = unless you just get rid of the SRP trust model, which I would prefer not to= do.

On Thu, Oct 14, 2021 at 11:30 PM Kangping Dong <wgtdkp@google.com> wrote:
Agree, though the OpenT= hread SRP server is implemented to support updating individual=C2=A0sub= types :)


BRs,
kangping

On = Fri, Oct 15, 2021 at 1:03 AM Abtin Keshavarzian <abtink=3D40google.com@dmarc.ietf.= org> wrote:
I fully agree= .=C2=A0
Treating service instances and their subtypes as a whole ma= kes sense to me=C2=A0 (helps simplify=C2=A0not only the SRP client=C2=A0imp= lementation, but the replication logic as well).=C2=A0
Abtin.=

On Wed, Oct 13, 2021 at 10:01 PM Jonathan Hui <jonhui=3D40google.com@dmarc.i= etf.org> wrote:
This makes sense to me. I was actually thinking through how o= ne might handle subtype edits in the context of SRP replication earlier tod= ay. Requiring atomic updates will certainly simplify=C2=A0the implementatio= n.

--
Jonathan Hui



On Wed, Oct = 13, 2021 at 6:44 PM Ted Lemon <mellon@fugue.com> wrote:
I've been doing the implementation for subtypes, and I thi= nk there needs to be some additional clarifying text. It turns out to be re= ally complicated on various levels to support adding and removing individua= l subtypes. So I would like to add text that restricts subtype updates roug= hly as follows:

Updates for service instances and their = subtypes are considered as a whole: deletes of individual subtypes are not = permitted. An update of a service instance replaces whatever subtypes may h= ave previously been present with the subtypes in the update.

=
The reason for this is that there's little utility to allowi= ng edits. A service presumably knows its subtypes, and so it's easier f= or the service to update them atomically rather than trying to keep track o= f what was sent previously. Allowing for editing of subtypes would make SRP= replication really, hard to get right.

I say this= having embarked upon an implementation and then backing it out because it = was just spiraling.
_______________________________________________
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
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--00000000000019be6505ce5be6cc-- From nobody Fri Oct 15 15:45:36 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8043A0DC7; Fri, 15 Oct 2021 15:34:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnssd@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433725177.17026.11903573846039897333@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:11 -0700 Archived-At: Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 112 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 15 Oct 2021 22:34:29 -0000 Dear Chris Box, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (1:00 requested) Friday, 12 November 2021, Session III 1600-1700 Room Name: Room 3 size: 503 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/dnssd.ics Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Chris Box Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: People who must be present: Barbara Stark Chris Box David Schinazi Eric Vyncke Stuart Cheshire Ted Lemon Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 18 10:26: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 45EEC3A16AA for ; Mon, 18 Oct 2021 10:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YzjsNCQBm7-P for ; Mon, 18 Oct 2021 10:26:43 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 8BE633A16BC for ; Mon, 18 Oct 2021 10:26:43 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id v2so10638992qve.11 for ; Mon, 18 Oct 2021 10:26:43 -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=vdvhI0IzFk9OPA3gX6B6kP31MDX3f9jk1GRzerIYnW0=; b=E28GpTSReVV+bdNDK9efJunU1HLo0Eiws8k8JjNHnotdqC4nfDIkZ4zcHeArO92JFz yeaJVpPkzh0DdNvZjmRUEvWVwBkNOxOlVtm0OOioqiYSsLomtDCId1zfDKLQcb67b4oE 2QEkqM74ZSEunktwB95yJvaydILbVX/YaVWbQ0hGMzc86KzREvJuonekRsQg/YNxhHRe z9zdw8B/iiPc03VvqPSxQSBajcWTLMzxxqZ+uPgcqXOOrgPVcniKYTMbeFbw0gSDbP1q QKXnNMF7fkfwuwhhHwdfbMzPNleqCMvVVBKddc0jWo0d3k5nd6WNLQcopeoYwAK9X1Oa 4b5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vdvhI0IzFk9OPA3gX6B6kP31MDX3f9jk1GRzerIYnW0=; b=dS/z6B3DzPwFUkiwAiS/c6wokrYl6n+l/Mq3nxKyVtbzxA0/iKTOjD4kQyxxH+42/N AGzbvNECojjDTEAnOKBsaMV79Pmtbe/ulBmK5XmFiWBst+agM7dmH3eD4qGc64H6OqC0 gWYOdqGY9YeTzkbfomnPyUYI9M80gRMD9x4ilezF7oJTiruE16s7Ko8yMJMMKD2THVNu 6PIwutFgItc7Ol7RsiSF/S9uUe7OZXNX2WFaCxq3gWHllDSAosAYU/LDCwEE41ayMHX0 Yh04f3FTyUa4XFXyr/1Jy8mGx1W/fDssf2Ff6lBtiBoCjJkNisza349CAzHICn5zzBQf ufaA== X-Gm-Message-State: AOAM533JP9GtzktHaGR+K3xuex3JmuQaNRSm2fRRrQUu4zNk3L98lkRz iuKcxdqQ3OqfogU9HZYx+BGo5IfWnsCvtQYyv/CX2WC2 X-Google-Smtp-Source: ABdhPJxYauiFB0fIZ19OVGVQwbcJ9/Pv+1lQzKtmFaB2uuAtsNPwigFyo+ey9wghdv+XA++wJWZ2+g1yRz1eCVv47HU= X-Received: by 2002:a05:6214:b30:: with SMTP id w16mr26849997qvj.61.1634578002208; Mon, 18 Oct 2021 10:26:42 -0700 (PDT) MIME-Version: 1.0 References: <163433725177.17026.11903573846039897333@ietfa.amsl.com> In-Reply-To: <163433725177.17026.11903573846039897333@ietfa.amsl.com> From: Chris Box Date: Mon, 18 Oct 2021 18:26:30 +0100 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000002deaad05cea3d9b1" Archived-At: Subject: Re: [dnssd] dnssd - Requested session has been scheduled for IETF 112 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: Mon, 18 Oct 2021 17:26:49 -0000 --0000000000002deaad05cea3d9b1 Content-Type: text/plain; charset="UTF-8" Hi WG, This slot should be easy to remember, since it's the last one of the week. As there won't be any participants needing to rush off to Madrid airport then we should have a productive working group session. I'll see you there. Chris On Fri, 15 Oct 2021 at 23:34, "IETF Secretariat" wrote: > Dear Chris Box, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > dnssd Session 1 (1:00 requested) > Friday, 12 November 2021, Session III 1600-1700 > Room Name: Room 3 size: 503 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/112/sessions/dnssd.ics > > Request Information: > > > --------------------------------------------------------- > Working Group Name: Extensions for Scalable DNS Service Discovery > Area Name: Internet Area > Session Requester: Chris Box > > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 60 > Conflicts to Avoid: > > > > > People who must be present: > Barbara Stark > Chris Box > David Schinazi > Eric Vyncke > Stuart Cheshire > Ted Lemon > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > > --0000000000002deaad05cea3d9b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

This slot should be e= asy to remember, since it's the last one of the week. As there won'= t be any participants needing to rush off to Madrid airport then we should = have a productive working group session. I'll see you there.
=
Chris

On Fri, 15 Oct 2021 at 23:34, "IETF Secretariat&qu= ot; <agenda@ietf.or= g> wrote:
Dear Chris Box,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.


=C2=A0 =C2=A0 dnssd Session 1 (1:00 requested)
=C2=A0 =C2=A0 Friday, 12 November 2021, Session III 1600-1700
=C2=A0 =C2=A0 Room Name: Room 3 size: 503
=C2=A0 =C2=A0 ---------------------------------------------


iCalendar: https://datatracker.ietf.org/m= eeting/112/sessions/dnssd.ics

Request Information:


---------------------------------------------------------
Working Group Name: Extensions for Scalable DNS Service Discovery
Area Name: Internet Area
Session Requester: Chris Box


Number of Sessions: 1
Length of Session(s):=C2=A0 1 Hour
Number of Attendees: 60
Conflicts to Avoid:




People who must be present:
=C2=A0 Barbara Stark
=C2=A0 Chris Box
=C2=A0 David Schinazi
=C2=A0 Eric Vyncke
=C2=A0 Stuart Cheshire
=C2=A0 Ted Lemon

Resources Requested:

Special Requests:

---------------------------------------------------------


--0000000000002deaad05cea3d9b1-- From nobody Fri Oct 22 18:11:28 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 31B233A087F for ; Fri, 22 Oct 2021 18:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 c3GJIviFjfS0 for ; Fri, 22 Oct 2021 18:11:23 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 D93783A0877 for ; Fri, 22 Oct 2021 18:11:22 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id l16-20020a9d6a90000000b0054e7ab56f27so6406797otq.12 for ; Fri, 22 Oct 2021 18:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MuaYd91CGEzi5UJI9w17jt5fMdY5LtQpEinFInbxLVs=; b=2iQQWWgt+bvGjOG6TFBE9MIX9/YCI0+72tiYjYPp/ETKsI/9qHJlpJWNzIn+ffeBVB uVQmaAS8oZHGT3OUcm4NEeg4dnjqOZI0+5goLpk5fZsP8+BNlPrqE5Y+adnCdkhLWKtS p0d3butKJbYKP5n1G6ragcuu4Fkbz40ZtJ1RgsuiaYGM7CXUXDrRPbpg4bXeG4eRXIFh d8F5h7Tf8EaWtLlDIfxRt6XIf856Q1o8UpaIbyULk1u+uiXXd2CUaD1Cc7A+3o4hoW99 TFn4pQwk9OgijWi7KORcaN5fnkGmNt26ttzU/025HWrWqLxgLlx7uB8At0gE+ANpiqnh NloA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MuaYd91CGEzi5UJI9w17jt5fMdY5LtQpEinFInbxLVs=; b=X2Tg9mNeWLRme4QaxZOk/UQzQ9CMkKwu03IuI12+hkoJdIXnW4FCI9LcQDjJRlMq5q bga+0RFQB/hsLEBnhjxiY0ughdsDuOOmLGQUau8zDJ4vm2v0W1r3jpsspWBISC2HE3as 9FmkTRCqfZL5iSsDcxNCefGZkJ7WxT8Mi0CMkhOzMKcnDxJsiZSmJ0aIKvsjgsasA8Sg 1zC09omC3UduO5kMXvOOCfOZnt9QOxmOt1dmrO58PvQzvaXgH6iSiEvEQIeJ/Lz+6ExM PdrtUN8O0qMzf0Uf9bpuep52V+0lJru1MbzPVc/vi3d7Ly7me14bFVpWrQA3eij2gioy ddYw== X-Gm-Message-State: AOAM533qX5MG3adcnYTJ9dT8d0fAu3o85mtA85asCcr5ejQHA20Q5k6J 7zXrCTSVV4QR532FLbZ5R3VMkSIfhwQALx2lnM5WaDIYj9g= X-Google-Smtp-Source: ABdhPJzc2Gb3mofkDJaJU2fN+7vN3NCKRov07EBLAJaz9pNoFjiHaye8En1sZ8ca5Lnyn2Jl6l+pozaK/LsrfTyvr9Q= X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr2446812otb.309.1634951480714; Fri, 22 Oct 2021 18:11:20 -0700 (PDT) MIME-Version: 1.0 References: <163495121756.28271.11931959293800230753@ietfa.amsl.com> In-Reply-To: <163495121756.28271.11931959293800230753@ietfa.amsl.com> From: Ted Lemon Date: Fri, 22 Oct 2021 21:10:45 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000003bbb4d05cefacec7" Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-tllq-tsr-00.txt 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, 23 Oct 2021 01:11:27 -0000 --0000000000003bbb4d05cefacec7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've uploaded a new draft for the working group's consideration. This solves the problem of what to do when two advertising proxies get updates from the same host at two different times. Using normal mDNS conflict resolution rules, the older (stale) update wins. This is correct behavior for non-proxied mDNS, but obviously incorrect for proxied mDNS. The "Time Since Registered" RR provides a way to indicate which mDNS advertisement is more recent, so that conflict resolution can choose the less stale answer rather than the more stale answer. I'd be curious to hear what people think of this proposal. ---------- Forwarded message --------- From: Date: Fri, Oct 22, 2021 at 9:06 PM Subject: New Version Notification for draft-tllq-tsr-00.txt To: =E7=A7=A6=E8=89=AF , Qin Liang , Ted Lemon A new version of I-D, draft-tllq-tsr-00.txt has been successfully submitted by Ted Lemon and posted to the IETF repository. Name: draft-tllq-tsr Revision: 00 Title: A 'Time Since Registration' Resource Record for Multicast DNS Document date: 2021-10-22 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-tllq-tsr-00.txt Status: https://datatracker.ietf.org/doc/draft-tllq-tsr/ Html: https://www.ietf.org/archive/id/draft-tllq-tsr-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-tllq-tsr Abstract: This document defines a new DNS Resource Record (RR) to be used with multicast DNS. The new RR is used to communicate the time at which the set of RRsets on a domain name were first registered. The IETF Secretariat --0000000000003bbb4d05cefacec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've uploaded a new draft for the working group's = consideration. This solves the problem of what to do when two advertising p= roxies get updates from the same host at two different times. Using normal = mDNS conflict resolution rules, the older (stale) update wins. This is corr= ect behavior for non-proxied mDNS, but obviously incorrect for proxied mDNS= . The "Time Since Registered" RR provides a way to indicate which= mDNS advertisement is more recent, so that conflict resolution can choose = the less stale answer rather than the more stale answer.

I'd be curious to hear what people think of this proposal.

---------- For= warded message ---------
From: <internet-drafts@ietf.org>
Date: = Fri, Oct 22, 2021 at 9:06 PM
Subject: New Version Notification for draft= -tllq-tsr-00.txt
To: =E7=A7=A6=E8=89=AF <Leonqin0101@gmail.com>, Qin Liang <leonqin0101@gmail.com>, Ted Lemon <mellon@fugue.com>


A new version of I-D, draft-tllq-tsr-00.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tllq-tsr
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A 'Time Since Registration'= ; Resource Record for Multicast DNS
Document date:=C2=A0 2021-10-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.ietf.org/archive/id/draft-tllq-tsr-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-tllq-tsr/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/archive/id/draft-tllq-tsr-00.html
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://data= tracker.ietf.org/doc/html/draft-tllq-tsr


Abstract:
=C2=A0 =C2=A0This document defines a new DNS Resource Record (RR) to be use= d with
=C2=A0 =C2=A0multicast DNS.=C2=A0 The new RR is used to communicate the tim= e at which
=C2=A0 =C2=A0the set of RRsets on a domain name were first registered.




The IETF Secretariat


--0000000000003bbb4d05cefacec7-- From nobody Fri Oct 22 18:23:47 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0703A07AC; Fri, 22 Oct 2021 18:23:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <163495218558.27188.7737688965826276203@ietfa.amsl.com> Date: Fri, 22 Oct 2021 18:23:05 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-11.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 23 Oct 2021 01:23:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-srp-11.txt Pages : 30 Date : 2021-10-22 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-11.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 24 19:53:55 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 806B63A08C5 for ; Sun, 24 Oct 2021 19:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 lcz-Xiw9KCyN for ; Sun, 24 Oct 2021 19:53:48 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 1241D3A08C0 for ; Sun, 24 Oct 2021 19:53:47 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id b4-20020a9d7544000000b00552ab826e3aso12951944otl.4 for ; Sun, 24 Oct 2021 19:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7853A1F5aCpLX5FzUzwhgTdyBFceBG5Xm5G29377+5o=; b=jP0q54Q2r12ofpiLzZOePQtt4jLIIlVyNCndmnZPv83qj5NlwvM4V0Dcjrjb6g5Dm1 j0HsZ5XEiXExLJYXPmgPSeJz+CShiKGM5mI+THUlzH+Hf9zWEur2KAlMhQKlWzeWAR6G chgxU7cabbHNr6IFwz+d8a8R4uWstk9AiMZCv+dIOFvbMvL2nAtuJux7xMyo/hV5NXSd QGXRAa0W39b4WEVqabQzjqI54Nfqjzy2eksVZXp+TIoShenR6NLjC0WkZItiTxeTOU+H CzDk3JjHmcPo4cy5jB9YN9wP6/dcxHep8MfQanuvi0yKjXq8WN4wkPD82ADWVkhtKHNf NN2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7853A1F5aCpLX5FzUzwhgTdyBFceBG5Xm5G29377+5o=; b=uB+a9VHHV0UXVmOWPhrBe+sY4jENYq3tsrro8ahoA4CT8KszkPqio3m8644Xapwxha 3QhqxPlVNaD5VVL/q/xW2JaG+gj8hHTLZsJWYUhIqxnZZfVhPNkSQZoFZoivq68G5gfY 2YAnbXMgGwDrAX/z+MvxuNISpF7t5723hgXxxEVLO+PBrhQXzcVdFSjNRcUj8yYfcfTL QdvuaqsWGWvemoqOY15LagtzGYI+oztjRTeoGJ0lMb/HmKracYCK3N44se1GUEJWsxIt Ar57z8ZPNyVQJGZtA5DZcJXQBV/gtTXWSBY/b7BVXWODkqQfmWYwhMrykmETH1ob4MgK m8Iw== X-Gm-Message-State: AOAM530wtQUM3oWRDZK+wfGPeplLjCSo7yK9ODDB31Gdu0pMxEi9cApU B5leWDJbcxMFqeXyfn/cf0Iyf02FtzLXSFiq4cEXb5kEgP3haA== X-Google-Smtp-Source: ABdhPJw5OOHE2Zc48/83/lRrR2aE51DKdBS+wjvTL0Tn9towwLUd1GFCiAj5fNswk879Z+jW0N2ksZtIt2iFKaLPubE= X-Received: by 2002:a05:6830:3114:: with SMTP id b20mr11739126ots.163.1635130423667; Sun, 24 Oct 2021 19:53:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Sun, 24 Oct 2021 22:53:07 -0400 Message-ID: To: Esko Dijk Cc: DNSSD Content-Type: multipart/alternative; boundary="0000000000001086bf05cf24788e" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp / review 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: Mon, 25 Oct 2021 02:53:54 -0000 --0000000000001086bf05cf24788e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review! On Thu, Aug 19, 2021 at 7:04 AM Esko Dijk wrote: > *** Abstract > > 802.11 (Wi-Fi) and 802.15.4 (IoT) networks > > -> add 'IEEE' so "IEEE 802.11 (Wi-Fi) and 802.15.4 (IoT) networks" > > As an editorial comment, in general the abstract should not contain more > details than the main text. > > So typically one would see back these terms again in an introduction. > I'm generally against bulking up the abstract, so I'd prefer not to add IEEE twice here. I think the typical IETF document reader knows what the IEEE 802 working groups are... However, if there is consensus to make this change, I will. > > > *** 2.2.1 > > "RFC 6763 describes the details of what each of these types of updates > contains" > > -> not everything contained in these updates is explained in RFC 6763. > Specifically, the "Key RR" is not in that RFC. Another RFC ref can be add= ed > here that defines Key RR as definitive source of information. > I've added a reference to RFC2539=E2=80=94thanks for noticing this! > *** 2.2.3.1 > > "SRP clients are allowed to send updates to the generic domain > "default.service.arpa"" > > -> In section 2.1.* it looks as if only constrained hosts can do this. Ca= n > full-featured hosts also do this? If not we can say "Constrained-Node SRP > clients are ..." If yes, then I would expect section 2.1.1 to mention > this use for the full-featured hosts. > I've added a caveat here. > *** 2.2.5.1 > > duplicated sentence "This key pair MUST be unique to the device." > Oops, thanks! > *** 2.2.5.4 > > Does the statement here imply that this draft formally updates RFC 2782? > > (Question to the WG. Maybe not: since the update only applies in SRP > context not for SRV records in general. But maybe yes: RFC 2782 says > "Unless and until permitted by future standards action, name compression = is > not to be used for this field." which would make it proper to refer to th= e > SRP draft as such future action.) > No, this is just for SRP servers and clients. > *** 2.2.5.5.2 > > "update that deletes the PTR record whose target is the service instance > name." > > -> This looks like a single PTR record. Prior section 2.2.1 mentions that > the service instance name may be referred to by multiple PTR records. So > in case of multiple, it is not required to have multiple instructions to > delete these multiple PTR records? > > (I.e. there's no risk of lingering PTR records that would point to a > service instance that's deleted?) > If you mean for subtypes, see the discussion I had with Abtin recently on the mailing list. For practical reasons, we do not support deleting of individual subtypes=E2=80=94it's all or nothing. > *** 2.3 title > > [Nit] -> may give the impression that all SRP server behavior is specifie= d > in here. > > Somewhere in 2.3 / 2.3.* it could mention that more normative behavior is > specified in other sections too, like Sections 3 and 4. > I've changed this to "Validation and Processing of SRP Updates". > *** 2.3.1 > > Grammar to be fixed: "Each instruction consists some combination" > Yup, thanks! > *** 2.3.1.2 > > [Nit] Bullet: > > "* Service Descriptions Instructions do not modify any other RRs." > > -> best rephrased to > > "* no RR updates other than the ones defined above." > > > > That would fit better in the style of the previous bullet points in the > list. > I've changed 2.3.1.2 and 2.3.1.3 to say "resource records" for consistency rather than "RRs" in the first case and "records" in the second case. > > > *** 2.3.1.3 > > "If a link-scope address or IPv4 autoconfiguration address is provided by > the SRP client, the > > SRP server MUST treat this as if no address records were received; that > is, the Host Description is not valid." > > -> This seems rather strict. If the client provides 1 routable IP address > and 1 link-local address, couldn't the SRP server just ignore the > link-local address? > > This might have some benefits for future/backwards compatibility , in cas= e > of future cases where link-local addresses are to be used for some reason= . > (If only for debug/diagnostic purposes) > > I agree that if the client sends only link-local address(es) then the SRP > server treats it as if no address records were received. > The issue is that the SRP server has no way of knowing what the scope of the link-local address is. So it's by definition an error to send one. > *** 2.3.2 > > [Nit] "must have that Host Description instruction as the target of its > SRV record" > > -> could rephrase to "MUST have the hostname of that Host Description > Instruction as the target of its SRV record" to be more precise. > > Similar comments can be given for the remainder of the section text that > talks about instructions pointing to instructions. (It's more like names > in instructions being equal to names that are used in other instructions) > > (not sure if MUST or must is desired here by the way) > The target of an SRV record is a domain name, so this would be redundant (and more wordy, which is why I'm resisting). > "For example, a DNS update that contains an RRset > > Add to a Service Name and an RRset Add to a Service Instance Name, > > where the Service Name does not reference the Service Instance Name, > > is not a valid SRP update message" > > -> 'RRset Add' refers probably to the "Add To An RRset" semantics of RFC > 2136? If so it would be good to use that exact same naming "Add To An > RRset" including the quotes here. > > With present text I'm wondering if I missed something in the DNS specs > that's called "RRset Add". > Good point, fixed. > > *** 2.3.3 > > "If any existing KEY record corresponding to a > > KEY record in the SRP Update does not match the KEY same record in > > the SRP Update " > > -> grammar issue. 'match the KEY same record' And a bit confusing: can > a KEY record in an update correspond to a stored KEY record but not match > at the same time? > > Perhaps the 'name' concept should be introduced here to clarify. > (Presumably the server will check if an existing Service Instance Name or > existing Hostname is stored and look up the associated KEY for that.) > Fixed, thanks. > "KEY record updates omitted from Service Description update are > > processed as if they had been explicitly present: every Service > > Description that is updated MUST, after the update, have a KEY RR, > > and it must be the same KEY RR that is present in the Host > > Description to which the Service Description refers." > > -> Can we replace here 'Service Description update' by 'Service > Description Instruction' ? > > E.g. > > "KEY record updates omitted from Service Description Instructions are > > processed as if they had been explicitly present: every Service > > Description that is updated through a Service Description Instruction > MUST, after the update, have a KEY RR, > > and it must be the same KEY RR that is present in the Host > > Description Instruction to which the Service Description Instruction > refers." > I've updated the text=E2=80=94see what you think. > "Otherwise, the server validates the SRP Update using SIG(0) on the > > public key in the KEY record of the Host Description update." > > -> what about: > > "Otherwise, the server validates the SRP Update using SIG(0) against the > > public key in the KEY record of the Host Description Instruction." > > > > (Using 'Instruction' and 'validates X against Y' instead of 'validations = X > on Y' ) > OK > *** 3 > > "SRP update servers MUST check" > > ->"SRP servers MUST check" > > > OK > *** 4.1 > > [Nit] " MUST be removed at the same time-it is never valid for a service" > > -> " MUST be removed at the same time -- it is never valid for a service = " > or > > -> " MUST be removed at the same time: it is never valid for a service " > This is a rendering bug=E2=80=94the text uses —. I think we should le= ave it and let the tools team fix the bug. > 3rd paragraph mentions that a SRP is by default configured with a 2 hour > Lease limit and 14-day KEY retaining time limit; and then it says that > constrained devices may negotiate longer leases. This looks incorrect, as > leases beyond configured upper limits won't be given by the server. > > Probably something else is meant here with 'negotiate'? For example if on= e > configures 'default values' for Lease and Key-Lease in the server, the > serve may extend to these default values if the client asks for something > shorter. If the client asks for something longer than the 'default values= ', > the server grants the longer values up to a hard limit that is also > configured in the server. > This text is somewhat divorced from reality, but I've changed it as follows= : Constrained devices with limited battery that wake infrequently are likely to request longer leases; servers that support such devices may need to set higher limits. > *** 5 Sleep Proxy > > The introduction text should clarify whether Sleep Proxy support for an > SRP server is OPTIONAL or MANDATORY. > > Also to make more clear that for clients the use of this function is > optional/OPTIONAL. (The last paragraph says so for constrained hosts, but > nothing for the full-featured hosts.) > > > > In relation to above, the same questions from my review of -04 of > 2020-10-13 still apply: > > - How would a service=E2=80=99s host know that the server is capable to d= o this? > If it doesn't know then it cannot trust the mechanism to work and go to > sleep. > > - Or, is there a way for the SRP server to reject an update with EDNS(0) > OWNER option such that the service=E2=80=99s host knows not to use it aga= in? > > > > [Nit] "Another use of SRP is for devices that sleep to reduce power > consumption" > > -> ideally it should mention somewhere that the device that sleeps is an > SRP client. Otherwise the statement is a bit too generic. E.g. > > "Another use of SRP is for SRP client devices that sleep to reduce power > consumption, while being able to offer registered service(s) without > interruption." > > > > "the device includes an EDNS(0) OWNER Option > [I-D.cheshire-edns0-owner-option]" > > -> the reference here is Informational; how can this be? To implement the > sleep proxy function it is normative to include the option. > > > > "When the DNS server receives a TCP SYN or UDP packet addressed to" > > -> "When the Sleep Proxy receives a TCP SYN or UDP packet addressed to" > > (see also below comment) > > > > "the Sleep Proxy must be on the same link" > > -> the term "Sleep Proxy" is not introduced. In the prior text when it > says "should set up a proxy" the name could be formally introduced e.g. > "should set up a Sleep Proxy" or "should set up a proxy, called the Sleep > Proxy, " > > > > Overall, I miss some details about what the Sleep Proxy does once it > receives a TCP SYN or UDP packet and it has woken up the sleepy device. > Does it then stop the ARP/ND proxying for the sleepy device right away? A= nd > when would it again resume proxying? > > What does the proxy do with the receive TCP SYN or UDP packet, discard or > forward to the woken sleepy device? (After how much waiting time?) > I reread the Sleep Proxy section carefully, and I think it's just incomplete. Since we're in last call, this creates a bit of an issue=E2=80= =94should we spend the time to fix it, or should we specify sleep proxy as a separate document? Given that we actually have a separate document that describes the owner name option, I'm leaning in that direction, and have removed this section from the current document. > *** 6.1 > > "Service Discovery Protocol servers" > > -> is this term defined? Should we say SRP servers here? > Yes, don't know how that happened. Probably very old text. > "a promise made by the registration protocol" > > -> "a promise made by the service registration protocol" > This text is a bit squidgy. Protocols don't make promises. I've changed it to: a promise made by the SRP Server to an SRP client > "replacing all or part of the service registration information with > information provided by an SRP client" > > -> the "SRP client" mentioned here I think should be "DNS client". Becaus= e > the case mentioned looked like an authenticated (non-SRP) DNS client maki= ng > DNS updates to records that were added by an SRP client. > Yes, that text was wrong. > *** 7 "Privacy Considerations" > > This text mentions the requirements for TLS. Perhaps the TLS bits are > better placed in Section 6, and Section 7 if needed can refer back to tha= t. > To me TLS seems one of the key ingredients to secure the protocol so I'd > expect to read something / most-things about this in Section 6. (Maybe > I'm wrong here in case TLS can't provide the authentication - since in so= me > deployments the client may have no trust anchor of the domain installed a > priori, so it can't authenticate the SRP server even when TLS is used.) > At present, TLS doesn't provide authentication=E2=80=94that's correct. We d= on't have a way to establish trust. > *** 9.2 > > "Availability of DNS Service Discovery Service Registration Protocol > > Service for a given domain is advertised using the > > "_dnssd-srp._tcp.." SRV record gives the target host and > > port where DNSSD Service Registration Service is provided for the > > named domain." > > > -> seems like a grammar issue here. Was this meant as a single sentence, > or as 2 sentences separated by a dot before the "SRV record" text? > > E.g. I could interpret as "using the X SRV record which gives the Y" or a= s > "using the X name. The SRV record gives the Y". > > Similar point for 9.3. > That is confusing. The reason for the trailing dot there is that it's a fully-qualified domain name, and such names end in a '.' to indicate the root label. But I think it's probably clearer to leave out the dot here. > --0000000000001086bf05cf24788e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review!

On Thu, Aug 19, 2021 at 7:04 AM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:

*** Abstract

802.11 (Wi-Fi) and 802.15.4 (IoT) networks=

-> add 'IEEE' so "IEEE 802.11 (Wi-Fi= ) and 802.15.4 (IoT) networks"

As an editorial comment, in general the abstract sho= uld not contain more details than the main text.

So typically one would see back these terms again in= an introduction.


=C2=A0I&#= 39;m generally against bulking up the abstract, so I'd prefer not to ad= d IEEE twice here. I think the typical IETF document reader knows what the = IEEE 802 working groups are... However, if there is consensus to make this = change, I will.

=C2=A0

*** 2.2.1

"RFC 6763 describes the details of what each of= these types of updates contains"

-> not everything contained in these updates is e= xplained in RFC 6763. Specifically, the "Key RR" is not in that R= FC. Another RFC ref can be added here that defines Key RR as definitive sou= rce of information.


I'v= e added a reference to RFC2539=E2=80=94thanks for noticing this!
= =C2=A0=C2=A0

*** 2.2.3.1

"SRP clients are allowed to send updates to the= generic domain "default.service.arpa""

-> In section 2.1.* it looks as if only constrain= ed hosts can do this. Can full-featured hosts also do this? If not we can s= ay "Constrained-Node SRP clients are ..."=C2=A0=C2=A0 If yes, the= n I would expect section 2.1.1 to mention this use for the full-featured hosts.


I'= ;ve added a caveat here.
=C2=A0=C2=A0

*** 2.2.5.1

duplicated sentence "This key pair MUST be uniq= ue to the device."


Oop= s, thanks!
=C2=A0=C2=A0

*** 2.2.5.4

Does the statement here imply that this draft formal= ly updates RFC 2782?

(Question to the WG. Maybe not: since the update onl= y applies in SRP context not for SRV records in general. But maybe yes: RFC= 2782 says "Unless and until permitted by future standards action, nam= e compression is not to be used for this field." which would make it proper to refer to the SRP draft as such = future action.)


No, this is= just for SRP servers and clients.
=C2=A0
=

*** 2.2.5.5.2

"update that deletes the PTR record whose targe= t is the service instance name."

-> This looks like a single PTR record. Prior sec= tion 2.2.1 mentions that the service instance name may be referred to by mu= ltiple PTR records.=C2=A0 So in case of multiple, it is not required to hav= e multiple instructions to delete these multiple PTR records?

(I.e. there's no risk of lingering PTR records t= hat would point to a service instance that's deleted?)

<= /blockquote>

If you mean for subtypes, see the discussio= n I had with Abtin recently on the mailing list. For practical reasons, we = do not support deleting of individual subtypes=E2=80=94it's all or noth= ing.
=C2=A0=C2=A0

*** 2.3 title

[Nit] -> may give the impression that all SRP ser= ver behavior is specified in here.

Somewhere in 2.3 / 2.3.* it could mention that more = normative behavior is specified in other sections too, like Sections 3 and = 4.


I've changed this to= "Validation and Processing of SRP Updates".
=C2=A0=C2= =A0

*** 2.3.1

Grammar to be fixed: "Each instruction consists= some combination"


Yup= , thanks!
=C2=A0=C2=A0

*** 2.3.1.2

[Nit] Bullet:

=C2=A0"*=C2=A0 Service Descriptions Instruction= s do not modify any other RRs."

-> best rephrased to

=C2=A0"*=C2=A0 no RR updates other than the one= s defined above."

=C2=A0

That would fit better in the style of the previous b= ullet points in the list.


I= 've changed 2.3.1.2 and 2.3.1.3 to say "resource records" for= consistency rather than "RRs" in the first case and "record= s" in the second case.

=C2=A0

*** 2.3.1.3

"If a link-scope address or IPv4 autoconfigurat= ion address is provided by the SRP client, the

=C2=A0 SRP server MUST treat this as if no address r= ecords were received; that is, the Host Description is not valid."<= /u>

-> This seems rather strict. If the client provid= es 1 routable IP address and 1 link-local address, couldn't the SRP ser= ver just ignore the link-local address?

This might have some benefits for future/backwards c= ompatibility , in case of future cases where link-local addresses are to be= used for some reason. (If only for debug/diagnostic purposes)

I agree that if the client sends only link-local add= ress(es) then the SRP server treats it as if no address records were receiv= ed.


The issue is that the S= RP server has no way of knowing what the scope of the link-local address is= . So it's by definition an error to send one.
=C2=A0=C2=A0

<= u>

*** 2.3.2

[Nit] "must have that Host Description instruct= ion as the target of its SRV record"

-> could rephrase to "MUST have the hostname= of that Host Description Instruction as the target of its SRV record"= =C2=A0 to be more precise.

Similar comments can be given for the remainder of t= he section text that talks about instructions pointing to instructions.=C2= =A0 (It's more like names in instructions being equal to names that are= used in other instructions)

(not sure if MUST or must is desired here by the way= )


The target of an SRV reco= rd is a domain name, so this would be redundant (and more wordy, which is w= hy I'm resisting).
=C2=A0=C2=A0

"For example, a DNS update that contains an RRs= et

=C2=A0=C2=A0 Add to a Service Name and an RRset Add = to a Service Instance Name,

=C2=A0=C2=A0 where the Service Name does not referen= ce the Service Instance Name,

=C2=A0=C2=A0 is not a valid SRP update message"=

-> 'RRset Add' refers probably to the &qu= ot;Add To An RRset" semantics of RFC 2136? If so it would be good to u= se that exact same naming "Add To An RRset" including the quotes = here.

With present text I'm wondering if I missed some= thing in the DNS specs that's called "RRset Add".


Good point, fixed.

*** 2.3.3

"If any existing KEY record corresponding to a<= u>

=C2=A0=C2=A0 KEY record in the SRP Update does not m= atch the KEY same record in

=C2=A0=C2=A0 the SRP Update "

-> grammar issue. 'match the KEY same record&= #39;=C2=A0=C2=A0=C2=A0 And a bit confusing: can a KEY record in an update c= orrespond to a stored KEY record but not match at the same time?<= /u>

=C2=A0 Perhaps the 'name' concept should be = introduced here to clarify. (Presumably the server will check if an existin= g Service Instance Name or existing Hostname is stored and look up the asso= ciated KEY for that.)


Fixed= , thanks.
=C2=A0

"KEY record updates omitted from Service Descri= ption update are

=C2=A0=C2=A0 processed as if they had been explicitl= y present: every Service

=C2=A0=C2=A0 Description that is updated MUST, after= the update, have a KEY RR,

=C2=A0=C2=A0 and it must be the same KEY RR that is = present in the Host

=C2=A0=C2=A0 Description to which the Service Descri= ption refers."

-> Can we replace here 'Service Description u= pdate' by 'Service Description Instruction' ?

E.g.

"KEY record updates omitted from Service Descri= ption Instructions are

=C2=A0=C2=A0 processed as if they had been explicitl= y present: every Service

=C2=A0=C2=A0 Description that is updated through a S= ervice Description Instruction MUST, after the update, have a KEY RR,

=C2=A0=C2=A0 and it must be the same KEY RR that is = present in the Host

=C2=A0=C2=A0 Description Instruction to which the Se= rvice Description Instruction refers."


I've updated the text=E2=80=94see what you think.
=C2=A0=C2=A0

"Otherwise, the server validates the SRP Update= using SIG(0) on the

=C2=A0=C2=A0 public key in the KEY record of the Hos= t Description update."

-> what about:

"Otherwise, the server validates the SRP Update= using SIG(0) against the

=C2=A0=C2=A0 public key in the KEY record of the Hos= t Description Instruction."

=C2=A0

(Using 'Instruction' and 'validates X ag= ainst Y' instead of 'validations X on Y' )


OK
=C2=A0

*** 3

"SRP update servers MUST check"<= /u>

->"SRP servers MUST check"

=C2=A0

OK
=C2=A0

*** 4.1

[Nit] " MUST be removed at the same time-it is = never valid for a service"

-> " MUST be removed at the same time -- it = is never valid for a service " or

-> " MUST be removed at the same time: it is= never valid for a service "


This is a rendering bug=E2=80=94the text uses &mdash;. I think w= e should leave it and let the tools team fix the bug.
=C2=A0=C2= =A0

3rd paragraph mentions that a SRP is by default conf= igured with a 2 hour Lease limit and 14-day KEY retaining time limit; and t= hen it says that constrained devices may negotiate longer leases. This look= s incorrect, as leases beyond configured upper limits won't be given by the server.

Probably something else is meant here with 'nego= tiate'? For example if one configures 'default values' for Leas= e and Key-Lease in the server, the serve may extend to these default values= if the client asks for something shorter. If the client asks for something longer than the 'default values', the se= rver grants the longer values up to a hard limit that is also configured in= the server.


This text is s= omewhat divorced from reality, but I've changed it as follows:

Constrained devices with limited=C2=A0battery that wake infrequ= ently are likely to request longer leases; servers that support such device= s may need to set higher limits.
=C2=A0=C2=A0

*** 5 Sleep Proxy

The introduction text should clarify whether Sleep P= roxy support for an SRP server is OPTIONAL or MANDATORY.

Also to make more clear that for clients the use of = this function is optional/OPTIONAL. (The last paragraph says so for constra= ined hosts, but nothing for the full-featured hosts.)

=C2=A0

In relation to above, the same questions from my rev= iew of -04 of 2020-10-13 still apply:

- How would a service=E2=80=99s host know that the s= erver is capable to do this? If it doesn't know then it cannot trust th= e mechanism to work and go to sleep.

- Or, is there a way for the SRP server to reject an= update with EDNS(0) OWNER option such that the service=E2=80=99s host know= s not to use it again?

=C2=A0

[Nit] "Another use of SRP is for devices that s= leep to reduce power consumption"

-> ideally it should mention somewhere that the d= evice that sleeps is an SRP client. Otherwise the statement is a bit too ge= neric. E.g.

"Another use of SRP is for SRP client devices t= hat sleep to reduce power consumption, while being able to offer registered= service(s) without interruption."

=C2=A0

"the device includes an EDNS(0) OWNER Option [I= -D.cheshire-edns0-owner-option]"

-> the reference here is Informational; how can t= his be? To implement the sleep proxy function it is normative to include th= e option.

=C2=A0

"When the DNS server receives a TCP SYN or UDP = packet addressed to"

-> "When the Sleep Proxy receives a TCP SYN = or UDP packet addressed to"

(see also below comment)

=C2=A0

"the Sleep Proxy must be on the same link"=

-> the term "Sleep Proxy" is not introd= uced. In the prior text when it says "should set up a proxy" the = name could be formally introduced e.g. "should set up a Sleep Proxy&qu= ot; or "should set up a proxy, called the Sleep Proxy, "

=C2=A0

Overall, I miss some details about what the Sleep Pr= oxy does once it receives a TCP SYN or UDP packet and it has woken up the s= leepy device. Does it then stop the ARP/ND proxying for the sleepy device r= ight away? And when would it again resume proxying?

What does the proxy do with the receive TCP SYN or U= DP packet, discard or forward to the woken sleepy device? (After how much w= aiting time?)


I reread the = Sleep Proxy section carefully, and I think it's just incomplete. Since = we're in last call, this creates a bit of an issue=E2=80=94should we sp= end the time to fix it, or should we specify sleep proxy as a separate docu= ment? Given that we actually have a separate document that describes the ow= ner name option, I'm leaning in that direction, and have removed this s= ection from the current document.
=C2=A0=C2=A0

*** 6.1

"Service Discovery Protocol servers"

-> is this term defined? Should we say SRP server= s here?


Yes, don't know= how that happened. Probably very old text.
=C2=A0=C2=A0

=

"a promise made by the registration protocol&qu= ot;

-> "a promise made by the service registrati= on protocol"


This text= is a bit squidgy. Protocols don't make promises. I've changed it t= o: a promise made by the SRP Server to an SRP client
=C2=A0
=

"replacing all or part of the service registrat= ion information with information provided by an SRP client"<= /u>

-> the "SRP client" mentioned here I th= ink should be "DNS client". Because the case mentioned looked lik= e an authenticated (non-SRP) DNS client making DNS updates to records that = were added by an SRP client.


Yes, that text was wrong.
=C2=A0=C2=A0
=

*** 7 "Privacy Considerations"

This text mentions the requirements for TLS. Perhaps= the TLS bits are better placed in Section 6, and Section 7 if needed can r= efer back to that. To me TLS seems one of the key ingredients to secure the= protocol so I'd expect to read something / most-things about this in Section 6.=C2=A0=C2=A0 (Maybe I'm wrong he= re in case TLS can't provide the authentication - since in some deploym= ents the client may have no trust anchor of the domain installed a priori, = so it can't authenticate the SRP server even when TLS is used.)


At present, = TLS doesn't provide authentication=E2=80=94that's correct. We don&#= 39;t have a way to establish trust.
=C2=A0=C2=A0

*** 9.2

"Availability of DNS Service Discovery Service = Registration Protocol

=C2=A0=C2=A0 Service for a given domain is advertise= d using the

=C2=A0=C2=A0 "_dnssd-srp._tcp.<domain>.&q= uot;=C2=A0 SRV record gives the target host and

=C2=A0=C2=A0 port where DNSSD Service Registration S= ervice is provided for the

=C2=A0=C2=A0 named domain."=C2=A0

=C2=A0=C2=A0

-> seems like a grammar issue here. Was this mean= t as a single sentence, or as 2 sentences separated by a dot before the &qu= ot;SRV record" text?

E.g. I could interpret as "using the X SRV reco= rd which gives the Y" or as "using the X name. The SRV record giv= es the Y".

Similar point for 9.3.

<= div>
That is confusing. The reason for the trailing dot there= is that it's a fully-qualified domain name, and such names end in a &#= 39;.' to indicate the root label. But I think it's probably clearer= to leave out the dot here.
--0000000000001086bf05cf24788e-- From nobody Sun Oct 24 19:58:34 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4C3A094D; Sun, 24 Oct 2021 19:58:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <163513071185.15332.4534632947717624629@ietfa.amsl.com> Date: Sun, 24 Oct 2021 19:58:31 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-12.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 25 Oct 2021 02:58:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-srp-12.txt Pages : 30 Date : 2021-10-24 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-12.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 24 20:18:49 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 36BD63A09FE for ; Sun, 24 Oct 2021 20:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 ZeJtFWl7XNk5 for ; Sun, 24 Oct 2021 20:18:43 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 B7FB73A09FC for ; Sun, 24 Oct 2021 20:18:43 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id y15-20020a9d460f000000b0055337e17a55so12974554ote.10 for ; Sun, 24 Oct 2021 20:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=1j0RN2WLorR+qSSQvnOtQxNxFcIkRLECyGlaIckzz00=; b=BMmqlk4pbDbw1D31TKbaNF2tTdEl3sdoA97pKNWuIlNnsWkKNH+23YxZToH490rXXZ 0wl1llbb3yyiK8hyMJgIxTY3kUYDZuCaEkb6HCXe7b82pLuK4Y+Pg6JCZ9hxOgGeFvJ4 M5oSEju6RiekpGRqIJe9nEMhR3K6ZvKcMDseUCegKH+sa6+NCYv37sqSXvacNp3kyL68 qatPKcHdji5unZkTi5PUnIwGSkopP7VPmCc/R8uN36LAu7cr+In/NBa+iwqRsg3j/7Bz L60yfrjNx8IREduo85lcN0YBcgvkVtkPYbNshViumtjJ2QOZKKxnG7uD2NW5ZT/vcc3K wEkw== 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; bh=1j0RN2WLorR+qSSQvnOtQxNxFcIkRLECyGlaIckzz00=; b=6KqHt7IeW7UoJLPumRP51li3sQdlUXyzp8NG1Qbym4h6b2Tg0aaCOvZTQ3E4xzTye8 bOJ3+VR+SrX8/CgQ2r4FV6It3sXifKDO+kjypmviQh0aN/zfszsgjH/01+F2FoYfP6BU iVmuLgydYMGZbIbqGqs9XFuhCwHM9b1Q+NdlagY0eNpaQHs62u/s6eVHxtz+K5NhDNsk ZOuWaEE7QPPKgFyiz1rCEnsJ/GzLngS1dtCNtYW+8Vig485lhUNB5pKjUzPyjl1QPo4I v0ytQSLUSlxmwdRLgdUANprMEfuvULLA285NKdtsU3VyAXcc0NfqOQjaPwQEZaG6UIgk z7BQ== X-Gm-Message-State: AOAM532nmbzHnRp1Us9pe1hEVY/077M23Tk8kjXaSwTcZ0Gj80lHKB9t NJtCqdZ2D6ZdgRT3BD/zSVSzmJ331g+UNUYz9ojvEG8qiV6CA//9 X-Google-Smtp-Source: ABdhPJwLmMXoQWZSVEadJ+PwUh/qN/GrndVwciB/e8aM2DX3ngPCtWeTZU+vshgdVjZsq60umX2+UDeJi8QE7jgpwlA= X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr11676928otb.309.1635131921549; Sun, 24 Oct 2021 20:18:41 -0700 (PDT) MIME-Version: 1.0 From: Ted Lemon Date: Sun, 24 Oct 2021 23:18:05 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="000000000000585eac05cf24d1a9" Archived-At: Subject: [dnssd] Last call update to draft-ietf-dnssd-srp 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: Mon, 25 Oct 2021 03:18:48 -0000 --000000000000585eac05cf24d1a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've posted a draft that I believe addresses all last call comments that came up. Most of the comments were relatively minor, but there are a few that are significant. First, in implementing support for dnssd service subtypes for SRP replication, it became clear that it was a problem to support updates to subtypes where the update adds a subtype but doesn't mention other subtypes added by a previous update, or removes subtypes. We could have done it, but it added significant complexity. So this impacted the SRP document in the sense that we needed to explicitly describe the behavior. The behavior that SRP requires now is that if any subtype PTR records exist pointing to a service instance that's being updated, and those subtypes are not present in the update, they are implicitly removed. The second big change is that Esko pointed out that the text describing the sleep proxy isn't really very consistent with the rest of the document, and indeed is somewhat incomplete. There isn't an easy way to handle this=E2=80=94either we have to stop and fix it, which might delay publicati= on for a long time, or we have to remove it. Because there's another document that describes the edns0 owner option, on which the sleep proxy depends, and that document is nowhere near publication (it's been expired since 2018), I think the right answer is to work on that document, and update it to add sleep proxy support to SRP, rather than keeping sleep proxy support in the base SRP document. Obviously the working group should consider whether or not we collectively agree with this approach. I unfortunately forgot about Esko's rather detailed editorial review when I produced the -11 document, so I had to do a -12 a today to address his editorial comments. These substantially improve the readability of the document=E2=80=94thanks for doing that, Esko! I am on vacation this coming week, so I won't be here to discuss this, but feel free to comment immediately, and I'll review and respond when I get back. Thanks! BTW, you can see a diff from -10 to -12 here: https://www.ietf.org/rfcdiff?url1=3Dhttp://www.ietf.org/archive/id/draft-ie= tf-dnssd-srp-10.txt&url2=3Dhttp://www.ietf.org/archive/id/draft-ietf-dnssd-= srp-12.txt --000000000000585eac05cf24d1a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've posted a draft that I believe addresses all last = call comments that came up. Most of the comments were relatively minor, but= there are a few that are significant.

First, in impleme= nting support for dnssd service subtypes for SRP replication, it became cle= ar that it was a problem to support updates to subtypes where the update ad= ds a subtype but doesn't mention other subtypes added by a previous upd= ate, or removes subtypes. We could have done it, but it added significant c= omplexity. So this impacted the SRP document in the sense that we needed to= explicitly describe the behavior. The behavior that SRP requires now is th= at if any subtype PTR records exist pointing to a service instance that'= ;s being updated, and those subtypes are not present in the update, they ar= e implicitly removed.

The second big change is tha= t Esko pointed out that the text describing the sleep proxy isn't reall= y very consistent with the rest of the document, and indeed is somewhat inc= omplete. There isn't an easy way to handle this=E2=80=94either we have = to stop and fix it, which might delay publication for a long time, or we ha= ve to remove it.

Because there's another docum= ent that describes the edns0 owner option, on which the sleep proxy depends= , and that document is nowhere near publication (it's been expired sinc= e 2018), I think the right answer is to work on that document, and update i= t to add sleep proxy support to SRP, rather than keeping sleep proxy suppor= t in the base SRP document. Obviously the working group should consider whe= ther or not we collectively agree with this approach.

<= div>I unfortunately forgot about Esko's rather detailed editorial revie= w when I produced the -11 document, so I had to do a -12 a today to address= his editorial comments. These substantially improve the readability of the= document=E2=80=94thanks for doing that, Esko!

I a= m on vacation this coming week, so I won't be here to discuss this, but= feel free to comment immediately, and I'll review and respond when I g= et back.

Thanks!


--000000000000585eac05cf24d1a9-- From nobody Sun Oct 24 20:21:42 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 A5F5C3A0418 for ; Sun, 24 Oct 2021 20:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 U0r_MBRXRxkT for ; Sun, 24 Oct 2021 20:21:40 -0700 (PDT) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 41A833A0063 for ; Sun, 24 Oct 2021 20:21:40 -0700 (PDT) Received: by mail-oo1-xc31.google.com with SMTP id z11-20020a4a870b000000b002b883011c77so898457ooh.5 for ; Sun, 24 Oct 2021 20:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Xx8QLcPczOBydtEonOHKV8b25AlOg4Mfeu2M2cJ4wYk=; b=QZTIDpLbTdjAMBfOgpx36VcmvnKaeBBaY308irDQjJgK5lWbuUSUxLnJbRgItyL8Ul /XmT1sHjOcgKt35inP/Ajf92GSqZ3/zsCbIeeFepv63ijzi+yTpXU4Z9Dka03Hs96r47 3uz8Kbt7eES7XrxhIJKkSyYkL4eL2T7QFD3IAJ1r7u11KFcF6oig/PHsGE3WBiyM003Y 3tG4Lx2Ngk65IEKCtlnQVrmUwpWeAoudnsKD8lYtVN682xl0L70SaP3cvrLSLT1Ms9xy TelxqbYjqVhEIW2/imDfx5AcJZW+nQKlBS7QoYx6UGAhlGcp38z8oJFkufSpNBuMBUq9 Dd8w== 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; bh=Xx8QLcPczOBydtEonOHKV8b25AlOg4Mfeu2M2cJ4wYk=; b=ZkcOvitUdCYELr9kZRitcxaSaq/hs/wzK3pr7qCgEG8B9bD7eFNjzQqeZmKSnXQfVw 9/qaBrR1/rjJRjm6AEE6kMt28L0aqzPDzYiXabEWFUe3wtfuuwFivUxZVq7mNEkteyzS Po5HV6/fhwNGMUhyGxg6YVjd4uc6Ng4gAvqdjA4pVNbQh4pHZEx/nsh3Kfova31wGlvt g9kYOl6fRbpZKAMo+UUmo/toJOf9ITGP7wHyT8xBnvxls2qgKE8qlWL9FwvxlOTvot6D 3arykI9HtbIhPiKgKoUaL7tqqH1tAqNQB0cI9hRKEnSSAWnyqaq1Aaek/HiQA6y1fJhR 6SgQ== X-Gm-Message-State: AOAM533uVI7B3h9tQY4HaWuCmD/03cJLTIQEtO4JyFHq1RrdDjQoYiO8 dUL0cHMrkiWZkEqTQQo7XoznARGLrO9xYh6KcHDboMN915Sfxg== X-Google-Smtp-Source: ABdhPJxgKYFCecAp/0gAthRQnIoC84NeXeph9SnzwGjlsZkiHMaxgW5sL51i+18uyFblWGNK438euc2lo4kzsC28oDY= X-Received: by 2002:a4a:e9f0:: with SMTP id w16mr10513739ooc.3.1635132096467; Sun, 24 Oct 2021 20:21:36 -0700 (PDT) MIME-Version: 1.0 From: Ted Lemon Date: Sun, 24 Oct 2021 23:21:00 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="000000000000c5630a05cf24db1f" Archived-At: Subject: [dnssd] Status of draft-lemon-srp-replication 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: Mon, 25 Oct 2021 03:21:42 -0000 --000000000000c5630a05cf24db1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have a -01 with updates based on the discussion with Abtin, but it's still in lawyer wait. I will check in tomorrow to see if our legal team has a chance to review it, and if it's approved I'll upload the new version tomorrow. I'd like this to be considered for adoption at the upcoming meeting=E2=80=94we have two implementations (dunno if they interoperate yet= though) so it seems like it has enough momentum to justify the effort. --000000000000c5630a05cf24db1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a -01 with updates based on the discussion with Abt= in, but it's still in lawyer wait. I will check in tomorrow to see if o= ur legal team has a chance to review it, and if it's approved I'll = upload the new version tomorrow. I'd like this to be considered for ado= ption at the upcoming meeting=E2=80=94we have two implementations (dunno if= they interoperate yet though) so it seems like it has enough momentum to j= ustify the effort.
--000000000000c5630a05cf24db1f-- From nobody Mon Oct 25 10:17:59 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 105343A0BFE for ; Mon, 25 Oct 2021 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 GvT7P7LZOthZ for ; Mon, 25 Oct 2021 10:17:52 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 BDA173A0BEF for ; Mon, 25 Oct 2021 10:17:52 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id ba39so5530212vkb.11 for ; Mon, 25 Oct 2021 10:17:52 -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 :cc; bh=NDSr2jHy+TLLWI40GHT+Mz54wfAc8rE8gWf5kE9osiM=; b=s8ULku80fQakAGC5ZWV2rI+dHJfxlxYUCNCU75E75JrRgvOKWGSsbjGkYK6rO5nOKQ B3T0YkCK4PUhg72YUs4RBzYGgsMneTXXfZWSq4YdI85e54ITaqFerIeyj4ktngDjdzzu EMXBWdF1/Yz5miloQoe2/FNQ4ra2R0mVXZADRrIQE6oewECLiasnul+lAZpRaeOUMe6b j2GDOimqIWK4bz/Wn41aQkOWLaFqevHiwhy3ppPmjMdVPqqkb6mgeoQJnZI9FsUw9Lh0 Sycf8tqxn3BGCOSVAhpaphrB+L6zhgaIL/AZpLPrYg8uS2va+ZOZdlVcxBokL237/ECm 8ABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDSr2jHy+TLLWI40GHT+Mz54wfAc8rE8gWf5kE9osiM=; b=YejtcXr3jHmyefo/aaEeqJ44INe/JO+LSNzFkqr0yqhQIUjeDO1NBzNbvtsUFcfK30 dSqpMhkrVzeA8ameaXE0gi4MTqPwEZRlkELqCg6BrUGUo5haZQZqvtXGdmaTD2R6/mpW ptZfkbHcSDSdX3+fyfbOmLIoZmwTTjdt6fAAeB+OjdXP7NY+wXGWarutGpt4usj8jRDx 2l6K1vsX//wupzx16+nI+Pd+XfbqaU6j7YwAxsCXEHSWkjrVCh5bU+W8W2mUqA6WbTjW tGS7rd2Aq0CInfYg6klfd4UfINiTD+vRnabGw3S3geMHq/4T6uBX/D07fdICAA3x+8Nl 4o7g== X-Gm-Message-State: AOAM530hM/nXGs8GUsOqfIFwBOmkmYwPoEo3T1eFZL9HLVWILjn5CrqB xyj4C3iNV+4qr6JFI76tlcvcwChEB36PylHtKlvC1iukanY= X-Google-Smtp-Source: ABdhPJwoZhhDpL5MI5Q+HsN9M1KMLnKfhzWDbajes/5C9GN0brCqWwBwyvH2kdsVT6dDtS26FFlXylCYglElT5oeWDA= X-Received: by 2002:a05:6122:8c8:: with SMTP id 8mr15131221vkg.5.1635182268232; Mon, 25 Oct 2021 10:17:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abtin Keshavarzian Date: Mon, 25 Oct 2021 10:17:37 -0700 Message-ID: To: Ted Lemon Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000003ebfa705cf308ad9" Archived-At: Subject: Re: [dnssd] Last call update to draft-ietf-dnssd-srp 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: Mon, 25 Oct 2021 17:17:57 -0000 --0000000000003ebfa705cf308ad9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ted. I read through all the new changes/diffs and the latest draft. They all LGTM. Abtin. On Sun, Oct 24, 2021 at 8:18 PM Ted Lemon wrote: > I've posted a draft that I believe addresses all last call comments that > came up. Most of the comments were relatively minor, but there are a few > that are significant. > > First, in implementing support for dnssd service subtypes for SRP > replication, it became clear that it was a problem to support updates to > subtypes where the update adds a subtype but doesn't mention other subtyp= es > added by a previous update, or removes subtypes. We could have done it, b= ut > it added significant complexity. So this impacted the SRP document in the > sense that we needed to explicitly describe the behavior. The behavior th= at > SRP requires now is that if any subtype PTR records exist pointing to a > service instance that's being updated, and those subtypes are not present > in the update, they are implicitly removed. > > The second big change is that Esko pointed out that the text describing > the sleep proxy isn't really very consistent with the rest of the documen= t, > and indeed is somewhat incomplete. There isn't an easy way to handle > this=E2=80=94either we have to stop and fix it, which might delay publica= tion for a > long time, or we have to remove it. > > Because there's another document that describes the edns0 owner option, o= n > which the sleep proxy depends, and that document is nowhere near > publication (it's been expired since 2018), I think the right answer is t= o > work on that document, and update it to add sleep proxy support to SRP, > rather than keeping sleep proxy support in the base SRP document. Obvious= ly > the working group should consider whether or not we collectively agree wi= th > this approach. > > I unfortunately forgot about Esko's rather detailed editorial review when > I produced the -11 document, so I had to do a -12 a today to address his > editorial comments. These substantially improve the readability of the > document=E2=80=94thanks for doing that, Esko! > > I am on vacation this coming week, so I won't be here to discuss this, bu= t > feel free to comment immediately, and I'll review and respond when I get > back. > > Thanks! > > BTW, you can see a diff from -10 to -12 here: > https://www.ietf.org/rfcdiff?url1=3Dhttp://www.ietf.org/archive/id/draft-= ietf-dnssd-srp-10.txt&url2=3Dhttp://www.ietf.org/archive/id/draft-ietf-dnss= d-srp-12.txt > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000003ebfa705cf308ad9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ted.
I read through all the new changes/diffs a= nd the latest draft. They all LGTM.
Abtin.

On Sun, Oct 24, 2= 021 at 8:18 PM Ted Lemon <mellon@fug= ue.com> wrote:
I've posted a draft that I believe addresses all= last call comments that came up. Most of the comments were relatively mino= r, but there are a few that are significant.

First, in i= mplementing support for dnssd service subtypes for SRP replication, it beca= me clear that it was a problem to support updates to subtypes where the upd= ate adds a subtype but doesn't mention other subtypes added by a previo= us update, or removes subtypes. We could have done it, but it added signifi= cant complexity. So this impacted the SRP document in the sense that we nee= ded to explicitly describe the behavior. The behavior that SRP requires now= is that if any subtype PTR records exist pointing to a service instance th= at's being updated, and those subtypes are not present in the update, t= hey are implicitly removed.

The second big change = is that Esko pointed out that the text describing the sleep proxy isn't= really very consistent with the rest of the document, and indeed is somewh= at incomplete. There isn't an easy way to handle this=E2=80=94either we= have to stop and fix it, which might delay publication for a long time, or= we have to remove it.

Because there's another= document that describes the edns0 owner option, on which the sleep proxy d= epends, and that document is nowhere near publication (it's been expire= d since 2018), I think the right answer is to work on that document, and up= date it to add sleep proxy support to SRP, rather than keeping sleep proxy = support in the base SRP document. Obviously the working group should consid= er whether or not we collectively agree with this approach.

<= /div>
I unfortunately forgot about Esko's rather detailed editorial= review when I produced the -11 document, so I had to do a -12 a today to a= ddress his editorial comments. These substantially improve the readability = of the document=E2=80=94thanks for doing that, Esko!

I am on vacation this coming week, so I won't be here to discuss thi= s, but feel free to comment immediately, and I'll review and respond wh= en I get back.

Thanks!


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000003ebfa705cf308ad9-- From nobody Mon Oct 25 10:23:10 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1143A0D32; Mon, 25 Oct 2021 10:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <163518258873.28511.11453341483750006463@ietfa.amsl.com> Date: Mon, 25 Oct 2021 10:23:08 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-update-lease-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 25 Oct 2021 17:23:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : An EDNS0 option to negotiate Leases on DNS Updates Authors : Stuart Cheshire Ted Lemon Filename : draft-ietf-dnssd-update-lease-00.txt Pages : 7 Date : 2021-10-22 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 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-00.html Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 13:07:04 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 947EE3A08DC for ; Mon, 25 Oct 2021 13:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 bpHH9A7N71iu for ; Mon, 25 Oct 2021 13:06:57 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 B003A3A0A66 for ; Mon, 25 Oct 2021 13:06:19 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id t4so17186064oie.5 for ; Mon, 25 Oct 2021 13:06:19 -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 :cc; bh=3j+eYlLZXXPRWTSxC0qScbT+PD2qnicqIIBTQyWUVhI=; b=JiueD7+ZPKJkJtunZRaovQhgO4bNrxHJPFPUgiLAuiZr1QmY+HrYDKqrIOzIZVgIG1 kNR2XWf+y7cufVwgXhPTG046TFQih4iBlH5IlhQwz1r74KlkjobYWZCOFD6KeOftfnY7 Q+ppXE7sIQnnUWJ13JW23KIL03cVfkths5kApIEuA7TcBuN9AVq+jCClmTnGAsLYAIE4 nMhr2yrLUq6zQAhXvLGZFk/mf+IDTKlYZ7ULBUuglJcS24qbieeRJwUPyvdhb+tfnVYX mN9Vz4wlcxsApHPoYVf4kxBQRNkQUeMJx7Oq29yDySdGqnUWj2726YPqgF3a+i4xI4cM FBcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3j+eYlLZXXPRWTSxC0qScbT+PD2qnicqIIBTQyWUVhI=; b=Ysrcy0mEts5rjRPHXKPUCyM9Fo9UMPshs6BxpRK5REKAMCKWtyiqfRrZegELCTgFbz zncW7/RUlHd6mtmtvmdj9bt2zYbYOyad/giB+8hgfonHkEZMGaWYRa0IxYj4FSYnph4K 29yW2o47hV2CX3fv7Pcx7H4v3vlRXQxLyAZg9UrMA+AhJmaL613zthNJQesMfk0HFD2r sGWmOahAMACPCS4FykjJWkJgdjtVq3z1zCJ/kkCqpI7Bj+znQid2SiWXEkviWoPCVkSz 9ahhi3leiz74zb7xiXWpoeJdyc7s3tjWFymM3ny6xHYUrNl9p7dJV3h159W3zN+Tv2Er B9lQ== X-Gm-Message-State: AOAM533cOo9neCtlc2nvEhcQqgd1OqNTi53pWXHj3aH4lvrlkpAJvvEW 4WdmnW/PUQMbdyKRUVLAHum1JX/3XuimJExGHdSUWkmCzIE= X-Google-Smtp-Source: ABdhPJxJkEBy4LnArAhsd+0rIgnavSxrxQUGtcwMNPkRpv0eIvkUkkM/QXI8jWM0MHr303PANvWEYKa/zDnYheWVi+A= X-Received: by 2002:a05:6808:14c5:: with SMTP id f5mr25498137oiw.168.1635192377377; Mon, 25 Oct 2021 13:06:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Mon, 25 Oct 2021 13:06:06 -0700 Message-ID: To: Ted Lemon Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000cb431a05cf32e40b" Archived-At: Subject: Re: [dnssd] Last call update to draft-ietf-dnssd-srp 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: Mon, 25 Oct 2021 20:07:03 -0000 --000000000000cb431a05cf32e40b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the update, Ted. I have reviewed the diff between -12 and -10 and the changes all look good to me. Enjoy your vacation! -- Jonathan Hui On Sun, Oct 24, 2021 at 8:18 PM Ted Lemon wrote: > I've posted a draft that I believe addresses all last call comments that > came up. Most of the comments were relatively minor, but there are a few > that are significant. > > First, in implementing support for dnssd service subtypes for SRP > replication, it became clear that it was a problem to support updates to > subtypes where the update adds a subtype but doesn't mention other subtyp= es > added by a previous update, or removes subtypes. We could have done it, b= ut > it added significant complexity. So this impacted the SRP document in the > sense that we needed to explicitly describe the behavior. The behavior th= at > SRP requires now is that if any subtype PTR records exist pointing to a > service instance that's being updated, and those subtypes are not present > in the update, they are implicitly removed. > > The second big change is that Esko pointed out that the text describing > the sleep proxy isn't really very consistent with the rest of the documen= t, > and indeed is somewhat incomplete. There isn't an easy way to handle > this=E2=80=94either we have to stop and fix it, which might delay publica= tion for a > long time, or we have to remove it. > > Because there's another document that describes the edns0 owner option, o= n > which the sleep proxy depends, and that document is nowhere near > publication (it's been expired since 2018), I think the right answer is t= o > work on that document, and update it to add sleep proxy support to SRP, > rather than keeping sleep proxy support in the base SRP document. Obvious= ly > the working group should consider whether or not we collectively agree wi= th > this approach. > > I unfortunately forgot about Esko's rather detailed editorial review when > I produced the -11 document, so I had to do a -12 a today to address his > editorial comments. These substantially improve the readability of the > document=E2=80=94thanks for doing that, Esko! > > I am on vacation this coming week, so I won't be here to discuss this, bu= t > feel free to comment immediately, and I'll review and respond when I get > back. > > Thanks! > > BTW, you can see a diff from -10 to -12 here: > https://www.ietf.org/rfcdiff?url1=3Dhttp://www.ietf.org/archive/id/draft-= ietf-dnssd-srp-10.txt&url2=3Dhttp://www.ietf.org/archive/id/draft-ietf-dnss= d-srp-12.txt > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000cb431a05cf32e40b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the update, Ted. I have reviewed the diff = between -12 and -10 and the changes all look good to me.

Enjoy your vacation!

--
Jonathan Hui


<= /div>
O= n Sun, Oct 24, 2021 at 8:18 PM Ted Lemon <mellon@fugue.com> wrote:
I've posted a draft that I belie= ve addresses all last call comments that came up. Most of the comments were= relatively minor, but there are a few that are significant.

=
First, in implementing support for dnssd service subtypes for SRP repl= ication, it became clear that it was a problem to support updates to subtyp= es where the update adds a subtype but doesn't mention other subtypes a= dded by a previous update, or removes subtypes. We could have done it, but = it added significant complexity. So this impacted the SRP document in the s= ense that we needed to explicitly describe the behavior. The behavior that = SRP requires now is that if any subtype PTR records exist pointing to a ser= vice instance that's being updated, and those subtypes are not present = in the update, they are implicitly removed.

The se= cond big change is that Esko pointed out that the text describing the sleep= proxy isn't really very consistent with the rest of the document, and = indeed is somewhat incomplete. There isn't an easy way to handle this= =E2=80=94either we have to stop and fix it, which might delay publication f= or a long time, or we have to remove it.

Because t= here's another document that describes the edns0 owner option, on which= the sleep proxy depends, and that document is nowhere near publication (it= 's been expired since 2018), I think the right answer is to work on tha= t document, and update it to add sleep proxy support to SRP, rather than ke= eping sleep proxy support in the base SRP document. Obviously the working g= roup should consider whether or not we collectively agree with this approac= h.

I unfortunately forgot about Esko's rather = detailed editorial review when I produced the -11 document, so I had to do = a -12 a today to address his editorial comments. These substantially improv= e the readability of the document=E2=80=94thanks for doing that, Esko!

I am on vacation this coming week, so I won't be h= ere to discuss this, but feel free to comment immediately, and I'll rev= iew and respond when I get back.

Thanks!


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000cb431a05cf32e40b-- From nobody Mon Oct 25 15:36:26 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 5E85F3A0A63 for ; Mon, 25 Oct 2021 15:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=ham 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 QcKszNxTboVJ for ; Mon, 25 Oct 2021 15:36:20 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 9BF703A0A46 for ; Mon, 25 Oct 2021 15:36:20 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id m26so12332073pff.3 for ; Mon, 25 Oct 2021 15:36:20 -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 :cc; bh=RD7ipRLSC4kRuLSSxT20plNV5aQEXpc0cHtXGt0EWbw=; b=irzx6OSXRFR6FTuHn8UIEAlSHrT53N+gU5/NXioq8O+Oz/V5k+KVQINWLhQyIYPnYI YFAunGl5TGZwM2Q1B+W1Ux5ovjoBZ5R15td531/jGgRCGrawYbYtyZWb2vttdZBvlIsd qj/K5sfeARJt7wZIvLYF/ppSRICRAknYFsfSoe02EVx9c3TbOYT0W9npnKuMTbcAtF3F 3kZqK/bncgdekh7akkwjfeQN67RcqIKqVDgFCKapKdqlavdz6CreY+5XsmxYhY3Q/Y0i sUI6KGC/x8pwnfnnUyqCxsE8DbyHalr2Mq4RJy79LPtUENS/5xErU02Ia9U0CtQAZpX9 3cSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RD7ipRLSC4kRuLSSxT20plNV5aQEXpc0cHtXGt0EWbw=; b=RezDREk+viUoLV0AmkfU76kc7bV2r9gWLtjKhuMK7E6tbvEbdHMq9fz5GW04bUQ5F8 HOCcYnOtKDzObrgu5T8J4KgalHfK/rHxogjtJ/rla1HROynngzcjrdCh0xjvDgfIdEz/ 3qRBprf9oDXLjSnHHcqZiDHHlo/KhpiKaDa+3Zh34Jd+Rk9i/dc4S7YuplBiweeJgbLX FBvFzO0dqL2OfEpeAd4tPF3WQvO1Ma8ijczX63tbwFBQdT/eCauqYPqlq8F7TgJ4fj3V sjofwTY0GqfZ0wzHN7Y/dP1OhYFT9RWHsPt9u9TZcBGh/GSePJRd239E5Z5KlEtIDK4k Q30Q== X-Gm-Message-State: AOAM533z5EMEefidgNJPPRHGPLd6qdxv1pnYkBHiEV1dxHDFmJ0w/Dkd SZzab3LPvXQi+AECIjWg2ac75hznWeZsSV4TLx2n0h+VEWc= X-Google-Smtp-Source: ABdhPJxR979/LDlBl455yGcyJPC1E+jt5Z0cCyGkWWCHJMeHSZ2s8zojbxaTOgs5VE9Llfc5606uMDN1jnftez1ljG0= X-Received: by 2002:a63:b957:: with SMTP id v23mr15367617pgo.74.1635201376911; Mon, 25 Oct 2021 15:36:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 25 Oct 2021 15:36:05 -0700 Message-ID: To: Ted Lemon Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000003504b405cf34fdf4" Archived-At: Subject: Re: [dnssd] Last call update to draft-ietf-dnssd-srp 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: Mon, 25 Oct 2021 22:36:25 -0000 --0000000000003504b405cf34fdf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Ted for the long-awaited update :-) As discussed a couple months back [1], this update was required to conclude the working group last call. Here are our next steps for this draft: - the chairs will let folks comment on the latest revision for the next two weeks (please comment on the list!) - we'll briefly discuss this draft at IETF 112 (DNSSD is currently scheduled on the last session on Friday 2021-11-12) - assuming no objections arise between now and then, the chairs will then submit the draft to the IESG for publication Thanks, David [1] https://mailarchive.ietf.org/arch/msg/dnssd/9JloygQVSzIpzlxbDf-wGsKqpWs= / On Sun, Oct 24, 2021 at 8:18 PM Ted Lemon wrote: > I've posted a draft that I believe addresses all last call comments that > came up. Most of the comments were relatively minor, but there are a few > that are significant. > > First, in implementing support for dnssd service subtypes for SRP > replication, it became clear that it was a problem to support updates to > subtypes where the update adds a subtype but doesn't mention other subtyp= es > added by a previous update, or removes subtypes. We could have done it, b= ut > it added significant complexity. So this impacted the SRP document in the > sense that we needed to explicitly describe the behavior. The behavior th= at > SRP requires now is that if any subtype PTR records exist pointing to a > service instance that's being updated, and those subtypes are not present > in the update, they are implicitly removed. > > The second big change is that Esko pointed out that the text describing > the sleep proxy isn't really very consistent with the rest of the documen= t, > and indeed is somewhat incomplete. There isn't an easy way to handle > this=E2=80=94either we have to stop and fix it, which might delay publica= tion for a > long time, or we have to remove it. > > Because there's another document that describes the edns0 owner option, o= n > which the sleep proxy depends, and that document is nowhere near > publication (it's been expired since 2018), I think the right answer is t= o > work on that document, and update it to add sleep proxy support to SRP, > rather than keeping sleep proxy support in the base SRP document. Obvious= ly > the working group should consider whether or not we collectively agree wi= th > this approach. > > I unfortunately forgot about Esko's rather detailed editorial review when > I produced the -11 document, so I had to do a -12 a today to address his > editorial comments. These substantially improve the readability of the > document=E2=80=94thanks for doing that, Esko! > > I am on vacation this coming week, so I won't be here to discuss this, bu= t > feel free to comment immediately, and I'll review and respond when I get > back. > > Thanks! > > BTW, you can see a diff from -10 to -12 here: > https://www.ietf.org/rfcdiff?url1=3Dhttp://www.ietf.org/archive/id/draft-= ietf-dnssd-srp-10.txt&url2=3Dhttp://www.ietf.org/archive/id/draft-ietf-dnss= d-srp-12.txt > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000003504b405cf34fdf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Ted for the long-awaited update :-)

As discussed a couple months back [1], this update was required to c= onclude the working group last call.

Here are our = next steps for this draft:
- the chairs will let folks comment on= the latest revision for the next two weeks (please comment on the list!)
- we'll briefly discuss this draft at IETF 112 (DNSSD is curre= ntly scheduled on the last session on Friday 2021-11-12)
- assumi= ng no objections arise between now and then, the chairs will then submit th= e draft to the IESG for publication

Thanks,
<= div>David


On Sun, Oct 24= , 2021 at 8:18 PM Ted Lemon <mellon@= fugue.com> wrote:
I've posted a draft that I believe addresse= s all last call comments that came up. Most of the comments were relatively= minor, but there are a few that are significant.

First,= in implementing support for dnssd service subtypes for SRP replication, it= became clear that it was a problem to support updates to subtypes where th= e update adds a subtype but doesn't mention other subtypes added by a p= revious update, or removes subtypes. We could have done it, but it added si= gnificant complexity. So this impacted the SRP document in the sense that w= e needed to explicitly describe the behavior. The behavior that SRP require= s now is that if any subtype PTR records exist pointing to a service instan= ce that's being updated, and those subtypes are not present in the upda= te, they are implicitly removed.

The second big ch= ange is that Esko pointed out that the text describing the sleep proxy isn&= #39;t really very consistent with the rest of the document, and indeed is s= omewhat incomplete. There isn't an easy way to handle this=E2=80=94eith= er we have to stop and fix it, which might delay publication for a long tim= e, or we have to remove it.

Because there's an= other document that describes the edns0 owner option, on which the sleep pr= oxy depends, and that document is nowhere near publication (it's been e= xpired since 2018), I think the right answer is to work on that document, a= nd update it to add sleep proxy support to SRP, rather than keeping sleep p= roxy support in the base SRP document. Obviously the working group should c= onsider whether or not we collectively agree with this approach.
=
I unfortunately forgot about Esko's rather detailed edit= orial review when I produced the -11 document, so I had to do a -12 a today= to address his editorial comments. These substantially improve the readabi= lity of the document=E2=80=94thanks for doing that, Esko!

I am on vacation this coming week, so I won't be here to discus= s this, but feel free to comment immediately, and I'll review and respo= nd when I get back.

Thanks!

BTW, you can see a diff from -10 to -12 here:=C2=A0https://www.ietf.org/rfcdiff?url1=3Dhttp://www.ietf= .org/archive/id/draft-ietf-dnssd-srp-10.txt&url2=3Dhttp://www.ietf.org/= archive/id/draft-ietf-dnssd-srp-12.txt

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000003504b405cf34fdf4-- From nobody Tue Oct 26 09:40:15 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 EC5CF3A14B6 for ; Tue, 26 Oct 2021 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham 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 YWw-tn3rYNM7 for ; Tue, 26 Oct 2021 09:40:10 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 839173A14B5 for ; Tue, 26 Oct 2021 09:40:10 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id b1so8027833qvk.5 for ; Tue, 26 Oct 2021 09:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=o7GsfDoPm4jKpajr3G0nE0I0XEdIhdjlhp5xAcGTPZY=; b=n/t3XJOaw1wHo9d5tPuQgMPXKNkQNPthrvhz8yaiIO+7z/CkPqJegOuTCj9vzJxXbp mnpeuc0fuCLC33sAI+o4kFeT9iIIx+BvjBpLqEvvZMPgCC2j1ODTo5s5ZZYX3QmyoY/b jZNEqrMz/rE06FrRA/KhW0q9eNcCnx0eImuwuYexDf3ot3H5DJBvCS+ziscyMa+86xlF 6KOMvwbtz8CELkQOkbQOeORsPlFbEyFbpl+lPbS/NUxa11dDd/nwj9cSBaK7uY//yJNp IOSaHt2g46GRDeeZIDr4W1PvCSLDPlBfX+A1vZO7PFcy8fE8RGxVB5MShSCg6BzoHPjU WJoQ== 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; bh=o7GsfDoPm4jKpajr3G0nE0I0XEdIhdjlhp5xAcGTPZY=; b=IKjF5xcsevlBPRGry5Meiz+vWnk/9UURGeu1j0IwRmCDMagja/Z2l4fkZuRP1EPKbx CJoNBm71VZH5SEg/1ikoEGn2RAHK5zefMCnOf/fGQgJayOBzfl1A6VHhRgEVewTcppNu liTHyblQuy1cFt9AwT7jxfiXXuwqGzl33Rf5axV8xPw5CStEi7tEsuI4Auh3iH1v4syy ypVxDwllXZ3BJyxH7zh/Dhauzu4UASeLgMhQu+Dm4QPMSKUB4rKk9TB6rK/OHI1vGZgG 8gyX4g1Cjdr4HXdK/WXX/jxTAVK1MxLAlaLNuQp0P9UbhrMAUUgvAzlkjhcvh7bgofM5 /jSg== X-Gm-Message-State: AOAM533luaq0tYF8+1VJXak8vjvnjzcEamkAfxxPCkc6d5X4X/ZzWMmC mYS4ddSY/17n9ZD9Sj+iEHvbCMm3YtZJXg4RJwvHVlhTK6U= X-Google-Smtp-Source: ABdhPJyGrmKOnyvM+F2clDB95f6Qh4xicZmwBbqxjgFmZzKN+5CJFAz2kaz/CY5RKM+SRBa68GXL8msRZ7Wpmy6yoJc= X-Received: by 2002:a05:6214:e41:: with SMTP id o1mr5608529qvc.61.1635266408969; Tue, 26 Oct 2021 09:40:08 -0700 (PDT) MIME-Version: 1.0 From: Chris Box Date: Tue, 26 Oct 2021 17:39:58 +0100 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000006b7a4605cf442114" Archived-At: Subject: [dnssd] Call for agenda items for DNSSD@IETF112 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, 26 Oct 2021 16:40:13 -0000 --0000000000006b7a4605cf442114 Content-Type: text/plain; charset="UTF-8" Hello everyone, What would you like to discuss when we meet on Friday 12th? It's a two hour slot, so there's space to make progress. As a prompt, here's what we have on the WG's kitchen table right now. draft-ietf-dnssd-srp-12 (currently final two weeks of comments, then we *could* be shipping it to the IESG right after this meeting - it's up to you) draft-sctl-advertising-proxy-02 (adopted in August, generated some discussion but awaiting a rename) draft-ietf-dnssd-update-lease-00 (adopted and renamed, with small diffs draft-sekar-dns-ul-03.txt - draft-ietf-dnssd-update-lease-00.txt ) And on the nearby bookshelf: draft-eckert-anima-grasp-dnssd-02 (presented in the last meeting: slides-ietf111-dnssd-eckert-grasp-dnssd ) draft-lemon-srp-replication-00 (presented in last meeting and recently reviewed by Abtin, the -01 did not make the draft cutoff) draft-tljd-dnssd-zone-discover-00 (presented in last meeting but not yet discussed on list) Finally, just arrived in the mail: draft-tllq-tsr-00 (addresses the problem of what to do when two advertising proxies get updates from the same host at two different times) The chairs will need to submit a draft agenda tomorrow (27th), but we can revise this until the 1st. So please let us know what you'd like to see. Thanks, Chris --0000000000006b7a4605cf442114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
<= br>
What would you like to discuss when we meet on Friday 12th? I= t's a two hour slot, so there's space to make progress.
<= br>
As a prompt, here's what we have on the WG's kitchen = table right now.
draft-ietf-dnssd-srp-12=C2=A0(currently final two weeks o= f comments, then we could be shipping it to the IESG right after thi= s meeting - it's up to you)
draft-sctl-ad= vertising-proxy-02=C2=A0(adopted in August, generated some discussion b= ut awaiting a rename)
=
<= div dir=3D"ltr">
And on the nearby bookshelf:
=
=
<= /div>
draft-lemon-srp-replication-0= 0=C2=A0(presented in last meeting and recently reviewed by Abtin, the -= 01 did not make the draft cutoff)
=
=
draft-tljd-dnssd-zone-d= iscover-00=C2=A0(presented in last meeting but not yet discussed on lis= t)
<= /blockquote>
Finally, just arrived= in the mail:
<= div dir=3D"ltr">
draft-tllq-tsr-00=C2=A0(addre= sses the problem of what to do when two advertising proxies get updates fro= m the same host at two different times)
=

The chairs will need to submit a draft agen= da tomorrow (27th), but we can revise this until the 1st. So please let us = know what you'd like to see.

Thanks,
Chris






=
--0000000000006b7a4605cf442114-- From nobody Thu Oct 28 09:59:25 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 B7B573A0061 for ; Thu, 28 Oct 2021 09:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham 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 7dkej_5tIutS for ; Thu, 28 Oct 2021 09:59:19 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 31F4A3A0062 for ; Thu, 28 Oct 2021 09:59:19 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id f1so6345309qto.9 for ; Thu, 28 Oct 2021 09:59:19 -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=aJK7ZHIJUEYX4fMtT2ZBi77OrRhrhK2AAXUnrWlj0ec=; b=YeBcGEOm5ij1X1s+XQGuGIzKBpwypfFTj83zfcXZQqJPwuts0JYSvq3z/nzY89bIIC w2ACJMErNPPVKBy3nn5f+OKyIC1ofIffCiOEfxP8B1n8WxJ2HJoOzF4Ct/+JOLmL+KGV 1LUK1g+28JmzciBl47MS+fztKxfnwB9lko2JzUf0WxmByEOwcEYO3HzW+/om5OTw3cXQ QQdjAnbmKdgpwvdmKs1KhELC2QnryDjXqbmGeRIxF0/9ljURaiusCQzoxIjpmRJniY7v YgX5rXIGw3/gfqGMAJRY0ZIvrhX1MOG6OdC4iyPweuGVihMtsBEoopQcNdmUPKfubzAp JVnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aJK7ZHIJUEYX4fMtT2ZBi77OrRhrhK2AAXUnrWlj0ec=; b=iV946n0DDiL5+iIp00MTZ4WnkwiVMo9xb3MbliHeyBygcFwxjISEY6QW/Hz/h821Es jiphZFVJS6eKKmLsJ4qt5CNXJ8dy8/vNZk24hFZF0GEu8xMK4ns14pLBEqcFG3g+TSoK Iv6dca1VTQPIeIj2aOtdW1w4R+wUfFFYl5aLUTASV6dEmS7YeICByXMOfJI+e10nENsG 1npyN9ITqxhxRa3mgKUUob3uBTRDBU5pLd25hxWRYBlt0332jLK1djHvDbIM3+g7Ollm hRtNxBvwOQbH6aE4FBdqeX5N7OWycG/kyF+FfZd932lyI8CD5br1tC1FlmhkkxQc4UqR ALNQ== X-Gm-Message-State: AOAM5317aqFk6p4onopc2xwiKawSIsWBYE2bg78gW/C/SLfIIitySuA4 q6IKk3gw1DoYfXtTIqAAxkOvT8criAwgYtAMUaKN21+4 X-Google-Smtp-Source: ABdhPJxlRQ3qWZimIIcpLAKZA9ZuSA1JfXYzh0tl32HtQf4iltCDHxJZjwQQMfcpXM/rCcqh3W04rE8FqFL6+Wp6+Tc= X-Received: by 2002:ac8:57d2:: with SMTP id w18mr5932281qta.322.1635440356925; Thu, 28 Oct 2021 09:59:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Box Date: Thu, 28 Oct 2021 17:59:05 +0100 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="00000000000086a48605cf6ca16b" Archived-At: Subject: Re: [dnssd] Call for agenda items for DNSSD@IETF112 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: Thu, 28 Oct 2021 16:59:24 -0000 --00000000000086a48605cf6ca16b Content-Type: text/plain; charset="UTF-8" Time to correct myself! During IETF112, the last slot on every day is two hours long, EXCEPT FRIDAY which is one hour. This kind of makes sense since I only asked for an hour. So far I've only had agenda requests from Ted, but still open to others if you wish. Draft agenda will be going up soon. Chris On Tue, 26 Oct 2021 at 17:39, Chris Box wrote: > Hello everyone, > > What would you like to discuss when we meet on Friday 12th? It's a two > hour slot, so there's space to make progress. > > As a prompt, here's what we have on the WG's kitchen table right now. > > draft-ietf-dnssd-srp-12 > (currently final > two weeks of comments, then we *could* be shipping it to the IESG right > after this meeting - it's up to you) > draft-sctl-advertising-proxy-02 > (adopted > in August, generated some discussion but awaiting a rename) > draft-ietf-dnssd-update-lease-00 > (adopted > and renamed, with small diffs draft-sekar-dns-ul-03.txt - > draft-ietf-dnssd-update-lease-00.txt > > ) > > And on the nearby bookshelf: > > draft-eckert-anima-grasp-dnssd-02 > (presented > in the last meeting: slides-ietf111-dnssd-eckert-grasp-dnssd > > ) > draft-lemon-srp-replication-00 > (presented > in last meeting and recently reviewed by Abtin, the -01 did not make the > draft cutoff) > draft-tljd-dnssd-zone-discover-00 > (presented > in last meeting but not yet discussed on list) > > Finally, just arrived in the mail: > > draft-tllq-tsr-00 (addresses > the problem of what to do when two advertising proxies get updates from the > same host at two different times) > > > The chairs will need to submit a draft agenda tomorrow (27th), but we can > revise this until the 1st. So please let us know what you'd like to see. > > Thanks, > Chris > > > > > > > --00000000000086a48605cf6ca16b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Time to correct myself!

Duri= ng IETF112, the last slot on every day is two hours long, EXCEPT FRIDAY whi= ch is one hour. This kind of makes sense since I only asked for an hour.

So far I've only had agenda requests from Ted, b= ut still open to others if you wish. Draft agenda will be going up soon.

Chris

On Tue, 26 Oct 2021 at 17:39, Chris Box <<= a href=3D"mailto:chris.box.ietf@gmail.com">chris.box.ietf@gmail.com>= wrote:
Hello everyone,

What would you like to discuss when we meet on Friday 12th? It's = a two hour slot, so there's space to make progress.

As a prompt, here's what we have on the WG's kitchen table ri= ght now.
<= /div>
=
draft-ietf-dnssd-srp-12=C2=A0(currently f= inal two weeks of comments, then we could be shipping it to the IESG= right after this meeting - it's up to you)
<= div>
draft-sctl-advertising-proxy-02=C2=A0(adopted in A= ugust, generated some discussion but awaiting a rename)
And on the nearby bookshelf:
=
draft-lemon-srp-replication-00=C2=A0(presen= ted in last meeting and recently reviewed by Abtin, the -01 did not make th= e draft cutoff)
=
draft-tljd-dnssd-zone-d= iscover-00=C2=A0(presented in last meeting but not yet discussed on lis= t)
<= /blockquote>
Finally, just arrived= in the mail:
draft-tl= lq-tsr-00=C2=A0(addresses the problem of what to do when two advertisin= g proxies get updates from the same host at two different times)
<= div dir=3D"ltr">

The chairs will nee= d to submit a draft agenda tomorrow (27th), but we can revise this until th= e 1st. So please let us know what you'd like to see.

Thanks,
Chris



=



=
--00000000000086a48605cf6ca16b-- From nobody Fri Oct 29 02:59:27 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 8E6A33A1015 for ; Fri, 29 Oct 2021 02:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=ham 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 IfDZa_YIyxAV for ; Fri, 29 Oct 2021 02:59:21 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 316143A1010 for ; Fri, 29 Oct 2021 02:59:21 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id j1so1316595qtq.11 for ; Fri, 29 Oct 2021 02:59:21 -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=Fp6MHx3l5JuxOA4zg0TlSVo2B9RJxZDFfSoP1iVFBbc=; b=M2X9cZcW5P/tToF49IrAcfvt1fKxROFMNnGaVWkIebFaF6tdgMpsqRMVzuGLRMQ2hM dJNHyfSftUaRQ5t0mVAWsw4hteo5o9wAOPDah9mZeKqj2mI8btt5hs8RXUJpkMT+BKJz XEKQ1jGZv/72nsUYW2neLGLSshp9En20A5lf9XGjZWPot7qBpJt8QxZ+KbmluWEF7XIw Qz78V4vJzp8/ne0PUSX8uAxd4LSp8f4r1LGlTTdI2SIq7fO0l28xK8bafK2bq3sPTome Efvb1oLJaKgSO+NIN8TMNXWKp07ez3wGWVF+lBBmXFjHEJLKhuSOyo5qgL21suzDcr5y NVCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Fp6MHx3l5JuxOA4zg0TlSVo2B9RJxZDFfSoP1iVFBbc=; b=qD1ZkM9qz1gj4ddEIXYbNLha71fMN92qt4nUk5VIuqcwLrbjMCd/+YhYlhwu4D66dy nSUvsj+D73S9JHRIIcw4JZtguy+MYm38toUNLpwsxb26lxoJRpmx2K4n8FBq6hhJIcvY BL0Y6a+sqDX5/XNdRELnGMkuFQWSAJncblMLHIxoDJ5nDV/lRQHhWTr6fPqYNAkOsr34 OEQIzRcVoVu91k+gZk371x+wbI8jEqdk5Xu9KI9GQimcLJRjH5X8RSDPYmXV7f4eg7xY vQLAhEiVDbXiONVhUZg9aD0FusYEIWxpiSDNtZu/r8ZDSmjpCDs6BR10gv/QQGxmdqQk 0q3Q== X-Gm-Message-State: AOAM530FgcPkqIqsFuiZ3PlFDstH+dFMplSYU6ldqT2wq1mjIQPX/CyG aWcLayN29IYmNzPzCMu3ZOdmE/jiQoFtNzDTDWDGsqkkN08= X-Google-Smtp-Source: ABdhPJzDGXaZ3ZgsM9uy8IMmxJBCxE5ODeny3KZAaEIqYaeCcmS+Ayj8/74/Jv2D3dhd96I9+C+7rfqoJdHB1XOv+rI= X-Received: by 2002:a05:622a:149:: with SMTP id v9mr4117036qtw.15.1635501559381; Fri, 29 Oct 2021 02:59:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Box Date: Fri, 29 Oct 2021 10:59:08 +0100 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000007a01e705cf7ae105" Archived-At: Subject: Re: [dnssd] Call for agenda items for DNSSD@IETF112 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: Fri, 29 Oct 2021 09:59:26 -0000 --0000000000007a01e705cf7ae105 Content-Type: text/plain; charset="UTF-8" Hi everyone The draft agenda is now posted at https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnssd-02 The hour is full but we are happy to consider changes such as new items, reordering or adjustments to allocated times. See you then. Chris --0000000000007a01e705cf7ae105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone

The draft agenda is now posted at=C2=A0https://datatracker.ietf.or= g/meeting/112/materials/agenda-112-dnssd-02

Th= e hour is full but we are happy to consider changes such as new items, reor= dering or adjustments to allocated times.

See you = then.
Chris
--0000000000007a01e705cf7ae105--