From nobody Thu Dec 17 15:36:05 2020 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 0E8313A0972 for ; Thu, 17 Dec 2020 15:35:58 -0800 (PST) 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.20150623.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 s2so4EuM8A-y for ; Thu, 17 Dec 2020 15:35:56 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 E41CC3A09C9 for ; Thu, 17 Dec 2020 15:35:55 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id 186so498475qkj.3 for ; Thu, 17 Dec 2020 15:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4B9qo6in9HVvya5loDyDYTFfoEO3RrqXo0oH75TpwsI=; b=xsh/WMcjsVxmR3zbeW+YgOHHjr2t9rfreAlJDsKOdUxZBKrkSC7lES4AVSDRI9+NRJ 22fuT08aQ/Yl36wIpO1BVnPz04CG5E2ownn3ZokTGGMf7dOWS8xN6nI4bgawqrVFI+BX 5WoWI8Fhd+bw0FP4kIZsjXkNgRwclOeuuM5rxiqmjfzBKP0FuQJ0zvbTuFO154sf73Vr w+HCd1oo+9DEm1G8rtEdXTxqsDnMehhzZe9VifF9Dbuucjamex+CQzbIOryYOpp4fBJ2 oL9qnKuSY/eaMcfH4uLjG1x5LNIehW8+oqaKrC+FDVc1rMJzKIwUXb65l11BmQceYXfo VZ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4B9qo6in9HVvya5loDyDYTFfoEO3RrqXo0oH75TpwsI=; b=AtFMOVNyugS4j0hekJM4DsackTmHEUZRxJD993zFyQiMuNyIcwnFCXRctKKwxjpiMU K50xY0SBhfiuWcDpCg4raysA/usgsX/KsYuN781JBhgvGAeqXzFT0l90Br+i5z+auafg mGokjd9x2yFfDGALgeZbzdSEFZSAre5joqSbRm/z7o6DBRJq+RdGjAtbwNQfL/16sxMN 2lg7y+xUfKGW5bexuevC+drLzCSEIIFiDYhdbAQZl3onYDjo0zMjYKIA8xCAmlbjS2mk FeJ1q6lLRLTh8J7DlI6GKOEzk6jgd0qykTTFnq9/sjYczpxRnO1kkFEHIHPm71wvhrdC wPiA== X-Gm-Message-State: AOAM533xQQiF1T0kpivNA3AqOQ1JqS4bYVIIN7md3jvE7F8oH3SwqYko MrEMCtKxh+W8lRmeaEkikfGtPA== X-Google-Smtp-Source: ABdhPJzKFfx4KqaZWRmIU5w5T5oSBwnUfdNlw7kirWAahUjtPW/yt3yTZLf3XMj+Al01pKymuaqFug== X-Received: by 2002:a37:aa15:: with SMTP id t21mr1985405qke.86.1608248154773; Thu, 17 Dec 2020 15:35:54 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u7sm4674439qke.116.2020.12.17.15.35.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2020 15:35:54 -0800 (PST) From: Ted Lemon Message-Id: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_52DF5875-6973-46CA-A5AE-510F32C57C91" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 17 Dec 2020 18:35:51 -0500 In-Reply-To: Cc: dnssd@ietf.org, Jonathan Hui , Kangping Dong , Rongli Sun To: Abtin Keshavarzian References: X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 17 Dec 2020 23:36:04 -0000 --Apple-Mail=_52DF5875-6973-46CA-A5AE-510F32C57C91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Abtin! To be quite frank, using a zero lease time was a quick hack, which only = does well if the only use case is that the whole device is going offline = and hence wants to take all its services offline. This is a fairly = common use case in mDNS, but I hadn=E2=80=99t really thought about the = fact that your use case also makes a lot of sense, and isn=E2=80=99t = properly addressed by my quick hack. For the use case you are proposing, I think the approach we agreed on in = the off-list conversation you are referring to indeed makes more sense. = One slight clarification, from your second point in your summary: the = lease time would be the normal lease time. What would be different would be that a delete would appear in the = message with no following add. This is sufficient to delete the old = service. It would be permitted under the conditions you describe. The = new service that was added, and the host record being renewed, would = have the new lease time; the old service would be immediately removed. Does that make sense?? > On Dec 17, 2020, at 5:55 PM, Abtin Keshavarzian = wrote: >=20 > Hi all, >=20 > Would like to summarize some questions/discussions we had on an email = exchange (with Ted, Kangping, Jonathan, and Rongli) related to SRP and = the process for removing individual service(s). >=20 > First a quick (personal) note, I have been reading the RSP spec = recently. I think it is a very well-written and easy-to-read/follow. So = I want to give thanks and kudos to guys who were involved (Ted, Stuart, = others).=20 >=20 > ------- >=20 > There may be use-cases where we want to remove a previously = added/registered service. The question is how to realize this. >=20 > I think this can be done by sending two SRP Update message: > - First one removing all services/host-info (with lease time zero) > - Followed by another SR Update re-adding services (excluding the ones = removed) and host-info >=20 > However, it'd be good if this can be done more efficiently with a = single SRP update message.=20 > =20 > - Currently SRP considers the message to be valid if it includes zero = or more Service Discovery and Descriptions, and exactly one Host = Description. > - The idea is to extend spec to allow Update msg to include Service = Discovery/Description (without Host Description) with lease time zero to = use for removing services. > - The update message needs to include the key RR and be signed. > - The server would accept the removal of service only if the key = matches the previously registered key associated with the host and the = service, and if the signature is valid. >=20 > Thoughts? >=20 > Abtin. --Apple-Mail=_52DF5875-6973-46CA-A5AE-510F32C57C91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Abtin!

To be quite frank, using a zero lease time was a quick hack, = which only does well if the only use case is that the whole device is = going offline and hence wants to take all its services offline. This is = a fairly common use case in mDNS, but I hadn=E2=80=99t really thought = about the fact that your use case also makes a lot of sense, and isn=E2=80= =99t properly addressed by my quick hack.

For the use case you are proposing, I = think the approach we agreed on in the off-list conversation you are = referring to indeed makes more sense. One slight clarification, from = your second point in your summary: the lease time would be the normal = lease time.

What= would be different would be that a delete would appear in the message = with no following add. This is sufficient to delete the old service. It = would be permitted under the conditions you describe. The new service = that was added, and the host record being renewed, would have the new = lease time; the old service would be immediately removed.

Does that make = sense??

On Dec 17, 2020, at 5:55 PM, Abtin = Keshavarzian <abtink@google.com> wrote:

Hi all,

Would like to summarize some questions/discussions we had on = an email exchange (with Ted, Kangping, Jonathan, and Rongli) related to = SRP and the process for removing individual service(s).

First a quick (personal) note, I have been reading the RSP = spec recently. I think it is a very well-written and = easy-to-read/follow. So I want to give thanks and kudos to guys who were = involved (Ted, Stuart, others).

-------

There may be use-cases where we want to remove = a previously added/registered service. The question is how to realize = this.

I think this can be done by sending = two SRP Update message:
- First one removing all = services/host-info (with lease time zero)
- Followed by = another SR Update re-adding services (excluding the ones removed) and = host-info

However, it'd be good if this can = be done more efficiently with a single SRP update message.
 
- Currently SRP considers the message to = be valid if it includes zero or more Service Discovery and Descriptions, = and exactly one Host Description.
- The idea is to extend = spec to allow Update msg to include Service Discovery/Description = (without Host Description) with lease time zero to use for removing = services.
- The update message needs to include the key RR = and be signed.
- The server would accept the removal of = service only if the key matches the previously registered key associated = with the host and the service, and if the signature is valid.

Thoughts?

Abtin.

= --Apple-Mail=_52DF5875-6973-46CA-A5AE-510F32C57C91-- From abtink@google.com Thu Dec 17 14:55:25 2020 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 A41843A07F4 for ; Thu, 17 Dec 2020 14:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.7 X-Spam-Level: X-Spam-Status: No, score=-15.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, RCVD_IN_DNSWL_BLOCKED=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 6cfzlUEkTq2B for ; Thu, 17 Dec 2020 14:55:20 -0800 (PST) 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 2A0873A07F0 for ; Thu, 17 Dec 2020 14:55:19 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id z9so81147qtn.4 for ; Thu, 17 Dec 2020 14:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ondiwTwuWH3l+nxhxz9Q8XWzGGYsk3o3qDDKu6VyaBg=; b=jeJnuBVY8Q/tI1OH9+FuuzMGlh2ip74U2TjUcVpVB7M7qudSUeY4AKpkPcdR1NwS6x OyXIz8oPyJxH2eiL0IGaFwocdSDY98Bj1NrMnU6yoTlhuNaTVnWh/+MNN0cthroO1bNk fa6fO9cgaDvOMNnxk0HOXookzzjmm93zHoSoCIw9wCW60xu+/1Nv1ro8vyTObr9h7fny vjAbGUzn4xYdCexvL4SOXMatH+41W30miwLuoXm19dhk9zZMDXWcHuU/6wbr7uFIrqEA HtiBoFOYWVSZLgV6chrgHPwJ3gLxQ92E/ncO6iRTpvmY0o6ulX5u4aVKhph/X1XWJ1nm 1RQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ondiwTwuWH3l+nxhxz9Q8XWzGGYsk3o3qDDKu6VyaBg=; b=Vysty+6uUcoyLKtNQxiY8ophzQ5EdQ7moVnrrMx6UZYe95b2Rl5OkZq394m0Xwkmqn 9QSMuYaPRpEAVJ4IMuA/TW3e69KW1c/6H4DGvurVNWj5I3/Vq4GdRJcUdUhK92aLyfTM O5uTfiHguDMea2p6tcXGT7MxvELH3mRAbZis5dn5DVyneFXN9HIhGkJ3q7/ShOPyKxoU 5gDlyC4MaEctL1OiDlv9PQvaVpKuUwjyimrSFVwSCX/S8S5wor3PQ1U2FGVuJgAtWrd4 NrEgxYidq4E3i1eomy07NmedOrxl/pDoLRxfQHlfSr3mNLvGtrS4YTWl1KgoLbXhrhIR rQPg== X-Gm-Message-State: AOAM532S8SaC539tq2H2ChkfBur4bhtVLra5X62j2FoFYSM1Bo6Y+UQt 3YvhCHLnpjaAmp9EzYPPRTyqvxfsyF5o7H3c/8ueZi2trKpttQ== X-Google-Smtp-Source: ABdhPJxY7fs11gTyrKmb4Ktr2s1H72ycXtI9Ov56wlQqq3MbR1mC+bqkSK+tUySJgi1YL1YwsZ62/fr5VtHvctn0s3g= X-Received: by 2002:ac8:454e:: with SMTP id z14mr1170320qtn.120.1608245718642; Thu, 17 Dec 2020 14:55:18 -0800 (PST) MIME-Version: 1.0 From: Abtin Keshavarzian Date: Thu, 17 Dec 2020 14:55:07 -0800 Message-ID: To: dnssd@ietf.org Cc: Jonathan Hui , Kangping Dong , Rongli Sun , Ted Lemon Content-Type: multipart/alternative; boundary="000000000000c5dc5b05b6b0e2bf" Archived-At: Subject: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 17 Dec 2020 23:45:36 -0000 --000000000000c5dc5b05b6b0e2bf Content-Type: text/plain; charset="UTF-8" Hi all, Would like to summarize some questions/discussions we had on an email exchange (with Ted, Kangping, Jonathan, and Rongli) related to SRP and the process for removing individual service(s). First a quick (personal) note, I have been reading the RSP spec recently. I think it is a very well-written and easy-to-read/follow. So I want to give thanks and kudos to guys who were involved (Ted, Stuart, others). ------- There may be use-cases where we want to remove a previously added/registered service. The question is how to realize this. I think this can be done by sending two SRP Update message: - First one removing all services/host-info (with lease time zero) - Followed by another SR Update re-adding services (excluding the ones removed) and host-info However, it'd be good if this can be done more efficiently with a single SRP update message. - Currently SRP considers the message to be valid if it includes zero or more Service Discovery and Descriptions, and exactly one Host Description. - The idea is to extend spec to allow Update msg to include Service Discovery/Description (without Host Description) with lease time zero to use for removing services. - The update message needs to include the key RR and be signed. - The server would accept the removal of service only if the key matches the previously registered key associated with the host and the service, and if the signature is valid. Thoughts? Abtin. --000000000000c5dc5b05b6b0e2bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Would like to summ= arize some questions/discussions we had on an email exchange (with Ted, Kan= gping, Jonathan, and Rongli) related to SRP and the process for removing in= dividual service(s).

First a quick (personal) note, I have been read= ing the RSP spec recently. I think it is a very well-written and easy-to-re= ad/follow. So I want to give thanks and kudos to guys who were involved (Te= d, Stuart, others).

-------

There may be use-cases where we = want to remove a previously added/registered service. The question is how t= o realize this.

I think this can be done by sending two SRP Update m= essage:
- First one removing all services/host-info (with lease time zer= o)
- Followed by another SR Update re-adding services (excluding the one= s removed) and host-info

However, it'd be good if this can be do= ne more efficiently with a single SRP update message.
=C2=A0
- Curre= ntly SRP considers the message to be valid if it includes zero or more Serv= ice Discovery and Descriptions, and exactly one Host Description.
- The = idea is to extend spec to allow Update msg to include Service Discovery/Des= cription (without Host Description) with lease time zero to use for removin= g services.
- The update message needs to include the key RR and be sign= ed.
- The server would accept the removal of service only if the key mat= ches the previously registered key associated with the host and the service= , and if the signature is valid.

Thoughts?

Abtin.
<= /div> --000000000000c5dc5b05b6b0e2bf-- From nobody Thu Dec 17 16:40:57 2020 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 595093A0A20 for ; Thu, 17 Dec 2020 16:40:55 -0800 (PST) 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 909UmVq96Hzi for ; Thu, 17 Dec 2020 16:40:53 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 C9E6A3A0A1D for ; Thu, 17 Dec 2020 16:40:53 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id 19so599608qkm.8 for ; Thu, 17 Dec 2020 16:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hsHEw27hcTBUVTiAeo4NeHFRVdX2szhe7d3HFpyj3D8=; b=KRJ4OgTVAxIBhjrYtexYqb7AmAFKL4AgKrINcyV0UVHSpjoP+Lsi4Ioh4IH2Azqy2r btSIoGBkrPqxXyWbnYWD2OKKACHwgUIDsUnMxeS6Nr7WwqHgZHjJ4iI9b/2gLVQW3Uw5 VkC6nfdUNMSjxMajyt4IxxATqaerlkYzWO3b+Ud24p9kUSv6IGkNhj9sVvQB/jK3j34u GQ4ISD/Sg0q0rVDU9QigLRdEnp+4Bg2Or0cVwo10rFperPRAhLNQozdWmKzKCKZ5e0El lzmSGwFWXEfjKh+roRYueUb6LYQGlojSHV0GkN741V4OhddYV9uQiTgJjPVcYg1+5gUW IxFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hsHEw27hcTBUVTiAeo4NeHFRVdX2szhe7d3HFpyj3D8=; b=VB6wIa/AnLxr4UB37ePYwUMo9wtTK2DuFNuXuDnSpML7v4zE0UFoL9Vnnyo1nmVW9f Kil/LqMdPCvkrzqgcHTegp+h7DR7vkaL2olwToc7ldAlsmFWOBszNv7Ndrwa4O3abAli 0+DObtS+4i22L90GT/1VqKDYhutlnyKMjvNCJQ5i0b08hxgy4SM7ooLWOoarTHbsKZEe x2Qi3RoNjZb6aut4Cv9hOqqwFb6/T8JaGB7OoVJ5WQII9fK20ciKNDF4fhQJw/f7xJly ppIoMGCQXqq/P23bzo10v35mzz3DG+Afr0EtKgrFZeNQFqohPhhJZ/dT460pYgxAFdhV HIXA== X-Gm-Message-State: AOAM5310vv3x+NpiO4KWOjn0E1mZxw1U1wGYof4umaFXLMg3S9p0zlJu PdW8GeJpfJj9H8D8tFJ1W5j9KHsHtqQcgqtdJ+XgBBOe9TblPA== X-Google-Smtp-Source: ABdhPJyIfVU33aOqqfQqWMpdDdXtBYkiSBslEu/KIq6i2UT4F1s8auByvJvzkF6cpyS9/BxEyZPrBug29C60Q2D7xic= X-Received: by 2002:a37:8307:: with SMTP id f7mr2226193qkd.70.1608252052463; Thu, 17 Dec 2020 16:40:52 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> In-Reply-To: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> From: Abtin Keshavarzian Date: Thu, 17 Dec 2020 16:40:41 -0800 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org, Jonathan Hui , Kangping Dong , Rongli Sun Content-Type: multipart/alternative; boundary="0000000000004c6b4b05b6b25c6d" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 18 Dec 2020 00:40:55 -0000 --0000000000004c6b4b05b6b25c6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ted, Yes, that makes sense and sounds simpler. :) I think it also allows multiple adds and removes, all, to happen from the same SRP update message. Let me try to describe some details: - In "Service Description Instruction", we allow a "Delete all RRSet from a name", with possibly no follow-up adds. - When a service is being deleted, we can consider allowing KEY RR "Add to an RRSet" for instance name to be optionally included, to have the server keep the instance name reserved (if desired). Does it make sense? - In "Service Discovery Instruction" I think we need to allow delete as well (I guess "Delete an RR from an RR set" for PTR RR)? - We continue to require SRP Update msg to always include exactly one "Host Description". Does this all sound good/reasonable? Anything I may have missed? Sorry I think I misunderstood the earlier discussion. Somehow I associated the remove to require registering with zero lease time. Thanks, Abtin. On Thu, Dec 17, 2020 at 3:35 PM Ted Lemon wrote: > Thanks, Abtin! > > To be quite frank, using a zero lease time was a quick hack, which only > does well if the only use case is that the whole device is going offline > and hence wants to take all its services offline. This is a fairly common > use case in mDNS, but I hadn=E2=80=99t really thought about the fact that= your use > case also makes a lot of sense, and isn=E2=80=99t properly addressed by m= y quick > hack. > > For the use case you are proposing, I think the approach we agreed on in > the off-list conversation you are referring to indeed makes more sense. O= ne > slight clarification, from your second point in your summary: the lease > time would be the normal lease time. > > What would be different would be that a delete would appear in the messag= e > with no following add. This is sufficient to delete the old service. It > would be permitted under the conditions you describe. The new service tha= t > was added, and the host record being renewed, would have the new lease > time; the old service would be immediately removed. > > Does that make sense?? > > On Dec 17, 2020, at 5:55 PM, Abtin Keshavarzian wrote= : > > Hi all, > > Would like to summarize some questions/discussions we had on an email > exchange (with Ted, Kangping, Jonathan, and Rongli) related to SRP and th= e > process for removing individual service(s). > > First a quick (personal) note, I have been reading the RSP spec recently. > I think it is a very well-written and easy-to-read/follow. So I want to > give thanks and kudos to guys who were involved (Ted, Stuart, others). > > ------- > > There may be use-cases where we want to remove a previously > added/registered service. The question is how to realize this. > > I think this can be done by sending two SRP Update message: > - First one removing all services/host-info (with lease time zero) > - Followed by another SR Update re-adding services (excluding the ones > removed) and host-info > > However, it'd be good if this can be done more efficiently with a single > SRP update message. > > - Currently SRP considers the message to be valid if it includes zero or > more Service Discovery and Descriptions, and exactly one Host Description= . > - The idea is to extend spec to allow Update msg to include Service > Discovery/Description (without Host Description) with lease time zero to > use for removing services. > - The update message needs to include the key RR and be signed. > - The server would accept the removal of service only if the key matches > the previously registered key associated with the host and the service, a= nd > if the signature is valid. > > Thoughts? > > Abtin. > > > --0000000000004c6b4b05b6b25c6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ted,

Yes, that makes sense and sounds s= impler. :)
I think it also allows multiple adds and removes, all,= to happen from the same SRP update message.

Let me try to describe = some details:

- In "Service Description Instruction", we a= llow a "Delete all RRSet from a name", with possibly no follow-up= adds.=C2=A0
- When a service is being deleted, we can consider a= llowing KEY RR "Add to an RRSet" for instance name to be optional= ly included, to have the server keep the instance name reserved (if desired= ).=C2=A0 Does it make sense?
- In "Service Discovery Instruc= tion" I think we need to allow delete as well (I guess "Delete an= RR from an RR set" for PTR RR)?
- We continue to require SRP Updat= e msg to always include exactly one "Host Description".

D= oes this all sound good/reasonable? Anything I may have missed?
<= br>
Sorry I think I misunderstood the earlier discussion. Somehow= I associated the remove to require registering with zero lease time.
Thanks,
Abtin.

On Thu, Dec 17, 2020 at 3:35 PM Ted Lemon <= ;mellon@fugue.com= > wrote:
Thanks, Abtin!

To be quite frank, using a zero lease ti= me was a quick hack, which only does well if the only use case is that the = whole device is going offline and hence wants to take all its services offl= ine. This is a fairly common use case in mDNS, but I hadn=E2=80=99t really = thought about the fact that your use case also makes a lot of sense, and is= n=E2=80=99t properly addressed by my quick hack.

F= or the use case you are proposing, I think the approach we agreed on in the= off-list conversation you are referring to indeed makes more sense. One sl= ight clarification, from your second point in your summary: the lease time = would be the normal lease time.

What would be diff= erent would be that a delete would appear in the message with no following = add. This is sufficient to delete the old service. It would be permitted un= der the conditions you describe. The new service that was added, and the ho= st record being renewed, would have the new lease time; the old service wou= ld be immediately removed.

Does that make sense??<= br>

On Dec 17, 2020, at 5:55 PM, Abt= in Keshavarzian <= abtink@google.com> wrote:

Hi all,

Would like to summarize some questions/discus= sions we had on an email exchange (with Ted, Kangping, Jonathan, and Rongli= ) related to SRP and the process for removing individual service(s).
First a quick (personal) note, I have been reading the RSP spec recently. = I think it is a very well-written and easy-to-read/follow. So I want to giv= e thanks and kudos to guys who were involved (Ted, Stuart, others).
-------

There may be use-cases where we want to remove a previously= added/registered service. The question is how to realize this.

I th= ink this can be done by sending two SRP Update message:
- First one remo= ving all services/host-info (with lease time zero)
- Followed by another= SR Update re-adding services (excluding the ones removed) and host-info
However, it'd be good if this can be done more efficiently with a = single SRP update message.
=C2=A0
- Currently SRP considers the mess= age to be valid if it includes zero or more Service Discovery and Descripti= ons, and exactly one Host Description.
- The idea is to extend spec to a= llow Update msg to include Service Discovery/Description (without Host Desc= ription) with lease time zero to use for removing services.
- The update= message needs to include the key RR and be signed.
- The server would a= ccept the removal of service only if the key matches the previously registe= red key associated with the host and the service, and if the signature is v= alid.

Thoughts?

Abtin.

--0000000000004c6b4b05b6b25c6d-- From nobody Thu Dec 17 18:07:09 2020 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 9976E3A0B58 for ; Thu, 17 Dec 2020 18:07:07 -0800 (PST) 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.20150623.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 yvCKAiO6OL9a for ; Thu, 17 Dec 2020 18:07:05 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 9C55C3A0B55 for ; Thu, 17 Dec 2020 18:07:05 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id z11so760700qkj.7 for ; Thu, 17 Dec 2020 18:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9H6yYBRzVLGOB1NdtWQNoppylTXjoxQJZINfxRdA4Jc=; b=iZlQcPmJ2Ov8IAj78YU7JgXJ/B8ZsUc1XjxQWADwWVHtLxw0J5l41TC67UlPz5eVyD lwSHzGWjSbf3cES4r/eXJOuyngYMidvW4E0ABpZA3GDxjnOakxGrnBIA9n+00OauHNgK 7L8ga8qOCLXp2HNkfYdASmXKpQ36frpL+9XHHxzntMzGtZ5FDclYlu0lBy2WcASKY+8V XNSEqqTxn6TRWTgrROljxewnxukIZcMJA4U/jO8hOrZiIN5irzzCA0AopNwc9tEc0Zrl YcKhs/va23aKjujWKS1vSq9u7K7kdrhn7xt8PIolqNURj9Kd2pd0W5E9YPkRbfjTAvwX NXtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9H6yYBRzVLGOB1NdtWQNoppylTXjoxQJZINfxRdA4Jc=; b=fAveazY4DAplnw/r+/CUqALi51QiZSjqvFe+aYfy5mEuPi0Xivl8Qfy3qJTRd1zq5W 6D+BhATIbuP07tHLtvd7msQhZ135cNVQV3pxisDA0RcA0b4nJFUvuSvTG7j1FjCke35t rQ+kgb79pBVdTcsyKo8JQUFeITxgav73FZc318j2hl6MBO7s7FmOHsY+EzZTGPiyOBX5 MoaKTDQ+k5jMbtOTgb/0CCbxUOpfNYw8tUgsn6lvFyhWflaAUO8DTdFECpuB++jcDPOi 59H0C6OPeLAlzzvAuWUeC6cOBKUmUIw44xlcKIeRAxtx7WtxBCK/Yrn9S+FlZng7y32M WYWg== X-Gm-Message-State: AOAM533yClsHsm2l22MRSW1gTxUPQ4q+Y7nnxKKPHQI6DB1YvUgY4DVs 3e2ozZMSCzX3L1i+150MW8mO4w== X-Google-Smtp-Source: ABdhPJwimP6P+16iJR1g/qZ4SentEZcMaOnxhCQJhFL67yaRi+VHTHSMxF5ry0vrVjfV11CPv0QeRA== X-Received: by 2002:a05:620a:528:: with SMTP id h8mr2626804qkh.40.1608257224533; Thu, 17 Dec 2020 18:07:04 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id l11sm4607167qtn.83.2020.12.17.18.07.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2020 18:07:04 -0800 (PST) From: Ted Lemon Message-Id: <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_458F215F-0A03-4B95-BBBB-EE37A613E70C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 17 Dec 2020 21:07:01 -0500 In-Reply-To: Cc: dnssd@ietf.org, Jonathan Hui , Kangping Dong , Rongli Sun To: Abtin Keshavarzian References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 18 Dec 2020 02:07:08 -0000 --Apple-Mail=_458F215F-0A03-4B95-BBBB-EE37A613E70C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 17, 2020, at 7:40 PM, Abtin Keshavarzian = wrote: > - In "Service Description Instruction", we allow a "Delete all RRSet = from a name", with possibly no follow-up adds.=20 Yes. > - When a service is being deleted, we can consider allowing KEY RR = "Add to an RRSet" for instance name to be optionally included, to have = the server keep the instance name reserved (if desired). Does it make = sense? We could allow this, but KEY RRs are large, so we might prefer not to. > - In "Service Discovery Instruction" I think we need to allow delete = as well (I guess "Delete an RR from an RR set" for PTR RR)? Yes, and the RR has to be pointing to a Service Description Instruction = which is also being deleted. > - We continue to require SRP Update msg to always include exactly one = "Host Description".=20 Yes. > Does this all sound good/reasonable? Anything I may have missed? It sounds fine. I=E2=80=99m curious what others think about this. --Apple-Mail=_458F215F-0A03-4B95-BBBB-EE37A613E70C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 17, 2020, at 7:40 PM, Abtin Keshavarzian <abtink@google.com> = wrote:
- In "Service = Description Instruction", we allow a "Delete all RRSet from a name", = with possibly no follow-up adds. 

Yes.

- When a service is being deleted, we can consider = allowing KEY RR "Add to an RRSet" for instance name to be optionally = included, to have the server keep the instance name reserved (if = desired).  Does it make sense?

We could allow this, but KEY RRs are large, so we might = prefer not to.

- In "Service Discovery Instruction" = I think we need to allow delete as well (I guess "Delete an RR from an = RR set" for PTR RR)?

Yes, and the RR has to be pointing to a Service = Description Instruction which is also being deleted.

- We continue to require SRP Update msg to always = include exactly one "Host Description". 

Yes.

Does this all sound good/reasonable? = Anything I may have missed?

It sounds fine. I=E2=80=99m curious what = others think about this.

= --Apple-Mail=_458F215F-0A03-4B95-BBBB-EE37A613E70C-- From nobody Fri Dec 18 05:20:55 2020 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 874AB3A0637 for ; Fri, 18 Dec 2020 05:20:54 -0800 (PST) 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.20150623.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 LJE41vETV9GM for ; Fri, 18 Dec 2020 05:20:52 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9C5333A067A for ; Fri, 18 Dec 2020 05:20:52 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id j26so1190671qtq.8 for ; Fri, 18 Dec 2020 05:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iZe7t+YxirdB2yCYn6mod7bWRTAOHC0efJGEF5dDJ0Q=; b=Z6C+mra4ZStrwvKmqk8+PUVwk7AXZ7YqSkAqYj8gZi7Gy34kvOeH29B3Sg+sOeHvqQ gAwZKAfcPABN1Z1DQ5LLITjm34W7zSqx9D0RG21tcc2HM5lyKEA4M9GgL4Jmjo/oMjQn 2iejTOnNKp7vYTyaZTXDGSJB1iuvPkoROoLEynkLFlcGSjkWRGe4qjfO2v2yqEYjD/b3 Vro4NH+KLFnuj6BqAXfZSYFDqiknCoBdGmLWWHBbZr6iWI5Cn91/FCYrnVTPN/S1rf2t B+y6HZiZinRNlwjn//7oI9vmmbLiFZ+GoyLOK9Q94dYpYzUyKDTlFr0SwpjQpeR6aQGZ jS5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iZe7t+YxirdB2yCYn6mod7bWRTAOHC0efJGEF5dDJ0Q=; b=i0nL6zLLV3uirvyvD8HBkFUHVxp42+xKUzyIQPrDdUhfDMXmaXo2SzWKMyRvAwNir9 7D3iNzWKaSh1BfeoENl8nii3CBSK08wWjM8RhexKThCMy4SZdrxL1DZhyT10O7Jme7C4 6zxTkZI9ip0zB+Pf0GcAttjMZxBxqqnyYRcN3dmGwbCRLkmyXzP0h3lPDzzyEOJXowPy 3cJaCDSOLoF2ewN/c7JwFHq1NItn6OtQCbHghb/dIxt9/OAljorlNUhDZFpwheva1MwD ZpnIgf5RVYKwBvd7cq/cYCi59DsnTaOcPuU0/BC6M/Pj880aydzoEssmXbAL32MwiSBi VSag== X-Gm-Message-State: AOAM5313WGxKBJImWn9Gs2yunjirsRVunfURXLCkrbfin4FpTx38yzBA BNdJP8M/ejNcH3u/PlZtQjl3Ag== X-Google-Smtp-Source: ABdhPJz2G6QN75uOiEtApVslbtvC2TcPI6/WFhRpnl6ruEtVCgUbymh1wNvFSaIkwnPgZVLBcjzojw== X-Received: by 2002:ac8:6895:: with SMTP id m21mr3859852qtq.20.1608297651511; Fri, 18 Dec 2020 05:20:51 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c139sm3911317qke.24.2020.12.18.05.20.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Dec 2020 05:20:50 -0800 (PST) From: Ted Lemon Message-Id: <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_316B31BB-66A7-4992-AEFF-FA8C1C7E12D7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 18 Dec 2020 08:20:49 -0500 In-Reply-To: Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun To: Kangping Dong References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 18 Dec 2020 13:20:55 -0000 --Apple-Mail=_316B31BB-66A7-4992-AEFF-FA8C1C7E12D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 17, 2020, at 11:02 PM, Kangping Dong wrote: > I'd like to summary my understanding of what current SRP-draft-06 is = doing/allowing: > We can add services separately. like, we can add "service-1" and in = the first SRP update and "service-2" in the second SRP update. > We can only remove all the services together with its host because = "exactly one Host Description Instruction" is a MUST for each SRP = update. > But the spec seems, is not enforcing this behavior: > Therefore, SRP servers MAY remove all > service instances pointing to a host when a host is removed, even if > the SRP client doesn't remove them explicitly. > If we cannot remove individual service without removing the host, = should the "MAY" be a MUST? > Otherwise, there may be no efficient way to clean up the service until = the lease time expires. Yes, I think this is an oversight in the specification. What my = implementation actually does is to remove all the entries when we see a = =E2=80=9Clease 0=E2=80=9D update with a valid host record that=E2=80=99s = signed with the right key. > To remove a service registration, the SRP client retransmits its most > recent update with an Update Lease option that has a LEASE value of > zero. > Does it remove only the services in my most recent update or all = services I have ever registered? My implementation does the latter. It tracks what services are = registered per host. > This is what > I was confused about and thought we can remove individual service. As = we cannot remove individual service, > I think we don't need to retransmit the most recent update: It may be = more efficient to always transmit a > SRP update with only Host Description Instruction and zero lease time. = Thoughts? Yes. > For the current use model, I agree it will work for most cases and = removing individual service may be rare > (even there are, it can be done with a "removing all" and an add). So = I don't have a strong opinion to support it. I don=E2=80=99t think we really have enough data to say. In the = interests of being general, I think it=E2=80=99s probably worth = specifying how to remove individual services. This is what I=E2=80=99d = originally intended=E2=80=94I did the =E2=80=9Clease time 0=E2=80=9D = hack because it was expedient, not because it was the right thing to do. I=E2=80=99ll spin a -07 later today if I have time that makes this = change and addresses your other concerns from above, and then if = you=E2=80=99re willing, you guys can review my changes and see if they = are sufficient. --Apple-Mail=_316B31BB-66A7-4992-AEFF-FA8C1C7E12D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 17, 2020, at 11:02 PM, Kangping Dong <wgtdkp@google.com> = wrote:
I'd like to summary my = understanding of what current SRP-draft-06 is doing/allowing:
  1. We can add services separately. = like, we can add "service-1" and in the first SRP update and "service-2" = in the second SRP update.
  2. We can only remove all the = services together with its host because "exactly one Host Description = Instruction" is a MUST for each SRP update.
But = the spec seems, is not enforcing this behavior:
Therefore, SRP servers MAY remove all
service instances pointing to a host when a host is removed, even if
the SRP client doesn't remove them explicitly.
If we cannot remove individual service without removing the = host, should the "MAY" be a MUST?
Otherwise, there = may be no efficient way to clean up the service until the lease = time expires.

Yes, I think this is an oversight in the specification. = What my implementation actually does is to remove all the entries when = we see a =E2=80=9Clease 0=E2=80=9D update with a valid host record = that=E2=80=99s signed with the right key.

To remove a service registration, the SRP client =
retransmits its most
recent update with an Update Lease option that has a LEASE value of
zero.
Does it remove only the services = in my most recent update or all services I have ever = registered?

My implementation does the latter. It tracks what = services are registered per host.

This is what
I was = confused about and thought we can remove individual service. As we = cannot remove individual service,
I think we = don't need to retransmit the most recent update: It may be more = efficient to always transmit a
SRP update with only = Host Description Instruction and zero lease time. = Thoughts?

Yes.

For the current use model, I agree it will = work for most cases and removing individual service may be = rare
(even there are, it can be done with a = "removing all" and an add). So I don't have a strong opinion to support = it.

I = don=E2=80=99t think we really have enough data to say. In the interests = of being general, I think it=E2=80=99s probably worth specifying how to = remove individual services. This is what I=E2=80=99d originally = intended=E2=80=94I did the =E2=80=9Clease time 0=E2=80=9D hack because = it was expedient, not because it was the right thing to = do.

I=E2=80=99ll spin a -07 later = today if I have time that makes this change and addresses your other = concerns from above, and then if you=E2=80=99re willing, you guys can = review my changes and see if they are sufficient.

= --Apple-Mail=_316B31BB-66A7-4992-AEFF-FA8C1C7E12D7-- From nobody Fri Dec 18 14:59:45 2020 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 7BC0D3A02BC; Fri, 18 Dec 2020 14:59:43 -0800 (PST) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <160833238344.15631.13868338438119686228@ietfa.amsl.com> Date: Fri, 18 Dec 2020 14:59:43 -0800 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-07.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: Fri, 18 Dec 2020 22:59:44 -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-07.txt Pages : 29 Date : 2020-12-18 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-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 18 15:01:25 2020 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 DA3043A0ADA for ; Fri, 18 Dec 2020 15:01:23 -0800 (PST) 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.20150623.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 BFaiSRkewTWW for ; Fri, 18 Dec 2020 15:01:22 -0800 (PST) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 D57013A0AD3 for ; Fri, 18 Dec 2020 15:01:21 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id s6so1729569qvn.6 for ; Fri, 18 Dec 2020 15:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s4nL+iOXfYWziyd2r4/0FtA6M/7AwBDZ0oeiY7yczCs=; b=mTM/VCfpZ3IexwqFKay1cCkvqi7MpVUMfEIZAfBW0WoK9UdiJZamhBcgZc5Q5GiRCM yC5OA+rp/sWQ4xSJxURpj3ST65znpNKzMtiGtldJzbFevtamogx4A1DK2my7gEuSUgo4 KMFs+oUD4Gn6rGldFj/WBhV0zi//9NJlbN4b51IcPTpSDEUq93qTm1SSQQz5KkHWhTSy goMkDYnwqggZEDZilSXZPTQ57AGQ04fuX2AwJDiOH4kZ9/QQDelzO6VQgl6pIO6FJsfC lqU4cuDOn93Y1sLSyxS6qTN76UyzOqVLQDILz3zii2jI6xyAvUiDx4BeGWYbSryBo+C0 VZpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s4nL+iOXfYWziyd2r4/0FtA6M/7AwBDZ0oeiY7yczCs=; b=OcJ0pu+vpCVdGtB6pVes+Dxf6PiJFnVl4a1ukresaRgvmpbmNgTVTXoz/RcfXcD0PW qbzlx9RNUP/aXhGWibgAMpzoTseMymDUZK2SyatvH1Ru+Eglnmn9cN5p3biCpXWxKoqG Oge5oig1RZd8he9WwcmiyGnwoOh94cnyR6rTrl/0s+WYgNe2VY9/RQbIS2uMg271Gb6s 1d6twF6b8fmdCfRf4ATT2keA47W+mx6slSWPfDU6KjYbBI9h5+oZK8mZlklmSkku7GUD WfXhMqLSOs4ZDyG0P3P9tSP4I30GGMsLKfcMfo+kcpqzQilg//FqG0sxkANbYt5+tP8M n0Lw== X-Gm-Message-State: AOAM533sppW4+Pj/ND52Ep6A/xxzpK6lUWS2EU//5pFPr0a8t0ImWGbX +PP4a41elzUgHmWFXBwNKDmU+g== X-Google-Smtp-Source: ABdhPJzWSEGjudPPhUHHAqwWACBWKuBC21YRozKNeoMq1Tt/+aOHNkXgWCXMC56tbURsOSsCG42qYA== X-Received: by 2002:a05:6214:762:: with SMTP id f2mr6929408qvz.54.1608332480799; Fri, 18 Dec 2020 15:01:20 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x185sm6691121qkb.87.2020.12.18.15.01.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Dec 2020 15:01:20 -0800 (PST) From: Ted Lemon Message-Id: <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9341B28C-463D-4069-A0EE-3CE254D0FD30" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 18 Dec 2020 18:01:18 -0500 In-Reply-To: Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun To: Kangping Dong References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 18 Dec 2020 23:01:24 -0000 --Apple-Mail=_9341B28C-463D-4069-A0EE-3CE254D0FD30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 18, 2020, at 9:23 AM, Kangping Dong wrote: > Sounds good, thanks! Looking forward to the 07 draft! Not sure if you guys are on the mailing list, so FYI I have updated the = document: 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-07.html = A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-srp-07 = --Apple-Mail=_9341B28C-463D-4069-A0EE-3CE254D0FD30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 18, 2020, at 9:23 AM, Kangping Dong <wgtdkp@google.com> = wrote:
Sounds good, thanks! Looking = forward to the 07 draft!

Not sure if you guys are on the mailing list, so = FYI I have updated the document:




= --Apple-Mail=_9341B28C-463D-4069-A0EE-3CE254D0FD30-- From nobody Fri Dec 18 21:25:56 2020 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 597E83A0EC8 for ; Fri, 18 Dec 2020 21:25:54 -0800 (PST) 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 injm704QWj12 for ; Fri, 18 Dec 2020 21:25:52 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 848E13A0EC6 for ; Fri, 18 Dec 2020 21:25:52 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id l14so2037133qvh.2 for ; Fri, 18 Dec 2020 21:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=otKpZ4ah3ilWcNX80oZagg/tVfkHqNtXTtE7Nj8wYVc=; b=sTz4heuDGm2zZtEBvlo9i4NJF71OLEK2AaPh+v/inXf2tWik4wFBOrf4bpzhCr2a+s DUjIzUQPtIUoKe0vYm8eEvn3ABq9+wEhm48sO2IkJLbVY6JdjybYO0IxKeUU6Jl2PRv3 Y7R9Er+LQlYUNS6rsaKY7feRsb4ihV8QLb2aQ6YTFq0C78U7wuo4zPY2TDuDSBI96XZQ rFDoaGdWRBo2x3sFZ0dPtIngITR6j15RU8k4Vx1oKr1VBdM+C+qeAshuCn7/e7M7wdTY lz4tsTq6f2298rr9ljmoFR3lZq6YpKevWbLAr8tM/qdVCAQun7xVzP5YTmK3WwHGScvt FOlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=otKpZ4ah3ilWcNX80oZagg/tVfkHqNtXTtE7Nj8wYVc=; b=IdS5ST9CT0ugyPTh/ikjsOwAfYOIVw7sw9IxcN5wDyJteW7DqwkhacJicsvk4pjT2/ PMlTFp6kVOyakjaN+R4e18qPr6W09aQxeX86jW/ETJ0G5x9WNiW+/Gf3YlaxOhzSd1Ps 1t6fq/APPxhrHqbVHDH/wiWSolBaAkVD4yOtMdVp2MOpamn/wgEbA7TihwCtajEtgrYR 2lCpn44u58Xvggkwk7Bf4urHQPJww3qkoGt9NdEYjUCGU7dYQd1Jugm/xfYHeSXjmPPc 4d9vWs/SOIwma7qjEr94hpkqbO7O2OMdItG/qojqNfTXd9n8rc1k4aOHHOScO+cH6EaU W3ng== X-Gm-Message-State: AOAM5331AnzkkNYsCOmb1fhzAhrPxKNtq7Uj9pkecIKy9xyon1kw4cr8 9O2C1yUL0EcRgO7o0oeOy+sFeOX2XcIScBAd4TVRJQ== X-Google-Smtp-Source: ABdhPJz7eGFbJdYaNMO/IxuvKXqzbzGTN6XLWUnaZdbmUQ169RfOkT0boSShkxzzEXqqLurqdbB7WX4+UCexsaxwARA= X-Received: by 2002:ad4:4426:: with SMTP id e6mr8281610qvt.51.1608355551208; Fri, 18 Dec 2020 21:25:51 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> In-Reply-To: <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> From: Abtin Keshavarzian Date: Fri, 18 Dec 2020 21:25:40 -0800 Message-ID: To: Ted Lemon Cc: Kangping Dong , DNSSD , Jonathan Hui , Rongli Sun Content-Type: multipart/alternative; boundary="0000000000004dfc9a05b6ca75d2" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 05:25:54 -0000 --0000000000004dfc9a05b6ca75d2 Content-Type: text/plain; charset="UTF-8" Thanks Ted for very quick draft 7. I read it through. It's clear and overall looks great. Thanks :) One question/suggestion on section "2.3.1.2 Service Description Instruction". I like this added text: > if there is no "Add to an RRset" SRV RR, then there is an existing > SRV RR on the name specified in the "Delete all RRsets from a > name" update that to a hostname for which there is a Host > Description Instruction in the SRP Update, and there is a KEY RR > on that name which matches the key with which the SRP Update was > signed. This is ensuring that a client is only allowed to remove service instances that were previously added by the client itself. I was considering this (corner-case) situation: - Suppose a client sends an SRP update message to remove a service and add a new one. - Server checks the msg and it is all ok, so it sends a response - But somehow the response is dropped and the client does not get it. - Client then retransmits the same SRP update message (with remove and add). - Now on the server, the corresponding SRV RR (associated with the service instance) no longer exists (since it was removed from the first update msg). - I think in this case, we still want the server to consider the second SRP Update as valid. So considering the RRset for the service instance name being removed (for which we have "Delete all RRsets from a name" with no follow-on "Add to an RRset" SRV RR): - if SRV RR do exists on server, we require server to verify that it was added by same host and key. - but if it does not exist, the server would be ok with it (basically just ignore the delete of the non-existing RRset), and consider the SRP update msg valid. Does it sound ok? ------- I also found two small typos: 1) In section 2.3.1.1 (Service Discovery Instruction) last bullet point, - ... is an "Delete an RR from ... -> is a "Delete an RR from 2) Right before section 6.2 ... credentialsto to update ... -> credentials to update Thanks, Abtin. On Fri, Dec 18, 2020 at 3:01 PM Ted Lemon wrote: > On Dec 18, 2020, at 9:23 AM, Kangping Dong wrote: > > Sounds good, thanks! Looking forward to the 07 draft! > > > Not sure if you guys are on the mailing list, so FYI I have updated the > document: > > 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-07.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-07 > > > > --0000000000004dfc9a05b6ca75d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ted for very quick draft 7.
I read it through. = It's clear and overall looks great. Thanks :)

One question/sugg= estion on section "2.3.1.2 Service Description Instruction".
I= like this added text:

> if there is no "Add to an RRset&quo= t; SRV RR, then there is an existing
> SRV RR on the name specified = in the "Delete all RRsets from a
> name" update that to a = hostname for which there is a Host
> Description Instruction in the = SRP Update, and there is a KEY RR
> on that name which matches the k= ey with which the SRP Update was
> signed.

This is ensuring t= hat a client is only allowed to remove service instances that were previous= ly added by the client itself.

I was considering this (corner-case) = situation:
- Suppose a client sends an SRP update message to remove a se= rvice and add a new one.
- Server checks the msg and it is all ok, so it= sends a response
- But somehow the response is dropped and the client d= oes not get it.
- Client then retransmits the same SRP update message (w= ith remove and add).=C2=A0
- Now on the server, the corresponding SRV RR= (associated with the service instance) no longer exists (since it was remo= ved from the first update msg).
- I think in this case, we still want th= e server to consider the second SRP Update as valid.

So considering = the RRset for the service instance name being removed (for which we have &q= uot;Delete all RRsets from a name" with no follow-on "Add to an R= Rset" SRV RR):
- if SRV RR do exists on server, we require server t= o verify that it was added by same host and key.
- but if it does not ex= ist, the server would be ok with it (basically just ignore the delete of th= e non-existing RRset), and consider the SRP update msg valid.

Does i= t sound ok?

-------

I also found two small typos:

1) I= n section 2.3.1.1 (Service Discovery Instruction) last bullet point,
- .= .. is an "Delete an RR from ... -> is a "Delete an RR from
=
2) Right before section 6.2
... credentialsto to update ... -> cr= edentials to update

Thanks,
Abtin.

On Fri, Dec 18, 2020= at 3:01 PM Ted Lemon <mellon@fugue.= com> wrote:
On Dec 18, 2020, at 9:23 AM, K= angping Dong <wgt= dkp@google.com> wrote:
Sounds good, thanks! Looking forward = to the 07 draft!

Not sure if yo= u guys are on the mailing list, so FYI I have updated the document:

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-dnss= d-srp-07.html
<= br style=3D"color:rgb(0,0,0);font-family:Menlo-Regular">A diff from the previous version is= available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-dnssd-srp-07



--0000000000004dfc9a05b6ca75d2-- From nobody Sat Dec 19 04:16:09 2020 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 2DF623A1032 for ; Sat, 19 Dec 2020 04:16:07 -0800 (PST) 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.20150623.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 tED89dFItoXI for ; Sat, 19 Dec 2020 04:16:03 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 5819A3A1034 for ; Sat, 19 Dec 2020 04:16:03 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id d14so4659727qkc.13 for ; Sat, 19 Dec 2020 04:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XZVFSPU2goJtBw9ZR2TX1/K7n43WkmU6YN9ksZH5S6Q=; b=lz+fj0OoNzr1FvTHHgwSS0TMXpyDQyk8fBU6mLAtSQNUGZwYBkhFuEVVPMnekleOxe /tSVNR1eVVBHUAj+al7oB3dJXa9JQHvv3VmzN0ydoh9f7cFU33nqT4Dk0BnJiKqzcgWR vM7fGrHKQfk8r6CLyzlBG/EfSK7MNBRaAfeN3fzseiytS4RzOini5MG9Etgdh0Wa+kmH 19x3WLVRT5mfD6IvP5LpAc/QlY5xYqOc6r9p9QCXHhwsQNXpr5+Fmk6cplNdTCu8q/uV /pZgSrYyZCtdd3mR9dOZ8+E0XOHARsDke04zX9YXpyCjyQRJvvKzZVYYc8/gnZZv77Yx xoxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XZVFSPU2goJtBw9ZR2TX1/K7n43WkmU6YN9ksZH5S6Q=; b=RT/EKFokm1LmPrQ9L90iq0IdBy/uxaUf/Z/jMgNpvRFWiBMYcmeV8FlOq9iDgs4rPQ kAihs3ZHDhFUTzzBZE01flojwaAz3qQOUAs3oDEobr2RubVB0FP0BcGXCnEJHHV8m14X fqiUjT/Gww2gw3yv0+A2AxMVycI9rOIV1/+Vd05vrPep6bbxAglQoR8TthFtBdLL/s1Z +fFDLjK0xJwH4lXUs20UR7UmoEsZTNK9+hWcx8RsKtIoOeaIopZFv3jltrOfsyFiYKHk yQndR+QcR8Dz//npTtcwETeulp91COp6O3NhwOsQiBhHOIcjWzjlwNugROt2yjmbQZmi WBJA== X-Gm-Message-State: AOAM53229FlG7g749HAYvL9cjfOa8nrgutgmR8PJfIFaOE3Qt+8iUpzi ikNvqqG4Khozfx488JNxEH58Iw== X-Google-Smtp-Source: ABdhPJwxaJQ0Gx6z02MCCwsW1q1qiZh+8ThXneVNzh1099m+XNk7NuLs8eihYDA0Xu6zFh4yG+LYzg== X-Received: by 2002:a37:8b81:: with SMTP id n123mr9568256qkd.242.1608380162229; Sat, 19 Dec 2020 04:16:02 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id b78sm2756835qkg.29.2020.12.19.04.16.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 04:16:01 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4B8AF9E0-8342-4C32-A1A8-6934DA134FCF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sat, 19 Dec 2020 07:16:00 -0500 In-Reply-To: Cc: Kangping Dong , DNSSD , Jonathan Hui , Rongli Sun To: Abtin Keshavarzian References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 12:16:07 -0000 --Apple-Mail=_4B8AF9E0-8342-4C32-A1A8-6934DA134FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian = wrote: > Does it sound ok? Yes, that=E2=80=99s a great correction. Thanks! --Apple-Mail=_4B8AF9E0-8342-4C32-A1A8-6934DA134FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian <abtink@google.com> = wrote:
Does it sound ok?

Yes, = that=E2=80=99s a great correction. Thanks!

= --Apple-Mail=_4B8AF9E0-8342-4C32-A1A8-6934DA134FCF-- From nobody Sat Dec 19 04:17:38 2020 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 D6ED83A1036 for ; Sat, 19 Dec 2020 04:17:36 -0800 (PST) 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.20150623.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 iDbrYhC7hy53 for ; Sat, 19 Dec 2020 04:17:33 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 DE3EB3A104C for ; Sat, 19 Dec 2020 04:17:32 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id m23so4658418ioy.2 for ; Sat, 19 Dec 2020 04:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=e7E743ddwCNVhICVFktlRy2K0nM3hBPNwowExo2D0tU=; b=CxqyNJWh73hoFTlrLY10TFOhrhmIEaf0acKisEJbcedcDefo8vp5lX+BRkEA5+PW9g CIi+WSlooq6cT1lTh5wiEcNPExUjYy4wxaeCxYWRNZmP2FoYL+aLUDsrxSFhS+MoXGby CmnK320O1wXNa3qiriKhe8Yhxg0jF4VdAGoH3YjQa9IqR5MtQmW9PMKv6Ysbm9kK0ryn /8zIWsiVnhC+e4HYnCmwjX+aR+7gUzxuksl0HSBy4LUFsJI7EPut4xQsXtp4gLk6u7MP f9aWzXXI4wtLiLLnqJpSioZKFppjTI4RvhqwJ+7F+dTAxciqxIRfPJa3OvTWwHi65qT6 OXsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=e7E743ddwCNVhICVFktlRy2K0nM3hBPNwowExo2D0tU=; b=D72Y1zFQbh/WR3p9cBAjLi3wogZPUfnm0Nxq0ZNEUKTSIbtLVmz4vjFYAePiUtaKeb 96181j7v3DEcqj78jQ7xhA6BkbZbAX2F/ZC0Xr7ygK+B3hpehqG2IzMHnRBVvHaFkx0d xOcvXDz6z8Z9c0RLVx3QCucRh/3nD8kCdBcOHuAmy5RjUJGymchyQrN3cnj68dbcOeH5 EjycSlE1G3U/TAJdynwuPwMQ+4PM+a1lSxRQzQynbhz8kSHikMQYAdteio01mv+dEOxw CpatJPYyvKmezmRJ8vbr3wGuMZDiyrf/U9syR6bJwPwRvsxzW3Yk6wokEOT4do1MSa6Z Z7NA== X-Gm-Message-State: AOAM532jlp/94nqL8nmIQvwxp/fFy+wtbtJeMqG4QjWFZkhY0wtltMTL X/NMbdfiseXq+ofz9+UpY+tXuw== X-Google-Smtp-Source: ABdhPJxMYn3MZvV+mKh1BnCSAa1V7Uq6RGxvqjOqa4LKiwJPLoU72KIaqFtHgwRiT+/AaGq/22UcEw== X-Received: by 2002:a02:c8c7:: with SMTP id q7mr8155731jao.7.1608380251994; Sat, 19 Dec 2020 04:17:31 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 14sm8819535ilz.7.2020.12.19.04.17.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 04:17:31 -0800 (PST) From: Ted Lemon Message-Id: <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_64CB3FE6-7152-4209-8374-24038A2F1F01" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sat, 19 Dec 2020 07:17:29 -0500 In-Reply-To: Cc: Kangping Dong , DNSSD , Jonathan Hui , Rongli Sun To: Abtin Keshavarzian References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 12:17:37 -0000 --Apple-Mail=_64CB3FE6-7152-4209-8374-24038A2F1F01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Actually, on second thought, maybe the right thing to do is check for = the KEY RR and not the SRV RR. If the key matches, the delete is okay. = If there are no records on the name, the delete is okay. > On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian = wrote: >=20 > Does it sound ok? --Apple-Mail=_64CB3FE6-7152-4209-8374-24038A2F1F01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Actually, on second thought, maybe the right thing to do is = check for the KEY RR and not the SRV RR. If the key matches, the delete = is okay. If there are no records on the name, the delete is okay.

On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian <abtink@google.com> = wrote:

Does it sound ok?

= --Apple-Mail=_64CB3FE6-7152-4209-8374-24038A2F1F01-- From wgtdkp@google.com Thu Dec 17 20:03:16 2020 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 AE09D3A0EAF for ; Thu, 17 Dec 2020 20:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.256 X-Spam-Level: X-Spam-Status: No, score=-17.256 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.342, 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 aGKKCl-KBJoC for ; Thu, 17 Dec 2020 20:03:15 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 7991D3A0EFA for ; Thu, 17 Dec 2020 20:03:11 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id x2so738799ybt.11 for ; Thu, 17 Dec 2020 20:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zfHKWzuwtMJenIdUJC+ngFzsGMddGJ0FTnn7o6xqwkc=; b=g2bxDswbEXQOm9h6xfmfBW7ZVhAddlD2+8qMZUfroIYjtie6eNbF5SSOf9BJVzbMTw fkuxGxqCer2j+laxoZmiWqx9HBKaFjVKgYLueHJZk7gRaMfc5iTIp8f7px6lRFTKMFSX uj2RYwh3cS1SNlOqVuPRgf6u0Q1NWpi2lQ0dxvhswdc9Ywxcc0UcqN0sxJCtZrSOs50l o5z0qUkIfL/Uax1i8nVmt9qC2iPkTXlCVwEZZtUeH75yd0u0Lg5QKsX/VP/FL5Vy/Xqv Grr2uDYRaQk/W1X1iZMlD5fzKJ7TuBQmBQhJvGOPq6Pid7DMTl/fPiS2aasP86KJNQQ/ P9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zfHKWzuwtMJenIdUJC+ngFzsGMddGJ0FTnn7o6xqwkc=; b=GFBhCrjkdApLe2VAPXZHEl+D1e8hZXllZhq8FAEW+xWldf2fC79KM4ufQvhbPOPtek HthnB5urt/j1FqmpLZgF4/APgPubsgukEWuNb2ahfRGA+UVfp8YJa7KxekMm9SX3BAH8 UtxICGxJcqBolwBScS1YE+uweV589zXZITZdXnOhtKMPIDba5J7hRTyCpoSN3ThYjFiu dUuNsf4lijDamhBDoYk4rqvWx0ynMcgz5Sw9Ne7XUDJ/nngByGJJxX8aMAX2gz0RpInf G4h0ijUpfzpnkw1NgLqhRuyNmn+VgVu+/tgzHyN1pApLqt7mxM9a4pSudizBwNjDB/Tv cdLw== X-Gm-Message-State: AOAM531NAOZchN+jpOQfbIYY8iw/zPdlad2gAY7HwRUNaDBA1kVbtd5J dsmc5Ct7L6PrMFYLutXHH8vX+qEkiVaEYICs8ALymQ== X-Google-Smtp-Source: ABdhPJyVPqPrl0g2At6AUbAo+Lr2KK7DLwoI8IvxnfcYEVFhEssSsKxDINHKZfje31ljC6aAlnUbmlAaf7p4VHKag1o= X-Received: by 2002:a05:6902:706:: with SMTP id k6mr3865676ybt.232.1608264190318; Thu, 17 Dec 2020 20:03:10 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> In-Reply-To: <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> From: Kangping Dong Date: Fri, 18 Dec 2020 12:02:34 +0800 Message-ID: To: Ted Lemon Cc: Abtin Keshavarzian , dnssd@ietf.org, Jonathan Hui , Rongli Sun Content-Type: multipart/alternative; boundary="000000000000c535da05b6b52f2d" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 13:44:56 -0000 --000000000000c535da05b6b52f2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ted, I'd like to summary my understanding of what current SRP-draft-06 is doing/allowing: 1. We can add services separately. like, we can add "service-1" and in the first SRP update and "service-2" in the second SRP update. 2. We can only remove all the services together with its host because "exactly one Host Description Instruction" is a MUST for each SRP update= . But the spec seems, is not enforcing this behavior: > Therefore, SRP servers MAY remove all > service instances pointing to a host when a host is removed, even if > the SRP client doesn't remove them explicitly. > > If we cannot remove individual service without removing the host, should the "MAY" be a MUST? Otherwise, there may be no efficient way to clean up the service until the lease time expires. To remove a service registration, the SRP client retransmits its most > recent update with an Update Lease option that has a LEASE value of > zero. > > Does it remove only the services in my most recent update or all services I have ever registered? This is what I was confused about and thought we can remove individual service. As we cannot remove individual service, I think we don't need to retransmit the most recent update: It may be more efficient to always transmit a SRP update with only Host Description Instruction and zero lease time. Thoughts? For the current use model, I agree it will work for most cases and removing individual service may be rare (even there are, it can be done with a "removing all" and an add). So I don't have a strong opinion to support it. BRs, Kangping On Fri, Dec 18, 2020 at 10:07 AM Ted Lemon wrote: > On Dec 17, 2020, at 7:40 PM, Abtin Keshavarzian wrote= : > > - In "Service Description Instruction", we allow a "Delete all RRSet from > a name", with possibly no follow-up adds. > > > Yes. > > - When a service is being deleted, we can consider allowing KEY RR "Add t= o > an RRSet" for instance name to be optionally included, to have the server > keep the instance name reserved (if desired). Does it make sense? > > > We could allow this, but KEY RRs are large, so we might prefer not to. > > - In "Service Discovery Instruction" I think we need to allow delete as > well (I guess "Delete an RR from an RR set" for PTR RR)? > > > Yes, and the RR has to be pointing to a Service Description Instruction > which is also being deleted. > > - We continue to require SRP Update msg to always include exactly one > "Host Description". > > > Yes. > > Does this all sound good/reasonable? Anything I may have missed? > > > It sounds fine. I=E2=80=99m curious what others think about this. > > --000000000000c535da05b6b52f2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

I'd like to summary=C2=A0my= understanding of what current SRP-draft-06 is doing/allowing:
  • We can add services separately. like, we can add "service-1"= ; and in the first SRP update and "service-2" in the second SRP u= pdate.
  • We can only remove all the services together with its host b= ecause "exactly one Host Description Instruction" is a MUST for e= ach SRP update.
    • But the spec seems, is not enforcing this beh= avior:
    Therefore, SRP servers MAY remove al=
l
service instances pointing to a host when a host is removed, even if
the SRP client doesn't remove them explicitly.
    I= f we cannot remove individual service without removing the host, should the= "MAY" be a MUST?
    Otherwise, there may be no efficient = way to clean up the service until=C2=A0the lease time expires.
    To remove a service registration, the SR=
P client retransmits its most
recent update with an Update Lease option that has a LEASE value of
zero.
    Does it remove only the services in my most re= cent update or all services I have ever registered? This is what
    = I was confused about and thought we can remove individual service. As we ca= nnot remove individual=C2=A0service,
    I think we don't need to= retransmit the=C2=A0most recent update: It may be more efficient to always= transmit a
    SRP update with only Host Description Instruction and= zero lease time. Thoughts?

    For the current use mo= del, I agree it will work for most cases and removing individual service ma= y be rare
    (even there are, it can be done with a "removing a= ll" and an add). So I don't have a strong opinion to support it.

    BRs,
    Kangping

    On Fri, Dec 18, = 2020 at 10:07 AM Ted Lemon <mellon@f= ugue.com> wrote:
    On Dec 17, 2020, at 7:40 = PM, Abtin Keshavarzian <abtink@google.com> wrote:
    <= span style=3D"font-family:PalatinoLinotype-Roman">- In "Service Descri= ption Instruction", we allow a "Delete all RRSet from a name"= ;, with possibly no follow-up adds.=C2=A0

    <= /div>Yes.

    - When a service is being deleted, we can consider allowing K= EY RR "Add to an RRSet" for instance name to be optionally includ= ed, to have the server keep the instance name reserved (if desired).=C2=A0 = Does it make sense?

    We could allow t= his, but KEY RRs are large, so we might prefer not to.

    - In "Servi= ce Discovery Instruction" I think we need to allow delete as well (I g= uess "Delete an RR from an RR set" for PTR RR)?

    Yes, and the RR has to be pointing to a Service D= escription Instruction which is also being deleted.

    - We continue to re= quire SRP Update msg to always include exactly one "Host Description&q= uot;.=C2=A0

    Yes.

    Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 13:45:13 -0000 --000000000000b28ea405b6bddbfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds good, thanks! Looking forward to the 07 draft! BRs, Kangping On Fri, Dec 18, 2020 at 9:20 PM Ted Lemon wrote: > On Dec 17, 2020, at 11:02 PM, Kangping Dong wrote: > > I'd like to summary my understanding of what current SRP-draft-06 is > doing/allowing: > > 1. We can add services separately. like, we can add "service-1" and in > the first SRP update and "service-2" in the second SRP update. > 2. We can only remove all the services together with its host because > "exactly one Host Description Instruction" is a MUST for each SRP upda= te. > > But the spec seems, is not enforcing this behavior: > >> Therefore, SRP servers MAY remove all >> service instances pointing to a host when a host is removed, even if >> the SRP client doesn't remove them explicitly. >> >> If we cannot remove individual service without removing the host, should > the "MAY" be a MUST? > Otherwise, there may be no efficient way to clean up the service until th= e > lease time expires. > > > Yes, I think this is an oversight in the specification. What my > implementation actually does is to remove all the entries when we see a > =E2=80=9Clease 0=E2=80=9D update with a valid host record that=E2=80=99s = signed with the right key. > > To remove a service registration, the SRP client retransmits its most >> recent update with an Update Lease option that has a LEASE value of >> zero. >> >> Does it remove only the services in my most recent update or all service= s > I have ever registered? > > > My implementation does the latter. It tracks what services are registered > per host. > > This is what > I was confused about and thought we can remove individual service. As we > cannot remove individual service, > I think we don't need to retransmit the most recent update: It may be mor= e > efficient to always transmit a > SRP update with only Host Description Instruction and zero lease time. > Thoughts? > > > Yes. > > For the current use model, I agree it will work for most cases and > removing individual service may be rare > (even there are, it can be done with a "removing all" and an add). So I > don't have a strong opinion to support it. > > > I don=E2=80=99t think we really have enough data to say. In the interests= of being > general, I think it=E2=80=99s probably worth specifying how to remove ind= ividual > services. This is what I=E2=80=99d originally intended=E2=80=94I did the = =E2=80=9Clease time 0=E2=80=9D > hack because it was expedient, not because it was the right thing to do. > > I=E2=80=99ll spin a -07 later today if I have time that makes this change= and > addresses your other concerns from above, and then if you=E2=80=99re will= ing, you > guys can review my changes and see if they are sufficient. > > --000000000000b28ea405b6bddbfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Sounds good, thanks! Looking forward to the 07 draft!
    <= div>
    BRs,
    Kangping

    On Fri, Dec 18, 2020 at 9:2= 0 PM Ted Lemon <mellon@fugue.com= > wrote:
    On Dec 17, 2020, at 11:02 PM, Kangpin= g Dong <wgtdkp@go= ogle.com> wrote:
    I'd like to summary=C2=A0my understanding of what current SRP-dra= ft-06 is doing/allowing:
    1. We can add services separately. = like, we can add "service-1" and in the first SRP update and &quo= t;service-2" in the second SRP update.
    2. We can only remove all = the services together with its host because "exactly one Host Descript= ion Instruction" is a MUST for each SRP update.
    But the = spec seems, is not enforcing this behavior:
    Therefore, SRP servers MAY remove all
service instances pointing to a host when a host is removed, even if
the SRP client doesn't remove them explicitly.
    I= f we cannot remove individual service without removing the host, should the= "MAY" be a MUST?
    Otherwise, there may be no efficient = way to clean up the service until=C2=A0the lease time expires.
    <= /div>

    Yes, I think this is an oversight in= the specification. What my implementation actually does is to remove all t= he entries when we see a =E2=80=9Clease 0=E2=80=9D update with a valid host= record that=E2=80=99s signed with the right key.

    To remove a service registration, the SRP clien=
t retransmits its most
recent update with an Update Lease option that has a LEASE value of
zero.
    Does it remove only the services in my most re= cent update or all services I have ever registered?
    =

    My implementation does the latter. It tracks wh= at services are registered per host.

    This is what
    I was confused ab= out and thought we can remove individual service. As we cannot remove indiv= idual=C2=A0service,
    I think we don't need to retransmit the= =C2=A0most recent update: It may be more efficient to always transmit a
    SRP update with only Host Description Instruction and zero lease tim= e. Thoughts?

    Yes.
    <= div>
    For the c= urrent use model, I agree it will work for most cases and removing individu= al service may be rare
    (even there are, it can be done with a &qu= ot;removing all" and an add). So I don't have a strong opinion to = support it.

    I don=E2=80= =99t think we really have enough data to say. In the interests of being gen= eral, I think it=E2=80=99s probably worth specifying how to remove individu= al services. This is what I=E2=80=99d originally intended=E2=80=94I did the= =E2=80=9Clease time 0=E2=80=9D hack because it was expedient, not because = it was the right thing to do.

    I=E2=80=99ll spin a = -07 later today if I have time that makes this change and addresses your ot= her concerns from above, and then if you=E2=80=99re willing, you guys can r= eview my changes and see if they are sufficient.

    --000000000000b28ea405b6bddbfc-- From nobody Sat Dec 19 07:11:51 2020 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 962D93A0936 for ; Sat, 19 Dec 2020 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.256 X-Spam-Level: X-Spam-Status: No, score=-17.256 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.342, 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 WOfMKlg5qsLm for ; Sat, 19 Dec 2020 07:11:49 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 294963A091C for ; Sat, 19 Dec 2020 07:11:49 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id w135so4728713ybg.13 for ; Sat, 19 Dec 2020 07:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLF37zD0NDeHE++Q8VIEPGKYTUVZQiT/wFZc4NqPBAI=; b=TA099mTNp9N0TXs7npd6lwoz8ODS4ca80hfemyH2dUTa//94RsaF0+01/9ENyWp4HI 02gQ62/9HOyXGhqC3uKRZ2mlMyS1uMjFiNpDH/rBnRc6egMqiUI6Nd4+zMcMtw/xSKUD sHgxhWTxtS85eeFzSVTSpVgaoui75/EROk2RHUHTOIalczCHZZ83vr8w0OE57S8TSLQQ CzU0Ot2bH0bVS2cU6t2vOOyMZwNuk15Zk81pqNq3HHGroqWz/+RCScJlVpy7oei2/nNr +3KjDIWZSR071/AUyqPYNeHyYJWTd//HRUFbh9JvKeZapVxHHWVOD7qqxxJLesXbOJAJ 1kGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rLF37zD0NDeHE++Q8VIEPGKYTUVZQiT/wFZc4NqPBAI=; b=bY6N08PIPEkEiI0KfKznr+FX5WUNjZlX81aATW41IEd+hl4W/uoXFbA2J0ub/ijiev U5Yg1ritlWUhzMYADnf62v81i8ITSF1i/9m6CDs697V8XYWWJhaYzYecYZUC0X9cUJQT s//BD9bViFMYt6E/gsI1Lk2/Y3dUsyC7wAXUOGjTL6lapf9ENtOEPmB4OLZC8JDs60d8 /5EBQZKgwxXg8hD9S2k41gT8TulOthjCLFacvwAiw/mEnS5a2ZjxyuCItgNG2kMxShUc eJkXWCT1cGO6bucGvuQDN3VS95q0ZMNxdMFXoqtH1HJ1aVRzNpjEz+8el6iN3PeRMqSu EpPQ== X-Gm-Message-State: AOAM5319i3KIKkuQvE7vSrVYKQgkHnvq7aQLf13Jt739PWwwL2ylCY1v YlzZOqaGdW7w8sJLwm27Az0jzZVKuIpbJpjE05O3/Q== X-Google-Smtp-Source: ABdhPJydcuBn6gMMlhA8nUrjH/qkHLFHS0zgL9pkvytA37MuMV0obSvBR61Ef2lcVVy/F6/oS89ehPRMsm91xyWqOyk= X-Received: by 2002:a25:e048:: with SMTP id x69mr12744907ybg.353.1608390708079; Sat, 19 Dec 2020 07:11:48 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> From: Kangping Dong Date: Sat, 19 Dec 2020 23:11:12 +0800 Message-ID: To: Ted Lemon Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun Content-Type: multipart/alternative; boundary="000000000000d1112a05b6d2a48e" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 15:11:51 -0000 --000000000000d1112a05b6d2a48e Content-Type: text/plain; charset="UTF-8" Hi Ted, Thanks for creating the 07 draft so quickly! The change overall looks good to me and I agree we should check the KEY RR rather than the SRV RR. I have some questions when reading the related sections: 1. in 2.2.5.5.2. Removing some published services , we have: > The second alternative is to send a normal SRP update, but as in the first > alternative, including a Service Discovery Instruction and a Service Description that > *delete* the service being removed. Should the "*delete*" be "*replace*"? 2. What's the use case of supporting multiple TXT RRs? in section *2.3.1.2. Service Description Instruction *, we have: > zero or more "Add to an RRset" TXT RRs, > Are there real use cases that we need more than one TXT RRs? What is the expected behavior for the advertising proxy to publish this service with multiple TXT RRs? (I think DNS-SD requires a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated to form a new TXT RR? If there is no such use case, should we require a single TXT RR? It will be easier to implement on both client and server side and consistent with DNS-SD. thoughts? BRs, Kangping On Sat, Dec 19, 2020 at 8:17 PM Ted Lemon wrote: > Actually, on second thought, maybe the right thing to do is check for the > KEY RR and not the SRV RR. If the key matches, the delete is okay. If there > are no records on the name, the delete is okay. > > On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian > wrote: > > Does it sound ok? > > > --000000000000d1112a05b6d2a48e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Ted,

    Thanks for creating = the 07 draft so quickly! The change overall looks good to me and I agree we= should check the KEY RR rather than the SRV RR.

    I= have some questions when reading the related sections:

    The second alternative is to send a normal SRP update, but as i= n the first alternative,=C2=A0
    including a Service Discovery Ins= truction and a Service Description that delete the service be= ing removed.
    Should the "delete&= quot; be "replace"?=C2=A0

    = 2. What's the use case of supporting multiple TXT RRs?
    zero or more "Add to an RRset" TXT RRs,
    = =C2=A0
    Are there real use cases that we need more than one TXT RR= s? What is the expected behavior
    for the advertising proxy to pub= lish this service with multiple TXT RRs? (I think DNS-SD requires
    a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated t= o form a new TXT RR?
    If there is no such use case, should we requ= ire a single TXT RR? It will be easier to implement on both
    clien= t and server side and consistent with DNS-SD. thoughts?


    BRs,
    Kangping

    On Sat, Dec 19, 2020 at 8= :17 PM Ted Lemon <mellon@fugue.com> wrote:
    Actually, on second thought, maybe = the right thing to do is check for the KEY RR and not the SRV RR. If the ke= y matches, the delete is okay. If there are no records on the name, the del= ete is okay.

    --000000000000d1112a05b6d2a48e-- From nobody Sat Dec 19 07:34:48 2020 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 AF1E33A09E8 for ; Sat, 19 Dec 2020 07:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.256 X-Spam-Level: X-Spam-Status: No, score=-17.256 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.342, 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 Zk0vbRZNmw84 for ; Sat, 19 Dec 2020 07:34:45 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 E842A3A09C0 for ; Sat, 19 Dec 2020 07:34:44 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id v67so4837457ybi.1 for ; Sat, 19 Dec 2020 07:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WYbGAVKv2uWcLhzoLA3McadtJjvyJChT808MRBYElzM=; b=r0mOAx9g474biW2qZzNCPzzpYm0kChhDhtZDgu5ngddB97Z8ze4LCllIV9QkjmBEEK UNYdgbFzv4nS4eNXvau4NHYMoGlo+F8wWWx5HOz/Km4BRlIMgWXu01jTuFpT7ovYr/TU tUPKgK4qCU2RsZ0St8chJCGCjB/KodA06V06NXblWaXsSgP8x7gbqLzpDnl/6llvHP7a OM1meLFNb4HPCULUffk9ZRHjn3hEK0WyvEQdrxfhx2b0vdBnPRd4IzgdQY3asV/eoPAb Ptyeg0FGpECFHMZmPlp4FYZee2oGq9kUa48CCNqzEUqcV89aLRYvO7ayJypeIaGWty9u GODA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WYbGAVKv2uWcLhzoLA3McadtJjvyJChT808MRBYElzM=; b=lcjo4RErFe/N5GnsjdIWaJGpy2sXu8dABhmuqe3MVL4Q+d3R+2JTF8/GaaHgiyWZbQ Q8Fzf093fMP4KgjZHRikfDDgTXqjTJkdBaX5c/6oG/WPF0/mO4Pya9unaBxVp9pevuSF Uyx9tAU4ou1g0P9YoSX8HeXudDx7TrwUe7+e/zI29q0MazPXnTy/xKcu4qhhLfSa+2O5 AygrP+f6SAG+W6lggD+FyF4kLVwevDC7xgi5+fcMV3wGYZbiJ30crnlLM8eHQrkvG6bs 4maD3KMMdORLH4FsQTqGbjgUjzgnyF5elmimk18X+98yJ0zqQoJq2A2f+nmFrgtwOLKX Fr+A== X-Gm-Message-State: AOAM530CXDOV0JRb6p6YJpzT6S0uO7hbfKP7KOjFOXwo/9yVdBdrB7lo 6jSOG/x1LuBPI1LE8jU6qhaDnrMbRJyCEAXSXMqg6g== X-Google-Smtp-Source: ABdhPJzmas+LBvSd8a8JwJBBXJa/XbdHy0ko7+yt2vF5U5P4LpITG/y6ijZTri5yoB0fH+LO230ggrBHwJDcNC3f95A= X-Received: by 2002:a25:d753:: with SMTP id o80mr11750732ybg.169.1608392083660; Sat, 19 Dec 2020 07:34:43 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: From: Kangping Dong Date: Sat, 19 Dec 2020 23:34:07 +0800 Message-ID: To: Ted Lemon Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun Content-Type: multipart/alternative; boundary="000000000000cebfe805b6d2f6fc" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 15:34:47 -0000 --000000000000cebfe805b6d2f6fc Content-Type: text/plain; charset="UTF-8" Sorry, another question :) In section 2.3.1. Validation of Adds , we have: SRP Updates consist of a set of *instructions* that together add or remove > one or more services. Each instruction consists either of a single add, a single delete, or a > delete optionally followed by an add. When an instruction contains a delete and an add, the delete MUST precede > the add. What is the use case of the "single add"? To my understanding, the "delete + add" pattern is for resetting the service to our current SRP update. So the "single add" pattern is for updating the existing service, for example, adding one more AAAA RR, right? I think, for most SRP clients, it will be more convenient for them to track all IP Addresses and always update with the whole IP addresses list rather than depending on this "update" model and register the addresses separately. The server, I think can also be simplified. Thoughts? Another issue with this sentence is that, the Service & Host Description Invalidation requires: > exactly one "Delete all RRsets from a name" RR, Seems disallowing the "single add" pattern? BRs, Kangping On Sat, Dec 19, 2020 at 11:11 PM Kangping Dong wrote: > Hi Ted, > > Thanks for creating the 07 draft so quickly! The change overall looks good > to me and I agree we should check the KEY RR rather than the SRV RR. > > I have some questions when reading the related sections: > > 1. in 2.2.5.5.2. Removing some published services > , > we have: > >> The second alternative is to send a normal SRP update, but as in the >> first alternative, > > including a Service Discovery Instruction and a Service Description that >> *delete* the service being removed. > > Should the "*delete*" be "*replace*"? > > 2. What's the use case of supporting multiple TXT RRs? > in section *2.3.1.2. Service Description Instruction > *, > we have: > >> zero or more "Add to an RRset" TXT RRs, >> > > Are there real use cases that we need more than one TXT RRs? What is the > expected behavior > for the advertising proxy to publish this service with multiple TXT RRs? > (I think DNS-SD requires > a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated > to form a new TXT RR? > If there is no such use case, should we require a single TXT RR? It will > be easier to implement on both > client and server side and consistent with DNS-SD. thoughts? > > > BRs, > Kangping > > On Sat, Dec 19, 2020 at 8:17 PM Ted Lemon wrote: > >> Actually, on second thought, maybe the right thing to do is check for the >> KEY RR and not the SRV RR. If the key matches, the delete is okay. If there >> are no records on the name, the delete is okay. >> >> On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian >> wrote: >> >> Does it sound ok? >> >> >> --000000000000cebfe805b6d2f6fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Sorry, another question :)

    =C2=A0SRP Updates consist of a set of=C2=A0instructio= ns=C2=A0that together add or remove one or more servi= ces.=C2=A0
    Each instruction consists either of a single add, a s= ingle delete, or a delete optionally followed by an add.=C2=A0
    W= hen an instruction contains a delete and an add, the delete MUST precede th= e add.

    What is the use case of the &= quot;single add"? To my understanding,=C2=A0 the "delete + add&qu= ot; pattern is
    for resetting the service to our current SRP updat= e. So the "single add" pattern is for updating
    the exis= ting=C2=A0service, for example,=C2=A0adding one more AAAA RR, right?
    <= div>
    I think, for most SRP clients, it will be more convenien= t=C2=A0for them to track all IP Addresses and
    always update with = the whole IP addresses list rather than depending on this "update"= ; model
    and register the addresses separately. The server, I thin= k can also be simplified. Thoughts?

    Another issue = with this sentence=C2=A0is that, the Service & Host Description Invalid= ation requires:
    exactly one "Delete all RRsets from a name" RR,
    Seems disallowing the "single add" pattern?= =C2=A0

    BRs,
    Kangping

    On Sat, Dec 19= , 2020 at 11:11 PM Kangping Dong <w= gtdkp@google.com> wrote:
    Hi Ted,

    Than= ks for creating the 07 draft so quickly! The change overall looks good to m= e and I agree we should check the KEY RR rather than the SRV RR.
    =
    I have some questions when reading the related sections:

    The second alternative is to = send a normal SRP update, but as in the first alternative,=C2=A0
    including a Service Discovery Instruction and a Service Description that <= i>delete the service being removed.
    Shou= ld the "delete" be "replace"= ;?=C2=A0

    2. What's the use case of supporting = multiple TXT RRs?
    in section 2.3.1.2. Service Description Instruction, we have:<= /div>
    zero or more "A= dd to an RRset" TXT RRs,
    =C2=A0
    Are the= re real use cases that we need more than one TXT RRs? What is the expected = behavior
    for the advertising proxy to publish this service with m= ultiple TXT RRs? (I think DNS-SD requires
    a single TXT RR, is it = correct?) Should multiple TXT RRs be concatenated to form a new TXT RR?
    If there is no such use case, should we require a single TXT RR? It = will be easier to implement on both
    client and server side and co= nsistent with DNS-SD. thoughts?


    BRs= ,
    Kangping

    On Sat, Dec 19, 2020 at 8:17 PM Ted Lemon <mellon@fugue.com>= wrote:
    Act= ually, on second thought, maybe the right thing to do is check for the KEY = RR and not the SRV RR. If the key matches, the delete is okay. If there are= no records on the name, the delete is okay.

    On Dec 19, 2020, at 12:25 AM, Abtin Keshavarzian <abtink@google.com> w= rote:

    Does it= sound ok?

    --000000000000cebfe805b6d2f6fc-- From nobody Sat Dec 19 08:06:02 2020 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 C10D23A0AE5 for ; Sat, 19 Dec 2020 08:06:00 -0800 (PST) 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 PCZidFY9Agf2 for ; Sat, 19 Dec 2020 08:05:58 -0800 (PST) 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 073F03A0AE1 for ; Sat, 19 Dec 2020 08:05:58 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id q25so4920376otn.10 for ; Sat, 19 Dec 2020 08:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZPyashs4Q0dHh+kqQFai2gSFowDA/OX4Pc/jQlvNJlE=; b=k6QdgI2icvwnIpewdsVaLbT/tFxcKciRfOKaweLR8uITIywNRhJ9cM9yqenuw5X0Uj rTjn6+dgWFS9T5lU5pQWr2BnUlIYbXqky7RTkr3IzgEw91CIqH9Jo7lqMWme3WzTFlh5 QoFFywbylwq8D8QdWMBIzChaKS/wTKBLmfcCWl1s1dyJzV8VKlKSiYnCB9f/+PCT3sRD S2BlRE1RZNyLHoN11Oorwp+tzIc6z5OrNfPvfFUgKS/LwQ5WPTp9cVI8lpcc3Yj7+xgh Uqj9Hfu+chW7SJ4NDgRXOCy+TTKjjBDq+y01Bb3XVRiswZpZcS59BVDqJ9FUCikM8ADr GLTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZPyashs4Q0dHh+kqQFai2gSFowDA/OX4Pc/jQlvNJlE=; b=miSkM8GlKm8UWVaWIz5rN+BZIwq0JOk3o2k0ar6b6QLkR3HcbQCx5xnT4//ydvDeN8 GEJ/OR3/bhbrQ9QV1Lx9l0o1Izb52z1TLGWthzhiB0ppzN5TbfuuaydnJAYkgKvgyOG/ mXqdKwp+PvMDPnfTv/98roIQ9d40C5kl1ddFOFJ9drwJAJaGuB/1zzRReeWM4InKwlKn tEYhjGfk5SHqvDOX5mjA77wXjLAlED1FIHiyTKILwPuGcQDL3n2Aq+2+ZiS7BxJiiIkY +6cFBjf5mVuCg5CZ5oKQrVeEJ+/3K6DF+Ce4EiVvtq743AvNsr7D17CfCa7lMIopZbfC EtJw== X-Gm-Message-State: AOAM530u23CWatJTGNcOY956jhuULmJoMXHZeDYNn82azGkiANDN1WnW fiqavBdXwETZ56ms5+0LKDlyiBorM66nSLu9H4eIxQ== X-Google-Smtp-Source: ABdhPJy5kPICKP38m8ya//H4T1yZJYQ/EjrsZgOBw1fg9IN63F0BPrm13Q65vQ/daHQ90yKjRopRYjKhsoqrZLNIdiY= X-Received: by 2002:a05:6830:204b:: with SMTP id f11mr6362969otp.372.1608393956990; Sat, 19 Dec 2020 08:05:56 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: From: Jonathan Hui Date: Sat, 19 Dec 2020 08:05:46 -0800 Message-ID: To: Kangping Dong Cc: Ted Lemon , Abtin Keshavarzian , DNSSD , Rongli Sun Content-Type: multipart/alternative; boundary="00000000000077810705b6d366a5" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 16:06:01 -0000 --00000000000077810705b6d366a5 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 19, 2020 at 7:34 AM Kangping Dong wrote: > > In section 2.3.1. Validation of Adds > , > we have: > > SRP Updates consist of a set of *instructions* that together add or >> remove one or more services. > > Each instruction consists either of a single add, a single delete, or a >> delete optionally followed by an add. > > When an instruction contains a delete and an add, the delete MUST precede >> the add. > > > What is the use case of the "single add"? To my understanding, the > "delete + add" pattern is > for resetting the service to our current SRP update. So the "single add" > pattern is for updating > the existing service, for example, adding one more AAAA RR, right? > > I think, for most SRP clients, it will be more convenient for them to > track all IP Addresses and > always update with the whole IP addresses list rather than depending on > this "update" model > and register the addresses separately. The server, I think can also be > simplified. Thoughts? > > Another issue with this sentence is that, the Service & Host Description > Invalidation requires: > >> exactly one "Delete all RRsets from a name" RR, > > Seems disallowing the "single add" pattern? > I believe the "single add" refers to a given instruction in the SRP Update. Section 2.3.1.1 Service Discovery Instruction allows exactly one "Add to an RRSet". Maybe the "Validation of Adds" section name should be updated given that the draft now supports "remove-only" instructions? -- Jonathan Hui --00000000000077810705b6d366a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Sat, Dec 19, 2020 at 7:34 AM Kangping = Dong <wgtdkp@google.com> wro= te:


    =C2=A0SRP Updates cons= ist of a set of=C2=A0instructions= Each instruction consists either of a single add, a single delete, or a del= ete optionally followed by an add.=C2=A0
    When an instruction con= tains a delete and an add, the delete MUST precede the add.

    What is the use case of the "single add"?= To my understanding,=C2=A0 the "delete + add" pattern is
    for resetting the service to our current SRP update. So the "single= add" pattern is for updating
    the existing=C2=A0service, for= example,=C2=A0adding one more AAAA RR, right?

    I t= hink, for most SRP clients, it will be more convenient=C2=A0for them to tra= ck all IP Addresses and
    always update with the whole IP addresses= list rather than depending on this "update" model
    and = register the addresses separately. The server, I think can also be simplifi= ed. Thoughts?

    Another issue with this sentence=C2= =A0is that, the Service & Host Description Invalidation requires:
    =
    exactly = one "Delete all RRsets from a name" RR,
    S= eems disallowing the "single add" pattern?=C2=A0

    I believe the "single add" refers to a giv= en instruction in the SRP Update. Section 2.3.1.1 Service Discovery Instruc= tion allows exactly one "Add to an RRSet".

    Maybe the "Validation of Adds" section name should be updated gi= ven that the draft now supports "remove-only" instructions?
    =

    --
    Jonathan Hui

    --00000000000077810705b6d366a5-- From nobody Sat Dec 19 08:08:00 2020 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 E696C3A0B06 for ; Sat, 19 Dec 2020 08:07:57 -0800 (PST) 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 yKWpZHGVw6lr for ; Sat, 19 Dec 2020 08:07:56 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 BF9D13A0B02 for ; Sat, 19 Dec 2020 08:07:56 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id x13so6487388oic.5 for ; Sat, 19 Dec 2020 08:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FDZoOSagD6//A6NFMTIy0Hw7BLS7t5XbY7tGO8hkei0=; b=vcFX/J7noeJByILYgaeU6OoqLymck7M2vgHr2LK/QvVUvsm0uyOYlIxCPi68Ym8j1K Nf/ANynbHxb9afVyUfLgy3f5rRTQYT/ERlUO5kxpjZQAwuMs/qyrK19kOxS1ap10Adt+ C7H79bbSI7jfFyk2r9U6yHQoxojzWHu1Eoj2YByzaNLhJtXt9aN9KghG/HAm4xZ46yBg htyPhiWJFirmvRrQbniBxhy7l4FQ+UhogPSEko8avPFfJXjIIrl4FLGsVBxraCi+dtVD FUuPIAmJHo4Jv1r+xA/GAIw5ndIAUeyJRjC85nHP0f3/owvIdbsaeb70BR6i0rbMB4fW AcSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FDZoOSagD6//A6NFMTIy0Hw7BLS7t5XbY7tGO8hkei0=; b=QLcmP/oIQX/INhJjHb8nDEYjnAyFwdNn6v2E8Oq2lClTz/5SFYQkGIkeZoqCyEO+fX pmHnk/4d05S/ien97e4SIh6m5pbYe825pGZ8yve32eX2MbRW0VIR52VfK+oDuqHqGWko JALJsWV00aG81DR6X9m2QXDdLFjAGdjKEwnl8pBIj91zXlACvCaMsluWV6W4UiKB38Nm tljerkvc6qVrVePmagvtvqvGhYnlD9Du9eyIzlDJ1a6B3wHMKlQE6uUxk0/gjVgdejth OqrF8Lzrs7XKb12Te7mQdvimxJ7DpT6Gk0Nq5A6KwUNcM3QnKzq++9Ugv/pkD6bnsN5Z brEA== X-Gm-Message-State: AOAM530kc4JU5vlaFQgy0f3iKyM5uRKq8zvple6Ra8YxMnpcv57lcZ+X dS8IpMMOGNmGOVGu6d53SsjTgK36NthPDa5TISBaNw== X-Google-Smtp-Source: ABdhPJxgjxpe+ejZqDQg66UhBGDImf5+KPw8PBCy18ycFWe2yl/Irm3PkX1nMaahlQdlbZxJFSuZHZnKLf9rq67XNNU= X-Received: by 2002:aca:53d2:: with SMTP id h201mr6205210oib.168.1608394075842; Sat, 19 Dec 2020 08:07:55 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> From: Jonathan Hui Date: Sat, 19 Dec 2020 08:07:44 -0800 Message-ID: To: Ted Lemon Cc: Abtin Keshavarzian , Kangping Dong , DNSSD , Rongli Sun Content-Type: multipart/alternative; boundary="0000000000008d1f1f05b6d36dc9" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 16:07:58 -0000 --0000000000008d1f1f05b6d36dc9 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 19, 2020 at 4:17 AM Ted Lemon wrote: > Actually, on second thought, maybe the right thing to do is check for the > KEY RR and not the SRV RR. If the key matches, the delete is okay. If there > are no records on the name, the delete is okay. > I agree on checking for the KEY RR. -- Jonathan Hui --0000000000008d1f1f05b6d36dc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    <= /div>
    On Sat, Dec 19, 2020 at 4:17 AM Ted Lemon <mellon@fugue.com> wrote:
    Actually, on second thought, maybe the right thing to do is check for th= e KEY RR and not the SRV RR. If the key matches, the delete is okay. If the= re are no records on the name, the delete is okay.
    <= br>
    I agree on checking for the KEY RR.

    = --
    Jonathan Hui

    --0000000000008d1f1f05b6d36dc9-- From nobody Sat Dec 19 08:14:51 2020 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 C497E3A0B08 for ; Sat, 19 Dec 2020 08:14:49 -0800 (PST) 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 nzgO0OSsWTOr for ; Sat, 19 Dec 2020 08:14:48 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 268E63A0B06 for ; Sat, 19 Dec 2020 08:14:48 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id h18so4918867otq.12 for ; Sat, 19 Dec 2020 08:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KijqkelYSAuoUsjwzQvFdf4oGyYv8MrXe5YnijwoRSQ=; b=hoiF3+Il6dGHxqEyRGrNuB4n+XnsQuuOV/twHFeiABZAV+KypAjEdtjfH5W9beYGwx h6KC6jIzj+0MNa9xX5iM2Wmj57EWGpdYC9EzjxdF1hoFj8VXiM2/k/Ls7pt9Lg+67/TO MvC0qBLXDQ+xY7F/NCO/Imd+OsRC+By61EZ0reHl2u2Ao3ohDGTiElhQN8+kWU7CN4O8 OeNPa30Q2BqelBZZe9AHLJbbPh8TxN2hPalJqGiY9Rw8E/2vW329k42tzaFOwb0aVjYl FSGhSTuUAVWmj5Psnxv6E0JT0UUj8Qzthv9mwYQ4NUe/zTKXAGiY3OcQ+mfaaeOyfO9Z tvjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KijqkelYSAuoUsjwzQvFdf4oGyYv8MrXe5YnijwoRSQ=; b=si6+W6y+5H42VH+jfsu6qlrVZyi+Zq5O1QPBJj4VdtA9PIw+6J+djjZO7BqlWMXX6b BicbN5OONmg3uiuamm9GJ+kRiXwLGNrRA3X/Y+QrKGLDHRyf27hxdjZ4BKHYy8yc7UZN lRTNGFau7zZH2r4qhN60Z/CAKI48jdIy4nZrVw92AoComuDDOB1iaPVAawL5dRCk3TUH TilNiMYwWmzrUbc80+NQEB2zu0IdwsBFwBpeHb/gyLkxdZGlCd4bLV939+jZBwigTBwC vAUQAZUYLZEAzr+uuqt62RC4azuwfKgA2dlFjZJklflxFbRGz9L0b9VRA9zPD0VgncOu XRSQ== X-Gm-Message-State: AOAM533nNpCMVD4agoqQB7afHfZG92hqo2+TWEsKDvlERxWON64Zsk/Y nqKeUtvzLGWP3xPKsjJ/xpyloBPV08V5cuUysBI0+Q== X-Google-Smtp-Source: ABdhPJwwEjQNVUmMstocwGy0oG4wTNbWjOpPJluYyG6rjWlOngBqVqJLSSPbeJn4e9uV800XKhhSuDHFu4IoeyIs43c= X-Received: by 2002:a05:6830:160f:: with SMTP id g15mr6757735otr.129.1608394487144; Sat, 19 Dec 2020 08:14:47 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: From: Jonathan Hui Date: Sat, 19 Dec 2020 08:14:36 -0800 Message-ID: To: Kangping Dong Cc: Ted Lemon , Abtin Keshavarzian , DNSSD , Rongli Sun Content-Type: multipart/alternative; boundary="00000000000011125005b6d38628" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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, 19 Dec 2020 16:14:50 -0000 --00000000000011125005b6d38628 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong wrote: > > 2. What's the use case of supporting multiple TXT RRs? > in section *2.3.1.2. Service Description Instruction > *, > we have: > >> zero or more "Add to an RRset" TXT RRs, >> > > Are there real use cases that we need more than one TXT RRs? What is the > expected behavior > for the advertising proxy to publish this service with multiple TXT RRs? > (I think DNS-SD requires > a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated > to form a new TXT RR? > If there is no such use case, should we require a single TXT RR? It will > be easier to implement on both > client and server side and consistent with DNS-SD. thoughts? > RFC 6763 Section 6.8 Service Instances with MultipleTXT Records discusses this. However, the end of the referenced section also states: Future protocol designs should not follow this bad example by mimicking this inadequacy of the LPR printing protocol. So I guess the question is whether we can/should mandate this future going forward in SRP? -- Jonathan Hui --00000000000011125005b6d38628 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    <= /div>
    On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong <wgtdkp@google.com> wrote:

    <= div>2. What's the use case of supporting multiple TXT RRs?
    zero or more "Add to an RRset" TXT RRs,<= br>
    =C2=A0
    Are there real use cases that we need= more than one TXT RRs? What is the expected behavior
    for the adv= ertising proxy to publish this service with multiple TXT RRs? (I think DNS-= SD requires
    a single TXT RR, is it correct?) Should multiple TXT = RRs be concatenated to form a new TXT RR?
    If there is no such use= case, should we require a single TXT RR? It will be easier to implement on= both
    client and server side and consistent with DNS-SD. thoughts= ?

    RFC 6763 Section 6.8 Service Instances with = MultipleTXT Records=C2=A0discusses this. However, the end of the refere= nced section also states:

    =C2=A0 =C2=A0Future protocol designs should not follow this bad=C2=A0 =C2=A0example by mimicking this inadequac= y of the LPR printing protocol.

    So I guess the qu= estion=C2=A0is whether we can/should mandate this future going forward in S= RP?

    --
    Jonathan Hui

    =
    --00000000000011125005b6d38628-- From nobody Sat Dec 19 21:51:57 2020 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 80C1E3A0ACB for ; Sat, 19 Dec 2020 21:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.256 X-Spam-Level: X-Spam-Status: No, score=-17.256 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.342, 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 OrUgqNHHi13h for ; Sat, 19 Dec 2020 21:51:53 -0800 (PST) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 B1FAC3A0AC8 for ; Sat, 19 Dec 2020 21:51:53 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id w135so5883550ybg.13 for ; Sat, 19 Dec 2020 21:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3fuycAhubvv0P112UEk9IT1bywcR/Oa+6QAv2vqlrZ0=; b=dBfsccLCuRYpBAd9XA2Zhtvgbdrx5uIq2E4XwX0nrZebk86FxWgJNMd3zAOEH6vmYc D0zwSr9YsivXkHp52W7Wp43Uw51zWfWji5ekLoB4rG5v0KDhCE7qs/b+LCRBXjw4dXvz mwTpyO1oeuluSZvve0H4+u3g5UoVtJz6s1hUi5zn8KvZEuNcPDd0jGGQJbMhm1yfRobi LhfVy2sn0WI+SeXt8VjXo678mRkvlKRM1v2CoZF4tpa+Q7keYq2nBNZ2l6rJlMR2Fzdg l1kMLN90T8aGOsVoqsotlJtbC6yG8LPoGfRHz6s+3//pcUurPXittIeDIUIDAUEksXaS VYqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3fuycAhubvv0P112UEk9IT1bywcR/Oa+6QAv2vqlrZ0=; b=pPa4tnQ4d/4YxmOpogQmKSx+M1ORbQg7K4o2eHgalfvxQtdlt9Jd6YpxXAdma2xmR7 jJZ8wY/eibpJk1CripmL9JP4fUKLKlISxGz7JA/ZsXgzdDwEPYdrt+qGmJ2K93B3B3i3 6nr5xwMF1DEBDlquO+/xLVIateggQJJ+ck+DeW6zkb+Uzv9YgwobKiXDAdFR6KHieRN5 saOVEXPCGWbYvAmtrBSGzhztyqk4is3PKAZKST4dovfqmtEf68qhE/fq1i45IqgT3fXZ CZchSrPHs+Sw/t/hRc3Fuzd1fEPW+6ejdx556UIR60eSwsZJQF3tgrqOlhXq7T79NBe/ L12w== X-Gm-Message-State: AOAM530wU4qc6uwEdfDP/aYAu0zveeSB6HgZwgynwDkx36Z57cs+jEiX /eUW1QU4dKhmo0C3oa4SPvjljT8jgG22cTz2K9Ew/A== X-Google-Smtp-Source: ABdhPJxlSf3sOwtKGFAqwHn7sYOCaW8F63qPdL7+BL15fgGW0hKWgwz2xcIogqVXAV0ooszvhItaw6Y5oFHIj+tn+cs= X-Received: by 2002:a05:6902:706:: with SMTP id k6mr16414031ybt.232.1608443512789; Sat, 19 Dec 2020 21:51:52 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: From: Kangping Dong Date: Sun, 20 Dec 2020 13:51:16 +0800 Message-ID: To: Jonathan Hui Cc: Ted Lemon , Abtin Keshavarzian , DNSSD , Rongli Sun Content-Type: multipart/alternative; boundary="00000000000038f65305b6def0ac" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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: Sun, 20 Dec 2020 05:51:56 -0000 --00000000000038f65305b6def0ac Content-Type: text/plain; charset="UTF-8" > > RFC 6763 Section 6.8 Service Instances with MultipleTXT Records > discusses this. > However, the end of the referenced section also states: > > Future protocol designs should not follow this bad > example by mimicking this inadequacy of the LPR printing protocol. > > Thanks Jonathan, I missed that section. So I guess the question is whether we can/should mandate this future going > forward in SRP? > Exactly. I would prefer we explicitly disallow multiple TXT records for SRP. BRs, Kangping On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui wrote: > > On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong wrote: > >> >> 2. What's the use case of supporting multiple TXT RRs? >> in section *2.3.1.2. Service Description Instruction >> *, >> we have: >> >>> zero or more "Add to an RRset" TXT RRs, >>> >> >> Are there real use cases that we need more than one TXT RRs? What is the >> expected behavior >> for the advertising proxy to publish this service with multiple TXT RRs? >> (I think DNS-SD requires >> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated >> to form a new TXT RR? >> If there is no such use case, should we require a single TXT RR? It will >> be easier to implement on both >> client and server side and consistent with DNS-SD. thoughts? >> > > RFC 6763 Section 6.8 Service Instances with MultipleTXT Records > discusses this. > However, the end of the referenced section also states: > > Future protocol designs should not follow this bad > example by mimicking this inadequacy of the LPR printing protocol. > > So I guess the question is whether we can/should mandate this future going > forward in SRP? > > -- > Jonathan Hui > > --00000000000038f65305b6def0ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    = RFC 6763 Section 6.8 Service Instances with MultipleTXT Records=C2=A0di= scusses this. However, the end of the referenced section also states:
    =

    =C2=A0 =C2=A0Future protocol d= esigns should not follow this bad
    =C2= =A0 =C2=A0example by mimicking this inadequacy of the LPR printing protocol= .

    Thanks Jonathan, I missed that sec= tion.=C2=A0

    So I guess the question=C2=A0is whether we can/should mandate this f= uture going forward in SRP?
    Exactly. I would prefer we= explicitly disallow multiple TXT records for SRP.=C2=A0

    BRs,
    Kangping

    On Sun, Dec 20, 2020 at 12:14 AM Jonath= an Hui <jonhui@google.com> w= rote:

    <= /div>
    On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong <wgtdkp@google.com> = wrote:

    2. What's the use case of supporting multi= ple TXT RRs?
    in section 2.3.1.2. Service Description Instruction, we have:
    zero or more "Add t= o an RRset" TXT RRs,
    =C2=A0
    Are there r= eal use cases that we need more than one TXT RRs? What is the expected beha= vior
    for the advertising proxy to publish this service with multi= ple TXT RRs? (I think DNS-SD requires
    a single TXT RR, is it corr= ect?) Should multiple TXT RRs be concatenated to form a new TXT RR?
    If there is no such use case, should we require a single TXT RR? It will= be easier to implement on both
    client and server side and consis= tent with DNS-SD. thoughts?

    = RFC 6763 Section 6.8 Service Instances with MultipleTXT Records=C2=A0di= scusses this. However, the end of the referenced section also states:
    =

    =C2=A0 =C2=A0Future protocol d= esigns should not follow this bad
    =C2= =A0 =C2=A0example by mimicking this inadequacy of the LPR printing protocol= .

    So I guess the question=C2=A0is whether we can/= should mandate this future going forward in SRP?

    -= -
    Jonathan Hui

    --00000000000038f65305b6def0ac-- From nobody Sat Dec 19 23:38:30 2020 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 7C90D3A0B1D for ; Sat, 19 Dec 2020 23:38:28 -0800 (PST) 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 VGvm_VkuRZiL for ; Sat, 19 Dec 2020 23:38:26 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 97BA93A0B16 for ; Sat, 19 Dec 2020 23:38:26 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id v126so1790401qkd.11 for ; Sat, 19 Dec 2020 23:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f6Rp5nyH1OzDVaDGy5rq5yJ+YWAUZEAGO310uRIpnG8=; b=aolkR+P1n2ZW2zLRrlfOK3KFjwFEZIbyqY/KuK+a0qmuWz/bbrwS+u+4MZmaUkpYtb DlXyQwa8BcfRXV9bndqju96Gx0ypJkL5gTSqD46+WqXcWan5ofzTSTp4UA58cle7+sP4 get4a3JQkW39WHLE/y4oTG79CoxqOvyQ9v6zyZ8Oay9Hrgo4/cuNyLds8vfP5Kf+85bg Ps8VJSRTHkWJVrRxhl17rqOqNMMPGZ4K8NxyLxhgfmVeegeWXdgoidOsFHKNEhPQWLDL l7UVELLHgD0tvRLGm5mCvQ/o7qiipO4o3Hn5iDTzSYDoxthkUPTiDTsGxNc2oKajrjD+ rf6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f6Rp5nyH1OzDVaDGy5rq5yJ+YWAUZEAGO310uRIpnG8=; b=Su3t7NXo7gbq2UX3RHxjyckfXqG4jhC2+JiPv3vKYDM3SwsEg6rCkL09WsHJNEyGts d2reSZOHNtypETCjZN2eXHxha/uTZ5vEizKGAR3+UNNYFrcgaXRmUoHIQLXGUqCnFnhU tPpWoX6eD7D8NZUpCaYJOSFO8cMRYOtQ7uH1QYjxECDHfjGNSqHVw1NBlJS3sIjQG/9/ E0HKciS62cM4wtGBsxPPRtVcTKjz/DjkI3GG5VtPyy4d2ZQ3wCetAJuT93w9AjKdeTPZ z0KHj2s9AwG71Sav1Jx2gNyYoH6PGtl3IvjJkqYG+KDMz5mjm2JFkpmPBD0v7J2MFGtI iezg== X-Gm-Message-State: AOAM533bQ7YyxaqzSD1MzSO1JygmcA0MUMiOo43+CdjfY2wLrsqxSCve TvzlX/OjsyufLyQfDDm65SPmdPYm2vPj8MRcSRA0nw== X-Google-Smtp-Source: ABdhPJyF+XB0yf7pZIiXLaVX+oiH4O3RIouLcnTP9QscFC0MokOyknWSZqXCfJeLlVn0AhzEdobl6ItRdRD6zIwpvm8= X-Received: by 2002:a37:4709:: with SMTP id u9mr4589269qka.70.1608449905205; Sat, 19 Dec 2020 23:38:25 -0800 (PST) MIME-Version: 1.0 References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> In-Reply-To: From: Abtin Keshavarzian Date: Sat, 19 Dec 2020 23:38:14 -0800 Message-ID: To: Kangping Dong Cc: Jonathan Hui , Ted Lemon , DNSSD , Rongli Sun Content-Type: multipart/alternative; boundary="0000000000003d938a05b6e06d18" Archived-At: Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06) 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: Sun, 20 Dec 2020 07:38:29 -0000 --0000000000003d938a05b6e06d18 Content-Type: text/plain; charset="UTF-8" Actually, on second thought, maybe the right thing to do is check for the > KEY RR and not the SRV RR. If the key matches, the delete is okay. If there > are no records on the name, the delete is okay. Thanks Ted. I agree. This sounds good (and simpler). On Sat, Dec 19, 2020 at 9:51 PM Kangping Dong wrote: > RFC 6763 Section 6.8 Service Instances with MultipleTXT Records >> discusses this. >> However, the end of the referenced section also states: >> >> Future protocol designs should not follow this bad >> example by mimicking this inadequacy of the LPR printing protocol. >> >> Thanks Jonathan, I missed that section. > > So I guess the question is whether we can/should mandate this future going >> forward in SRP? >> > Exactly. I would prefer we explicitly disallow multiple TXT records for > SRP. > > BRs, > Kangping > > On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui wrote: > >> >> On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong wrote: >> >>> >>> 2. What's the use case of supporting multiple TXT RRs? >>> in section *2.3.1.2. Service Description Instruction >>> *, >>> we have: >>> >>>> zero or more "Add to an RRset" TXT RRs, >>>> >>> >>> Are there real use cases that we need more than one TXT RRs? What is the >>> expected behavior >>> for the advertising proxy to publish this service with multiple TXT RRs? >>> (I think DNS-SD requires >>> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated >>> to form a new TXT RR? >>> If there is no such use case, should we require a single TXT RR? It will >>> be easier to implement on both >>> client and server side and consistent with DNS-SD. thoughts? >>> >> >> RFC 6763 Section 6.8 Service Instances with MultipleTXT Records >> discusses this. >> However, the end of the referenced section also states: >> >> Future protocol designs should not follow this bad >> example by mimicking this inadequacy of the LPR printing protocol. >> >> So I guess the question is whether we can/should mandate this future >> going forward in SRP? >> >> -- >> Jonathan Hui >> >> --0000000000003d938a05b6e06d18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    Ac= tually, on second thought, maybe the right thing to do is check for the KEY= RR and not the SRV RR. If the key matches, the delete is okay. If there ar= e no records on the name, the delete is okay.

    <= /div>
    Thanks Ted. I agree. This sounds good (and simpler).

    On Sat, Dec 19, 2020 at 9:51 PM Kangping Dong <wgtdkp@google.com> wrote:
    RFC 6763 Section 6.8 Service Insta= nces with MultipleTXT Records=C2=A0discusses this. However, the end of = the referenced section also states:

    =C2=A0 =C2=A0Future protocol designs should not follow this bad<= /font>
    =C2=A0 =C2=A0example by mimicking this= inadequacy of the LPR printing protocol.

    Thanks Jonathan, I missed that section.=C2=A0

    So I guess the question=C2= =A0is whether we can/should mandate this future going forward in SRP?
    Exactly. I would prefer we explicitly disallow multiple TXT= records for SRP.=C2=A0

    BRs,
    Kangping

    On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui <jonhui@google.com> wrote:
    =

    =
    On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong <wgtdkp@google.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

    =
    2. What's the use case of supporting multiple TXT RRs?
    =
    zero or more "Add to an RRset" T= XT RRs,
    =C2=A0
    Are there real use cases that= we need more than one TXT RRs? What is the expected behavior
    for= the advertising proxy to publish this service with multiple TXT RRs? (I th= ink DNS-SD requires
    a single TXT RR, is it correct?) Should multi= ple TXT RRs be concatenated to form a new TXT RR?
    If there is no = such use case, should we require a single TXT RR? It will be easier to impl= ement on both
    client and server side and consistent with DNS-SD. = thoughts?

    RFC 6763 Section 6= .8 Service Instances with MultipleTXT Records=C2=A0discusses this. Howe= ver, the end of the referenced section also states:

    =C2=A0 =C2=A0Future protocol designs should not = follow this bad
    =C2=A0 =C2=A0example b= y mimicking this inadequacy of the LPR printing protocol.

    So I guess the question=C2=A0is whether we can/should mandate this= future going forward in SRP?

    --
    Jonatha= n Hui

    --0000000000003d938a05b6e06d18--